Idle Energy

CoWirshing - 05/05/2026 -

Currently working on this game. I had wanted to release this game by now but I keep hitting minor walls.

Once I knew AI was capable of creating games, the plan was to generate another game quickly to learn more about the AI's capabilities. Unfortunately, I hit three major issues right out of the gate: selecting a type of game I could easily understand and design for, learning how to direct the AI to make that type of game, and efficiently using the AI to code.

Initially I attempted to make a pinball game because it seemed simple enough. The need for a physics engine complicated the matter and I'm not willing to install a game engine until I know I will absolutely need one for these projects. I spent several days researching the best types of games I should focus on being limited to HTML, which is how I ended up on the Idle Game genera. The genera is not one I have spent much time playing so I spent the next few days learning about the different types of idle games, their origins, mechanics, and settling on a model that would be simple to implement.

I thought directing the AI to make a simple idle game would have been swift and easy. The initial idea of 'Clicking' and 'Gaining' a resource was easy to code, but then we needed to do something with that resource to add a reason to collect the resource. Surveying the landscape of idle games, I couldn't find one that dealt with energy generation. So, we have a resource and we can spend that to create ways of auto-generating the resource, introducing the idea of power plants. This idea led to different eras of power generation, which lead to needing energy to scale up exponentially. Ultimately, spending energy for energy producers didn't make a ton of sense, so currency was introduced as a second resource, followed by the need to generate literal resources (wood, metal, microchips, etc.). As the game ballooned, directing the AI efficiently became increasingly more difficult, as terms within the initial game design were not well defined. This is a core issue with vibe coding, a lack of structure that can make changes or introduction of new features more difficult as development goes on.

As the game formed and grew in scope, so did the token consumption of Claude. Making good, thoughtful changes in an efficient way, and correcting misunderstandings caused by my assumptions and poor wording, was eating a lot of data and processing power. When using an AI that is token capped, like Claude, unnecessary token consumption turns development into a slog. The advantage of AI is quick testing, changes, and iteration, so constantly reaching the hourly and weekly caps has slowed progress immensely, removing that advantage entirely. The solution is simple, but not one I can employ at this stage for the current game.

For the next game, I will need AI agents and skills to maintain efficiency in order to maximize the potential of using AIs to create games. These aspects of using AI should reduce the unnecessary token expenditure, returning me to the expect pace of development.