Lessons of my first incremental game

My first incremental game, the good, the bad, the whys, the lessons. Maybe you should make one too.


I've always liked JRPGs. But I've always thought that levelling up was a bit dumb. I've never liked MMORPGs or the dungeon-based, gameplay heavy stuff. The character gets stronger, not the player. You can grind your way out of battles. The challenge felt muddy. So, to me, I was only playing RPGs for the story.

But then I started playing incremental games. It was really fun. And there are many similarities between JRPGs and incremental games. So maybe one reason I could keep playing JRPGs for so long was because of the incremental aspects, even though I didn't realize it in a conscious level.

Most of my games so far had very little "incremental" elements. You know, numbers showing progress, getting stronger. I felt like that was one of my weaknesses as a game designer. Not because every game needs those, no. But because it was something I enjoyed but failed to recognize. So I decided to build an incremental game.

When I first started the project, I decided these two goals:

  • To get experience coding incremental games
    • For genre combinations or for better understanding the mini-incremental aspects to include in my games
  • To create a fun idle game that could be played over a long time period

In this article I'll share some of the stuff I learned while building this game.

Incremental / Idle Games

For those who don't know, in these types of games, gameplay usually involves clicking on something to gain some sort of currency, until eventually you automate currency gain and you start making progress while the game is idle.

The genre started gaining popularity in 2013 with titles such as Cookie Clicker, Candy Box and A Dark Room. Inside of the idle game genre there are many subgenres, you can check out this video for more info on the subgenres.

Why you should consider building an incremental game

Very fast to get something playable up and running

Fire up Javascript, create a button, create some text to show some currency. Bam, you have a clicker game (almost as hard as a hello world). Create another button, create some code to automate things, bam, you got an idle game. Of course, they are both pretty barebone examples. But you didn't have to install anything. Depending on your experience with Javascript, these things probably took you less than 10 minutes. You could even do these things online, on those test-your-javascript websites, without having to create any files.

Abundance of games but there is still room for more

The thing about these games is that a person can juggle multiple of them. While doing something else. It's not so time demanding, it's easy to get in and get0 out. However, there are many similar titles out there (since they are so easy to make). Fear not though, since they cost so little to make it's easy to experiment with new gameplay ideas and concepts, so it's not hard to try and innovate.

The Incremental Game Subreddit

Great place to get feedback. Many players (not just devs) willing to try out new things. Many of them don't care too much about graphics (they do care about usability and information overload though). Really helped me improve the game. Thanks guys!

A word of caution though

A lot of the fun of incremental games is based on discovery. Uncovering mechanics, power ups, etc. And balancing plays a huge role in in development. You, as the developer, will have a hard time figuring out if your game is fun or not while play-testing. It likely won't feel fun to you, unless your gameplay allows for multiple play styles and is hard to predict.

What went right

Console-based prototyping

I decided to code the game in C# because I wanted to apply the gained knowledge in future Unity Projects. However, I didn't start off with an Unity Project. Instead I fired up a console application in Visual Studio while prototyping. This gave me two advantages:

  1. Faster iterations, better architecture options, no need to wait for Unity's clunkiness or to have to deal with it's monobehavior structure.
  2. Rendering and game logic had to be separated from each other even in the prototype phase. Not just as a design decision, but as an obligatory requirement.

Sandboxed execution

One thing I did very early in development was to define the minimum building pieces of my game's logic. And  then I built the entire game using only these pieces. The execution of these pieces is what I call "the sandbox". I think it's easier to understand this concept by showing a concrete example. So in my game, I decided the following rules:

  1. The only data in the game will be stored in a class named value. Values can only hold floats. Even ints will be stored as floats.
  2. The only thing that can change a value inside the sandbox is a Formula. Formulas always output only one number. This number can then be assigned to any value.
  3. Everything that happens in the sandbox is represented by the Happening class. Happenings can fire off formulas to change values. They can also fire other happenings.
  4. The only interactions allowed from outside the sandbox is:
    1. Reading the data stored in values
    2. Reading the result of formulas
    3. Changing the data stored in values
    4. Fire up Happenings
Some advantages of this approach:
  1. Complete separation between the definition of how the game works and the actual execution of the game. This means that the code I write to define the game is only ran once, after that everything is ran by the sandbox. This makes it much easier to debug and to make choices regarding code design.
  2. It's not harmful to write sloppy game definition code (great for prototyping) because that code will only be ran once so it's not complex to debug the code and find bugs. It really helps when your code isn't a huge structure of classes filled with callbacks and functions
  3. The sandbox code is completely reusable for other incremental games
  4. Easier to make moddable (not that I did)
