Category: Geek / Technical

Last time, I reported that I was working on iOS SDK updates for my existing projects, which required taking a short break from The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

iOS build automation

So as I said last time, much of my iOS port work tended to be manual, partly because Apple development environments are so bizarrely different from everyone else’s, and partly because Apple seems to strongly discourage build automation.

Well, sort of.

See, I made the mistake of thinking that build automation is the same as everywhere else: you write scripts using command line tools, and then you can specify configurations and kick off builds whenever you want.

But last week I found out that the reason why I couldn’t find much info about using xcodebuild is because it was buried in the docs for using the Xcode Cloud. “Oohhhh, of course! You’re supposed to do it the Apple way!”

Well, whatever, I’m not planning on using their Cloud services, and I’ve figured out much of what I need to do with CMake and xcodebuild as it is.

In fact, I think I am at the point when I can run a single script to generate an Xcode project and then build it and install it on a simulator to test it, and a different variation of the script to build and archive and upload to the App Store for validation and potentially preparing for publication. Nice!

Of course, as I said, I have an old Mac Mini that runs an old version of Xcode, so when I try to do so, I get a fun error:

Asset validation failed. SDK version issue. This app was built with the iOS 16.2 SDK. All iOS and iPadOS apps must be built with the iOS 17 SDK or later, included in Xcode 15 or later, in order to be uploaded to App Store Connect or submitted for distribution.

BUT what this error also tells me is that I’m probably ready to use Mac in Cloud.

Mac in Cloud offers a Pay-as-you-go plan. While I could have gotten the day by day plan, I decided to go with the hour by hour plan because my own development efforts match it better. Some days I only get an hour of game development in, and it would feel wasteful to have access to 24 hours and use such a small part of it.

What I didn’t anticipate was that I found myself not logging in to make progress because this past week I found myself struggling to find an hour that I knew wouldn’t be interrupted. My desire not to waste my limited hours conflicted with the need to make forward progress and my own time capacity.

It didn’t help that when I finally tried to log into the Mac in Cloud instance that I kept getting an error message. When I contacted help, they offered no help (other than a screenshot that indicated that they had logged into my account successfully) and instead offered help related to connecting to the server in the first place. Obviously if I got as far as the login screen and error messages, then I didn’t have an issue connecting, right?

But I clicked the link they provided, which took me to the same place, and I couldn’t login still.

So I decided to finally get a screenshot, and…suddenly I could log in? I must have been typing my username and password wrong this whole time?

