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.
Note: this blog post is sort of a stream-of-consciousness post, and largely based off my own memories and readings over the years. Some things here I may have misremembered, and may be incorrect. Hopefully they won’t affect the point I end up heading towards by the end of the piece.
Me & Film
In 2011, I became a video game developer. It was a sort of happy accident, in a way. A confluence of things – from a contact through a former co-worker to my side-line as a video games critic – lead to me (accidentally) pitching a video game idea to an acquaintance who ran his own studio.
Not to diminish the enormous amount of work that my brother and I put into the next decade of our life making games together, but the kick-off event was completely and absolutely accidental.
Before that, if you’d asked me what I wanted to do with my life, I’d have answered “make films” without hesitation. And that wasn’t just a pie-in-the-sky dream, either. In the years before 2011, much of my ’20s, I had finished two micro-budget feature films, a dozen odd short films, two web series’ and that’s without getting into the numerous failed projects – things that remained incomplete for whatever reason.
So in 2010, it 100%, to me, looked like that was my future. It was something I loved, and I couldn’t imagine doing anything else with my life.
In retrospect, the films I made were… student-ish. Which isn’t a huge shock. I didn’t go to film school, so I learned by doing. Making tons of cheap films was a way to learn how to shoot, how to edit, how to direct, and how to write. I learned a ton from them, and while I can tell you (truthfully) that the organisational, writing and visual skills I learned doing those helped me in my latter career making games, I was also left with a sense of loss. I told myself I’d keep making films ‘on the side’ as I made games, but as anyone who’d done it can tell you, video game development, especially indie development, is all-dominating. My time was all taken up with making our games, sometimes 7 days a week for months at a stretch.
You don’t think of it as ‘crunch’ when you’re an indie, you think of it as kind of… doing what needs to be done until you release a game or two and can get proper financial support.
The last week I’ve worked on implementing the sensor & detection systems for Deck & Conn. They’re now done. Well… working, and are as ‘done’ as they can be until play-testing lets me tweak the specifics of it a little more.
This dev log will cover how the sensor systems work, and a bit of my thinking behind them.
I broke my ‘fast track to alpha’ rule this past week and decided to do something which technically isn’t -required- for Deck & Conn until beta but… I wanted to do it. Partly to prove to myself I could do the art for it on my own, and partly just for a change.
And so, here it is – the ship’s communication systems.
Now, that’s not just getting buried deep in the ship’s computer. One of my favourite little bits in (especially older) computer submarine sims is when you could visit the captain’s cabin – to read notes, your war log, or just for that feeling of that it kinda is like a real boat.
So I knew what I needed for Deck & Conn – a second room. The captain’s cabin. In which would set your 15-minutes-into-the-future-of-1986 secure communications terminal.
A few weeks back, I began to run into problems developing Deck & Conn. Not logistical problems, or design problem, but coding problems.
Background for those who haven’t read previous dev logs: this game was being built in Love2d using LUA – my first time using the language or the framework.
I ran into a weird problem – data that was being passed down by numerous function pointers that’d just be… wrong. I did eventually find the problem, of course, and it was a Me problem, but what bothered me was this: it took me a day of debugging using the limited tools available to me to find the one tiny issue I’d made buried deep in my code which was resulting in bad data being filtered through.
This isn’t fundamentally a problem with weak-typing, but it sure convinced me of one thing: for projects this big, I wouldn’t be using this language/engine again. It seems great for quick small 2d games, but for something on this scale with this much data massaging… it wasn’t a good fit.
But, I kept going, until… it crashed. I ran it again, and it ran fine. It was a sporadic problem. After some fussing about, here’s what I found: about one in ten times I’d load up Love2d it’d CTD. I did the debugging I could, but seemingly Lua would just fall over when loading my some 8,200 lines of code in for parsing. I couldn’t find the problem, and it wasn’t consistent. I knew in theory I could fix it – I had the Love2d source, after all. I could open it up in Xcode, run the game through that, and go burrowing into it to find what the problem was.
But… why? Sure, I wanted to finish this game, but something else occurred to me…
Let’s go back a bit. To look at just what I intended to do with Deck & Conn, and why.
I was tired of projects taking me ages – I wanted to finish some games. So my plan was this:
Find a language/engine that let me do some good 2d game development quite fast, and ship a few games.
Each game would let me build tools and UI / rendering framework which would make the next game easier.
Each game would build off the codebase and work of the previous one, making more difficult games possible without re-building the wheel each time.
I even have the successor games to this planned out.
But, the important part is that third bullet point – ‘build off the codebase of the previous one’.
I had decided already that for me personally, and for the games I had planned… I was not going to use Lua and Love2d again. It just wasn’t a good for for the games I had planned.
A Tough Decision
So, when the second game came around, I knew I’d be re-building all the work I’d done in Lua in another language – probably C++, in the home-brew engine I’d been tinkering with on and off for years.
So… why not do it now?
If I chose to finish this game in Lua, it’d mean fighting more debug problems, sure, but it’d also mean building more code that fundamentally would never get used again.
But how long would that take? Could I even use my scratch-built engine for it?
I dismissed it at first, even joked about it out of frustration. But then… it stuck in my head. I found myself wasting more and more time debugging an increasingly big game in Lua… how long would the port take, and if I added that port time to the time saved by re-using more code with the next game, AND the time I’d save having full C++ low level debugging tools for my game… maybe it would be worth it?
I thought on it for a while, before finally deciding… fuck it. I’d do it.
So, for most people reading this, the idea of “I’m going to port my game mid-development to a whole other engine” already sounds pretty absurd. Then when you tack on “C++”, and “scratch-built engine”, it probably enters the realm of farce.
But you have to consider – I’m weird. I’m one of the two humans on planet earth who actually likes C++. And I’ve been coding in it for decades – I began learning it in the late ’90s, and while I didn’t use it that much for the next decade, since 2011 I’ve largely coded in C++. That’s a hell of a lot of experience I can rely on to make short work of what I’m doing.
So, the decision was made.
Time to explain what the engine is…
When I began coding games professionally, I was making iOS and iPad games – both contract and my own. To make conventional apps for iOS or iPad back then, the language of choice was Objective-C. But for games, especially if you knew you’d want to port to Android (or to conventional desktop platforms), C++ was the common language. So the studio I worked with used a C++ engine called Cocos2D-X, a 2d-centric C++ cross-platform engine geared toward mobile development (it used GLES rather than full OpenGL initially).
It’s… a messy framework. Documentation was not great, originally. As time went on, it all became a bit of a problem for me. I had big games written using a framework where sometimes in order to make it work on new iOS versions (or new iOS architectures – like when it moved to 64 bit) I actually had to totally re-build my code – and sometimes that was unfeasible.
That’s why to this day the two best mobile games I built do not work on modern iOS devices.
But it was what I knew, so I kept going after the release of my final Flat Earth game – and eventually by late 2020 (using all the lockdown time) I had a really rather complex “next gen for 1994” game engine going. It had tile work, complex UI, draggable windows, top bars, context menus… everything I knew I’d need for the kind of games I enjoy making.
But that was in Cocos, and eventually development stalled, especially as the tile based game I was building was ultra complex, and big projects are hard to stick with.
So I began to rebuild it my own using libSDL. It was low level, but I had plenty of experience by then and quite enjoyed working with it.
Meaning that by the time I ran into the Lua problems… I had a simplistic but functional cross-platform libSDL based engine already a good chunk of the way done. I hadn’t ported all the fancy UI over but for Deck & Conn… I wouldn’t need it.
So my shiny new 2d 5-minutes-into-the-future-of-1994 engine would be what I’d finish the project in.
Just one small problem remained: porting 8,200 lines of Lua code into C++.
It’s not as bad as that of course – much of the Lua code, I think as much as 1/3rd of it, was UI code I already had at least partly working in Sapphia.
Cut to two weeks later and… I’m nearly done. The gameplay logic and data all works. 80% of the UI is done, with whats’ left being bespoke UI widgets such as the torpedo launch systems.
Somehow, burying my head in Xcode, I have gotten the whole thing almost back to where it was, losing myself about 2.5 weeks and that’s it.
I’m pretty happy with that.
The New Plan
This has to change my timeline, of course. Not by much, but still things are pushed back a bit.
Firstly, I’m clearly not going to hit alpha (core gameplay) this month – there’s just a few hours left of the month. I’m now a few weeks behind.
But just a few weeks, and in the long term it was the best decision.
Debugging is easier. I have more options for other platforms to port to. And honestly, it runs faster.
So, that’s where I’m at – a new engine, Sapphia, and slightly altered release plans.
I should hit Alpha in the first half of February, Beta (including the meta game) in early March, and hopefully release in April.
That’s the plan anyway.
And now this is all done, I can start live-posting on mastodon about the process.
Okay, so I got both a lot less and a lot more done in the past week than I’d hoped. Wait, week? Was it a week? Two? Week and a half? What even IS time? Regardless, it’s partly because I actually let myself relax a bit – saw friends, went on photography expeditions, and just generally made my time off work just a bit more holiday and a bit less… work
But then there’s the fact that what I ended up doing took more work than I’d presumed. Or, rather, I forced it to take longer.
When I first sat down to write this, I thought maybe I’d gotten to do it for another fortnight again, like last time. But no, I just got a crapton done because I’m off work fro the year so I’ve been working almost full-time on Deck & Conn for a few days now.