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…

Read more

The Problem

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.

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.

Wish me luck!