GBGames

In last week’s report, I finished creating the pickle jar, sped up the perceived loading of the game, and started the work of enabling the player to give items to another character in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I continued working on the feature of giving items.

Sprint 2024-28: Giving Items

Planned and complete:

• Give items to entity

Unplanned and complete:

• Show quantities of items in inventory

Unplanned and incomplete:

• Show item on counter on actual counter in kitchen

Last time, I was trying to figure out what giving an item should look like. That is, I had concerns about manipulating inventory contents and dealing with situations in which the inventories are too full.

Ultimately I decided to allow the player to select an item from the party’s HUD, then attempt to give the item to the other character.

If the other character has room, then they accept it.

Even if you ended up giving them nothing, but doing so is kind of rude.

If they don’t have room in their inventory, then no items change hands and they say they can’t take the item.

I will eventually need to add definite and indefinite articles to the scripting code sooner rather than later. These conversations sound too stilted and awkward.

Meanwhile, I also added a trigger to start a specific script when you give your parents the jar of pickles.

I created a new kitchen counter Furniture object, which has room for one Item, and that scripted sequence adds snacks to the inventory of that Furniture.

You can see that there are actually 6 snacks available. This is the first item that has a quantity associated with it.

Right now, you can only take all of them at once, but I want to work on allowing the player to choose to take only one if they want.

Specifically it would be great to hand out the sandwiches to each member of the Explorer’s Club, ultimately finishing the Snack Quest. And of course eventually I’ll make Quests a formal part of the game, too. B-)

The next thing I am working on is showing the snacks on the kitchen counter so you can tell an item is there to collect. I can see this same feature being applied to shelving and cabinets to allow the player to see what is available in some Furniture without having to open it first, if it makes sense for the contents to be visible.

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!

Last time, I reported that I showed an indicator when a friend had something to say to you and started creating a new trigger criteria based on item acquisition for The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I finished the item acquisition trigger work, then worked on improving startup times.

Sprint 2024-27: What to do with the pickles?

Planned and complete:

• Trigger intro script when pickle jar acquired

Unplanned and complete:

• Defect: Game startup takes too long

Unplanned and incomplete:

• Give items to entity

I basically needed to draw a pickle jar and get it into the game, so I did so:

Next, I realized that starting up the game was needlessly slow. A lot of media assets getting loaded upfront means the game runs quickly when you finally get to it, but there was no reason to load everything if you didn’t need everything. Plus, I don’t remember what the load time should be on mobile devices, but I think you get dinged by the app store reviewers if the game doesn’t start up quickly.

And on the main menu, you need hardly anything at all. I wrote a few hundred lines of code and spent time trying to get the various parts coordinated to avoid crashes, which mainly involved not trying to draw the dungeon before the dungeon assets were loaded.

But now the main menu is almost immediately available. When you start a new game, only the media related to the house and the customizable characters are loaded.

And when you enter the dungeon the first time, the dungeon-related media is loaded.

The main tricky part was handling two scenarios: loading the game when the player is in the house, and loading the game when the player was in the dungeon. The latter required all of the art assets to be loaded at once.

Actually that is strictly not true. I could always load the house-related media the first time you return to the house if you loaded while in the dungeon. I might revisit this issue in the future.

But for now, the main thing I’ve accomplished is deferring media loading until needed. While the load time hasn’t changed, what has changed is perception. The game starts up and you are immediately on the main menu, ready to start, and even if the game begins loading when you actually start a new game from the main menu, by this point you as the player are invested enough to tolerate a bit of loading.

And of course once the media has been loaded, you don’t have to load it again for the rest of your play session.

Finally, by the end of the week, I was working on the ability to give an item to another entity, and I am reminded that game design is hard.

I have created a Give Item button by combining two images from https://game-icons.net/. I hope it reads well.

So I envisioned you would click on the middle button, which would open up something similar to the Furniture inventory screen to allow you to give an item to another character.

Currently inventory management only occurs with furniture, and the way it works is that the furniture inventory is centered, and the party’s inventory is at the bottom of the screen.

Originally I thought I would let you select a party member’s item and say “Give” but then I have to worry about whether or not the receiver has open slots of inventory, how to respond, etc.

