The Final Stretch

I’m super excited to say that with tonight’s update, Sara and I both got something huge finished! We’re on the last stretch of this project before we can call it “done!”

Sara finished the living room - a massive effort on her part - and it’s been imported into the engine. It looks awesome. That’s also the last room done, and the remaining graphics required for this are very small.

An interesting fact here is that in addition to the entirety of the background, Sara also did her first normal maps (for the fire in the fireplace). They look really good, and the dynamic fire and shadows really bring the room to life!

Less immediately noticiable is what I did - I’ve finished mobile support! Check the game out on itch on your phone - it works pretty much completely!

Mobile support was a pain, mostly because the feedback loop had a lot of steps - export the game to a folder I’m serving on my LAN, load that page on my phone, wait for the game to load, see what worked. Testing it on the PC wasn’t really cutting it, as it didn’t represent the reality of a phone screen (and there was no touch support). Some of the functions I was depending on were pretty poorly documented, too - nowhere in the docs does is say that warp_mouse can’t move the mouse in HTML5 games, for instance (although I understand why it can’t).

So, what’s left?

Well.. not a lot, to be honest. We’ve got to proof all the dialog in the game, we’ve got to discuss and add cutscenes for the beginning and the ending, and most importantly (and most difficultly) we’ve got to name it. There are a few odds and ends besides, but nothing major.

I feel really good about this project. I can’t wait for it to be complete.

Mobile Support (In Progress)

While Sara finishes the living room graphics, I’ve been working on a stetch goal for this project - mobile support. From my investigating, it looks like that involves three bigs things:

• Scaling down the scene to fit on the mobile interface
• Making the controls work on a touchscreen
• Fixing the UI to center on the variable dimensions

But before even that, I need to detect if I’m running on a mobile browser or a desktop browser. Godot doesn’t expose that easily, unfortunately; the platform is exposed as “HTML5”, which doesn’t help. I did get that sorted, though, although maybe somewhat teniously.

The next point, scaling the display, is proving to be harder than I anticipated; the relevant functions are not super well documented, and resizing the canvas produces unexpectd results.

Making the controls work on a touchscreen seems pretty easy; the touch location is tracked as the cursor location, and all I’d need is to intercept “mouse press release” events and re-center the mouse in the screen to prevent continued scrolling.

Finally, the UI is going to need some work; dialog boxes should be easy to center, but the rest of the HUD is still in the same scene as the root node, and I don’t know if I’m going to break them out, or just move them.

I’m not sure what to do about changing screen orientation..maybe nothing. This might be a landscape-only experience.

Anyway, this week’s build has the start of it; there’s an attempt at scaling the display (doesn’t work great, but it’s a start), and the controls are at least partially fixed (you can pan in both directions). More to come next weekend.

Rough Week

This week I’ve got some minor improvements in the UI. Items in the inventory now highlight when you click them, and the locked door only shows the lock icon once you’ve clicked on it (and know it’s locked).

I played around with adding mobile support, which I think is just a few things:

• Detecting if the browser is running on a mobile device
• Replacing mouse controls with swipe controls for panning
• Scaling the scene to fit the mobile viewport

However, I got stuck on the first one! Godot has a “platform” which initially looked super promising, until I realized it returns “HTML5” regardless of what the browser is running on. From there I tried some hacky things with detecting touchscreens and using the JavaScript runtime to test it, but ultimately I gave up.

It’s been a rough week. Maybe by next Friday I’ll feel more inclined to work until 12:30 am again.

Accessiability

Last weekend, after publishing the update, I was feeling pretty good. This game was really coming together. I was excited to see someone actually play it.

Who better than my dad.

Now, I mean no offense when I say that my dad is not the best or most experienced computer user on the planet. In fact, he may well’ve never played a proper video game before, ever. So when I asked him to give our game a try, it was treading new ground for him. And that was perfect.

