Category: Game Design

In last week’s report, I talked about replanning the remainder of the project backlog for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

This past week, I started work on my first set of tasks for the new year.

Sprint 2024-1: Pre-production and initialization

Planned and incomplete:

• Render dungeon based on light levels

I took a family trip earlier in the week, but even so, I managed to get quite a bit done when it comes to handling lighting in the dungeon.

I envisioned having light sources that spread light to adjacent cells, with the brightness lowering as it goes, similar to the lighting in Minecraft. I also wanted certain dungeon environments to have an ambient light, so there is no actual light source, and those cells are just by default lit by a certain amount.

Now, that still leaves the question of how to actually represent and implement lighting in the dungeon.

Since the dungeon is represented as a collection of dungeon cells, I decided to create an associated collection of dungeon light levels.

So for a given cell at a particular location, there would be a dungeon light level at that location.

The dungeon light level is represented as a color and a value that indicates how bright the light would be.

0 would be pitch black, and 10 would be full brightness.

By default, the dungeon light levels would be whatever the ambient levels are for those corresponding cells.

Then for each light source, the light would spread while attenuating.

After manually trying a few approaches on paper, I hit upon a way to handle the light propagation and attenuation, and I wrote out my attempted algorithm before writing any code for it.

And then, since I knew this code could get complicated as I was figuring out edge conditions, I test-drove it.

And I was immediately glad I did. I could very easily have written code that I thought should work but that wouldn’t have done what I wanted. To date, I wrote seven unit tests for this lighting code, with each one either adding functionality or confirming that certain functionality would work in certain cases, such as dealing with closed vs open doors.

I added some logs and I modified the code to ensure that it didn’t process dungeon cells that it didn’t need to, which saves on processing time. This kind of optimization wasn’t captured in my unit tests, but the tests did verify that the end result was correct even with fewer cells getting processed.

While I am confident that this code is fairly efficient, I also know that I don’t need to call it frequently. Unlike an action game, which might need to update lighting in real-time, this game only needs to update the lighting data when something actually changes, such as when the player enters the dungeon, toggles a light switch, or opens or closes a door or otherwise changes an obstacle that blocks light.

By the end of the week, I was confident that the lighting system worked, so the only thing left was to make use of it when rendering the dungeon.

The dungeon walls and “things” such as doorways and ladders were fairly straightforward to update. Basically, for each column for my raycasting code, it would draw part of a texture and tint it by that cell’s color and brightness setting.

And it looks more or less fine (if a bit dark in this room). Currently I treat the brightness value as multiples of 10%, but perhaps 10% drops in brightness are too drastic, especially going from 10% brightness to 0%. Maybe instead of linear drops in brightness it should be a different curve, but perhaps brightness levels should be multiples of 5% and so the brightness level should go from 0 to 20. I’ll toy with it to see what might look good.

But first, I still need to tackle the ceiling and floors, which handle rendering a bit differently.

While the walls draw columns of textures and can be tinted, the ceilings and floors draw individual pixels of textures, each of which represents the actual pixel color from the source texture as a Uint32 value.

Now, when I usually deal with color, I am dealing with RGBA values, with each of R, G, B, and A being a value from 0 to 255, or even using hexadecimal values if I want to match what I might see in HTML color codes. So 0xff would be equivalent to 255.

Drawing walls, the only color I deal with is my tint value, which is the dungeon light level’s color multiplied by its brightness percentage.

But drawing the ceiling, I need to directly modify the color value of the pixel in question, and I am still figuring out exactly how. The Uint32 value should correspond to RGBA-like values, and in this case, I believe it is ABGR8888 in SDL2’s representation.

But I ran out of time before I figured out if merely bit-shifting and using my tint value directly in a similar way that I do for walls will result in something that looks right.

So that’s the first task to tackle this coming week.

Although I am also curious what is up with this doorway which is rendering at full brightness despite being in what should be a completely darkened room.

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!

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!

Here’s the companion video for Monday’s Freshly Squeezed Progress Report: More Interactivity in Intro Sequence:

Enjoy! And let me know what you think by replying below!

Merry Christmas!

This is my final Freshly Squeezed Progress Report of 2023. In my previous report, I finished animating transitions and started working on making the intro sequence more interactive in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I set out to finish the intro work.

Sprint 49: Pre-production and initialization

Planned and complete:

• Redo intro to be more interactive

As Christmas was nearing, it also meant that I was going to have days off from the day job. While I imagined much of my time would be spent preparing for the holidays, especially with travel to visit family in Chicago, I was hoping I would also be able to squeeze in a bit of game development before the end of 2023.

