Lessons of my first incremental game

Introduction

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:

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:

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:

Some advantages of this approach:

Some disadvantages of this approach

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:

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.

Conclusion

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:

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.