Category: Game Development

In the previous report, I had made progress on clothing customization for the characters in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I have since finished the footwear menu and then moved on to some more interesting work.

Sprint 35: Pre-production and initialization

Planned and complete:

• Revise character customization

Unplanned and complete

• Defect: Android app won’t run
• Create party

With a variety of footwear, the player can now wear socks, shoes, sandals (but not socks AND sandals…yet), and boots. While I want to revisit the character art (especially faces), customization seems done enough.

And I could finally move on to some experiments with dialogue systems.

Except first I needed to figure out why the Android build I created wasn’t running.

Initially I thought it was a memory issue. In past projects I would kick myself when I needed larger sprites for another purpose, such as creating high quality icons or printed items, but I only had smaller sprites that worked well enough in-game.

So I’ve been trying to create large sprites on the order of 1024×1024 pixels, rather than something like 32×32 or 64×64.

While in the back of my head I thought that I might run into memory issues, especially when each item of customization is such a large source image, I figured I could address it later.

Fortunately, it turned out to be almost a non-issue. Basically, when I worked on updating the supported target API for Google Play for my other games, I upgraded each project’s configuration and SDL2 Android project source as well as my development system’s build tools.

But I didn’t update THIS unpublished project’s relevant configuration, so I was using newer build tools with an outdated source/configuration.

Once I updated a few of the project’s files and used the newer android-project from libSDL2, everything worked fine.

So I didn’t have a memory issue after all, and I can kick that can down the road.

NOW I could work on dialogue systems.

Sorta.

I thought of a few scenarios I wanted to support, and I considered having different kinds of conversation types that each communicated the player’s goals to the game, such as persuading someone to do or not do something, or share information, or whatever.

Then I looked back on all of the various notes I’ve taken for the past few months about conversation topics, the role of emotions, character goals, trust between characters, and more.

And at some point I realized that it might be easier for me to hang a design onto something more concrete, and that requires me finally putting together the concept of a party.

In this game, I decided to have the party consist of a maximum of three members, partly to keep things simpler for me to develop but also to keep things simpler for the player to track.

To start, I added a button so you can configure your party in the bedroom, where the Explorer’s Club meets. After some discussion with my friend Branwyn, I decided that there was no reason to restrict the party to just the kids and so the parents (or grandparents? caretakers?) in the kitchen can join, too. So instead of the typical “kids are the heroes, parents are oblivious or MIA” kind of story, you have the option to get one or both of your parents to explore the dungeon with you!

Since all characters in the game are Friend objects, and a party is made up of a collection of Friend objects, this functionality was easy to add.

And so now I just need to change the dialogue so that the speaker isn’t hiding behind the party HUD.

I could configure the party, then reconfigure the party elsewhere, and leave someone in a different location from where they originally started out. As you can see, a few characters are now in the kitchen instead of the bedroom. Perhaps splitting up needs to happen as game play to allow for two characters to manipulate things at once.

So now that I have a party, and that party will always have the player’s character as a member, I can start experimenting with the party interacting with other characters through dialogue.

Again, my goal with dialogue is to do more than merely have branching text output or have relationships build as a simple function of “you said something nice to X, so X likes you more by Y points. After Z points, they become a romance option” or something like that. And I don’t want dialogue to merely be combat mechanics in disguise.

But I want dialogue to be as compelling as the combat usually can be in typical 1st-person dungeon crawlers. Like real-life, you’re not necessarily trying to debate someone into submission. You’re both navigating the absurdity of communication, and you are mutually trying to understand and learn.

At the same time, I am a bit wary about how much content I would need to create. Will I necessarily need to write a bunch of dialogue to cover various scenarios? If I don’t write dialogue, can I get away with scripts that merely describe how the dialogue is happening (“You ask about [TOPIC]. Sam replies enthusiastically. You learn [XYZ]”) or will that come off as less compelling?

These are the kinds of things I probably should have been exploring since the beginning of the year.

One thing I realized that is going to make me revisit the face customization sooner than later is that I think emotions will play a key role. Someone who is afraid or angry is going to be less forthcoming with information than someone who is happy or confident.

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!

While I didn’t write a report last week (strangely a 3-day holiday weekend sometimes results in less time to write than usual), since my last report I was working on hair customization options for the characters in The Explorer’s Club from The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

Besides hair, I had to create clothing options, too.