Unfortunately, for the first time, I tested positive for COVID-19, which threw our plans out the window.

I wasn’t feeling well partway through the week, so I decided to test myself, got a very bright, very positive result, and immediately masked up and isolated from the family. Luckily they have tested negative, and we are privileged to have a spacious enough house that I can isolate from them.

I finished my last day of the year for the day job (I work remotely), but it was a struggle, and I needed a couple of uncharacteristic naps. I have since had fevers, a weird dry cough, spells of feeling tired, a stuffy head feeling, and having runny or stuffy nose at different times. It could be worse, but being sick on your vacation time and especially around the holidays sucks either way.

All that’s to say you should get vaccinated, mask up, and stay safe this holiday season.

As for what I was able to accomplish in game development, I would characterize it as iteratively polishing the intro.

Since the intro is now more interactive instead of just a long sequence of scripts, I needed to make sure that similar flags and triggers get set at the correct moments.

For instance, after the initiation ceremony for the new member, there needs to be a way to ensure the player goes on what I’m calling the Snack Quest. Basically, the new member suggests that they are hungry, and so a quest for snacks from the kitchen is proposed.

There are now multiple ways it can be started.

One, the original trigger than prevented the player from leaving until the ceremony is started is replaced with a trigger than prevents the player from leaving until the Snack Quest is introduced, and then starts the scripted sequence that does introduce it.

Two, if instead the player talks to the new member about the club, the same scripted sequence can occur.

And of course, once the sequence occurs, it shouldn’t happen again, so I had to make sure these sequences also include instructions/commands for changing flags and triggers to do so.

A trigger for preventing the player from leaving the bedroom can set the current script to the introduction of the Snack Quest, and the script sequence itself eventually disables that trigger, sets a new trigger for entering the kitchen, and updates the new member’s beliefs about the Explorer’s Club so that if you were to ask that character again, the response would be different.

I am very quickly realizing that between triggers, flags, and script IDs, I had a number of similar-sounding names that were making things confusing on top of the fact that it was hard to visualize how they all interacted with each other.

There’s a lot of moving parts, and the game has hardly any content in it as it is! I definitely need a better way to plan, manage, and understand it than digging through my code and hoping I didn’t miss anything.

Working through this intro sequence is a bit frustrating because I am finding that there are some fundamental things I can’t do with my existing implementation. For instance, when you are in the basement, part of the interactive intro now requires the player to search for the pickles in the basement for the Snack Quest.

In my head, what happens is that the player knocks over the broom, which hits a secret brick, which opens a secret door.

In-game, for now, I still need a way to make that happen. The broom is currently just part of the background image of the main basement room. I need the broom to be a separate object, to have it animate, to have the brick in the wall be a separate object to animate, and to have the secret door appear after all of that.

So, nothing technically challenging, but it isn’t something I can just do. I need to actually have the broom be something represented in the code and as data, as well define how it gets interacted with, and how it is represented to the player.

Once I do this kind of work, however, similar things in the game could much more quickly be thrown in.

Another example is in the dungeon. Right now, all dungeon doors can just be opened or closed by the player. While I anticipated locked doors when I created them, there is no locking mechanism implemented yet.

But now I want not only a locked door but also a locked door that needs something special to open it.

Beyond just capabilities, here’s the actual game play I want to see: when the player enters the dungeon for the first time, it should be exciting to return and tell the rest of the Explorer’s Club about the discovery. But what if the player doesn’t?

Well, there should be a good reason to go back anyway. Or two.

One is to require the use of an item. So if the dungeon is too dark, then a flashlight sounds like a good thing to go back and get.

What if the player already acquired the flashlight by rummaging around earlier? Well, that’s fine. Always be prepared, right?

The second reason to go back is because in order to open this door, the door bar needs to be moved, and it is too heavy to do alone. Moving it requires a full party. So if the player ran out of the bedroom without party members, then they need to go back.

What if the player got the flashlight AND also formed a party for the Snack Quest and so already has a party? Then full-steam ahead! That’s a good chunk of the Explorer’s Club doing some exploring, and they can always tell everyone else when they get back and might even have more to share when they do.

The dark dungeon and this door barrier ensures that the player knows how to talk to people, how to search and acquire items, and how to form a party. Sounds like a good intro sequence that onboards the player to figuring out how to play the game so far.

BUT, right now, I don’t have a concept of lighting in the dungeon, nor do I have doors with bars on them. Those need to implemented.

So updating this intro sequence is frustrating because I keep finding features and capabilities that I don’t have yet despite having worked on this project for the last year, but it is also helping me to identify what to work on next.