Some disadvantages of this approach
  1. This works well for incremental games because they can be built effectively from a small amount of pieces. For other genres the design of the sandbox may be subject to much change or be really hard to reuse between games
  2. Some advanced features may require very complex use of the pieces
  3. For other game genres it's hard to decide on how granular you want the sandbox to be and there are also performance issues to worry about.

Another game that used this approach is Sim City. Moddable games in general have to do something like this.

What went wrong

No deadline

This was my biggest mistake, I believe. By far. Almost all of the problems described below would likely have been avoided or have been irrelevant had I decided on a deadline for this. A short one too (one month), since the main goal of the project was to be a learning experience.

Implemented very little related to the theme

So I decided the theme and the things I wanted for the player to be doing before starting coding. It was supposed to be a medieval setting game with a theme of hypocrisy. So the character would make speeches for peace while fighting wars, be against stealing but stealing himself, keeping slaves, etc. Sounds cool. But I thought I could implement these things slowly as development progressed, so the first, main gameplay-related content I was creating had nothing to do with hypocrisy. I did add some thieves into it but the hypocrisy thing was kinda of a storyline thing only, it wasn't too embedded into the player's main actions.

There isn't anything inherently bad about this, although the beginning of the game does feel a bit more generic because of it and it's not what I wanted from the game.

Bad game mechanic synergy

While building the game I played a very cool game called Ankyria. Ankyria fit my lifestyle like a perfect glove. It's an idle game that involves making some choices based on the current state of the game and then waiting a lot to see the results of the choices or having these choices played out through a large span of time. It was a very idle idle game. So Ankyria inspired my design. But I already had a theme decided and had an idea of the things the player should be doing. So the mechanics in Ankyria, mainly the waiting, were hard to support with my current design since I didn't offer as much variety and complexity as Ankyria does.

Once again, nothing inherently bad. The game worked, I just wasn't too satisfied with the current mechanics. I only realized this a bit late into development and the game had already developed an identity. This, alongside other issues, made me feel incapable of fixing it without changing it into a whole new game.

Bad scope

So, incremental, easy to make, huh? How can you have a bad scope, you lazy dev?

Well, balancing incrementals is hard. It's important to automatize balancing from the start, I believe. I didn't. Everytime I added content I had to make some estimation on how long it would take to clear it, tweak some values, run around the code changing stuff... Developing new content was not a good experience. I was also unhappy with the game. I didn't have motivation to automatize balancing and make content creation smoother. Why not? Because of all the other issues I'm describing here.

Low scalability

I started coding some game mechanics and all that jazz. And then I realized I thought the game was a bit boring (again, I'm the developer so it's hard to be sure). And I started adding these little bits of story here and there. And I let people play the game. And some people gave great responses to the game. So I kept adding stuff and ran into the issues described above, especially the bad scope issue. The way I coded my game, I need a lot of content to support long-term play. My design only allowed me to have two of three:

  1. Long play times
  2. Viable amount of content
  3. Fun

So I had to sacrifice one to get the other two. I sacrificed long play times. The project had too many issues for me to keep adding content to it.


Well, here is the game, if you wanna play!
I consider this to be a success, even if I didn't meet all of my goals. I learned a lot and it wasn't such a bad game for my first incremental, given the time I spent developing it. If I could change anything, it would definitely be to have a deadline.

The other one thing I would change is to forbid myself from giving the game a context and story until I knew I had:

  1. Meaningful gameplay
  2. Complex enough mechanics that makes content take time to consume
  3. Ease of content creation.

If you ask me, I only had the first one, to some degree, and the story was carrying the game. Meaningful gameplay is a pretty loose term, I might explain what I mean better in another opportunity.

Next time you tell a beginner to build pong, consider telling him to build something similar to Candy Box, A Dark Room or even Cookie Clicker. Should be easier to make and more likely to be fun and unique. Maybe.


Latest Jobs

IO Interactive

Hybrid (Malmö, Sweden)
Gameplay Director (Project Fantasy)

Arizona State University

Los Angeles, CA, USA
Assistant Professor of XR Technologies

IO Interactive

Hybrid (Copenhagen, Denmark)
Animation Tech Programmer

Purdue University

West Lafayette, IN, USA
Assistant Professor in Game Design and Development
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more