Sprints 33 and 34: Pre-production and initialization

Planned and incomplete:

• Revise character customization

“All that was left was finishing the hair customization menu and getting clothes options in there, and I would feel good stepping away to work on something else.”

I wrote that statement in the previous report, and as I am coming towards the end of this work, I’m laughing at how much I underestimated it even as I was weeks into the effort.

I am obviously not an artist by trade, and I also haven’t worked in Flash or similar tools in the past, which means I am not as familiar with what is needed to compose a character out of separate pieces of art.

I’m learning a lot as this work has continued, and I find myself needing to decide between making improvements now or leaving them to incrementally improve later. For instance, I’m getting less and less satisfied with the face shapes, eyes, and mouths as the rest comes together, but I’m leaving them as is with the intention to update later.

After I finished creating hair options, I started working on clothing, which required creating bodies for the clothing to appear on. After all, if someone is wearing short sleeves, you should see arms that would otherwise be covered up by long sleeves.

There were some funny missteps.

In this image, I forgot to apply skin color to the pelvis sprite, and it looks like I’m creating a poorly-drawn reboot of the Rugrats cartoon.

Also, why are the arms so long? It forced me to figure out proportions better. When I had temporary rectangles and sprites, it didn’t matter as much, but now the characters need to look at least somewhat right.

Soon I created options for shirts, pants, and when I noticed everyone was still barefoot, footwear. Again, as I worked, I realized that there were better ways to handle some of it.

The face shapes sometimes cover up the details on the shirts, and so I think I need to make some of the faces have longer necks associated with them.

Also, right now, the pleated skirt only somewhat works because the sprite for the pelvis and the sprites for the legs only seem to look like a single item, and I didn’t have an easy way to do the same for a long dress because the sprites weren’t long enough to do so. I don’t know how wrong it will look when it is animated.

Anyway, the neat thing is that with the variety of colors, clothing, hair, facial features, and body shapes, each randomly-generated character has a greater chance of having a unique look.

But I do wonder if I need to put my thumb on the scales to encourage more differences. Do all three of these characters have the same hair stylist?

At the moment, the characters can have socks, sandals, or sneakers. I’d like to provide a few more options for footwear, and then I can move on to something much more interesting and core to the game, such as experimenting with dialogue mechanics.

For now, though, I’m feeling satisfied that the characters have some personality coming out, as opposed to how they looked when they were just one of a handful of simple-looking floating heads.

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 was making good progress on character customization options for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I intended to continue the work, but there were some other things I needed to work on urgently.

Sprint 32: Pre-production and initialization

Planned and incomplete:

• Revise character customization

All that was left was finishing the hair customization menu and getting clothes options in there, and I would feel good stepping away to work on something else.

Instead of making significant process on it, though, I spent most of my development time dealing with Google Play’s annual target API policy requirements.

Each year at the end of August, Google Play updates the requirements for apps. New apps always need to target the latest official SDK/API or they won’t be accepted in the Google Play app store, and existing apps also need to update to support a recent SDK/API in order to support the ability to do future updates and for Google Play to offer the app to newer Android devices.

In practice, it means periodically finding out whether your already-shipped applications might need any code or configuration changes to continue to run.

In the past, most of my effort involved getting a newer version of libSDL2 which already supported the new target API, but I discovered that the latest version did not have any changes related to Android development compared to the older version I was using.

Which meant that the latest targetSdkVersion was still outdated and an updated libSDL2 wouldn’t be enough.

So ultimately, I updated the Android SDK and NDK to the latest versions, updated libSDL2 to the latest version, then modified the android-project from libSDL2 so that it used a newer version of gradle and I set the targetSdkVersion to 33.

I like having my apps be backwards-compatible, and so I wanted to keep the minSdkVersion at 16, but apparently the NDK won’t support anything earlier than 19.

I documented more details at https://discourse.libsdl.org/t/google-play-targetsdkversion-requirements-and-deadlines/, and it looks like soon there will be a newer SDL2 version that will support Google Play’s new target API requirements. It’s unclear if my documented changes post helped with that change getting made in the official library code.

So both Toytles: Leaf Raking and Toy Factory Fixer have been updated in Google Play, and I’ve made some changes to make these annual updates a bit more automated.

And now I can get back to creating hair customization options for The Dungeon Under My House.

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!