When I set out, I didn’t mean to spend a year in pre-production, but I really need to start making this game into a game that can be played, which means leveraging what has come before to actually create game play. My dungeon will turn from being a test case to being a place to actually explore, and as ideas and characters and situations get more concrete, I will need to revisit or create the code and data and art that I need to make it possible.

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.

But I’ll write more about it later.

For now, I hope you have a safe and merry holiday season!

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!

Here’s the companion video for Monday’s Freshly Squeezed Progress Report: Putting Some Bounce in Your Step:

Enjoy! And let me know what you think by replying below!

Last week, I reported that I added animated transitions when navigating through the rooms of the house in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I had some finishing touches on those transitions, then I could work on creating more actual content for the game.

Sprint 48: Pre-production and initialization

Planned and complete:

• Move between rooms of house by doorways/stairwells

Unplanned and incomplete:

• Redo intro to be more interactive

As I last reported, at the end of the previous week, transitions between rooms looked like this:

But halfway through last week, I added some character movement:

And then with a little more work that same day, the walking animation now looks like this:

Seriously, that’s adorable, right?

I’m actually impressed with how great it feels even though it is slower. In order to sell the bouncing movement and have it read well, I had to double time pre- and post- transition walking animations, yet it isn’t noticeable that the total transition time has increased from 1 second to 1.5 seconds.

Redoing the intro

So, my rough plan was to finish the transitions animations and then immediately set to work on the dungeon.

But I remembered that I hated the intro sequence I had created.

It was basically one long, unskippable cutscene, and I wanted something better.

So I set out to make my intro much more interactive.

I broke up the long intro into smaller pieces, so there is now only a few pieces of dialogue to introduce the main character, the Explorer’s Club, and setting the tone “We have an Explorer’s Club, but we live in a boring town, so we’re not really explorers, but we’re inducting a new member today!” , and then you can do whatever you want.

Well, within limits. To keep the player focused, the entire game at this point is purposefully isolated to the bedroom where the Explorer’s Club is having its meeting. While I could allow the player free movement, at this point, the Explorer’s Club meeting is going to be a bit of a tutorial to onboard new players into how to interact with the characters of the world.

So while I had a way to start scripts based on the player entering a room, I needed new code to prevent a player from leaving a room in the first place.

Instead of catching the end of the initiation ceremony, you can now start it.

To do so, I want the player to talk to the person who is joining, ask about the club, and have them say, “I am ready!” And then give the player the option to say “Hold on…” or “Let’s start the ceremony”.

And instead of pre-scripting the entire ceremony, I think it would be neat to have the player ask X questions of the initiate, and then end the ceremony after the last question is asked by doing a short pre-scripted sequence.

BUT despite many months of work I have done before, and the work I’ve done on asking questions and producing generated dialogue in particular, I didn’t have any code to support generating an arbitrary, pre-scripted response to a question you might ask. So I needed new code for that, too.

Well, I was delightfully surprised at how quickly I was able to add that code and see it working in-game.

Here’s the script that starts when the player tries to leave the room before they have initiated the new member ceremony:

And here’s part of the ceremony, in which the player asks the initiate some questions:

This dynamic quiz is hardcoded, but it makes use of various flags, commands, and code to track how many questions there are left. The player can ask in any order, and while it doesn’t matter yet, there could be other situations in which what was chosen and in what order might make an impactful difference on the player’s experience.

What’s left for the intro

Once the ceremony is over, which involves Pat reciting the Explorer’s Club oath, the mood should be anticlimactic. The Explorer’s Club isn’t actively doing any exploring or going on quests, after all.

Then I want the club members to propose a quest to get snacks, which involves the player going to the kitchen to meet their parents, who will still tell them to get pickles in the basement.

To make that part interactive as well, I will need to add some code that allows the player to click on items in the background, such as the shelving in the basement.

And only then will the secret basement door to the secret basement room will be revealed.

Revisiting the intro sequence to make it more engaging for the player has led me to add code to make things happen that I couldn’t do before, and at the start of the week I was worried that it was going to be a lot of work and that I was very far away from anything playable even after a year of working on this project.

But while it is true that there is quite a bit left to do, I am finding the work of adding the capabilities into the project aren’t as big of a lift as I was worried it was going to be.

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!

Here’s the companion video for Monday’s Freshly Squeezed Progress Report: Transitions and Dungeonbuilding:

Enjoy! And let me know what you think by replying below!

In last week’s report, I finished (for now) the background art updates for the house in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I set out to add some simple yet effective screen transitions before tackling the dungeon.

