With the project finished, there was still a bit more to actually do.
There always seems to be.
So, we cleaned up the itch.io page, and I added all the metadata I could to the project here for safekeeping. At this point, all I need to do is get the word out there that this is a thing that exists, and people should check it out.
..where to go from here?
I don’t know. I never thought I’d make it this far. It’s a finished project. A whole new adventure.
At long last, we’ve finished the project!
Took a little longer than we expected, but it is done! The “finished” build is going up tonight, and I’ll send it around to some folks I know to see if they have any feedback or catch any spelling errors before trying to get some hype around it from the internet at large.
I’m very excited!
Tonight, Sara finished up the cutscene while I coded them, and at long last all the assets and code are finished. We’ve even got a thumbnail:
Even more exciting, we have a name:
Pluck
Sara came up with it, which means she did the hardest part of this whole project. The word “pluck” is commonly used to describe taking something quickly, but it has another definition - bravery or courage.
We’re going to review all of the text in the game soon, and then send it out to a round of tester before calling it finished. I’m very excited.
I’d thought that all the programming was done, but a last-minute addition required a bit more - introducing red, your nanny pat friend that is also the game’s hint system.
We were already talking about putting him in - he’s part of the book Sara’s writing that this is based off of, and his omission would be weird. In the book, red is the one keeping an eye on you while Dad’s out, and so we decided that he would make a good hint system in the game.
The hint system for this game has been in flux for a while. For a few builds, a “?” icon appeared in the bottom right corner, and highlighted all interactive elements in a room when you hovered the mouse over it. That wasn’t awesome, though - it often drew your attention to irrelevant things, and the game doesn’t have any real pixel-hunting anyway. It didn’t solve the problem of “I’m stuck and don’t know what to do,” it just hightlighted things to click on and hoped the player would eventually click the right things.
Red now provides actual hints based on where you are in the game. Since you can have multiple quests going at once, I structed these as you asking red for advince on something, or maybe just complaining about a setback, with red responding with something helpful. Which quest is chosen for any individual interaction is random, maybe helping players stop persuing a quest they’re stuck on to try something new that they might have some success with (and hopefully figuring out something in their current quest while they’re at it).
I’m pretty sure that, past some minor work to get cutscenes fully finished, this is the last of the code.
The title says it all! We’ve now finished all the in-game graphic! The only remaining things are the cutscene cards; one for the intro needs color, and the outro needs to be finished and added to the game.
Tonight we added the sleeping sprites for Frank. We also added Red, a new character who’s going to handle reminder dialogs; soon, instead of talking to yourself when leaving, you’ll be talking to Red. He’ll also give hints, so if you get stuck he can rmind you what you still need to do, and also give you some hints about how to do it.
But the real important question: are we any closer to coming up with a name for this project?
No, no we’re not.
Sara’s been hard at work on the intro/outro cutscenes, and we’re getting really close. Tonight’s update includes two of the three intro panels finished (the last is almost done) and some additional graphical tweaks, namely the kitchen and bedroom got a bit more door on the right side to compensate for screen space hidden by system bars on android devices.
Once the last cutscene panels are done, we’re going to review the entire game’s dialog to ensure it’s consistent and call this done!
There are only a few TODOs left on the list. We got a couple done tonight; new sound effects were added, cutscenes were mostly coded, and I added some more polish while Sara finishes up the cutscene graphics. We’re going to try to make this week the last push; she’s going to focus on this project, and I’ll hop on in the evenings to do what I can to improve it. My biggest focus right now is decreasing the load time. To taht end I spent most of this evening trying to unwind what part of the initial load is taking so long.. and it’s still not totally clear to me. But I’ll get it.
I’m so excited to finally be finishing a project!
We’re getting really close to finishing this thing - the only remaining tasks are to make and implement the cutscenes, add the odd asset, comb through the text to ensure consistency and tone, and, of course, to name the game.
While Sara’s working on cutscenes, I’m trying to do some optimization to make the game load more smoothly, especially on mobile. Before tonight, loading on mobile took what felt like forever, including about 5 seconds where the screen was just blank. That feels bad.
My assumption was that the issue is the immediate loading of all rooms when the master controller is ready. That’s a blocking operation, and loading all four rooms at once like that is bound to be slow. But before I started in on that, I looked for lower-hanging fruit.
While I don’t have a good measure of load times at this stage, I am using exported and packaged file size as a proxy. When I started, the zipped game was 13969895 bytes (~13.3MB).
First off, I went through the whole project and removed unused assets. Super simple, super easy win - I removed ~813KB from the packaged file with no change at all to the resulting program.
Next, I read Godot’s docs on audio files, as I noticed that the sound
effects were well within the top 20 largest files (as revealed by
ls -laS */*/* | head -20). Turns out, Godot offers the ability to
compress and flatten files on import, making a signifant different for
the wav files I’m using for sound effects. Cutting out the stero
channel and using Godot’s compression removed another ~740KB from the
packaged game. Great!
A little more looking at the largest files in the game (this time
excluding audio files with a | grep -v audio chained in the middle of
the above command) revealed that the three files related to the backpack
in the living room were unexpectled large - every other image asset
except the background/cutscenes were under 100k bytes. Upon inspection,
it turns out those image files were huge, and were being scaled by a
factor of ~.126 in-engine to get them to fit in the room. I copied the
scaling factor for all three into GIMP and exported the downsized
images, and another ~962KB were saved. Excellent!
Finally, to address the initial loading time - Godot’s docs suggested
using preload instead of load for static resources to load them
with the scene. Since all four rooms need to be loaded when the game
starts, this seemed sane to me - no reason to load one scene, then load
four more immediately. Doing this actually increased the size of the
exported game slightly (~1.7KB), but it loaded noticably faster being
served from my desktop to my phone.
So, overall, I shaved off ~18% of the final file size. But how did it perform? Before uploading the game to itch, I grabbed a profile of the current build loading on my desktop, paying special attention to the time taken by the function call that starts the game (and the time between the loading spinner and the first room actually appearing). My inital sample was 1.78s of black screen while the game started itself. I then uploaded the new build and tried it, with an encounraging 1.14s as the result. That’s a 35% reduction in blank screen time!
But of course that’s not good enough.
Next I’m going to experiment with Godot’s threaded loading example found here. With any luck, I can use the intro cutscenes to hide the background loading, and have all the rooms ready to go before you even see the bedroom. In that case, the initial blocking load need only be the cutscenes themselves, and they should be comparitively small (and fast) when measured against what we’re doing now, which is loading the entire game up front.
Last week we did a first draft of the ending cutscene using an idea I had to animate it simply. If you haven’t seen it, go beat the game real quick and give it a look - it’s.. bad. And not because of the art; the aesthetic just doesn’t match.
I should’ve listened to Sara when she told me a few still images would do the job better. We’re moving in that direction now.
This weekend’s update is all about mobile controls. When I first got this running on mobile, I thought the “edge of screen mouse pan” worked, but it was immediately obvious when anyone else tried it that it was unintuitive - you just want to click-and-drag to pan on a touchscreen. So that’s what we’re doing now, and it’s effectively an entirely different interface.
Implementing click-and-drag panning wasn’t super hard (fortunately my initial camera code was pretty easy to modularize); the harder part was making the rest of the game work with that input style. For example, if you happened to tap on something you could interact with, you immediately got a dialog, and you couldn’t pan - super disruptive when you accidentially tapped something when attempting to just look around. The fix for this ended up being that on mobile, things are interacted with on mouse up instead of mouse down, and we track if you were panning the screen before the mouse up to know if it should count or not. Fortunrately again, the interaction code was simple enough to allow a function call to replace the existing condition without much fuss (although more places than I remembered repeated that check).
With that sorted, interacting with items became weird; it was more natural to click-and-drag inventory items, especially when everything else worked on mouse up now. So again, mobile’s input scheme diverges - on mobile, you drag inventory items onto interactable entities instead of selecting them and then selecting the entity. I think this feels prety natural.
So, I was also wrong about mobile input, initially. But being wrong is okay, because it’s how we learn. I’ve been playing The Witenss lately, and it makes wrongness a mechanic in some ways - it presents you with a simple puzzle to teach you, but as the puzzles get harder, your assumptions get proven wrong, and in doing so you get closer to understanding. I was wrong about cutscenes, and I was wrong about mobile input, but in being wrong I learned how to do it better.
Did we waste a night of work? Maybe. Or maybe we spent that night learning how to make the game even better.
Time for another concept art post!
Tonight, we started on the cutscenes. There’ll be two; the first will be at the very beginning, a dream of what happened right before the game starts to frame the story. The second happens when you get all the items and finish the game, and it’s already implemented!
The goal here was to take the existing objective framing and bolster it with some plot. The opening dialog says “Dad left last night and isn’t back yet” - who’s Dad? Where’d he go? Why are we worried? That’s what the dream will cover, at least partially.
When you finish the quests and leave, the exit cutscene is just you leaving - this game leads into the story of the book Sara’s writing, so the ending cutscene doesn’t cover much except giving more resolution than a dialog box.
Implementing these wasn’t actually that bad; I was worried that my
master controller wouldn’t like sharing with a cutscene orchestrator,
but with a simple cutscene_mode I got it playing nice.
Once these are done, plus a few odds and ends and some mobile polish, this game is finished. Very exciting!