Development continues as per last post… but with some side-tracking. Just enough side-tracking that I ended up completely forgetting about my blog last weekend, and not even realizing it Friday.

Checklist

• fixed a ton of bugs and loose ends in Alice is Dead
• pushed forward a bit on drafting out Alice is Dead
• cleaned up and refactored a common library
• got pulled into some theatre shenanigans

Alice is Still Dead

Not a lot to report, as most of the fixes and changes are relatively small, but overall they add up to quite a lot of progress. I’m excited to put together a new demo soon (!) to let people see the changes; we took down the old one because it was getting rather long in the tooth.

On top of that I’ve also begun to draft out the next section of the game. Since I’ve built our tooling for Alice is Dead (and Godot’s editor works by default) in a way that makes it very easy to swap art in and slightly adjust positions of things, I can build out the functionality for rooms with art that only passingly resembles the final art. For areas that we don’t already have the final art, rather than just twiddling my thumbs uselessly until Hyptosis gets the final painting done, I have started scribbling out some rough drafts based on our notes and discussions.

This means that some of the art can be wildly out of place and tonally jarring with the game, but we just use our imagination to pretend it’s not – it serves its purpose either way.

As an aside, we actually built a whole game this way – I drew the rough art for the whole thing and then he just sprinted through painting it as fast as possible. It worked pretty well, at least from my point of view! It meant that I could try things out with drawings that took me five minutes and he didn’t have to waste time drawing and painting anything that didn’t actually get used. There are a few final things to finish with that game, and neither of us have touched it in years… Maybe we’ll put it out some day, or maybe its bits will get recycled into something else. The code I wrote for that game actually formed the basis for what I built for Alice is Dead, already.

A Collection of Common Code and Scripts

I start a lot of little projects and prototypes (probably more than I should, honestly, but that’s a separate thing). One thing that I always feel as a big drag on that, though, is just… starting something new. It means a lot of clicking things to set stuff up, you don’t have any of your nice utilities you’ve set up, and you’re bound to forget something or other when you just go and copy stuff from old projects.

Back when I was making a bunch of games as fast as possible a few years ago, I really felt that pain as I was starting them. If you only want to spend two or three days on a game, then spending an hour getting your development environment set up right is a significant amount of that time. Along with that, with Escape from Evil Island I decided to actually export to itch, and figure out how to do it (relatively) correctly – and I didn’t want to have to figure that out over again next time I wanted to deploy something to itch.io, so I wrote it (relatively) re-usably.

So where does all this go? I’ve been gradually putting together a library/base project/collection of utilities/whatever you want to call it, which has all the basic parts that I find myself putting in games over and over. It’s grown considerably over time, and over the last week or so I decided to finally cross off some things off my to-do list that I’ve been meaning to do for months. I creatively call my base library gd_base (because it is godot-specific), and at this point it has…

• a singleton to take care of all the “global” state (this actually recently changed from an autoload to a mostly-static class)
• a boot-handling scene
• an empty class to do all the game-specific setup, separate from the global singleton
• the basic directory structure I like to use
• built in config loading and saving for things like input config and a fullscreen toggle
• basic sound handling and setup
• generic menu handling (supporting keyboard, controller, and mouse)
• some general utilities for input state handling, asynchronous stuff, etc
• addons that I want in all of my projects (right now I just have gd_editor_size in there)
• bash scripts for handling exporting (on whichever platform you’re currently on), and deployment (to itch and/or steam)
• an install script to copy everything into a new directory, including setting up configuration and paths (if possible)

I may be forgetting some specifics about the setup, and I admit that there’s also a lot of cruft in there that doesn’t need to be there, or needs to be refactored! I’ve been treating it as sort of a “living library” – while working on a project, if one of the library bits doesn’t work the way I want it to, I’ll change it, and then (likely quite a lot later) I’ll go and see if I want to adopt that change, or something like it, back into the main gd_base repository.

I have probably (definitely) put more work into it than I’ve ever “needed to”, but having it as a way to quickly get going on a new prototype or game jam idea is valuable to me – and having a solid way to leave notes and scripts for myself for the future, to get things like deploying to an external platform working, means that I just have some peace of mind that if I’ve managed to do something in the past, I’ll be able to do it in the future. I think everyone who intends to make more than one game should consider doing something similar. You don’t have to sit down and make yourself a bunch of bash scripts or a bunch of finely-tuned utilities or anything right away, but if you find you’ve finished a game, maybe take a look at some of the code you’ve written and think about whether you might want to use any of it again! If you do, maybe put it somewhere that you can find it more easily. You can grow it over time – in fact I’d argue that it will only be useful if you grow it over time, using bits and pieces you’ve actually used to solve problems.

I likely won’t ever publish gd_base, at least not in its entirety. It is quite personal, in the sense that it is built very strongly around how I want to lay things out and work within a game, but that doesn’t mean that I necessarily want to hold it up as some sort of panacea for anyone else’s problems, or strong example for How Games Should Be Made. The real value in it is that I built it myself, and I’m just not really convinced that it would be especially useful to anyone else.

Theatre?

I did some stage acting a long, long time ago, and I enjoyed it a lot. It then, unfortunately, fell by the wayside as things do in life. I’ve had passing thoughts about getting back into it for many years (basically, since I stopped doing it), but I’ve never really had the time, energy, or general wherewithal to even try to make it happen. Last year, I got the opportunity to do sound design and sound tech work for a local theatre company, and I had a blast. It was a huge amount of time, though, and I wasn’t even on stage – the actors, stage hands, set designers, and so on all put in far more hands-on time than I did, but it was still a lot for me at the time. Circumstances have changed and I have even less time now (compatible with doing theatre, anyway), so unfortunately, I haven’t really figured out a way to go back for a second round.

Except that, when I went to see a play put on by that same theatre company last weekend, the stage manager (who was the director of the previous play I’d worked on) came out and asked me what I was doing next week, because their sound guy had gotten sick. So I’m running the sound booth for another show! It was terrifying to step in to a show nearly halfway through its run, but thanks to notes from the sound designer and patience from the cast and crew, it’s been a lot of fun. That is likely why it didn’t cross my mind to post last week – but things should settle down again after this weekend.