Despite having been “in development” for about 3 calendar years now, Kenoma has not actually taken that long to construct. Various episodes within my life have required that I step away from the project for about half of the total time the thing’s been in existence, so it’s really more like one and a half years of real work on the game.

Such a turnaround might sound incredible, and to some degree it is (though it is no more incredible than anyone else who manages to actually make something, in my view). But the reality is that this is something anyone with the right inclination can do if they simply dedicate their early thoughts to scope. I was Hell-bent on making sure this project would be finished relatively quickly, to the point of being downright miserly in terms of what concepts could be allowed to worm their way into the design. The choice of the game’s style, genre, premise, design, gameplay structures, etc., were all influenced significantly by this desire for speed. Ideally, I wanted the game done by early 2024.

Obviously this did not happen. I don’t think, even without gaps in development time, it would have happened either. It’s taken 1.5 years of nose-to-grindstone work to get it feature-complete, after all; that means at best the game would have released in mid 2024. This, of course, is the most sinister trick of every project ever. It always takes longer than you expect. But I digress.

I was so set on a short turnaround because of the context I found myself in. Prior attempts at making games in my teens and observations of the industry have taught me one thing most of all: if you are not extremely careful with your scope, you will easily spend up to or even more than a decade on a project. This idea terrifies me. No art is worth a decade of work. Could you imagine, being 40 years old and only having 4 completed projects under your belt, despite having worked at them every day since birth? Nightmarish.

In light of this desire, I was able to make much of the game development process very quick. Audiovisual design and programming are topics I have years of experience with. As such, I was able to easily discern what would be fast to do and what would not. Now, the writing is a different story. My expectations of speed there were totally wrong.

NOTE: Kenoma’s visuals and audio have been previously explored HERE and HERE, so I won’t spend that many words to describe the major shape of them.

Previously explained artistic and mechanical considerations factored heavily into the visual identity, but speed was a major deciding factor as well. As I’ve previously stated, it is much easier to choose what color a pixel is when you have only two possible colors, and depiction of anything must first and foremost be a kind of skewed utilitarian. Without color as a shorthand and with such large pixels, it is all you can do to simply make something look like a tree. This was a boon to my speed-based concerns: I had fewer decisions to make and was forced into a specific, cohesive style for every sprite that I couldn’t ever break without losing visual coherence. Less choice leads to faster turnaround.

Kenoma’s minimal audio is similar, though there is a bit more nuance. Music has an inherently greater freedom of movement in extreme simplicity than the game’s visual art: the nuances of melody and rhythm are unchanged, even when using primitives that fit with 1-Bit color. Sound effects, though, are a different story. You can make a passable sound for most situations with a synthesizer or two, but there’s no hope of approximating reality. You must, therefore, embrace abstraction. What sound does a jump feel like it makes? This non-representational nature is incredibly freeing and very good for quickness: all I need is an arbitrary sound that seems about right, and it will end up perfectly legible.

Programming quickly is a trap option, and one that I know well. Fast code is sloppy code, which will cause all sorts of headaches later when you need to build on it. So instead of focusing on getting the code done as fast as possible, I focused on writing it as simply as possible. The simpler a set of instructions, the easier it is to write and to fix when it breaks. Debugging is always the killer when it comes to time spent on programming, anyway.

To put it more bluntly: no fancy tricks, no squirrely systems. Convoluted code like creature/enemy AI used as sparingly as possible. A stone age program, made out of rocks and twine – which is far easier to make work properly than oil and actuators and steel.

This was one of the largest contributions my speed-scope made to Kenoma, structurally. Anything regarding varied critters, intricate mechanical interactions, fine-tuned precision gameplay, was out. The code and design work would take too long. By that logic, combat was out too: it would just get boring otherwise. Games without fighting are constrained to one kind of obstruction: puzzles and locked doors. I decided to draw on older, more straightforward progression structures. From back when “interactive fiction” games used to be called “text adventures”. But instead of describing the areas with prose and using a text prompt interaction, you move with WASD through a visual environment.

But a game that hinges on the old text adventure structures needs plenty of text. If there’s little action, then the narrative needs to pick up the slack. So I had to write 60,000 words.

The writing process took at least a third of the game’s development time, by the calendar. But really it was more like half, with how much it needed to factor into the world environment and gameplay progression. And, of course, everything of any note whatsoever would require its own text description. Keeping everything straight and consistent within the narrative/lore and writing, rewriting, proofreading, etc., probably took about as long to make as a similarly-sized mechanic-focused game. If not longer.

But that’s just how it always is. I tried to streamline every part of the process I could, and it still ended up taking far longer than I wanted. I simply did not account for the fact that having the narrative be the primary focus would require the same amount of effort as having gameplay be the focus. Though, this is partially because I expected the game’s narrative to be quite a bit smaller. Initially I didn’t think I’d written more than 20,000 words!

It’s tempting to have the main takeaway of this be that Kenoma was hastily designed in a way that left too much on the table, and was built first and foremost to be a convenient project. At least, I am tempted to do such. But I don’t think it’s quite accurate. The game’s core identity existed before I started to make these decisions, and I believe imposing these restrictions on myself resulted in a better, more focused final product. Kenoma could be more about platforming, or it could have been given some kind of combat system with enemies abounding. But would its core concept really benefit from that?

* * *

BrukhoLevin Mailing List: https://www.brukholevin.com/mailinglist.html

KENOMA on Steam: https://store.steampowered.com/app/2933260/Kenoma_Action_Without_Action/

KENOMA on itch: https://brukholevin.itch.io/kenoma-action-without-action

KENOMA press-kit [for journalists]: https://www.brukholevin.com/kenoma_presskit.html