Freshly Squeezed Progress Report: Raycasting, Vector Math, and Distractions

In last week’s report, I started work on figuring out how to implement a simple raycasting engine for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I tried to continue the work this past week.

Sprint 11: Pre-production and initialization

Planned and incomplete:

• Move player in dungeon view

The short version is that I once again spent much less time on game development than I would have liked and so no, it isn’t finished yet.

The long version is that I was unable to dedicate time to game development partly because my family needed to spend time on figuring out how to protect our trans daughter from Iowa Republicans who recently passed bills and got them signed into law that prevents her from getting the care she needs in our state.

Besides those pains, I’ve also been dealing with literal pain in my back and my leg that has made it difficult to do much of anything, including sleep.

Meanwhile, any effort I was able to expend was spent on trying to understand the example implementations of raycasting that I’ve found so I can create my own implementation.

Most examples you find are either academic in nature, and so bizarrely all of them tend to have terribly short, non-descriptive variable names and other issues, or they are written by someone who is mainly focused on explaining the concept and so isn’t trying to setup the code’s design for anything more robust.

So while I could just copy the code and see if it works, and then adjust accordingly, I prefer to make sure that I understand what I’m trying to do. Sometimes I can replace a data structure with another. For instance, I have a Point class that is basically meant to be an position represented by X, Y, and Z values, so there’s no reason to have separate floating point values for X and Y like in many examples because I could always use a Point.

Or rather than make a very long function with a bunch of random variables everywhere, I can isolate some of the calculations into functions.

And rather than assume that I’ll be rendering from the point of view of the player’s party, I could instead make it render from the point of view of an arbitrary location, which leaves the possibility of scripting scenes or following a different character or object.

But frankly, the lion’s share was finding out that I was setting up some camera vectors incorrectly, and so while I expected the rays would always hit a wall, somehow it was escaping out of the defined dungeon grid cells and and so my code was entering an infinite loop as a given ray was not able to hit a wall at all.

I stopped the infinite loop by ensuring that a request for a grid cell that wasn’t defined returned something that indicated its walls were considered “out of bounds” instead of no walls, so the rays would hit something, even if I don’t intend to render “out of bounds” walls.

But I was still figuring out why some of my rays were hitting the “out of bounds” walls instead of my actual walls when I got to the end of the week. At least I can say that half of them seem to hit actual walls, although I haven’t looked to see if those walls seem sensible.

I really hope I can make the time to get this work finished enough to render the walls. I can’t wait to maneuver through my dungeon.

And I really hope that my daughter can grow up and live a long and happy life.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!