Author: Gianfranco Berardi

In the previous report, I had started the work of designing dialogue systems, which required stepping back to design the concept of knowledge for a given character in The Dungeon Under My House, my second Freshly Squeezed Entertainment project.

I made some great progress in the last week.

Sprint 37: Pre-production and initialization

Planned and incomplete:

• Characters speak when TALKed to

As you know, The Dungeon Under My House will be a non-violent 1st-person dungeon crawler. Most dungeon crawlers tend to feature hack-n-slash game play at their cores, and at best you’ll find people saying, “Well, this game allows you to be a pacifist if you want.” But those games clearly still have violence as a key aspect of the game.

So if not violence, then what? The challenge I’ve set out for myself is to make conversation and dialogue the focus of the game.

But I’m not interested in writing a visual novel or the typical branching dialogue that seems to be the state of the art in most games.

And I’m not interested in merely dressing up combat so that instead of swords and armor you use insults and witty retorts. That’s still combat.

Instead, the game play of conversation will revolve around knowledge acquisition.

Maybe. I’m still learning about the nature of conversation and dialogue and relationships.

In last week’s report, I started implementing the concept of a character’s Cognition, which represents their knowledge, values, beliefs, and attitudes.

A character can know about Topics, which represent their awareness of something in the game.

And so the focus this past week was on taking this internal, foundational work that I did the week before and make it visible and tangible for the player, if only to make it less hand-wavy and more concrete for myself.

Seriously, I could spend a lot of time learning about linguistics, philosophy, and models of communication, but at some point, I do need to make something.

So I started out by letting the player click on one of the party members, which pops up a menu. Which presents an option to ASK a question, and then you can select any character currently on the screen, then you can select a Topic to ask about.

Now, right away, a design decision I have to make is whether or not the player has access to a party member’s knowledge. In this game, the main character represents the player. Yet there is a party you form with other characters. I think I like the idea that you would need to talk with your party members to share knowledge, and perhaps I can even provide an option to “chit-chat” so that all knowledge is mutually shared to make it less tedious.

Anyway, I have also been very concerned about how intuitive and easy it will be to go through the asking-question flow as a player. When you want to ask someone a question in real life, are you thinking, “I want to know more about that cat, so I will ask Chris” or are you thinking, “I will ask Chris, who knows something about that cat.”

So I decided to cut out one step by allowing the player to click on a character first, which already communicates an intent to talk with that character by the player’s main character, then click on ASK, then click on a Topic.

By the end of the week, I had a working topic menu, with some sample topics seeded which represent knowledge of the individual members of the Explorer’s Club and the main character’s parents, plus some generic topics.

I’m not an expert on user experience, but I was pretty proud of the idea of adding faces and icons at the top to make it obvious what you are doing at this step of the process.

I can already anticipate needing to provide built-in filters, such as People, Places, Things, or “Recently Learned” topics, or other things that might be useful to help navigate what I expect to become a very large list of topics. Maybe I can allow the player to choose specific topics to put into their first page so that they are easily at hand. We’ll see.

Once you select a topic, then a custom dialogue script is generated. Eventually the text and menu options can be more varied instead of always asking a question the same way, but for now I needed something I could interact with in the game.

Finally, since dialogue on the screen represented a situation in which the player had made a decision to ask the question, I now needed a way to persist this dialogue. I don’t want someone to ask a question, then restart the game partway through the discussion and have the game act like the question was never asked in the first place. All dialogue in the game is hard-coded at the moment, so this part took a bit of work, but now the decision is locked in.

So far, the question gets asked, but there is no response yet. Currently, no one in the game knows anything ABOUT the Topics they are aware of, so when I start working on it this week, the first thing to do is to create a simple response that will be the equivalent of a 404 error on a website: “I don’t know anything about XYZ.”

But then comes the real work of figuring out what Facts and Beliefs look like and how a character decides what to tell you, which leads to how you gain new knowledge, which I hope will be experienced as an exciting development by the player.

For now, I’m excited that this major aspect of the game’s design is starting to come together.

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