And then I thought, “What if the receiver’s inventory is on screen like the furniture inventory?” but then it would be possible to take things from the other person, right? That seems strange when you just said you were going to give something to them instead.

Also, what if they don’t want to give it away? Do things need to be “locked” so you can’t take but can give?

So I’ll figure it out this week and let you know next time what I decided.

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!

In my last report, I finished adding stamina to the characters you can have in your party and optimized in-dungeon rendering in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

Sprints 2024-25 and 2024-26: Conversation topic indicators

Planned and complete:

• Show indicator when Friend has something to say

Unplanned and incomplete:

• Trigger intro script when pickle jar acquired

I’ve been trying to put myself into the mind of a brand new player figuring out how to play this game, which has helped me see ways to enhance the game in small yet impactful ways.

Before now, if you were to start playing the game, you would have a quick bit of scripted dialogue, and then it would dump you unceremoniously into the bedroom, and it would be up to you to figure out what to do.

And it didn’t sit well with me because I was asking too much of a hypothetical new player: knowing to click on a particular character on the screen as opposed to one of the other characters or to one of the more obvious button-looking buttons, then knowing to click on the Ask button, then knowing what topic to pick.

So I decided to provide some guidance in the form of an indicator that says, “This character has something to say to you!”

This iteration was still clunky, I realized. In real life, if you see someone who clearly has something to say to you, you wouldn’t say, “Hold on. First, let me ask you something” and hope you picked the topic they wanted to discuss.

So I streamlined it. If a character has something they want to say to you, they will launch into it immediately when you click on that character.

Now, after you hear that you should talk to Pat to start their induction ceremony into the Explorer’s Club, there’s a very obvious question: which one of the six characters on the screen is Pat?

By this point, you would likely notice that Francis should match the look of the character in the bottom party HUD, and you have met Sam who urgently needed to talk to you from the outset.

So how do you figure out who Pat is?

Well, one thing I did to help is provide a “What do you want to do with XYZ?” box when you click on a character to interact with them.

Without it, you had to click once more on either the Ask or Tell button to get their name.

Now, I COULD make it so that immediately after talking to Sam you see Pat has a speech bubble over their head, but I think I like the idea that you have to essentially do some trial and error and get acclimated to who is who in the process.

Also while playtesting, I discovered that when you click on the shelves in the basement, it always plays the intro script that shows how the secret door appears. There was a simple way to address it, but it was a hack fixing a hack, so I ultimately decided to create a new type of trigger criteria.

When you acquire the jar of pickles off of the basement shelves, THEN the script would kick off.

And once the script runs, it disables that trigger, so the script won’t run a second time. Whew!

Now, you might notice something: where are the pickles?

Well, the original drawing of the jar of pickles on the shelf was tiny, and I didn’t think it would work well for an actual item.

So I am currently applying my limited artistic talents to make something a bit better:

And while I am sure I could have thrown this in, by the end of the week I was not able to dedicate the time to more game development, so you’ll just have to imagine that jar being in the animated GIF above, as I’m sure by the time you read this I will have that time to make it a reality.

Awkwardly, I keep finding myself wondering what to work on next, mainly because I have a lot of questions about the directions this project can go in. I simultaneously want to answer those questions, which I expect to look like a lot of thinking and writing, and I want to ensure that the project keeps moving forward in tangible ways, which looks a lot more like coding, drawing, and creating maps.

Which of course makes me want the time to do both.

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!

Last week, I reported that I added the concept of Stamina to the party members in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I built off the resting mechanic to add sleep, plus addressed other things this past week.

Sprint 2024-24: Stamina and resting mechanics

Planned and complete:

• Friends have stamina

Unplanned and complete:

• Defect: Dungeon rendering is too slow on Android
• Sleep in bedroom to restore stamina

Unplanned and incomplete:

• Show indicator when Friend has something to say

Since your party can use up their energy, I now have to handle the situation in which all of their energy is gone.

As I said last time, resting isn’t meant to be very efficient and should be seen by the player as a waste of time that they want to avoid. I talked about the party members becoming Exhausted.

I ended up creating some scripted dialogue whenever someone does become Exhausted. If multiple people become Exhausted at once, then a random party member is chosen as the speaker.