A couple of weeks ago, I reported that I was working on character customization for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

While I had a trip with my family for a long weekend, I continued to make progress over the last two sprints.

Sprints 30 & 31: Pre-production and initialization

Planned and incomplete:

• Revise character customization

Sometimes you don’t see how much work there is until you’re in the middle of it.

And I keep finding new ways to add complexity to character customization and rendering.

When I originally envisioned this work, there would be multiple options for different facial features. So the work was to create a bunch of buttons and art for noses, then do the same for mouths, then do the same for hair, etc.

But more and more, it feels like I need to account for how things are offset based on the face shape. A head of hair looks fine on a round head but not so fine on a wide one.

Or in the case of mouths, I need to separate the lips from the teeth, so instead of a single thing to draw, I have two, mainly because if I give the player the option to change lip colors, then I don’t want the teeth to look like they are also changing colors.

I’m not entirely pleased with the actual art, especially with the mouths, but the variety does help a lot in terms of making the characters look more interesting. Each time you start a new game, you and your friends in the Explorer’s Club get randomized features.

I am still working on hair, which I am finding awkward. While I could make hair that always fits over each head type, it does limit my options. Another, more complex approach is to apply multiple hair sprites to the head using offsets and scales based on the head shape. So a tall skinny head would have a top hair sprite that might be scaled smaller in width, with left and right hair sprites that are offset closer to the middle, and a wide, short head would have a wider top hair sprite and the left and right hair sprites would be offset further away from the center.

The more complex approach offers some more capabilities, of course. For instance, in animating the character’s hair, it might look better to have multiple hair sprites that move independent of each other.

In any case, while I knew character customization was going to be complex, and even though I knew I was going to provide a limited set of options, I still underestimated the work.

Plus, I still need to implement clothing. I’m getting tired of the placeholder bodies I created.

At the same time, I’ve been investigating better ways to make dialogue more interactive and ensure the game feels less like sitting through unskippable cutscenes. I’m toying with having different types of dialogue. Along with the typical scripted sequence, I think creating arguments/debate could be interesting. An argument has adversaries, a topic to argue about, facts, and evidence. The goal of being involved in an argument might be to convince your adversary of your position, or to sow dissent, or to gain esteem. Perhaps each argument ends with learning something new about a topic, whether you win or lose the argument.

And of course, an entity’s experience, charisma, knowledge, and current state can impact how well they can argue. A nervous individual might be easily convinced by confusing dialogue, but a more confident individual might question their adversary’s actual understanding.

Being able to ask questions, listen, and talk will be primary actions, probably with a target entity or a group.

But of course this raises questions: should the player control the entire party, or just the main character? Controlling the entire party might be easier to implement, and it allows for strategy along the lines of determining which strengths to use and weaknesses to shore up.

But having indirect influence on your party members might be interesting. What would it look like if the player’s party can act independently of the player? Do you need to worry about a hothead blurting out too much info in a heated argument with another character? Will you get frustrated because the friend who would be great at convincing someone to let you by keeps getting talked over by a different friend who is confident yet very ignorant? And is that an enjoyable frustration to play through, or is it just plain annoying?

This dialogue work is more interesting to me, so I can’t wait to finish off the character customization work for the time being so I can start prototyping.

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!

On August 25th, you can get my leaf-raking business simulation game, Toytles: Leaf Raking for Windows, Mac, and Linux and pay 50% more than usual.

Why?

itch.io, the very indie-friendly platform for game developers, writers, musicians, and artists in general, will be having one of their Creator Days.

For 24 hours, itch.io will take no cut from any sales, which means the creators get to keep all of the profit.

Many creators are creating sales for the weekend to participate.

I’m taking part, but instead of discounting my game’s price, I thought I would increase it instead.

I think the game’s original price is more than generous, and a temporary increase still puts it under the cost for a movie ticket or a monthly subscription to a streaming service.

But, just in case you would prefer not paying more, you have one week before the price increase to get it at the usual low price. Click below!

Toytles: Leaf Raking is also available for Android and iPhone/iPad.

You can also get my first Freshly Squeezed Game, Toy Factory Fixer, at itch.io. It’s free to download and play, but you can contribute money if you want. If you wait until next week, itch.io will let me keep more of any money you would pay, but anything at any time is greatly appreciated. B-)

