Why is a cat like a condenser?

I am building a game, and this is my first devblog. In it, I'll try to take you with me on the journey of writing a game like Starship CEO. Today: why is a cat behaving like a condenser?

I'm not sure exactly when I started building my first games, but I do know it was in QBasic, on our old Commodore 386sx-25. The 25 is the processor's speed in MHz, so nerds will know how old that is. From the start, I was less interested in the results and more in the process, the techniques, the optimization. I was constantly asking myself: "How can I do the same, with less code?" Some would call this lazy.

To be clear: I wrote all the rules for three-in-a-row before realizing that most of them are just rotated versions of rules I already had. After writing a function that could do that rotation for me, my game still worked exactly the same, but with three-quarters of the rules gone. Still unsatisfied, I wrote a crude 'binary sieve' that let me write a guaranteed non-losing AI opponent, purely based on one number that represented the board, ignoring orientation.

In other words, I go to great lengths to have to do less. And now I have decided I want to publish a game... with that level of laziness optimization. What could possibly go wrong?

StarTrade Enterprise, St. Mary's, Starship CEO

The foundations for Starship CEO were laid about two years ago, when I started work on StarTrade Enterprise. As some might notice just from the name, I had ideas. Too many of them, in fact, and because of that I made almost no progress at all. One of the biggest issues was that I had ideas about this game and I wasn't able to kill my darlings, which left me in a permanent state of frustrated indecisiveness and inaction.

After figuring out what was stumping me (a shift system that gave workers an assigned shift on duty and two shifts off for sleep and recreation), I started St. Mary's, a hospital sim, using my lessons from StarTrade Enterprise to guide me. One of the things I decided early on in St. Mary's was that most content should be authored, not programmed: a disease is a disease, is a disease. There is no reason to have an "uncommonFlu.cs" in my project if it does the exact same thing as "FloatedHead.cs" but with slightly different parameters. And so the DataMachine was born:

The DataMachine

In the DataMachine (DM) I can author EntityTypes, capabilities, Roles and Jobs - and, for St. Mary's, illnesses, cures, symptoms, detection methods, comorbidity, the works. The game reads the JSON the DM generates and builds entities from it, using composition throughout, with no inheritance anywhere in the game. Is this wonderful? Absolutely: I can author a new piece of furniture in about two minutes, have it run a recipe, draw power, and switch itself off when there are enough of the materials it produces. I can author new recipes in mere seconds, zones, materials, and all of it works automagically... well...

I got stuck quickly. You'd think it's a simple loop: explore symptoms, exclude impossible illnesses, send for more testing until only one illness remains, then treat the only remaining option, right? But the simplicity is deceptive, because finding the next test to perform becomes a difficult choice as soon as you have to factor in what's available in the hospital, which illnesses you're trying to exclude, the chances of each test revealing something useful, the symptoms you've found so far, and so on. Nobody knew health care could be so complicated. So after kicking that can down the road for a while, I decided I had, once again, chosen a domain that was far too difficult to capture in a DataMachine-like tool. At least for now.

Starship CEO

And so I started my third game concept, based on the same idea: author fat data, write slim C# code. I called it 'Starship CEO' - not the name I really wanted, but the city-building/resource-management/spaceship-building field is heavily copyrighted, trademarked and saturated, and "StarTrade Enterprise" would undoubtedly have landed me in hot water with Paramount.

So, with the same pragmatism that left my hopes and dreams for StarTrade Enterprise behind, I just chose something descriptive, available and legally near untouchable: "Starship CEO". I slimmed down the design of what the game is supposed to be, copied St. Mary's to a new folder, ripped out anything hospital-related and started Starship CEO. A little over a month later, I have published this website, created a Steamworks account, and uploaded the first version to Steam (not visible yet). For me, that is moving at warp 10, so I hope I won't start evolving soon.

So... why should nobody ever do this? Well, to be honest: it's a fun coding exercise, it's a real head-scratcher, and if you like these sorts of problems, by all means, try it. But you should be prepared to answer (and debug!) problems like "Why is this cat producing water?!??", "Why are the food processors moving through the ship?!", "How did my Helm die (not break. Die)?!!" and "Why can I place a plant, but not a painting, on the ceiling?". Because if, in theory, there is no real difference between a cat, a helm, a plant, a painting or a condenser, then they all, in theory, can do what the others can.

I regularly waste multiple days thinking out a new feature, only to see it fully crumble at the first dawn of its implementation, just because I'd forgotten that a 'divider' can be both a floor and a wall. Or I watch people die of hunger because I added an activity 'Pet the cat', and now they forget to eat.

When it works, however, it's almost like magic: It's highly testable, and once I'd authored Health and dying, I got Intergrity and breaking down for free. Once I'd authored roles, I suddenly also had urgent jobs and once it's all finished, I can create a game, in Unity, without opening Unity...

In theory...

Nerdy stats