It’s been a while and it’s been… quite a month. A lot of Life(tm) happened, limiting what I had time to do, coupled with other bits of Life(tm) happening which left me, frankly, in a state where I wasn’t in a good emotional state to do much creative design work on Deck & Conn.

But, I’m me, and my brain also perpetually tells me I Need To Be Doing Things, so I found other ways to be productive this month.

In short: the game now has a working Windows build, there’s an audio engine in it, and there’s a new generic data load/save system. Oh, and I did some more art for the game.

Windows

I am not really a Windows person. I used to be – hell I think my MCSE might still actually technically be valid – but I’ve not really voluntarily used Windows for much in a few decades now outside of the odd game. Which certainly meant that I stuck to developing on the tools & system I know and love – Xcode and macOS. Which is fine for me, and fine for the like 4% of indie gamers who use mac, but at the end of the day I knew that even for beta testing, I’d need to port it to Windows.

I was going to wait until I had more of the mechanics finalised but something I can’t go into right now came up last month which made me decide that the Windows port should suddenly take priority over other things.

Fortunately, past-Elissa did a pretty good job of sticking mostly to C++ standard libraries for everything, so the port job from Xcode / macOS to Visual Studio / Windows was far less painful than I’d feared.

In fact even much of the file handling which in engines past would have required writing win32 equivalents to the POSIX-style file handling required no effort. As this engine is done in C++20 instead of more archaic versions, I was able to use std::filesystem for most of the general purpose file stuff.

In all, it took me about 4 hours to port to Windows, which has to be a few record for me I think. Given this is the fourth time I’ve ported something of mine to Windows or Linux though, at least by now it’s become a bit more second-nature what kind of things to avoid when coding that stick you to your core development platform.

It’s for now just a Visual Studio project, but I think what I might end up doing is making a cmake configuration to make the windows/linux build process semi-automated in a slightly easier way.

But I’ll think more on that in the future.

SOUND!

Another thing I wasn’t sure I’d be doing before alpha is sound but… let’s face it, without sound you’re missing a lot of the Vibe of a game. Especially for something like this.

In the past, I’ve used a few different sound libraries for games. I used fmod once, which is a great library but… for something small like this, I didn’t want to do battle with something proprietary, especially if I wasn’t going to use 90% of its fancy features.

My next thought was to write my own engine from SDL itself. Which is nice in theory but… the messy process of loading chunks, playing them back, performing callbacks, etc… that was too much work, and I knew that someone has to have done this before. Sure enough, they have.

I ended up deciding to use SDLmixer. It’s simple, integrates with SDL nicely, works on every platform I need it to, AND is fully open source like SDL itself so I can do manual port jobs if/when I need to.

Atop SDLmixer I made myself a pretty basic game sound engine. It functionally has four features – play a sound, play a sound on loop, play a sound while fading it in and/or out, and then there’s… advanced sounds.

These are for things like the ship’s engines. These are actually three sounds – a ‘start’ sound, a ‘stop’ sound, and a looping ‘is running’ sound. To ensure my engine was working I then put some test sounds in place. So for now, there’s ONE button with a click sound, an the APU has a working advanced sound loop.

I designed the sounds using Audacity and Logic Pro X, using creative commons 0 / public domain samples from Freesounds. That’s basically what I’ll be doing for the rest of the sounds, when I get to them.

But for now, at least knowing the code works is the important thing.

Config & Data Files

As I ramp up to alpha testing (reminder: for this project, alpha testing is what I am considering the bulk of the core combat & gameplay loop being functional, but not the campaign/metagame stuff), I realised something else I’ve been putting off that I need to do is scenarios.

On paper that doesn’t sound like a massively difficult thing… because it’s not… but it does also mean that if I didn’t want to hard core all the scenarios and map files in, I’d need a file format for them.

I decided that one of the things I most want for this game is to move as much of the game settings, data, maps, scenarios etc into human-readable (and human writable) files.

I mused on this a bit and then decided that simple was best.

What I came up with is this: KVF files, or ‘key/value files’. Essentially, a slightly different and easier to write version of old Windows style .ini files.

Each file has commands (any line beginning with a # symbol), sections (any line beginning with the $ symbol) and then any combination of key/value pairs.

The game loads the values as strings, but can also automatically convert them into integers, floats, lists of integers, or lists of strings.

The file system also supports a few variations to make lists, to give me a few more options for legibility within the files themselves, especially if I am not the one doing the writing.

For instance…

mylist=first
mylist=second

The second line here will not over-write the value of ‘mylist’ with ‘second’, but instead append it – making a list of strings.

This code produces the same result:

mylist=first,second

This allows a very large list to appear one per line, and a small list (such as the x,y locations in the above example file) simple being a single, easy to read line.

I’m going to use this file format for everything – game config settings, map data, configuration data, even game save data.

This would make loading and parsing files a bit bigger than binary serialised blobs, of course, but something I very much want to do with Deck & Conn is not restrict players. If someone wants to futz with their save files? Fine. Make their own maps? Fine. Design their own campaigns? Fine. Produce mods? Also fine.

Something I’ve learned over the years is that the way you would play a game, and how you would get enjoyment from it, is not a universal truth.

It’s Art, Mr Ebert

And finally, I also decided, when I hit a total wall, I decided to just chill and begin working on some art for rooms that will be useful in the next few months.

The main ‘room’ of the ship is the one you see screen shots of in every blog post. This one:

This is the main bridge. However, other rooms are simpler. This is the one which you’d have also seen if you follow me on mastodon, or have been reading these blogs – the communications room.

Without repeating my dev log post on the making of this room, the short version is that I had to decide on an art style for these rooms.

In the final game, I anticipate the following “rooms”:

• The comms room aboard your ship (as shown above)
• A bar on a space station, serving as the main space between missions, and the background you see when at the game’s main menus
• A computer on a space station where you can select missions, make crew staffing choices, etc
• A mechanics deck on a space station, where you can upgrade your ship and talk to the mechanic about the latest state of the vessels that are fighting around the galaxy

Given I knew I’d want it (if not need it) for alpha testing, I decided on the space station bar.

So, my first task was to do the basic modelling. For this I used tinkercad, though for some more complex rooms I might end up using Blender.

That resulted in this:

With this done I sat down and began to sketch out the basic colours, shapes, and finally the shadows.

The art style is designed to evoke the sort of ‘detailed but not TOO detailed’ pixel art which was common in military and scifi games of the early ’90s, and also not take me too long – I could spend weeks touching every screen up to look hyper detailed, but I also want to release the game some time and not still be working on it in 2027.

And this is the result. An empty room, a KIA/MIA board for vibe, and a desk up front. I will probably also finish off a few other details here. I am thinking I might put a retro Osbourne One-like portable computer on the table in front of you, and when it’s in the game the screens will blink/animate a bit, and ships will periodically fly by the outside. Keep in mind, however, that most of the time this screen will mostly be background art as the main menu (and any sub-menus) sit atop them to one side.

And that’s it for this month. I can’t tell if that’s a lot of work or not. Some days it doesn’t feel like it, as I’m still not quite done with the AI for enemy ships but… other days it feels like a lot.

Regardless, my next steps are: finish implementing maps & scenarios using the KVF files, make the main menu for selecting scenarios, and finish the combat AI.

From there… well, Alpha, I guess. Then it’ll be testing & combat-balancing time!

Exciting.