Watching him get through the first few tasks was very eye-opening for me. I thought I was designing this to be accessiable to people who aren’t familiar with commonalities of video games, but it turns out I’d made some assumptions I didn’t notice, like that you should click on things, or moving the mouse is part of gameplay.

To that end, this week’s update is mostly focused on making the systems of the game less mysterious to players that maybe aren’t familiar with video games in general. There’s now a “Click to Continue” prompt that appears on dialog boxes, but only a second or so after all the text has appeared (which means players that know what to do will probably never see it). We added a small tutorial section that instructs a new player how to look around a room (by moving the mouse) and how to interact (by prompting a click). This has a secondary benefit of guiding players to the right to begin with, which will lead them right to the backpack (and the first puzzle) and almost gaurentees their mouse will go past the front door, displaying its exit arrow and hopefully prompting a click (to show players where their ultimate goal is, and how to get a reminder of what needs to be done to get there).

I think the most eye-opening thing my dad revealed during his playthrough, though, was a total design oversight on my part: when asked to find water for the branch, he found his way into the kitchen, then saw a pitcher sitting on the counter and clicked it. He was then confused as to why nothing happened. I hadn’t even considered this, but I’d accidentially introduced one of the worst possible pitfalls in puzzle desing - a solution that makes sense, but doesn’t work for no reason! This one was an easy fix (now there’s a prompt telling you the pitcher is too heavy, we might remove it entirely), but it’s also got me looking over the whole game to make sure there are no more logical solutions that we put in the game that just don’t work.

The last thing I noticed was that it was hard for him to spot the cup. I moved it down the counter, but I also added a mouse-over hint icon that highlights all clickable elements on the screen, which should make it very obvious what you can interact with to avoid that situation.

On the positive side, with the few mechanics the game has described to him, my dad actually made it through the first quest. It was very exciting to see him think through the puzzles (he gave the branch the empty cup, triggering the “the cup is empty” message and reasoned that the sink was the right place to go!), and it gave me some real confidence that this is going in a reaonsable direction.

Once we get a little more done, I intend to seek out more testers of various levels of video game experience. Hopefully we can get the whole game very welcoming to anyone who would play it; the intended audience isn’t limited to just gamers, after all.

Sound Effects!

Tonight’s update has been a long time coming; sound effects! Pat and I took some time last weekend to bring a microphone around the house and record various doors opening, water pouring, and other odds and ends, and tonight I poured over Audacity isolating samples, boosting them to a proper volume, and then importing them into the game.

To be honest, it wasn’t as hard as I thought.

As far as Godot goes, the only real issue I ran into was for PickupItem sound effects; they previously removed themselves from the scene on pickup, but that also removed their AudioStreamPlayer, meaning their sound effect would play, but immediately the player would be removed. It was somewhat perplexing, but after a while scratching my head I realized what was wrong, and now PickupItems only hide themselves upon collection (which is effectively the same).

I think the most eye-opening thing was how sounds that were recorded in one context (a physical object doing something) can easily be given an entirely different life in a new context; for example, the door opening sounds I’d intended for the dresser in the bedroom just didn’t sound right, and using the squeaker kitchen cabinet samples just felt better - even though the original samples were basically the same sort of furniture! For the next round of effects, I’m going to try to think more creatively about what can produce the type of sound I want, instead of trying to capture literally the sound a specific object makes.

All Quests Complete

This is a huge milestone for the game: ALL QUESTS ARE FINISHED!

That’s right, as of this commit, the entire arc of the game is playable! That’s not to say the game is finished; there’s still plenty to do before it’s done, but it’s done-ish!

This time, I added the quest for the Sword & Sheild (as described in the last post), and tweaked a few existing things. Notably, I added a cool particle effect to Frank in the cellar, which I think goes a long way to bringing that room to life. I’d like to add at least one effect to every room to add some extra interest to the scenes; the bumblebee in the kitchen is unexpected and brings the room to life, the fire in the living room adds some motion and interesting shadows (more to come when the room is finalized, as I intend to have flickering shadows in the stones lining the hearth as well), and now the cellar has a particle effect for Frank sleeping. The only room without something is the bedroom.. which I’ll have to think about.

