Deck & Conn, Log 12 – “New Contact!”

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.

Jonesy – accept no substitutes.

A Feature Script

So… uh… I just wrote a very bizarre feature script. Its title?

Capitalism Conquered: The Bee and Forklift Rebellion

Of course, ‘write’ is a very nebulous concept here. It began when I had a bizarre prompt I put into chatGPT for a scene from a film script. Then when the scene ended I gave it another prompt, following both where it lead me and re-leading it to where I wanted it to go.

And… it got weird. Real weird.

You can read it here.

Some Details

This is a screenplay generated using chatGPT. I began by prompting it with a beginning scene, then adding more random characters and absurd events. Some things are explicitly put in as prompts by me (such as the first few characters). Others, such as Tom Cruise, Captain Nemo, or the random character played by Chris Farley, are entirely inclusions of chatGPT.

My rule to do this was simple: I could re-generate a scene as many times as I wanted to create something that fit what I wanted, and I could strip opening or closing descriptions of a scene if it clashed with what came before, but except for sometimes removing an extraneous letter (its spelling is quite random) if I didn’t like a line, I had to re-generate the whole scene.

There are very few exceptions to this, and even then only when I felt I had no other choice to have it make even the tiniest bit of sense.

I mostly did this incrementally, but sometimes I went back in the edit and decided that I needed additions to the story. This results in some rather (even got chatGPT) out of place non sequiters and references to things long ago.

The program routinely broke and I had to open a new chat window and once again remind it of the core story (that this group of characters was trying to overthrow capitalism with bees and a fork lift) before generating the next scene.

I realised I could do this for an incredibly long time and just keep going – and maybe even generate something vaguely sensible, but, where’s the fun in that?

So here it is – a (short) feature script nominally written / prompted by me and generated by chatGPT.

All characters are… yeah look this is a copyright nightmare, naturally. Only made worse when chatGPT kept including other real people or copyrighted characters as it went along.

Key Takeaways

  1. Almost nothing was generated which wasn’t in the prompt. Very few of the tangeants the story takes weren’t given by me in the prompts.
  2. Even when I asked it to write ‘funny’ scenes, it rarely altered the context of what it wrote. The bits that are funny are funny by accident, or because I gave it a prompt which resulted in something funny happening at the end of a scene.
  3. Its actual script writing form is just bizarre. Every second time I ran it it’d produce a format that was half way between film screenplay and half way between stage plays, and I’d have to manually edit the format (or generate it again and hope for the best).
  4. Some characters it seems to be able to grab a ‘voice’ for from its massive database of internet trash pretty easily. Johnny Silverhand, for instance, uses some distinctive cyberpunk voices and a cadence that fits for him… mostly. Other characters, like Yoda, despite having a more distinctive way of talking… it entirely fails to even try to generate. For some reason its autocomplete-esque thing did NOT result in any Yoda-like speech for Yoda. (So I just dropped him after the first scene he appears.)

Deck & Conn, Log 11 – Priority Action Message

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.

Welcome to your cabin, Captain.


Deck & Conn, Log 10 – Hello, Computer!

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.


Deck & Conn, Log 9 – A Much-Needed Overhaul

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.

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.

Wish me luck!

Deck & Conn, Log 8 – Firing Point Procedures

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.

So let me explain…


Deck & Conn, Log 5 – World Gen & UI

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.