Deck & Conn, Log 2 – Crew, and (in retrospect) a mis-step

Given last log post was mostly an introduction, and I’ve produced a big steaming helping of code since then, I might as well explain what I’ve been doing and why.

So, first up, I need to complain a little, because to code this, I’ve had to learn Lua. (Which, to be honest, was half the point of the project – I love learning new programming languages, unless they happen to be Perl.) In theory this sounded fine. Another language that’s used with some frequency, if mostly as a scripting language tied into existing engines.

Turns out there’s a reason for this – Lua is a very bare-bones language. When people told me that before, I presumed they meant “lacks standard libraries to do many regular tasks”. What I didn’t think they, and turned out to be the case, was “lacks features such as case / switch statements, ability to natively duplicate data structures by value”, etc. Not a show-stopper by any means, but certainly one that’s caused me no end of pain. I can deal with every complex data type being a “table” (that is, by turns, a dictionary/map or a dictionary/map masquerading as a list/array), but being able to copy them natively would be nice.

Gosh my code for this game will seem weird at first blush when it’s done.

For instance, instead of making a class or struct type and just making an instance of it, I’ve had to cheat and make “template” tables, indicated in my code by using camelcase naming with a leading upper-case character. I then run my own little tools.createInstance() function to do a deep copy of the ‘template’ object.

That’s all fine, but it’d be SO easy to accidentally modify the data in a template if I don’t pay attention to what I’m doing.

Anyway, rant over… so just WHAT have I been coding?

What I Have Been Coding And Why, In Brief

So, here is the current state of the game.

Deck & Conn, Very Very Pre-Alpha Test Build

That may not seem like much to start with, but that’s because I’ve begun in earnest by doing mostly housekeeping, structural, and behind-the-scenes code.

Ship’s officer procedural generation using US Census names. (I’ve just got male/female for now but will figure out a logic for adding in the odd non-binary or genderless person in there too soon.)

Under all that is the basic data structures for ships, reactors, faster-than-light modules, and the capacity to procedurally generate your ship’s crew.

Not that you can see this except by looking at the debug logs, of course. (Enjoy my typo there, of course, and please meet BERTA CRUMM, “Helsman” of the CEN Nightingale.)

The basic structure of the project so far I’ve put some thought into – all game-specific code sits in the code/ folder, with rationally named modules such as ‘renderer’, ‘terminal’ and ‘data’ (though I suspect in future I will split up the ‘data’ into a subfolders like ‘ships’, ‘sectors’ and ‘missions’ etc). Below that is the ‘engine’ folder, which contains modules I’ve written which are entirely detached from the game itself, so should I ever want to make another LöVE2D game I can just drop them into my new project, or even make them a submodule in git should I get that far.

The other thing I spent some time coding there is the text renderer. At its core, of course, it uses the basic love.graphics.print function, but what my code does is two-fold: firstly, it implements my own version of the RTSoft ANSI colour system used in Legend of the Red Dragon and Planets: The Exploration of Space, two BBS door games I played a lot in my early teen years.

Secondly, I have a Terminal module that tracks a text-mode terminal in-game. I can have as many of these as I want. It basically means that I have functions like “addLine”, and it will append them to the bottom. On the in-game screen, it’ll wrap the text and show the lines as makes sense for what the terminal is. For instance, by default it’ll only show the bottom lines of the terminal history, as if you’re using a DOS machine.

I haven’t implemented it yet, but I do also have the capacity to easily ‘scroll’ the terminal too, should I want to for email / reading terminals. I got most of that done yesterday.

What’s Next?

I’m thinking it’s time for more widgets. I’m thinking analogue-style gauges would be cool, and some first passes at the “sector view” for the main viewscreen.

Once I have buttons, a few widgets, and the main viewer, you’ll be able to move your ship. That I like a lot.

On the other hand, I’d love to do more with the terminal code, so I could implement the “you’ve been given command of your first ship” orders screen.

Imagine this, but modempunk…

Congratulations! You are in command of the USS S-44

But for now… I’m thinking a bunch of small-wins would be good. So widgets it is!

See you in the next post…