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.
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.
Now that the C++ porting is done and I’m making forwards motion, it’s time for an update!
The first big new features implemented since the port job was done is… the ship’s computer.
There’s quite a few parts to this beast, including a fully functional terminal system – so this will be a fairly detailed post, including some info about the systems which have computer screens.
So, here’s where Deck & Conn was at just over two weeks back…
And here’s where it’s at now…
You may notice some changes. In fact, if anything it may seem like it’s gone backwards – there’s missing widgets! (Also colour tweaks – I’m still working on that.)
Buckle, it’s time for a story – an explanation of a major change in the project, that dominated the last two weeks of my life…
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…
The Plan
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…
Meet Sapphia
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.
Sapphia Engine, 0.01
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.
The Port
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.
It’s been a hot minute since I did a dev log, and that’s partly because what I ended up doing in the last little while took a lot more time than expected – or, more to the point, I got a lot more done than I expected.
In short, I worked on world generation, some pen ‘n paper UI design and fixed a pile of bugs I’d missed.
