Category: Geek / Technical

Last week, I reported that I had finished clothing customization, fixed an issue with the Android build, and then created a way to configure your party in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I finally started serious and earnest work on what is probably the biggest key to this game’s design: the dialogue system.

Sprint 36: Pre-production and initialization

Planned and incomplete:

• Characters speak when TALKed to

When I started the week, I had plans to add menu options to let the player initiate a dialogue with another character or multiple characters in the vicinity, either by telling someone something or by asking about something.

Right away, I realized that I needed to step back and get those “something” concepts figured out. I needed to get from hand-wavy and vague concepts to something concrete and playable.

Now, it isn’t as if I haven’t been thinking about this topic for many, many weeks. I’ve got browser tabs open that are almost as old as this project is, each pointed to various forums, Reddit threads, and Wikipedia articles.

I spent much of the early part of the week reading about how communication and dialogue works. It turns out that this topic isn’t covered in a single field of study, such as linguistics. Everything from sociology to philosophy to anthropology to computer science to screenwriting touches on theories and models of communication. It’s a rich research area, and I know that I’m barely scraping the surface when I look at the Wikipedia articles or references.

I’ve also found posts online from other game designers trying to tackle the challenge of making dialogue compelling. Once you skip over all of the replies from people who can’t get past some surface concerns, there’s some real interesting directions to go in, such as this post about how modeling relationships with NPCs is the same as psychological simulation, acknowledging that there is no simple way to do it.

I just finished listening to The Great Courses: How Conversation Works by Anne Curzan over the weekend, which taught me concepts such as the locutionary, illocutionary, and perlocutionary forces, as well as putting names to the concepts I was toying with of report talk (functional, information transfer) and rapport talk (about relationship/affinity).

And of course, Chris Crawford famously left games to work on furthering interactive storytelling, and he had the advantage of dedicating himself full-time to the effort. His focus was on making a new form of drama rather than a new form of game.

And while I’m not interested in doing the same, I think it helps to know what has come before.

I don’t usually give myself a lot of time to play games, since my time is so limited for game development that it feels hard to justify not doing game development when I have a moment of “free” time. But I made some time to play Oxenfree and Signs of the Sojourner over the last few weeks, as each did something a bit interesting with dialogue.

Oxenfree was a delight to experience (how did I sleep on this game? Oh, right, I don’t play games as much as I would like), even when there were times that a character would interrupt his own line of dialogue or when Clarissa would reply outside of the house when I was inside perusing books on shelves, which was creepy in a way that the game didn’t intend.

And Signs of the Sojourner makes the deck-building game all about conversation. In each conversation you try to match cards with someone, and if you do well, you get some good responsive dialogue, but if you don’t manage to match cards, then it represents a failure in communication somehow. And the game simulates overall exhaustion by giving you cards that can’t match whenever you travel, and if you have too many such cards in your hand, you might have no choice but to fail a conversation.

However, both games still seemed to boil down to pre-written, branching dialogue under the hood. Even if Signs of the Sojourner has you play a game rather than choose your dialogue, you still encounter either a “good” script or a “bad” script.

And while I know that some people are experimenting with generative AI creating dynamic dialogue for NPCs, it is only really solving the “what to say” part, but it is still doing so within a framework of typical dialogue as seen in most games.

I’m more interested in figuring out how to make dialogue playful.

And since I like to keep pointing out how part-time my efforts are, I’ll take this moment to say that I both love all of this research and hate it. On the one hand, it gives me a base to stand on. I didn’t make up what I’m doing from scratch, and so it should be more familiar and understandable to a player. It’s based on the state of the art of humanity’s understanding (or at least my understanding of humanity’s understanding).

But on the other hand, I wish I could spend a lot more time living in the rabbit hole, experiencing other games, studying research papers, and corresponding with experts to get a feel for what that understanding is. But since I have a day job and a family and other obligations, I allow myself only limited time to work on my game development efforts, and it is even more important that I pay attention to how much time I spend on something that doesn’t get the game released.

It reminds me of how much I could accomplish in a shorter period of time if this was my full-time endeavor rather than something I make an effort to give space for. And I always feel like whatever I create is the equivalent of a child’s drawing when that child has no understanding of light, shadow, shape, line, and perspective.

And I suppose the only thing that helps is knowing that it isn’t like a ton is riding on this one effort. It doesn’t have to be my best and last. It just has to be my best that I can do right now, which can inform tomorrow’s efforts.

So what if I take this Freshly Squeezed Entertainment project as an opportunity to explore one approach that I might take? And the next project can be either a different approach entirely or a refined version of this one.

After all, I don’t have to solve “compelling dialogue in games” in 2023. Or 2024.

So as I said, early in the week, I recognized that I was in a rabbit hole of Wikipedia articles, and while I like it there and don’t want to be pulled out yet, I also want to prototype and play with something sooner rather than later.

I’ve mentioned in previous reports that conversations can revolve around Topics. So before a conversation can happen, those Topics need to exist. And the characters need to know about them.

So I created a Cognition object that each character has. Maybe I should have called it a Mind? Too late. The file is saved.

Anyway, a character’s cognition currently represents their knowledge, values, beliefs, and attitudes. If a character doesn’t “have” a Topic, then they aren’t aware of it, and so they can’t ask about it, and they certainly can’t tell someone else about it.

What they know about the topic could range from very little to being an expert on it, depending on what Facts they might have collected related to that topic.

BUT they could also have Beliefs that may or may not be true. So those beliefs aren’t verified facts, just assumptions or hearsay. They believe X, and as far as they are concerned X is true, but in objective terms, X could be false. And they might have a range of certainty of those beliefs.

Assumptions/Beliefs can be verified or falsified, which may depend on the character’s willingness to deal with the truth when it doesn’t match what they wish it could be.

But I’m getting hand-wavy again. In concrete terms, I created a character’s Cognition, which has a collection of Topics representing awareness of some subset of all of the Topics possible in the game. To start, the Explorer’s Club characters can know about the club and its members (each other). They can know about other characters, such as the player’s parents in the kitchen. They can know about rooms such as the bedroom being a meeting place and the kitchen and the basement.

I was hoping to implement a way to allow a player to see the topics that their main character knows, but I ran out of time before the week ended.

That said, despite not having much to show in-game, I was able to create a quick prototype using a deck of cards to see what it might look like to have three characters, each with some set of topics, and see how knowledge can get shared and disseminated. It helped me see that having Topics representing awareness is fine, but having Beliefs about a given Topic gives the player more tangible things to play around with.

Perhaps having a Topic means the player can ask another character about it. “What do you know about SAILORS?” for instance. But you can’t volunteer information about sailors if you don’t have any facts/beliefs collected.

Currently a Cognition has Topics to represent awareness, and a Topic has Beliefs to represent knowledge about that subject.

And remember, those Beliefs could be wrong, so there might be contradictory Beliefs or disinformation to deal with.

I’m hoping that learning a new key Belief/Fact is going to be as exciting as discovering a magical piece of weaponry or armor usually is in a typical first-person dungeon crawler.

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 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!