So recently, I've been stuck on a problem dealing with Raycasting... There were specifics about my situation which meant I could not use the methods described by Amit over at [Red Blob Games](https://www.redblobgames.com/articles/visibility/). But I do believe I've managed to come up with something quite extraordinary...

So recently, I've been stuck on a problem dealing with Raycasting... There were specifics about my situation which meant I could not use the methods described by Amit over at Red Blob Games. But I do believe I've managed to come up with something quite extraordinary...

- Describe the situation So every game needs an accurate way of detecting collisions, between any two bodies which are considered "solid". In my game, I wanted to implement some form of visibility. This meant coming across Amit's article (and definitely not for the first time) which was clearly the easiest, and probably the only way of getting visibility into my game. However, before going balls to the walls with trying to implement such a complex problem, I decided to use Raycasting for collision detection first. And so that's what I did.

My game is a 2D birds-eye view of a world, where the character is central to the screen and can move in all directions, on both axes. The quirk about my game though, is that it is infinite in size! Yes. An ever-expanding map which can go both directions on both axes.

What Amit described was purely a solution to the visibility problem. There was no way that I could use the solution he's identified to my collision detection problem, let alone my over-arching Raycasting problem. So I did some more research... This led me to Lode V's webpage where he describes how games such as *Wolfenstein* and *Doom* managed to create a 3D world. Now, as soon as I read this article I instantly realised that those games were Psuedo-3D. They're actually 2D where the camera can rotate around in that 2D space. But I digress...

This article helped me immensely. Mainly because of the method I had to use. I had to actually find the intersections between each tile. I had to stop at each tile determine if it was solid, and then continue. This had to be done along the ray's path, however.

So I came up with a quick and dirty way to do just that! And boy it didn't work. I should've documented the process, to explain the problems I encountered and how I fixed them. But that would, honestly, expand the size of this post by 5-fold, because I rewrote that abomination too many times! Being realistic though, all the issues I ran into were mathematical problems which I had to solve or were my own stupid mistakes. Nonetheless, the solution was found.

Ultimately, I used my good old friend Mathematics to complete the solution. What I ended up doing was finding the x and y-intercepts along the ray and determined which intercept was closest to the origin, and then tested whether it was a collision. I have two resources which I'd like to share which show these.

The first is a Desmos Graph, which allows you to test a ray and find the intersections. The only issue with using a cartesian graph, however, is that it's y-axis is mirrored to that of a game. Nonetheless, the principle maths behind it remains the same.

Oh, and also! Here's a link to the Gist which holds the classes required for this method to work! https://gist.github.com/TheBrenny/98f8f27ad1bb53f4ee80179f43dbc64b

Got questions about programming, electronics, or life? Shoot an email!