I ended up spending about half of May visiting family, since I finally got vaccinated, so I don’t have a ton of new progress to share right now – but I do have a number of new ideas, and there’s plenty to talk about that I didn’t get to in the last DevBlog.
Right before I left, I took a dive into completely reworking the map editor… again. This was a fairly successful redesign, and I was able to fix most of the bugs during the trip – enough of them, anyway, to make building levels possible. What I eventually realized with the map editor is that I’d made a huge mistake in how I’d engineered it: I was duplicating data. I don’t know if this is considered classically bad programming practice – I have heard many many injunctions against reproducing code, but relatively few against redundant information. In my experience, many bugs seem to emerge from conceptual ambiguity over which part of the code is meant to “own” data and which are meant to request it: When that flow is confused it can be easy to end up splitting up the relevant information between different parts of the program, making it almost impossible to keep track of what the data is supposed to be. This is all a bit vague, and I may go into more detail in a future programming essay, but the upshot in this case is that information about the size and shape of each room on the map existed in two places: In the visible tiles on the map and within the rooms themselves – actually, technically, it existed in three places, since in addition to the rendered tiles the world map also held a grid describing what those tiles were supposed to be. Part of the reason why this part of the project went so far out of control was just because every change I made had to be synced between these different components, and each individual necessary change became easy to overlook – effectively multiplying the work I had to do several-fold and making it much easier to make stupid mistakes. Having realized this structural issue, I completely overhauled the whole setup, deleting a significant portion of the code I’d created, to create a system with a clear and stable relationship: The role of the map was just to be a tool to conveniently display rooms and provide tools to create, delete, and resize those rooms. With this in mind, it becomes much easier to understand what needs to be done at what step, what part of the program holds responsibilities and data and what part is tasked with merely accessing and presenting that data. There are still a few improvements to make – the map doesn’t always display the tiles it’s supposed to, and some of the auto-generated placeholder rooms are slightly erroneous – but, because the important data is now that which is contained within the rooms themselves, I can just manually modify those rooms as needed to accomplish whatever I’m trying to do in the moment. When I find the time and motivation to revisit the map editor, I can fix those few remaining issues.
That accomplished, it was time to start building the levels in earnest. This turned out to be a bit more artistically challenging than I’d expected: Part of why I chose this extremely simple art style was to make it faster and simpler to generate assets – which has indeed been the case – but sometimes it still takes a while to figure out the visual language of an area. The first section of the game, immediately after the player leaves the starting room, are the city streets. Right away I ran into an art problem: This game is a 2d platformer, but a street is by definition something which is long and more or less flat. While the world the game takes place in is not in a great state, I didn’t want to break the terrain apart like there had been an earthquake, so I had to consider how to make the streets feel fairly grounded and realistic while still interesting to play. The first thing I realized is that this visual language immediately began to make more sense if I made the ground level represented by the center of the street rather than the sidewalks – though I am of course more accustomed to walking on sidewalks, centering the action on the street meant that it felt intuitive to have parked vehicles block the player’s path rather than merely being background or foreground elements. I also looked at how a number of other 2d platformers had solved this issue, and pulled a few choice ideas I noticed – vents, balconies, and awnings could all add vertical variation to the flow of the streets. Finally, I also created a wooded park section to break up the urban area, which changes the feel of the area as a whole and makes it all feel less repetitive.
Building the levels themselves, though, is going quite a bit slower than I’d expected. After quickly slapping together a fairly enjoyable demo level I thought “well, that went very smoothly, I can just assume most level development will go about the same way.” It turns out, however, that there’s a big difference between throwing together a small and abstract environment where you can test out a few enemies and player abilities and creating a realistic slice of world which is still composed to allow meaningful gameplay. The level of attention and detail required for even relatively small and straightforward areas can be significantly greater, and I frequently need to stop developing an area to create new tiles to fill it out and add details.
Because this month was so busy, I’m still quite a ways away from building that full-featured vertical slice of the experience I was talking about last week – but I’m not as far away as I was worried I would be! The general room layout of the first section of the game is done, and going through and adding details to each room is a lengthy but enjoyable process which I’m comfortably pushing forward on a bit at a time every day – perhaps not as quickly as I’d wish, but steadily. Some additional programming work will need to be done to set up some special interactions and a multi-layered map system (something which I added some framework code for while working on the map editor but didn’t wholly implement) – this sounds very sophisticated and impressive, but in this case it just means the world will have some doors in the background which you can enter to go into a back room. Mostly the remaining work for this section is just building more rooms, along with a couple of enemies and a boss fight.
While I was traveling, though, I had a lot of time to think about what the total scope of the game is and what I’m trying to convey with the experience, as well as fleshing out some ideas that had been rattling around in the back of my head. Surprisingly, these ideas didn’t balloon the project out of control, as I’d been concerned they might – the scope of the project increased somewhat, but not drastically, and I have a pretty good idea of the total arc of it now so it’s unlikely to expand much further. All of my games end up somewhat themed around death for some reason, except in this case where the game is really really themed around death – around all existence and personal experience, all possibility and memory, converging to a single point like the tip of a needle. There’s other elements I can pick out, absurdity and greed and self-image, but death is what the story is about. Still, there’s no reason to make it bleak or dreary! I hope to include plenty of humor with the sorrow, and plenty of inspiration with the existential horror.