Last week, I reported that I had addressed a crash bug and then started the work of replacing the placeholder art for characters in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I continued the work this past week.

Sprints 29: Pre-production and initialization

Planned and incomplete:

• Revise character customization

If you recall, I was tired of the placeholder art I was using to represent the characters in the game. Floating heads of various shapes were functional, but it was past time to make the characters resemble something more like what they will in the final version of the game.

At the very least, it would make the screenshots more compelling.

And the best way I thought to do this work was by creating character customization menus.

I decided to split up the customization categories into Body, Face, and Clothing.

On the Body customization screen, you can pick a skin color, and you can change the height and size of the character.

On the Face customization screen, you can change the base face shape and you can change the eyes and eye colors.

As I was ending the week, I threw in a single nose, mouth, and hair option, because otherwise it was creepy seeing the characters with unfinished faces.

I figured a terrible haircut would be better than nothing.

I’m relatively pleased with how these faces are turning out so far. I mean, I’m not going to pretend this isn’t still programmer art and that I still want better art, but it feels a lot more cartoony than what was there before. It’s becoming more real.

I find that I want to ensure the facial features have custom offsets on different faces. That is, a short and wide face might have the eyes offset farther away from the center than a tall and narrow face, and the nose might be lower or higher on a given face. I suppose I could let the player customize placement of features, but I could also keep it simpler for now.

This enhanced customization work means players can personalize the game more, and while I don’t anticipate having the capacity and ability to cover every possibility, I hope to provide a good variety to play with and to allow players to see themselves in their characters. And I can always improve it later.

Is there anything you wish character customization allowed you to do that you don’t usually see in other games? I’d love to hear from you in the comments section.

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 previous sprint report, I created an introduction script for The Dungeon Under My House, my second Freshly Squeezed Entertainment project, but I decided I wasn’t happy with it.

I also discovered a mysterious crash issue when I ported it to Android to test it, and I was definitely going to need to fix that issue.

Sprints 28: Pre-production and initialization

Planned and complete:

• Defect: Android crash when drawing ceilings in dungeon

Unplanned and incomplete:

• Revise character customization

After I finished working on the dungeon doors and basically having a working dungeon mode, I switched to focusing on the house and the intro script. At the time, I was able to create an Android build and verify that while the dungeon view needs optimization, it was functional.

So imagine my surprise after getting the intro script done and wanting to share it with others that the Android build crashes when entering the dungeon while my desktop build does not. Something was going wrong, and there were no changes to the dungeon rendering code between my previous Android build and my current Android build.

I found it frustrating to debug on Android, but after a few days of poking at code and adding logs, and yak-shaving to try and fail to get debug symbols so that LLDB could tell me what I was looking at, I could narrow the apparent issue to a crash when rendering the ceilings or the floors.

If I removed the ceiling and floor rendering code, the game seemed to work just fine. So what gives? Well, when I render the ceiling and the floor, I create a buffer of pixel data, then update a sprite’s contents with that data.

In other words, I did something like the following:

