This past week I continued working on the dungeon representation.
Sprint 9: Pre-production and initialization
Planned and incomplete:
- Move player in dungeon view
I was out of town and visiting with family, so I did not put in as much time as I could have, which meant not getting as much done as I was hoping to by the end of the week.
To create a simple dungeon map, I needed to finish creating the data structures to represent the dungeon. This work was the easy part.
I had a grid-based dungeon, so naturally grid cells would be the basic building block.
If I wanted to keep things simple, I could have had each cell represent either an empty block of hallway or a solid block of wall. Zero or one, and I’d be done. Maybe use different numbers to represent different types of walls or hallways.
But I wanted more flexibility. Each grid cell is made up of four walls, a ceiling, and a floor.
So instead of drawing the outside of a grid cell in the simple version, I would need to draw the insides of the grid cell.
I anticipate needing a companion tool to create the dungeon layout as this game develops, perhaps using something like Tiled, but for now, I just need to give myself a simple dungeon, so I hardcoded one.
Old games used 2D trying to simulate 3D because 3D wasn’t viable on the older computing power they were using. Today, the advice to make similar games is to use a 3D engine and try to replicate the 2D feel.
And this past week, I started to really get as sense of why that contemporary advice exists. Just to have a single dirt tile for the floor, I determined that there is no way to get around needing to create that same tile from different perspectives.
In this screenshot of my art mock-up in GIMP, the yellow dotted square can represent the player’s viewport. To create the left side floor tile, I had to extend the dimensions of the canvas left and right. Then, just to see how far it goes back to the horizon, I kept shrinking the new side tile by about two-thirds. There is a back wall that I placed as a representative for the player’s maximum visibility.
Many 1st person games show a dark dungeon with visibility extending only a few tiles ahead, which gives a great atmosphere but also has the practical benefit of limiting how much art needs to be created to represent it.
For me, I think I determined that I can scale the art in code and get the same effect, so I only need to draw the tiles that are in the nearest row. No need to create separate tiles farther away, because scaling will handle it for me.
But because I want areas of my game that might be well-lit and provide greater visibility, I need to create a lot more tiles that are seen from the side than I would if I followed the tradition, mainly because those tiles could be seen in the distance. So instead of maybe one or two tiles to the sides, it looks like I’ll need to create quite a few more.
And that’s just one tile! To break up the monotony, I will also want to create variations on that tile.
And I would still need the ceilings and the side-views of walls. Perhaps I can simplify the art needs by creating modular aspects of the floor, ceilings, and walls, so I can have one generic piece of art that gets covered by brick outlines, chunks of rock, smears of dirt, etc in different locations to give the appearance of a variety of art.
But I will work incrementally, and so for now I just want to render floor tiles. One tricky thing I needed to figure out was to figure out exactly which cells are being rendered in the first place. The player can be in an arbitrary location in the dungeon, and so “forward” is relative to the player’s orientation.
Basically, I would need to figure out which cells to render and where on the screen. A cell to the left of the player would need to render tiles that are in the correct perspective, which means knowing what perspective that cell should be in. Turning around would show that same tile in a different perspective, or not at all.
Again, 3D engines have solved these problems so that they are a non-issue, so why am I doing it this more difficult way?
Because I’m stubborn, maybe. I wanted to try it, and now I’m in the middle of it.
I know 3D would make a lot of this work easier, but switching to 3D would mean needing to switch to an existing game engine, something I’m not ready to do because then it means abandoning my many years of code that I’ve built up. Maybe I’ll think about it if I am still trying to figure this dungeon rendering effort weeks from now.
But it’s fun to figure things out, and that’s part of the reason why I like doing it the hard way.
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!