I missed a few months didn't I? (Mar 20)

Posted on Tue 03 March 2020 in Devlogs

This post is part of my dev logs series. These articles are a compilation of fragments I write over a month about my work as I go. Therefore they are not as finely edited or deeply researched as my main articles, but a good deal more bloggy.

Where does the time go? I find myself always busy but never seem to get anywhere. Well shit its 2020, I haven't written to my blog in over a year and I find myself standing in a future that is both figuratively and literally dying around me. But so do you; this isn't a political blog.

Last night I wrote a song.

Or more accurately a set of loops; creating music sucks BTW, its a culture divided between elitists, and those lucky enough to "just get it". I feel it may have been a lot less accidental that I broke into tech at a young age, than maybe I thought.

But SEGFAULT, this is a tech blog...

Do your readers care about a string of samples you glued together while sleep deprived?

God I hope not, too much pressure for me. What I hope you care about is the project I wrote a song for.

Announcing: "Lost at C" a "Lonely Robot" Production.

"Lost at C" is an immersive puzzle game, where you are thrown in the deep end as a programmer trapped aboard a ship adrift in the depths of space. With most of the ship's system's offline and the clock ticking, only you can save the ship and her frozen crew from a fait worse than death.

When I started this blog back in early 2017 I mentioned "Sneak peaks on closed source projects", this is what I was alluding to. This game, intended for commercial release has been in development, under complete radio silence, for the last 4 years. Making video games is hard, doing it alone sucks, and doing it on Linux is even harder. Since the inception of the idea back in mid-late 2016 this game has been through 5 complete reboots, always on a new engine. Game engine's are peculiar things that inherit a lot of the assumptions of their designers about how and what you want to make. Building a programming game breaks a lot of those assumptions, making development a slow and uncomfortable experience.

That brings me to:

Why there was no Devember 2019 post.

Well actually there was. It just wasn't on this blog. Technically I announced this game on the Level1 Tech's forum in Dec '19 as I started the Devember challenge. Last year I took on writing the UI of the game, as the seasonal challenge, but quickly got stuck and progress stalled, as yet again my will to push through this doomed project faded again.

Yet the power of blogging prevailed and I was pointed to a game framework written in Rust, a language I am intimately familiar with. GGEZ fixed most of the problems I was having, and I was able to limp to the end of Devember '19, ego battered, but code on the screen.

Interestingly this game is actually older than the language it is written in.

Why are you announcing now?

You completed Devember 3 months ago, and you've been working on this forever with no real progress.

I am stubborn. and in Spring 2019 I learnt I could harness that by publishing progress on my work. If people see my work and react to it, I have to improve it else my ego is bruised. The same happened this year and I am getting close to a workable tech demo.

But Game programming is still hard. My determination is fading. Its hard to remain enthusiastic about pouring 15 hours a week into a seemingly endless project, especially when you have a "Day Job". So its time to rub the ego again, and drum up some external motivation.

So what about the Game, what is it, really?

The core mechanics borrow heavily from the Zachatronics franchise of games, but critically were inspired by TIS-100. While playing this game it occurred to me, "this is cool, but what if it were more real?" The next three months were spent conceptualizing the idea of a game console that had a secondary CPU module that could be programmed by the player and would run their program very slowly while they left it in their pocket. Sorta like a Tamagotchi but for programmers.

This was going to be too expensive to be viable.

Editors Note: (It may have been impossible with my hardware skills and connections in 2016, maybe not so much today; the cost to market for niche electronics has hit the floor in the last half decade.)

Eventually, and with a heavy heart the idea was moved back to building a video game.

TIS-100 emulates a very simple machine, in an interpreted code environment running in Unity [citation needed]. While fun the limitations of the machine and the environment it was simulated in left me wanting more. That is why a large chunk of the last 4 years went into figuring out the best way to make a more meaty version of this, while keeping it accessible.

I might get sued for admitting this, but the game uses a real instruction set emulating a real CPU!

Enter the MSP430 from Texas Instruments: a tiny microcontroller CPU designed to be easy to code for in both C and assembly. Ironically the CPU has rust support so I could in theory run the game on it XD

The MSP430 only has 27 instructions. There's a bunch of aliases which bring the count up to 51, which sounds scary, but the player only needs to worry about roughly 20 of them. It's 16bit and can address all of its memory very easily, making it perfect for a gentle introduction into "real" assembly programming.

The game is emulating the CPU and its associated memory byte for byte, therefore the programs the player enter have to be run through an assembler. All of this machinery was purpose built in house, meaning that the core mechanics of the game are going to be reliable and run smooth.

The game's UI is focused around providing clear information about what is happening, and making it easy for the player to find what they need to solve the puzzle, and learn assembly while they are at it.

The game's levels will focus around interfacing the computer with the real world. You've got a spaceship to fix and the only way you can is by programming these little computers in all of the ship's systems to do their job, and pass the tests. As Mark Watney said in The Martian "you just solve the problem, and then the one after that [...] and if you solve enough problems you get to go home"

So... Screenshots? Release date?

Please give me content, its 2020 and life its self is starting to loose meaning, I need more content!

Ok calm down.

No screenshots yet, the renderer is in a sorry state not remotely representing what I want the finished product to feel like. I aim to put some work into that in the next week or so, once that is done and I add some actual levels, and a bit more UI I will create a new post with some game footage.

I am aiming for a tech demo somewhere around June this year. (Human Malware Permitting) Which will probably be released in the form of a very limited alpha play test.

After creating a tech demo you have to actually make a game out of it, less technical work, more artistic. This falls firmly out of my experience area, so I am expecting there to still easily be 24 months of development time left in this project, assuming I don't burn out and life doesn't stop me working on it.

So there, now you all know why I never update my blog.