If any member isn’t Exhausted, then you get the option to rest or continue, and I’m still toying with the idea that non-Exhausted party members need to use more energy to “carry” the others.

But if everyone is Exhausted, then you are forced to rest.

Next, I realized that I was tired of dealing with the slow dungeon rendering. Ever since I added more wall, floor, and ceiling images to draw, the rendering of the dungeon has become quite stuttery.

I anticipated it was due to needing to read from different parts of memory to get the texture information for rendering, but I am glad that used a profiler because I discovered the real bottleneck was due to making and destroying copies of DungeonGridCell objects needlessly.

Each DungeonGridCell knows what type of floor and ceiling it has, so when I wanted to know what type of floor to draw, I would ask for that grid cell by index, but I was making a copy of it. Then I would ask for the floor type, then I would discard the copy.

These objects contain everything about a grid cell, though, so the copy was also getting the walls, any doors, any portals, any tags, the lighting that might be baked in, etc. Each object isn’t terribly large as a piece of data, but when you copy and destroy the object unnecessarily half a million times, it adds up to a lot of extra processing.

So I changed the code so I can ask for the floor and ceiling data by reference to the cell, eliminating a bunch of that extra unnecessary processing.

The next bottleneck in the rendering code was related to how the flashlight lighting was being processed. Similar to how I was doing processing unnecessarily on each pass, I was doing repeated calculations that didn’t need to be repeated.

Basically, lighting data for the dungeon is retrieved once, but then if the flashlight is being used, there are a number of modifications to the lighting that need to occur before the final lighting is used to determine how to render a specific dungeon cell. So the code iterates through the flashlight’s affected cells, figuring out if the cell in question should be lit up more by the flashlight or if the existing light is brighter.

And I was apparently doing this in the most inner loop despite the fact that the lighting calculations will be the same. Whoops.

If you recall, when I render the floor and ceiling, I go pixel by pixel, looping first over each row, then inside each row, I loop over each column. That’s the inner loop.

So I moved the flashlight lighting modification code outside of both loops, because all I need to know for the flashlight modification code is the current location of the party and the current lighting data, neither of which changes inside those loops.

And suddenly, I was delighted to find that the dungeon rendering code was fairly smooth again. At least, it is quite smooth on my desktop computer. On my Android phone, whereas before it was quite unplayable, it is now tolerable.

Then I worked on adding the ability to sleep to gain back all of your energy. I’m not sure if I’m happy about the user experience, but to make a long story short, I added a second option to the Rest menu to sleep for 10 hours in exchange for replenishing your party’s stamina.

Did you know that pre-teens need about 10 hours of sleep a night? It seems like a lot, but I suppose it makes sense that a kid with an 8pm bedtime won’t be waking up at 4am.

Anyway, I had to take into account that the rest of the Explorer’s Club might also be low on stamina, especially if the player had swapped out party members, so when you sleep, EVERYONE in the room gains back energy.

And I decided to make sure that the Sleep option is only available at night. My thinking was that letting you sleep at any time is both unrealistic and also allows for an abuse of the sleeping mechanic.

One thing I worry about is the idea that there are three party members but six potential friends who can be party members, and I really need more reasons for why choosing one over another matters.

Being forced to go without a particular character who has certain skills you wanted to leverage might be a good thing to have the player worry about, a nice side-effect of not being able to restore stamina whenever you desire.

By the end of the week, I found myself playing the game so far and trying to figure out what to focus on next. A major part of the game will be conversing with others, and I still need to work to make it more intuitive.

I spent time thinking through how to indicate on the screen when a character wants to say something to you and how you might interact with that character to get them to say it, but I’ll need to continue that work this coming week.

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 latest Freshly Squeezed Progress Report video, with footage covering the last month or so of development, including this past week’s report: Stamina, Energy, and Resting

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

In my last report, I added the concept of time plus a watch on the HUD that allows the player to track that time in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

Sprint 2024-23: Stamina and resting mechanics

Planned and incomplete:

• Friends have stamina

As I said in the previous report:

I decided a core part of the game would involve managing time. While the game is turn-based and wouldn’t require dexterity and perfect timing of button presses to do well, it will require the player to pay attention to the clock and to manage time as a valuable and scarce resource.

Why? Because I decided that the major theme of the game is the idea that there is too much to do and not enough time to do it all.