The next big piece for me to work on is sound effects; I think that having a small sound clip for most interactions (or at least most interactions that amount to something) will really add some polish. We also intend to add cutscenes, one in the start and one at the end, which should serve to frame the story nicely and give you some additional impetus/resolution.

I don’t want to set unreasonable expectations, but I’m going to push to have this game finished by the end of March. Just a little later than the initial goal of “before January 6th”.

The Final Quest

The original concept for this game included the “tutorial quest” of getting your backpack, and then three more things to collect, each a “quest” of their own, which you could do concurrently. Tonight, I started on the last of them.

This quest involves getting a sword and shield from over the mantle of the fireplace. In order to reach, you need the stool set before the first, but there’s a problem; a domovoy lives in the fireplace, and he’s not having it! In order to get the stool set in place, you need to appease him (with cookies!).

This seemed pretty simple to implement, until I did it and realized it would be a lot more impactful to actually have the stool (with the cool shadow effect) in place while the domovoy objected; that required chaining dialogs, which didn’t work as easily as I’d’ve hoped as functions aren’t first-class entities in GDScript (at least not until 4.0). As such, some additional infrastructure was needed in the MasterController to support dialog_finished callbacks.

We’re very close to a fully functional game now; at this point, I mostly need graphics, and to get some cutscenes in place. I’m also looking at recording and implementing sound effects sometime soon.

Imp Quest

This Friday Night Jam, we’ve got the imp quest “finished!” And by “finished” I mean that most of the graphics are done, and all of the dialog is temporary - but it works! This is a great time to introduce Frank:

I don’t know if Frank is going to be his final name, but this little imp guy is central to the second quest - he guards the potion you need to leave the house. Frank likes liquor, so you’ve got to give him the bottle in exchange for the potion.

Frank is eventually going to have a rotating dialog pool, where some of it includes hints on what he wants, and some of it builds the characters of the game. These might even get put in before we publish the next update. But for now it’s tomorrow, and Brett’s heading out after this YouTube video is done.

Proper Signposting

We watching a pretty good video on adventure game design by the Game Maker’s Toolkit channel that emphasized the need for signposting in point and click games, so this commit aims to make sure the player can’t get too stuck at any point, by making the front door behave like every other door in the game (with an icon when you mouse over it) and by having it detail what you need. Aside from this, I think we had most of the advice already covered; I have played a decent amount of adventure games.

Bumble Quest

This Friday Game Jam, I wasn’t really feeling it. Maybe it was a particularly busy week at work, maybe it was rewiring some lamps earlier this evening, or maybe I was just tied, but I sat down with my Bang! energy drink and didn’t have any ideas.

So, while the last episode of Netflix’s pretty..bad.. Dracula series played in the background, I started on finishing the bumble quest. I made pickup items that depended on game state, and once I was done I noticed the warning that a subclass was overriding a parent class’ variable - lo and behold I’d done the same thing last week, and so similarly that some of the variables were named the same! At least I’m consistent.

That aside, it was a hugely successful night! Sara finished the bumble graphic, and I finished the coding - now the game isn’t over until you have a backpack and honeycomb. Here’s the concept:

This is a fairly simple quest, but with a one-off mechanic; when you open the kitchen cabinet, a bumblebee flys out with the honeycomb you need. It avoids your mouse, and continues buzzing around the room until you offer it a flower. You make this offer by selecting the flower from your inventory, but not actually clicking anything (causing the flower to follow your mouse). Once the bumble reaches the flower, it’ll trade you for the honeycomb it’s carrying and fly off.

I realized tonight that the mouse interactions were still wrong sometimes, and by drawing what I thought was the mouse position, I realized why: the mouse position wasn’t being moved to account for room panning! Once that was sorted, it behaves exactly as I’d expect.