Freshly Squeezed Progress Report: Refreshing the Project Plan

Welcome to the first Freshly Squeezed Progress Report of 2024!

In my last report of the 2023, I was ending a bout with COVID, I had finished some tasks to make the intro sequence more interactive, then found a need to do an assessment of my project’s needs in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

Since then, I’ve focused mainly on creating a fresh backlog of tasks for the project.

Due to the fact that I was still recovering from COVID, I didn’t make a plan for the week after my last report, and I felt like I ended the year quite poorly. You can read more in my review of 2023 and preview of 2024 post, Planning 2024: Building on the Successes of 2023

I did, however, spend some time optimizing the dungeon rendering code, mainly by removing some text logging. I’m not sure how much faster I can make the inner loops of my raycasting code, but once the logging was removed, the game ran so much smoother on both my relatively underpowered laptop and my phone.

That logging helped me debug the code as I was developing it, and while I had turned off outputting the actual logs, the act of creating the logs was still slowing things down significantly.

The next bit of optimization was to only calculate what to render when needed. That is, calculating raycasting for the floor, ceiling, and walls, plus objects such as doors, is expensive, but if the player is idle, there is no need to do all those calculations each frame. This isn’t an action FPS, after all.

So now the dungeon view only re-calculates when the player is actively moving or performing actions, and otherwise it just re-renders what it figured out the last time.

My laptop fan used to whir loudly when I was in the dungeon even if I was standing still, but now I can leave the game idle for quite a long time without any noticeable battery usage or CPU usage.

Now, while I can’t see obvious ways to optimize the rendering code that calculates what sprites to create and/or render, I think I can still improve how it stores what to render. For instance, while the floor ends up becoming a single texture that gets blitted at once, I believe the walls and objects are still a collection of single-pixel wide columns, and if I similarly turned those into a single texture, then when the game is idle it can do three draws (ceiling, floor, and walls) rather than 2 + however many columns wide the dungeon view is. And in fact, why not just create one sprite rather than three while I’m at it?

Anyway, after I spent my first week of the year making plans for the coming year, I looked at my game’s backlog and found myself still unhappy with it. Some of it was created at the beginning of the project, and they seemed to prematurely assume certain mechanics and content that I have since decided I don’t want to put in the game.

So I created a new tab in my project plan’s spreadsheet to create a new backlog from scratch.

Since this game project is already over a year old and I want to ship it sooner rather than later, another benefit to redoing my backlog is that I can focus on trying to limit new features while also honing in on game content and game play more than infrastructure code.

As I said in my last report, “But after a year, I think I need to do an assessment of what features and capabilities I still need as well as what the game content will need to be. Too much is still too vague, and I really expected that more would be defined and playable by now when I first started. ”

I have since come up with almost 40 tasks. I know this isn’t a comprehensive list. It’s impossible to anticipate everything, at least in a reasonable amount of effort and time. Plus, in the past, I have found that implementing one feature sometimes reveals the need for more player feedback or other supporting features that I might not anticipate until I have played through the game or had a playtester tell me when they got confused or lost.

But I also know that there is still more to work on that I haven’t specified, especially since many of the tasks I did identify are still capability-related: features I implement that allow me to develop game play around them later.

For example, “Render animated dungeon textures” eventually will allow me to show water flowing on the floor or spilling from the walls. “Update which texture should be shown in dungeon cells” is about allowing me to change a texture based on the state of the game, so if I have a tunnel with no water, but later I want that tunnel to feature flowing water, this feature lets me do it.

But what isn’t quite captured thoroughly yet is that kind of game content. I don’t have tasks for creating those tunnels, or for creating the player’s ability to flood a tunnel with water by turning on pumps or opening gates.

I do have some tasks for finishing out the intro sequence, which involves illuminating a too-dark passage and using teamwork to remove a heavy beam from in front of a door you immediately discover. But I need to get concrete and specific about the rest of the actual dungeon contents.

Which brings me to the other part of my work this past week: worldbuilding.

About this time last year, I had ideas and even mapped out a rough idea of the “first” level (which I have since decided will be the only level for this game’s first release). I also had ideas for interactions with entities you discover in the dungeon.

But even today, none of it was very real. It was on paper, it was in my head, but it wasn’t detailed enough to actually implement yet.

So I spent time mentally walking through what the player could do after the intro sequence completes. What happens when the player opens that barred door and finds themselves in the rest of the dungeon? Where can they go? What can they do? Who can they meet?

And then I tried to figure out how to ensure I need to implement the minimum number of new features.

I had envisioned a platform in which you can look down into a reservoir or a sewer tunnel, but with my custom raytracing code, I would need to implement a way to render floors differently based on height. It is probably easy and quick to do, but what if I just don’t do it at all? That’s even faster.

So my workaround is to allow access to reservoirs and sewer tunnels by way of hatches and ladders. That I can do with my existing features.

I have a rough idea for one particular character, and I hope to identify even more in the coming weeks. And since conversation is supposed to be such a key part of the game, I really want to continue working on the dialogue system.

But I need to capture these game content and game play tasks in my plan. I’m worried that if I only average a little over 7 hours a week like I did last year that it means I’ve already identified too much work to get done by the end of June. And that’s probably fine, it could be a little late. But I really don’t want to discover too late that this game requires another calendar year of development, so I’m hoping I can get as much of the known tasks in front of me so I can figure out how to prioritize them and how to scale them down. I’ve already decided that instead of having a special notification for some events that instead I could use the existing script/dialogue code to present information to the player, for instance.

Here’s to 2024! 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!