And with a concrete concept of time, the rest of the mechanics can work to either directly or indirectly involve time somehow.

I decided that another major resource to manage is the stamina of your party members. Taking certain actions should use up stamina, and so should walking in the dungeon.

First, I needed to show a party member’s stamina in the HUD. I spent some time thinking through how to represent it in a way that communicates everything useful to the player.

Having a meter alone tells you how much current energy exists relative to the maximum amount, such as:
“(======____)”, but I felt like it left out important information such as how much energy exactly exists. Someone with half of 10 total energy would look the same as someone with half of 100 total energy.

Having just numbers will give that information, such as “ENERGY: 3/10”, but you lose the ability to see at a glance how much energy the party member has relative to their maximum amount.

I could have both a meter and numbers, and that seems like the best of both worlds, but it risked crowding the HUD.

I eventually came up with the idea of using a row of orbs to represent energy, with smaller orbs underneath to show how much the last filled orb has left in it. The challenge right now is that I still don’t know what magnitude/scale makes sense for stamina. I didn’t want to spend time making a pretty UI widget only to find out that it doesn’t make sense when I have to change the general range of values that you can have for stamina.

Having a max of 10 energy can be represented by 10 bars in a meter or 10 orbs, but what if I decide that 5 makes sense? Or 1000 to give the player more flexibility with how they use their energy?

So for now, I went with using simple numbers, knowing I’ll want to revisit this stamina HUD representation question later when the game’s numbers are more nailed down.

Next, I needed to use stamina when walking in the dungeon. I already had a way to add 5 minutes to the time when you walk 30 steps, so I just piggybacked off of that code to also decrease the stamina of the party members by 1.

Then, I added the ability to rest in order to recover stamina.

As you can see, you can choose to rest for 10 minutes in exchange for gaining back +1 energy for each party member. I also considered adding other options, such as resting for longer periods of time in exchange for more energy, but I’ll start with this one option.

I spent quite a bit of time trying to figure out where the Rest button should live, though. I originally envisioned it being part of the watch’s functionality. If you click on the watch, perhaps you can set an alarm, and one choice you can make is to rest 10 minutes.

But managing time was conceptually different from managing stamina, and I realized it would be counterintuitive to lump it in with watch utilities.

I don’t like it on the main HUD, because I think choosing to Rest won’t be as common an action as what the navigation controls provide, but similar to the choice to represent stamina with simple numbers for now, I’ll revisit this HUD question once more of the game is working together.

The last thing I needed to do was handle the situation in which the party’s stamina hits 0 energy, forcing them to rest.

If the entire party is at 0, it makes sense for force a 10 minute rest. But what happens when at least one party member isn’t at 0?

I’m thinking about being somewhat forgiving here. Maybe some dialogue pops up, offering the chance to rest or to continue on, knowing that the other party members now need to use more of then own energy to make up for it.

So for each party member at 0, the remaining party members might use up 1 extra energy when moving around. So if one party member is at 0, the other two members each use up 2 energy instead of 1 for every 30 steps. And if two members are at 0 stamina, then the remaining party member uses 3 energy. Maybe. I’ll toy with this idea for the future.

For now, though, I decided to implement one idea I came up with while sketching out some of these mechanics: Exhaustion status.

If a party member hits 0 energy, they get an “Exhausted” status, which will create a bit of scripted dialogue to that effect. If all members are similarly exhausted and out of energy, then the only option is to rest for 10 minutes.

Otherwise, if there is at least one party member who has energy, then a second option to continue without resting is available.

I’m not finished with this part. I still need to indicate on the HUD that a party member is exhausted, and I’m trying to figure out how to best convey the consequences of continuing without resting.

I’m also trying to figure out what consequences make sense for having the Exhausted status. Maybe all actions take an extra energy to perform, or twice as much energy for perform while Exhausted? Perhaps, upon returning back to the house, party members who are Exhausted cannot return to the dungeon for a day (they need to rest, after all), forcing the player to choose other party members. I like this idea because eventually I want the player to have reasons to choose some party members at different times, and avoiding exhausting your party becomes important in its own right to avoid being without a key party member for a particular task.

Since time plays such an important role, using the option to Rest should be something the player doesn’t want to do unless they have to. But I’ll need more of the game in place to see how it all plays out.

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!