Sprint 47: Pre-production and initialization

Planned and incomplete:

• Move between rooms of house by doorways/stairwells

Most of my week was spent writing, between sending out my latest issue of the GBGames Curiosities Newsletter (sign up here: https://www.gbgames.com/get-the-gbgames-curiosities-newsletter/) and creating my 2023 Black Friday Creator Day post-mortem.

So I didn’t get as much time to work on game development, yet in my limited time I think I managed to make something impactful.

Up until now, navigation through the rooms of the house required exiting the room-specific view to see the whole-house view, then clicking on the room you want to go to.

I’ve been wanting to allow the player to click on doors and stairwells to navigate between the rooms of the house, eventually allowing the player to click on other things in any given room to investigate or find items or interact and oh geez I’m making a point-and-click adventure accidentally, aren’t I?

Actually, I’ve been aware that some of my house view screens have been leaning in that direction for some time, and I am just going to have to live with it.

Point-and-click adventures aren’t exactly my favorite type of game. Don’t get me wrong. I have fond memories of playing Maniac Mansion over and over, and I’ve played Sierra’s King’s Quest series at a friend’s house when I was younger, and I remember playing a few others with a different friend, such as the creepy Golden Gate.

So I like point-and-click games when I play them, but I find myself gravitating to strategy and simulation games if I have a choice.

But in practical terms, it means that once I realized that I had point-and-click aspects of my game, I didn’t know what the state of the art was.

But hopefully as the focus of this game will be the dungeon much more than the house, the point-and-click aspects will be relatively minimal, and I can do just enough to support what I need to do, such as allowing the player to scrounge for supplies in the various rooms.

Anyway, transition animations were a nice-to-have that just makes the game look and feel so much better, and between clicking to navigate and these transitions, it took only a few hours to implement.

It’s a little rough, but it’s nicer than instantly teleporting.

The only thing left was to add pre- and post- transition animations of the party members walking towards or away from the doors and stairs. I don’t want to create a walking animation, but as the house was inspired partly from a dollhouse vibe, I want the characters to “walk” in a manner that looks like someone is playing with dolls. Sorta like Monty Python stop motion characters.

In the meantime, I wanted to give some attention to the dungeon itself, and so I sketched a few thumbnails for ideas of different areas of the dungeon that the player might see.

Some of the areas are inspired by real-life sewers, fantastic anthropomorphic burrowing animal apartments, mysterious dirt tunnels, abandoned utility pipelines, and spy thriller ventilation systems.

These sketches helped me see areas that I had already made plans for with actual details, but it’s not an exhaustive set. I spent less than an hour on them, and I look forward to dedicating more time to filling in this world of the dungeon.

But it will definitely be much cooler in-game than merely sketched in these tiny windows.

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!

Here’s the companion video for Monday’s Freshly Squeezed Progress Report: House Background Art “Finished”:

Enjoy! And let me know what you think by replying below!

Last week, I reported that I was focused on other priorities and didn’t get too much done in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I set out to finish the background art this week.

Sprint 46: Pre-production and initialization

Planned and complete:

• Create location art

I didn’t spend as much time on game development as I wanted this week either, but it was definitely more substantial work.

I think the bathroom has become my favorite room, partly because I was getting the hang of using Gimp’s Perspective Tool to ensure the perspective of the art was more or less correct.

All that remained was the basement. I created a secret entryway from the main room, which leads to a secret second room with a ladder.

Now, you might have noticed that one image shows in-game footage and the other does not.

That’s because the doorway isn’t always present, and I still need to make the intro script and programming changes to allow the player to go from not knowing about the secret entrance to discovering the secret entrance.

Part of my work is turning that background image of a doorway into a separate set of sprites that I can overlay onto the actual background art.

Anyway, these rooms were the last things to do for this pass of the art work. I anticipate that I might want to change things or revisit, and there is always more I could do to improve the art, but let’s say that it is finished enough for now.

Meanwhile, we’re at the beginning of the December now, which is usually one of my least productive months, partly because I like to use some of my time to prepare for the coming year.

But I also want to take stock of the project and figure out more precisely what the remaining scope is. Despite putting in about a year of development, I feel very, very far away from a concrete version of my vision for this game, which included multiple characters with their own agendas and desires, a sprawling underground dungeon, a player-editable map, items and inventories, and a time system among others.

It’s a lot, and while I already anticipated slimming the scope down, I am worried that I need to do even more scope cutting, and I’d like to make sure I keep the essence of the planned game as well as get a better idea of how much work is left to do.

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!