void drawCeilings()
{
    const int pixelSize = targetDimensions.width() * targetDimensions.height()/2;
    Uint32 pixels[pixelSize];
    // Figure out what to put into pixels.
    updateSprite("DungeonCeilingSprite", pixels);
    ...

The drawFloors() code is almost the same.

This code works. Or at least, I thought it did.

Maybe I had some memory getting trampling due to new code? I tried removing all that new scripting and triggers code, and I still saw the same problem.

Ultimately, and I wish I had a better way to confirm it is true, I think my game is getting a bit big memory-wise.

I came across something about being able to set the maximum stack size of a thread, and it made me wonder: what if instead of setting up the pixels on a stack, I create them on the heap?

So I made the following change:

void drawCeilings()
{
    const int pixelSize = targetDimensions.width() * targetDimensions.height()/2;
    Uint32 * pixels = new Uint32[pixelSize];
    // Figure out what to put into pixels.
    updateSprite("DungeonCeilingSprite", pixels);
    delete[] pixels;
    ...

And the crashes disappeared.

This experience did get me to fix a few minor memory issues that valgrind identified that had nothing to do with this issue, but it also made me wonder if I needed to shrink the PNGs I was loading into memory at the start of the game. I worry I’ll be running into a similar issue soon.

But let this be a reminder of what Brian Hook said in Write Portable Code: you can’t say your project is cross-platform unless you actually build and run it cross-platform.

Anyway, after I did a bit more testing to try to make sure the crashes were actually resolved, I moved on to do something I’ve been looking forward to for some time: making the characters look better.

All of the graphics in the game have been placeholders until I figure out the look and feel I am going for, but until then, it makes for some ugly screenshots.

Weeks ago I got tired of seeing nothing but floating heads, and I decided to give the characters bodies, but throwing a skin-colored rectangle under the face sprite was probably not my best idea.

This is supposed to be a family-friendly game, but quite frankly, this was a little too phallic-looking.

Sorry. B-(

So now that I’m addressing the characters, I decided to give them better placeholder bodies.

My old attempt at a placeholder body was simple but problematic (in a different way). I was drawing the head, and then attaching the body to it, but then I needed to guess or do extra math to figure out where to place the character vertically so that the feet end up where I want. Some characters are taller or shorter than others, after all.

Now I start from the feet and go up. When I say where I want the character to be, their feet will be in that location. No guesswork.

Humorously, I did see what happens when I don’t correct the character location values.

But how does this new placeholder rendering, which is only slightly better than before, help with player customization?

Well, I have new menus in mind for character customization. One menu will be allowing the player to customize the body in terms of skin color, height, and size. Another will allow customization of facial features. Another will customize clothing.

So for now, my rendering code takes into account skin color, face type, height, and size, properties that are available in the character code. When I add the menus to modify those properties, I can see when they take effect immediately.

Unfortunately, chasing down that crash bug meant less time to dedicate to creating those menus, but I hope to make significant progress, including updating the face art so that it is a lot less placeholder-y.

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 was working on the intro script for The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I have since continued the work.

Sprints 27: Pre-production and initialization

Planned and complete:

• Create introduction script

I had envisioned a multipart introduction that allows the player to learn about the characters of the game and navigate their way around the home before finding themselves in the dungeon.

With the first scripted part finished and kicked off as part of the game’s initialization, I created triggers that would start the second and third parts.

The first script features dialogue with your Explorer’s Club friends, and ends with you on a quest to get snacks.

I created triggers that have arbitrary criteria, and one criterion I created was to determine if you had entered a specific room.

So when you enter the kitchen, it would start the second part of the intro script, which eventually sends you to the basement.

Entering the basement kicks off a third intro script, which ends with you discovering a part of the basement you didn’t know existed before.

This second basement isn’t visible in the house view until that point, but it features a ladder, and when you climb down and enter the dungeon for the first time, it kicks off the final intro script.

To make all of the above work, I needed to modify the triggers, commands, scripts, and menus to support a bit more flexibility and capability. Up until now, a menu option was always tied to a single command, but now triggers, scripts, and menu buttons can all kick off a series of commands. In practice, it means I can have a trigger disable itself after the first time it is triggered, while also starting a dialogue script, while also setting an arbitrary flag to a particular value.

Many years ago, I made a game called Stop That Hero!, and in it I created a data structure that could be any arbitrary data type that I would like. It turned out afterwards that I discovered boost::any was a thing, but my own code worked well enough, and I found it useful this time around, too.

Well, anyway, now that I have the intro scripts, I found that I didn’t like what I had made. It’s functional and it does what I set out to do, but in my head I have this colleague who once said that he hates long sequences of introduction that prevent him from playing the game right away. He hates it so much that he stops playing the game entirely.

And I realized that I had made just such an intro.

So I started thinking about ways to change the intro so that the player is more actively involved and driving things instead of passively hitting the “Continue” button until the blocks of text go away.

I’ve mentioned before how I want dialogue to be more than merely static text with branching, and I think this intro would be a good opportunity to figure out what the player should be able to do and how to make it work.

Unfortunately, before I could work on it, or on making the art for the characters much better, I discovered that while the game seems to work just fine on my development machine, it crashes when I run it on Android, specifically when entering the dungeon.

It is strange, because I have an Android build from a few weeks ago that runs perfectly fine, and I haven’t touched the dungeon code since that build.

The crash seems to point to a memory trampling issue, and I spent the last few days of the week investigating and debugging. Unfortunately, while I narrowed down where the crash seems to be occurring, it isn’t clear to me why it is occurring.

Creating an array of Uint32 shouldn’t cause an issue, but clearly something is wrong:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x74db82e79e88
Cause: stack pointer is in a non-existent map; likely due to stack overflow.

And I wonder if it doesn’t have something to do with the triggers and scripts, which need to live separately from the main GameData data structure, which may or may not be handled properly when I am periodically saving it.

So this coming week I hope to figure out why the Android build crashes. So far I have fixed a number of minor memory issues that valgrind found, but none of them seemed to be related to this issue.

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 last week’s report, I made it easier for me to playtest and improved the interface when in the house screen of The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I since set the work on creating a scripting system to get the intro going.

Sprints 26: Pre-production and initialization

Planned and incomplete:

• Create introduction script

I envisioned the introduction roughly as follows:

1. Dialogue involving the player’s main character and their friends in the Explorer’s Club.
2. Player puts together a party for 1st quest: go get snacks.
3. Go to kitchen, have dialogue involving parents, who send party to basement.
4. While in basement, discover secret room with a secret ladder that leads to the dungeon.

To start, I needed to change from hardcoded scripts to something a bit more general purpose.

I created a few data structures to hold the text, the id of the speaker so I knew which character to render along with the dialogue box, and a collection of menu options. Those menu options would have commands that would run when selected, with “Continue” setting the next script ID as the current script.

That part was easy.

The trickier part was allowing the scripts to handle variables. Since I want the player to be able to customize the names and looks of the Explorer’s Club members, I couldn’t hardcode their names.

So instead of “My name is Francis”, for example, the script text is “My name is {{friend[0].name}}.”

I don’t normally do a lot of text parsing, so I wasn’t familiar with what text parsing utilities I could leverage. My plan was to keep it simple, using std::string and find() and substr().

If I wanted to separate the script into words separated by spaces, those functions would be great, but it seemed my code was going to be more complicated when using the curly braces and brackets. Was there something else I could do?

So of course as soon as I asked in a C++ IRC channel for advice, I thought of regular expressions, and by the time someone responded, they just confirmed I was on the right track with that line of thought.

What was really annoyingly helpful was that someone fed a similar question into a generative AI, and it popped out some code that was more or less what I was trying to write. In the past I’ve seen people share links to FAQs or forum posts, but this was the first time someone asked an AI and gave me the generated response. My initial reaction was to hate this new development in IRC question-answering, but I was very impressed with the results. The regex string the AI generated to match with the curly braces gave me a quick shortcut, so at least I didn’t spend too much time trying to create that regex myself.

In case you are wondering, the regex is “\\{\\{([^}]+)\\}\\}” and you can read it as “get me everything between the {{ and }}”. My initial attempts were nowhere near that string, by the way.

I wrote code to parse out the variable name, the array index, and the property name.

Once I had all of those, I could then throw it at a growing if-else statement for various variables I want to support. So in this case, I would see “friend” and check which array index and which property, and then the code would use std::regex_replace() to substitute the appropriate text.

So “{{friend[0].name}}” would get replaced with the result of gameData.getFriend(0).name, which is “Francis” by default, and “{{friend[0].nickname}}” would use a different code branch to use gameData.getFriend(0).nickname instead.

Besides “{{friend[]}}” variables, I also added support for “{{currentLocationName}}”.

So now I have the ability to create the first part of the dialogue, with the main characters having an Explorer’s Club meeting. They are inducting a new member, and then someone suggests getting snacks.

Oh, and now that I can show different people talking, I found it frustrating with this placeholder art to know WHO was talking, so I added a label that shows the character’s name.

Eventually I would like to create a “quest” system, so upon finishing this first part of the intro, you get a new quest, with an initial objective to go to the kitchen to ask your parents for snacks, and new objectives getting added to go to the basement.

But for now, I needed a way to start the second part of the intro. Going into the kitchen should start a dialogue with the parents.

So I started working on a trigger system. A trigger has criteria, such as the player being in a particular location. If the criteria is met, then the trigger’s commands should get processed.

I decided that triggers should be either active or inactive. This way, the game isn’t constantly checking all potential triggers in the game, and it will be easier to manage if I only have to worry about accidentally meeting criteria or debugging wrongly successful criteria on fewer triggers.

For now, I have the one criteria, which I can use to detect if the player has made their way to the kitchen. I still need to have a way to enable or disable triggers, process active triggers, and process a triggered trigger’s commands.

But that’s work for the coming week.

In the meantime, I have also been trying to create a prototype for the meaningful dialogue system I want to create. Instead of merely branching dialogue with “correct” or “incorrect” choices, I am toying with the idea of conversation threads based on topics. Threads can progress (instead of being static), can relate to other topics, and can be “loose” or “tied off.”

What if each time you talked to an entity in the dungeon, you could pick up where you left off in your conversation, rather than get a stock response each time? What if that entity is actually interested in you, and so it isn’t enough to simply read some text and dismiss it. You have to answer, and your answer matters. Being dismissive might be an option, but the consequence is that you are seen as dismissive. On the other hand, if you are enthusiastic or deceptive or get caught in a lie, there would be other appropriate consequences.

That’s what I’m going for, anyway. I know I’ll need to prototype this part and try to create something enjoyable and feasible. I anticipate needing a LOT of writing to make this work well, but I want the focus to be on the game play rather than the text.

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 previous report, I created an Android port with the intention of making it easier to hand someone a demo, then placed residents in the titular house of The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I continued by making the ability for me and others to playtest a bit easier.

Sprints 25: Pre-production and initialization

Planned and complete:

• Quit to main menu

Unplanned and complete:

• Make house rooms into buttons

Unplanned and incomplete:

• Create introduction script

One of the ways it would be easier to playtest the game is if I didn’t need to close it and restart it to try it from the beginning each time.

I added a way to quit to the main menu, which sounds simple, and mostly was, but part of the work involved thinking through the user interface a bit more. Up until now, the house view was basically a view of the room or house layout and some buttons on the side.

It’s still mostly the same, but I’m trying to anticipate what else I might want on the screen. For instance, the player’s party should be visible in some way. I also need room for buttons that might always be on the screen, and others that are contextual.

Which of course begs the question of what buttons I expect to need. I know I eventually want a button that lets the player see the map, and even though it hasn’t been implemented yet, I think the needs there are obvious. I also haven’t implemented dialogue/conversations yet, but in this case I don’t yet know what I want to provide the player.

So for now, I gave the background a color other than black, created a gear icon to represent “settings” and gave the settings modal the button to return to the main menu.

Next, I was tired of having the right side of the screen full of buttons representing each room in the house, so I created a button out of each room itself. It was fairly quick work.

Finally, I decided it was time to start talking.

That is, I’ve been thinking about how to design and implement the dialogue/conversation systems for a long time, but I need to start making something real. The current intro script has been nothing more than hardcoded menus, and I need to make it more general purpose so that more scripts can be more easily written.

As I’ve said before, my intention is not to merely create a simple dialogue tree like most games. If all I wanted was an NPC who repeats the same sentences until you choose the correct response option, it would be relatively simple and easy to implement. After all, my game Toytles: Leaf Raking (which, by the way, is on reverse sale this week, so feel free to check it out) features such dialogue, so I can always build on what I’ve already made.

Since The Dungeon Under My House will be a non-violent game, I wanted to have dialogue and interactions become more engaging and interesting to replace the otherwise compelling mechanics of hack and slash that is typically in a 1st person dungeon crawl. I don’t want to merely disguise hack and slash mechanics. I want conversations to be a completely different kind of game play.

Unfortunately, while I have a number of different ideas and directions to go in, there’s a lot of unknowns still.

For instance, should there be random encounters? It’s typical for this kind of game, and while it might be challenging to ensure these encounters are interesting and varied, it might make the dungeon feel more populated.

Alternatively, what if the encounters are with entities that you can see beforehand, that take up space in the dungeon? Then the player can choose when and where to engage with an entity, and my own work to write dialogue is limited to the characters I purposefully created.

I’m leaning heavily towards the latter, partly because I want conversations to be meaningful and impactful. If you talk to an entity who sticks around, you can build a relationship, whereas having random encounters results in a lot of interactions with strangers you never see again and won’t impact your life much.

I’m envisioning giving the player options to speak with a particular type of tone, to have different intents with messaging such as amusing or scaring or inspiring, to brush off, to merely listen intently, and to do any number of the kinds of things people actually do when they interact with others. I want NPCs to have memories of how they were treated, to have goals that dictate how they treat the player’s party members and others, and ways to influence and be influenced.

For now, though, an intro script will likely look much more like a typical dialogue tree, introducing the player to the game world and getting them to their first goal as quickly as possible.

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!