Last week, I reported that I successfully loaded the level data from a file in a way that works on Android and other platforms seamlessly, then spent time on design and planning for The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I worked on adding the concept of Time into the game this week.

Sprint 2024-22: Project Management

Planned and complete:

• Advance time when navigating dungeon/performing actions

I decided a core part of the game would involve managing time. While the game is turn-based and wouldn’t require dexterity and perfect timing of button presses to do well, it will require the player to pay attention to the clock and to manage time as a valuable and scarce resource.

Why? Because I decided that the major theme of the game is the idea that there is too much to do and not enough time to do it all.

And with a concrete concept of time, the rest of the mechanics can work to either directly or indirectly involve time somehow.

To start with, the main values to worry about are the minutes, hours, and days that can pass as the player plays the game. While I want the game to end after a period of in-game time has elapsed, I haven’t decided if it will be a weekend, or a week, or an entire month.

But the player should know how much time has passed, so I created a watch that will be on the HUD and visible almost all the time.

Eventually this watch will be a button that the player can press. I envision being able to set alarms and reminders to help the player manage their time.

But for now, it just needs to display the current time and day.

I also advanced time by five minutes whenever the player walks 30 steps in the dungeon. I don’t expect that either of those numbers will be in the final game, but it is a start.

I think the watch looks pretty decent, and with time in the game, I can build more mechanics on top of it, and I can even create an ending, which is what I anticipate doing next.

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!

In my last report, I added comic strips to my scripts and worked on getting the Android build to work after adding the ability to load the level layout for The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

Sprint 2024-21: Project Management

Planned and complete:

• Why won’t game run on Android after map-loading code was added?

As I said last time:

But ever since I added the dungeon loader to load the dungeon from a JSON file, I found my Android build crashes.

It turns out that I had a discrepancy in my build scripts that didn’t add the JSON file from my resources directory into the correct location when I built the project for Android.

Once I fixed it (and fixed the typo that prevented it from copying the file still), it still crashed. It turned out that I ran into a known issue when loading files from the Android assets directory, which you cannot simply open using std::ifstream since it is in the APK’s .zip format.

You are supposed to use the Android AssetManager, but I am under the impression that libSDL2 provides a mechanism to do so, especially since many of the assets I already load, such as images and audio, load fine using the existing image-loading functions.

SDL2 provides a mechanism to do so. If instead of using std::ifstream I used SDL_RWops, under the hood it will determine if it needs to use Android’s interface to load a file from the assets directory.

Unfortunately, the documentation for SDL_RWops isn’t terribly great, and it seems to assume you already know what you’re doing. If you really dig into the libSDL2 and related libraries such as libSDL2_image, you’ll see that there are plenty of places that SDL_RWops is used to load and write files.

For example, in SDL2_image, there is the function IMG_Load() that you might use to load any type of file, such as PNGs or BMPs. Under the hood, it delegates the work to SDL_RWFromFile() and then uses the resulting SDL_RWops to load the data for the image into an SDL_Surface object.

That’s great for images, but what about my JSON file that represents the dungeon’s level data?

I found a number of people doing strange things like copying character by character a file from the assets directory into the player’s SDCard, and I thought I was going to need to do some low-level data manipulation to eventually get the entire JSON document into an std::string. Plus, how was I going to get an SDL_RWops to know how to read my file?

But then I discovered that there is a handy function:

void * SDL_LoadFile(const char * file, size_t * dataSize);

The docs say “Prior to SDL 2.0.10, this function was a macro wrapping around SDL_LoadFile_RW.” Of course, when I look at the code, it still wraps that _RW function today.

Anyway, long story short, using this function, I can get the contents of my JSON and load my dungeon from it as usual. And re-reading the docs right now, I realize I might have a memory leak to deal with. But otherwise, my Android build runs again!

What’s next? Unfortunately, I have been struggling with this question. I have a backlog of tasks that add capabilities and features to the game. For example, items and inventory exist, but there are no items in the dungeon or a way to interact with or see them even if they did.

But I feel like I’m missing something more fundamental than a random assortment of features.

