Preface

Heads up – this post is meant more to justify my decisions to myself rather than be informative to anyone else. However, I know that I find relatable parts in ramblings of others, so perhaps this is something relatable to you.

I thankfully went on holiday mid-way through writing this post. The Alps appear to have blown some wind of sense through my cranium, relieving this post of the majority of silly deliberations.

The premise

Recently I’ve found myself struggling to find a good mental framing to work on projects that I want to put out to the world, i.e. not learning purposes or personal use. I mostly struggle with two issues: reward latency and lack of confidence in the project.

Reward latency – the time it takes between starting something and the reward you get from finishing it. This problem becomes apparent even when it comes to personal projects, on which I can spare only an hour or two a day. Achieving even trivial goals seems to take weeks, or requires trading sleep, exercise or food, which is counterproductive in the long run. This only gets worse when applied to a product instead of a personal project. At the same time, this is tricky, as I don’t want the creative process to turn into a tiktok-like dopamine mechanism.

Lack of confidence that the project has any potential is a problem, because it makes it difficult to ignore the lack of motivation and approach the situation in a disciplined manner – simply sitting down and consistently doing the work. If I am to dedicate months or years of work, it’d better be backed by something more than just beliefs of a person who has never designed a game.

Finally, I feel stretched thin when I try to write the code and think about game design at the same time. Putting on the training wheels by ignoring the programming side and focusing only on the game design side might yield better results.

The goal

I’ve had the idea of a deck-builder tetris game swirling in my head for years now. I finally feel it’s a good time to put out a prototype and have people lay their hands on it and then completely annihilate me with their feedback.

The primary purpose of this prototype is to explore the design space of the game instead of thinking about the programming aspect of it. The design exploration and the feedback will then be either my guideline when trying to convert this game into something that is indeed fun, or proof that my skills are presently not sufficient to make this game viable and that I should move on to another project.

The conflict

I’m certain that LLMs diminish people’s ability to write code and rob them of various tricks they could have learnt – much in the same way that using a calculator in middle or high school robs people of quick mental arithmetic skills and of learning various neat tricks¹. Now don’t get me wrong, it’s fine to use the calculator, but you may have skipped some tricks if you never did it the hard way.

I’m also confident that the idea of “journey before destination”² is indeed highly important to leading a fulfilling life and, for that matter, to even reaching the correct destination at all.

I hope it’s obvious how these beliefs might cause one to struggle with handing off a massive part of the creative process to a clanker.

The resolution

As the focus falls on the design of the game, I’ve decided to frame the situation like so: prototyping is only a small part of the journey – where code is mostly unimportant, where the basic, core game design ideas are king. Am I potentially missing out on cool emergent mechanics by not writing the code myself? Yes, highly likely. Am I trying to evaluate the whole game now? No, only the core design principles!

I’ll lose out on learning to write prototype code more quickly for sure. But that is not a skill I am trying to achieve here, so I am fine with this tradeoff.

Should I decide to continue developing the game after the prototypes, I will throw away the prototype code and primarily work on it with my own hands, which resolves the issue of missing out on potential emergent mechanics and on writing code. I will concede – it’s very alluring to keep vibe-coding after all, but I have a very good reason to do as little of that as possible for the final product. As I have already alluded to, the implementation details have an impact on the game feel. Slight quirks, sequencing of actions, input handling, etc. all contribute to how the game feels and are subject to implementation details, not to mention all the emergent mechanics that are implementation dependent.

At the end of the day, this is a creation that I am making, not an LLM.

The process

I won’t go into the minutiae of what kind of setup I use, as attracting AI shamans³ with their apparent “you’re doing it wrong” mantra is not something I wish to do.

The important thing is that I have informed the agent of a specific toolchain to use and have specified rough principles it should follow to not overcomplicate the code. That’s it.

Every time I start a new mechanic or improve an existing one, I prompt the agent to formulate a spec sheet. When writing the requirements for it, I am essentially writing a design doc for that mechanic. That allows me to focus only on the design and nothing else. During the writing of a spec sheet, the agent asks me questions about edge cases and integration details with other existing mechanics. This way I am exposed to the programming side as well, but only when it concerns the player-facing part of the game. Finally, after reviewing the spec and allowing it to formulate a plan, I simply let it write whatever code it comes up with.

A quick playtest afterwards and Bob’s your uncle. I can move on to the next thing.

The outcome

In terms of my mental wellbeing this has been a little strenuous. Using an LLM seems to push me in the direction I do not want to go. The amount of reward you get from getting an output so quickly felt very addictive. I’m afraid that it might completely annihilate any ability to resist the temptation of immediate reward… As if social media hasn’t done a number on that already. In other words, yes, the LLM helped the lack of motivation, perhaps even too well. However, not well enough for me to throw away the promise of writing the end-product myself. Making the game mine is more important than being momentarily happy.

For the sake of generating the prototype, this is working great so far. Currently, I’ve only made the first version of the prototype. It’s not something super exciting yet – just the basics. The bare minimum to communicate the idea of the game. The work was done quickly – I had the basic stuff within three evenings, spending one more to fix up fonts/scaling and another creating the pieces and working on the game balance. Doing it myself with all the small bits of UI scaling, etc. would have been a 1-2 week adventure. The LLM didn’t faceplant into a pile of spaghetti code yet, so I am expecting to finish these prototypes before it gets too complicated and starts breaking more things than it creates. The result I managed to achieve with it is good enough for evaluation by other people. So I would say that it also did great in helping me create something that will either build up or demolish my confidence in the project.

Finally, as I was only writing design docs by completely disconnecting my brain from what the implementation might be, it removed a whole category of problems I need to think about. This definitely allowed me to come up with ideas that I would have otherwise immediately avoided due to them taking too long to implement or requiring me to refactor the existing code.

The prototype

Elevator pitch of the game:

A deck-builder tetris where you battle other people’s builds testing both: your strategic foresight and quick decision-making.

You can find the prototype versions here. As of the time of writing this post, I’m planning four prototypes, each building new mechanics upon the previous version. Once all the versions are done, I will put out a short writeup about how the process went and hopefully put it on itch.io.

If you have a spare 10 minutes, I would appreciate you giving it a shot and filling in the feedback form. The game is written using raylib and compiled to WASM to run in the browser, so it should work on most devices with physical keyboards and mice.

The digression

A short, more technically oriented note about what I didn’t expect during this prototyping run.

One thing that I did not consider was that superpowers would require the agent to write quite a lot of unit tests. This ended up being very useful and something that I would have definitely not done, had I done the prototype by hand. Simply because it’s a lot of code that would have to be constantly maintained, which is contrary to trying to push out a quick prototype.

I’ve never been the biggest fan of unit tests because it’s annoyingly costly time-wise to maintain them. In my opinion integration/end-to-end testing is always more efficient, since it catches the really annoying issues that happen at the intersection of systems. However, if writing/maintaining unit tests were free, I wouldn’t mind doing them at all. LLMs make them essentially free, so I’m seriously considering heavily leveraging an LLM to write tests based off of API docs/spec sheet in my everyday work.

It might even push me towards the TDD way of doing things. I’ve never been a fan of that, because I solve problems while writing code, not beforehand. This means that I write and rewrite the code a lot before coming up with a final solution or even the final “shape” of the code. When the API is flip-flopping so much, it is really annoying to have to change the tests too. Usually the test logic itself would remain more or less the same, but the test would have to be redone because of API changes. An LLM would be able to keep the tests up to date with the API, which would rid me of my major issue with TDD.