And of course, by this time, I didn’t have the hour to take advantage of anymore, so I wasted a session. B-(

Anyway, I expect I’ll make the time this week, and hopefully building with the latest Xcode and SDKs won’t pop up too many surprises to debug and address.

The Dungeon Under My House scope

Meanwhile, I’ve been slowly plodding along with The Dungeon Under My House (TDUMH), and I recently decided to figure out just how much work is left.

You might be thinking: wait, you don’t know?

No, I don’t. No one really knows how big a project is at the start. You can pretend to know, but often your initial project plan misses things, sometimes very big things, and so you find yourself working on things you didn’t know you would be working on.

So my approach to this project was to try to identify some major features upfront, but also to be flexible enough to handle the addition of new features as I recognize their need.

As you may remember (since I bring it up a lot!), I’m a very, very part-time indie game developer. Between family, a day job, and other obligations, I only spend so much time on game development.

On average this year, I have done around 7 hours of game development in a week. Some days I do multiple hours, and some days (usually weekends) I do almost none. Even some weeks have very few hours while others have more to make up for them. In other words, my productivity is uneven.

As much as I would like more time to work on game development, I currently can’t see sacrificing other priorities in my life to make it happen. Given my capacity, I’ve found my plodding efforts are fairly sustainable. I feel like I could keep up this pace forever.

However, I know this project has been in development for a very long time. At least, calendar time. The actual amount of time spent working on it probably works out to a bit over 650 hours, although I don’t keep track of time spent on individual project, so any chunks of hours working on my previous game updates aren’t separated from these numbers. But most of the time is definitely focused on TDUMH, so let’s pretend 650 is a good rough number.

If this was a full-time effort for me, 650 hours works out to a little over 16 weeks, or ~4 months. That’s not bad. Another 6-8 months, and I can this project being not only finished but also highly polished.

But since it isn’t a full-time effort, those 650 hours are spread out over 20 months. I’ve spent 20 months of my life on slowly adding features and creating the game content to take advantage of those features, and I don’t have a game anywhere near releasable.

When I started this project, my intention was for it to be a six-month project. Not a six-month full-time project. A six-month project at my current game development pace.

It’s not great being 20 months into a six-month project with no sense of how many months are left.

So when I wasn’t working on iOS SDK build updates, I was spending time trying to identify all of the remaining work for TDUMH. I’m not finished with the scoping work yet, but I can say that there is quite a lot left to do.

Once I get a much more solid sense of it, I can make a decision about the future of TDUMH. My goal is to release games more frequently than I am, stay tuned!

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report, I updated the buttons to significantly improve the look and feel of The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

While much of last week was spent attending to other tasks, such as creating a devlog video about the last two months of progress, I did spend a little time on automating my iOS builds for Toytles: Leaf Raking and Toy Factory Fixer.

New mobile requirements

This work is generally applicable to all of my projects, not just The Dungeon Under My House, but it will benefit as well.

I like to ensure my game is available on as many devices and platforms as possible, so I write cross-platform code, avoiding proprietary technology as much as possible. By doing so, I am able to publish my games for Linux, Mac, Windows, iOS, and Android.

Unfortunately, Apple and Google like to update their requirements for keeping your apps in their stores, even if your game hasn’t changed.

For Google Play, it’s not so terrible: I simply get the latest NDK and SDK and build, fixing whatever little changes might be required that usually doesn’t affect my game’s code so much as the various Android-specific scripts and configuration. And I can do it on my normal development computer, which is a Dell PC I bought in 2013 running Ubuntu that has had some of the internal hardware upgraded and still works just fine.

But for the App Store, I cannot easily do the same. In fact, not only does Apple require that apps need to support iOS SDK 17, but that the apps must be built with Xcode 15, which means it needs to run on an Apple computer.

Both iOS SDK 17 and Xcode 15 were released about a year ago, and both are free. What’s the big deal?

Well, unlike previous updated requirements, this one comes with baggage.

See, I have a Mac Mini. I bought it in 2017, and despite it being fairly underutilized and otherwise perfectly working hardware, it’s old enough now to be considered officially “vintage”.

If you’re not familiar with Apple hardware life cycles, vintage means Apple stopped selling the product between 5 and 7 years ago, which limits how much support they provide for it.

In this Mac’s case, it stopped getting OS updates after macOS Monterey, which means the latest Xcode available to me is definitely NOT Xcode 15.

Next year, my Mac Mini will be considered “obsolete” because it will be after 7 years since they last sold that model of Mac Mini.

Ok fine, I just need to buy a new Mac, right?

Well, I’ll get to that. But first, the computer I have still processes bits and bytes just fine, and so I’m more than a little frustrated that Apple’s policies are forcing me to abandon the as-already-mentioned perfectly working hardware.

Yet Apple won’t provide new OS updates to this machine, which means no Xcode updates, which means I cannot use this perfectly working hardware to create and publish apps in the App Store anymore.

You know, if Apple sales were a real money-maker for me, I could see the investment in a new computer being a no-brainer cost of doing business. But they aren’t.

In fact, between paying $700 for the Mac, $400 for the iPhone SE to act as a test device (which of course is also now vintage), plus $170 for a used iPhone 7 to act as a second test device when I couldn’t reproduce an issue on the SE that was being reported to me from a customer, plus $100+/year for the Apple Developer program since 2019, I’ve spent a lot of money to ensure my games can be available on the App Store as it is.

In return, I can say that I’ve only earned back a total of a little over $100.

To be clear, that amount is the total since my first sale on the App Store in 2020.

I have not earned back my investment the same way I have with the one-time Google Play $25 developer program fee.

Now, you can say that I should be doing more promotion, that I should make the game more attractive, and it is my fault and such, and you’re probably right.

But it still makes me wonder why I should spend hundreds more for a new computer just because Apple insists that I need to use one.

Which is why I signed up for Mac in Cloud’s services. If I can successfully build and publish my games through THEIR modern Mac, I can pay significantly less than the price of a new Mac that Apple will call vintage within a few short years, and the only thing I need to worry about is testing on a real device.

The real challenge is that my iOS development up until now has been fairly manual.

I have a CMake file that allows me to generate an Xcode project. For some time I had pieces that I still had to update in Xcode such as adding images to the resources folder and setting up code signing, but eventually I updated my CMake files and other configuration to set those automatically, too. The only thing left that I did in Xcode was building and archiving the project, then uploading to the App Store to publish it.

But I’ve never liked feeling like I need to use Xcode. Almost all information and help out there assumes you are building through the IDE for some reason.

While I don’t find it to be a very fun IDE to use, the main concern is that I like scripting and automation better. Having a script you run to build your games can be a more consistent experience, and I don’t need to worry about forgetting how to do something when the scripted command is in version control.

So my work this past week has been trying to figure out how to automate the building of my project with xcode-build. I’m doing this work on my Mac Mini, because again, it is otherwise perfectly working hardware, but also because I don’t need to use up my Mac in Cloud hours.

Once I get it figured out on my own Mac, then I’ll switch to using the Mac in Cloud service, where I expect I’ll run into minor Apple-specific configuration requirements that I’ll only discover when Apple rejects my app for not having them or when Xcode 15 turns some optional configuration into a requirement.

Wish me luck. I hope it won’t take me long, and if Mac in Cloud works, the price is much more affordable, but I am wondering if next year’s $100/year Apple developer program fee will be worth it, and we’ll see how my efforts to sell my game in the coming year work out to change the equation.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Here’s the latest Freshly Squeezed Progress Report video, with footage covering the last couple of months of development, including this past week’s report: Improving the UI

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

Last week, I reported that I had fixed a number of defects and finished working with quantified items allowing the player to distribute snacks to other characters in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I needed to switch my efforts to supporting other projects but first I decided to tackle something that makes a substantial difference to the look and feel of the game.

Sprint 2024-31: UI – buttons

Planned and complete:

• Improve UI buttons shapes/images

If you’ve been following along from the beginning, you know that I’ve had some placeholder buttons in place.

Here’s what it looked like last week, which is what it has looked like for months after I did a slight improvement by creating the outline, but I was never happy with it:

And here’s what it looks like today:

I decided to take advantage of the Kenney UI Pack, part of the many free assets created for game developers to use in their games. Why haven’t I been doing this sooner?

I took a button that I liked, modified it so that it can represent different button states, and now this lifeless interaction:

instead looks like this:

Seeing it in action really helps explain how much of an improvement this small change made.

I also realized that it would help to have fonts that contrast better with the button’s color, so I tweaked some of my UI helper code to allow me to specify the font color, and I think it is definitely better.

What do you think?

The GIF doesn’t seem to make it clear each time the button is pressed, but I think that’s more due to the frames being dropped because in-game it looks fine.

After this small yet impactful change, I started to work on my existing games. Basically, Apple requires new and updated apps to be built with Xcode 15 and use at least iOS SDK 17, and my current Mac Mini is too old to support the latest Mac OS which is why I can’t run Xcode 15.

So I signed up for Mac in Cloud which offers access to an M1-based Mac Mini and development environment that I can remote into, and it lets me pay for hours instead of days. That’s great, because as someone who works very, very part-time, who sometimes only works an hour a day on my projects, I don’t need to feel like I’m wasting my money.

Still, I do need to make sure that I make those hours count, so I’m currently updating my games to use the latest libSDL2 and related libraries. By and large it is straightforward and everything is compatible, but of course the main sticking point is that Apple has new requirements that the library might not yet support.

I’m still investigating, but I know a lot of effort is being put into libSDL3, so it isn’t clear to me yet if libSDL2 will be able to support the latest App Store requirements.

And I’ll see how complicated this work is and if I think it might be worth it going forward. My apps haven’t actually changed, yet I have to go through this effort just to keep them up in the App Store, and I’m not sure if it is worth it.

I’ve been paying ~$100/year for the privilege of being in the Apple Developer program, which allows me to publish to the App Store, but I am not making anywhere near that from the App Store, and unless my marketing efforts start to change the numbers substantially, I’m just paying to lose money, which makes this annual porting effort questionable as a business activity.

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 possible to see furniture inventory previews such as Snacks on the Kitchen Counter and started the work of handling quantified inventory items in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I finished the quantified item work this week.

Sprint 2024-30: Giving quantified items

Planned and complete:

• Allow player to give/take arbitrary number of multi-quantity item

Unplanned and complete:

• Defect: Items added to inventory by command go missing after load
• Defect: Inventory preview renders in same spot on screen despite room transition animation
• Defect: Dungeon won’t render upon first entering
• Defect: Loading in dungeon seems to use previous move/turn state instead of latest

Sometimes seemingly simple things take quite a bit of effort to make happen.

In this case, I already had a way to transfer quantified items such as Snacks from furniture to the party’s inventory. I wanted to reuse the interface to give an item to another character, but it required a lot more work to make happen.

As I said last time, giving items is a two-step process.

First you select what you want to give. Then there is an attempt to give the item, and the receiver either accepts it or rejects it, currently based on their own Inventory’s capacity.

So unlike swapping out an item from a Furniture’s Inventory, which is immediate, there are edge cases to handle with giving quantified items.

For example, let’s say I have an Inventory slot with six sandwiches. I could give a character all six of the sandwiches I have in my Inventory. In that case, if they reject the gift, then I get all of the sandwiches back.

I could also give only one sandwich, keeping the rest myself. If they reject that gift, then the sandwich should be returned to the same slot that has the other five sandwiches. However, if I had my sandwiches split across two slots, then which slot does the sandwich get returned to? Ideally it would be returned to the slot that I swapped it out from originally.

And there are similar Inventory management concerns for other cases.

All this is to say that it took me some effort. I had to make changes to the Inventory and Item code to help make it easier, plus some code related to the menus involved with giving and swapping Items. Then testing to make sure I didn’t miss any edge cases and solving for the ones I discovered I had missed.

And of course, not introducing new problems, such as discovering that I accidentally made it possible to either completely lose the sandwiches or duplicate them. There should only be six total sandwiches in the game:

But once I got it all working, I could hand out snacks to the Explorer’s Club, which finishes the Snack Quest (official quests aren’t in the game yet):

One thing I did discover is that handing out individual sandwiches to everybody was tedious. I need to eventually look into a “Divvy it up” command to split things up faster.

Otherwise, I fixed a number of defects, the trickiest of which was finding out why entering the dungeon the first time would show a black screen instead of the inside of the dungeon. I thought it was an order of operations problem in that the dungeon was rendering before lighting was calculated or something like that.

It turned out that the player’s position upon entering the dungeon was initializing to position (0, 0), so that’s what would be rendered. In the map, that position is out of bounds at the moment, so there is no lighting, no walls, nothing. So the dungeon renders, and then to be efficient, it won’t rerender until something changes.

But the problem was that right after the dungeon renders, my code sets the position properly to the location of the ladder leading back into the house, but it does so in a way that bypasses the “something has changed” logic.

The problem is that player’s the initial dungeon location depends on the dungeon being loaded to find that ladder’s location, which did, in fact, require changing the order of operations for loading a game so that the dungeon was loaded first, then the game’s variable data (such as the party’s dungeon position) is initialized, then if the game needs to overwrite that data from a save file, it does so.

Anyway, I’m glad that issue is fixed. It was annoying.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I had finished the work of giving an item to another character and adding a trigger that produces an item in a furniture’s inventory in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I then wanted to make it possible to see such items when they are available.

Sprint 2024-29: Preview furniture in a location

Planned and complete:

• Show item on counter on actual counter in kitchen

Unplanned and complete:

• Defect: Crash when trying to add items to inventory after load

Unplanned and incomplete:

• Allow player to give/take arbitrary number of multi-quantity item

A Furniture object can have an Inventory, and when it comes to things like drawers and fridges, it makes sense that you have to open them before you can see what’s available.

But after you give the Pickle Jar to your parents in the kitchen, they make snacks and put them on the counter.

And after this past week’s efforts, I’m happy to say that you can now see what’s on the counter without having to open up the Kitchen Counter furniture view.

I created a FurniturePreview object, which renders on the screen whenever you are in a room with a Furniture object that has one associated with it.

While testing, I realized that I had some issues with persistence. First, I couldn’t figure out why the snacks weren’t appearing on the counter despite everything looking right, but debugging showed me that when I load the game from a save file, it wasn’t overwriting the default inventories but instead appending the saved ones after the default ones. So I addressed that issue.

But I also discovered that the snacks were disappearing once they were added to the counter if I immediately load the game afterwards. Basically, once an item gets added to a furniture, I needed to save the game. I decided to log the defect and address it after the work i was doing on multi-quantity items.

Before, moving items from one inventory slot to another was an all or nothing deal. It makes sense for single items like the Flashlight, but Snacks are quantified. So I added an interface to allow the player to choose a quantity.

The trick here is that I don’t have any real way to keep track of the transaction, so it comes to this interface, it is immediate. That is, if you decide to swap snacks with an inventory, the inventories update in real-time.

The interface for giving items to another character, however, is a bit different. Instead of immediately giving the item, it is a two-stage process.

First, you choose what you want to give. Then, you attempt to give the item, and if the other character has space in their inventory, they’ll accept it. Otherwise, the item stays in your inventory.

With non-quantified items, the item doesn’t actually leave the inventory of the party until after it is confirmed that the other character has room to receive it.

So I ended the week trying to figure out how to allow the player to choose to give an arbitrary number of a quantified item to another character in a way that is both intuitive for the player and isn’t ridiculous to code. Ultimately I decided to create a Give Item scratchpad inventory. That is, it is an inventory with the purpose of temporarily managing the giving of items.

Effectively, you are swapping immediately with this temporary inventory, then when the gift giving is confirmed, the other character receives it from the temporary inventory, but if the gift is rejected, then the party receives the temporary inventory back.

Of course, it is important to make sure it is returned to the correct character’s inventory slot, and now you can sorta see why game design can be challenging. B-)

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 finished creating the pickle jar, sped up the perceived loading of the game, and started the work of enabling the player to give items to another character in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I continued working on the feature of giving items.

Sprint 2024-28: Giving Items

Planned and complete:

• Give items to entity

Unplanned and complete:

• Show quantities of items in inventory

Unplanned and incomplete:

• Show item on counter on actual counter in kitchen

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

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

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

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

Planned and complete:

• Trigger intro script when pickle jar acquired

Unplanned and complete:

• Defect: Game startup takes too long

Unplanned and incomplete:

• Give items to entity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

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

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

Planned and complete:

• Show indicator when Friend has something to say

Unplanned and incomplete:

• Trigger intro script when pickle jar acquired

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

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

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

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

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

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

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

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

So how do you figure out who Pat is?

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

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

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

Sprint 2024-24: Stamina and resting mechanics

Planned and complete:

• Friends have stamina

Unplanned and complete:

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

Unplanned and incomplete:

• Show indicator when Friend has something to say

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!