So I spent time writing down what I want the game to be about. Not just the idea of a non-violent, 1st-person role-playing game, or the idea that the game will revolve around conversations and knowledge-acquisition, but the meaning behind the game that I want to convey.

Throughout development I’ve thought about the game’s themes and even wrote down some of those thoughts, but now I’ve settled on a particular theme, and it is helping me to drive a number of mechanics that support it.

I’ve also retroactively tried to think through what it means for the game to be party-based and have a 1st-person perspective. I could make a game that is mechanically indistinguishable from a single-character RPG with a top-down perspective, or I could be deliberate about taking advantage of the strengths and avoiding the weaknesses of the specific format I picked.

I still worry that the minimum amount of work left on this project is a LOT, but I also feel like I have a better idea of what forward motion looks like. I am less concerned about random mechanics and more about what supports the theme.

And for reasons that will make sense in future posts, I think the core mechanics will all revolve around Time as a concept, something I’ve thought about putting into the game since the beginning but only now feel confident in working with.

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!

Last week, I reported that I updated the art in the titular dungeon of The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I also started the work of making a part of the intro sequence clearer, and I finished that work this past week.

Sprint 2024-20: Project Management

Planned and complete:

• Show broom knocked over when searching for pickles

Unplanned and incomplete:

• Why won’t game run on Android after map-loading code was added?

To start with, there is a part of the intro sequence in which the player goes into the basement to look for a jar of pickles, as requested by the parents in the kitchen, and then for some reason a secret door appears.

In my head, I had a somewhat elaborate series of events involving knocking over the broom, which hits a secret button in the wall, which opens the door.

But none of that was communicated to the player, so it just looked like the player clicked on the shelves, saw the main character Francis say something in shock, then suddenly there is an entryway that may or may not have been noticed as being new depending on if the player was paying attention to the scene before and after.

Now, I could have used animated sprites and effects to make it clear what was happening, but that sounded like a lot of work for a one-time situation, and I feel like this project is too big as it is.

So after a bit of thought, I came up with what I hope was an effective solution while also requiring the least amount of effort.

So I made some comic strips to illustrate what happened.

I’m hoping these two sets are enough, but I could always add a third showing the secret door opening to make it more obvious if it is still needed.

After that work was done, I spent time trying to identify all of the work I might have left in this project.

And it is a lot. I mean, if I was dedicating full-time effort to it, it would probably only be a few months of work, and since I’m sure I am underestimating it, maybe some small multiple of a few months.

But since I am working mere hours at a time on it in a given calendar week, I’m worried that I’m looking at another year of development, and I’m sure I’d find new features and fixes that take up time, too.

So I think my most immediate project management concern is nailing down exactly what this project absolutely needs. For example, I had ideas of entities navigating throughout the dungeon on their own based on their own agendas and time passing.

I can avoid an entire category of work involving pathfinding and decision-making if I decide that it can be in a future project or potential sequel instead. Dungeon entities might just need to be statically placed for this project if I want to finish it in a more reasonable period of time.

On the other hand, since this game is meant to be non-violent, which means I don’t get to rely on existing and tried-and-true game mechanics related to health, weaponry, armor, and combat, I wanted to focus on relationships. The entities you encounter and your interactions with your own party members NEED to be at a minimum level of complexity to make it interesting. When cutting scope, I need to be mindful that some things getting cut will reduce the richness of those interactions.

Meanwhile, I wanted to address what I thought was going to be am minor fix to ensure the project runs on my Android phone again. It makes it easy to show to people what I’ve been working on if I have the latest version available in my pocket.

But ever since I added the dungeon loader to load the dungeon from a JSON file, I found my Android build crashes.

It turns out that I had a discrepancy in my build scripts that didn’t add the JSON file from my resources directory into the correct location when I built the project for Android.

Once I fixed it (and fixed the typo that prevented it from copying the file still), it still crashed. It turned out that I ran into a known issue when loading files from the Android assets directory, which you cannot simply open using std::ifstream since it is in the APK’s .zip format.

You are supposed to use the Android AssetManager, but I am under the impression that libSDL2 provides a mechanism to do so, especially since many of the assets I already load, such as images and audio, load fine using the existing image-loading functions.

So I ended the week investigating how to load my text file into my project. Once I have the Android build functional again, I’m going to be doing some serious design and project management work.

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!