In last week’s report, I showed off some progress I made in rendering the walls of the sample dungeon I created.
I managed to fix a few issues and then produce something that looks fairly decent.
Sprint 13: Pre-production and initialization
Planned and incomplete:
- Move player in dungeon view
I realized that I had a mistake in my code that used the wrong value, which was creating the weird effects I was seeing.
And suddenly, I had reasonable-looking walls!
Now, strangely some of the walls were still popping out of the view area, and there was that weird gap on the right side.
Addressing the issue of rendering outside of the view area required that I add a few lines of code to determine not only if the lines should be clipped to the top and bottom of the view area, but also determining what part of the texture I needed to draw. That is, if the top was clipped, then I would need to start drawing from the top of the view area using the correct part of the texture as the start of the line. Otherwise, it would look off.
I fixed the red gap when I discovered that I was figuring out where to draw each column using the textureWidth variable instead of the width of the target area.
The next big issue was that it still felt like you had your face to the wall. I wanted to set the player’s view back a bit so they could see a bit of the floor and ceiling.
The nice thing was that my code was already differentiating between the player’s party’s position and the start of the rays that are cast to find the walls. Still, I needed to make what feels like a few hacks to get things rendering properly.
Basically, I needed to set the player’s view back by a certain amount. I chose to move the player’s view backwards 0.75 units.
The problem is that the ray was already being offset from the player’s position (0.5, 0.5) to center them in a grid cell, and moving another 0.75 back moves the ray’s start into a different cell.
So I when it came to stopping the ray, I had to ignore any wall encountered in the first step to the next grid line, because otherwise the wall from the cell behind the player would fill the view area.
I also had to add something to limit the number of times it would try to find a wall. Anytime I exited the play area, it would lock everything up as it stepped forever toward walls that didn’t exist.
Weirdly, if the limit was what I thought a reasonable amount, then I would see artifacts, especially when turning.
Oh, that’s right. I added animation. Now when the player steps forward to turns to the side, I interpolate from the original position/orientation to the target one.
Anyway, turning would produce walls that looked like they were protruding out, so I had to create a relatively large maximum limit of grid cell stepping. Unfortunately, if you ever do step outside of the boundaries of the dungeon somehow, it slows the game down to a crawl, and that’s on my main development machine which is relatively powerful.
So that just makes it all the more important to ensure that the player can’t ever see outside of the defined boundaries of the dungeon.
By the end of the week, I had walls that looked pretty decent and animation that looks pretty decent.
I still need to add floors and ceilings, which I expect will be relatively quick, although it might require using a slightly different technique compared to rendering walls. With the walls, I can draw a rectangle using part of an image as a source. With the floor, I might need to go pixel by pixel horizontally as I determine which part of the source image needs to be rendered at each area of the screen.
For now, though, it’s nice to be able to navigate my test dungeon, complete with animation.
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!