Thoughts on making small games
I notice more people talking about making small games. As I’m also currently focused on this goal, I thought it would be good to write something about it. I think that indiedevs in general have a few misconceptions about the problem and aren’t thinking about it clearly, and in this post I’ll go over that argument.
The meaning of small
The first thing to notice is that the word small, when used in the context of making games, is conflating multiple meanings into one word. The first meaning is related to how long or how many people it took to make the game. The second meaning is related to how long it takes for players to go through the game.
When indiedevs use this word to describe their games, they’re generally referring to both meanings at the same time, or to one of them in an interchangeable way with the other.
For instance, this great talk (watch it in its entirety, I highly recommend it) goes over techniques for making games every month. However, it implicitly assumes that because this development duration is small, the games also will be fairly small for the players. This is illustrated in the first point where one month games are referred to as “concept games” rather than real games.
Another example of a similar assumption is in this article, which goes over a game made in 4 months. Similarly, it is implicitly assumed that because the game was made in a short timeframe, the game would also necessarily be fairly small from the perspective of the players. (1 or 2 hours long)
In both of these cases you see the same error being implicitly made, which is that both meanings of the word small are the same thing, and this logically leads to the idea that if you make a game in a short timespan it must be the case that the game will not last a very long amount of time to the player. These are just two examples, and they’re simply illustrative because this error is made by pretty much every indiedev talking about making small games right now.
The game scope chart
To further illustrate this point, you could look at this problem as a chart with four quadrants. On the horizontal axis we’ll have one meaning of the word, on the vertical axis we’ll have another. For clarity’s sake, we’ll refer to the meaning that pertains to development time as small/big and to duration for the player as short/long.
We generally don’t care about the top two quadrants of the chart. Those are related to games that have big development times or teams, and that’s not what people are referring to when they talk about small games. We’re then left with the bottom two quadrants, and here we have a spectrum that goes from small short games to small long games.
Most indiedevs inherently assume that because a game is small, it has to be short. I reject this notion entirely. I think the quadrant of small long games is fairly unexplored, and it’s useful to think about if this is a valid quadrant at all.
My experience with BYTEPATH
The only game I’ve released so far is BYTEPATH, and it falls under what I would consider a small long game.
It’s small because it was made in about 4 months by me alone, and it also has a fairly small scope. By the nature of its gameplay it’s essentially a single screen game with lots of upgrades, like one of those old flash games.
And it’s long because it feels like a long game. Despite being made in just 4 months, it has a skill tree with about 900 nodes, it has 10 different characters, around 40 classes… Essentially, it’s what I also like to call a spacious game.
You ever listen to a song or an album for hundreds of hours? I’m currently doing this for Thank You Scientist’s Terraformer and it’s crazy how despite listening to it for so long I still find new things in each song that I didn’t notice before. This album is a spacious album. It can be thought of as this large space, and as you listen to it, you’re exploring it, mapping the environment, finding new walls, rooms, objects, that you didn’t know were there before.
Games can also be like this, and long games are generally like this. BYTEPATH certainly is because it was made to be so, as the goal of the game is finding new builds to play, to the point where the main gameplay itself is kind of irrelevant.
And because of this I think BYTEPATH did way better than I expected it to do. It’s also important to note that despite me calling spacious games long games, they don’t necessarily have to be played by most people for a very long time. Here’s what BYTEPATH’s hour distribution looks like:
This is definitely not impressive but it’s also not too bad. And I know for a fact there’s at least one guy (I saw him in the game’s reviews) who played it for over 100 hours. When games feel spacious they have the possibility of keeping people playing for a fairly long time, which increases the chances that the game will do well.
Small long games
The most important point here is that small long/spacious games DO NOT need to take a long time to be made. If I were to make a game like BYTEPATH again I’m fairly confident I could do it in 2 months, and it would be a significantly better game too, simply because it’s actually not that hard. (I’m 100% not some kind of disciplined productivity God or anything)
When developers focus on making small games, this implicit notion that the games also have to be short is wrong. You can make small long games, and because of the way the market works, those kinds of games will tend to do better than short games. I’m not the first person to notice this:
Another issue that happens often is that because developers are making small games that they feel are sort of worthless, they don’t really do a good, serious job at marketing them. For instance, the example game from this article was marketed on Twitter only.
Anyone who has released a game knows that twitter is notoriously poor at driving sales, and that sites like reddit are much better. Would it really have cost these developers that much time to make a few posts about their games on reddit? No. And I know for a fact that a game of such visual quality would have done very well on multiple subreddits.
So a lot of the conclusions people reach about their efforts with smaller games, and the conclusion the author reaches in that article as well are pretty pessimist and in my view mistaken. I think that most devs making smaller games would benefit tremendously from taking making their games somewhat more spacious and from thinking more clearly about how they’re going to market it.
The right development duration
Another thing to consider is what’s the right timeframe for making a small game. One of the videos above focuses on 1 month per game, and both my previous game and the game from the article above took 4 months. I think the right duration is between 1 and 2 months.
The reasons for this are fairly simple. If you’re making a 1 month game you probably want something with a scope such that it can be finished in 2-3 days, and then you spend the rest of the month polishing it in various ways. This keeps your game fairly focused and it’s a good strategy if you want to drastically increase your chances of actually finishing and releasing the game.
If you’re making a 2 month game this affords you a little more time such that you can actually start adding some meat to it and make it more spacious. But I personally think that it’s too easy to start getting lost in scope-creep if you give yourself much more time than 2 months, so that would be my limit.
Currently that’s what I’m aiming for with the game I’m making and I already overscoped myself slightly (meaning I should have chosen an even smaller game), so I think it really pays to keep this duration limited like this unless you’re already more experienced and know you can avoid making these kinds of mistakes.
What also matters is how much money you can expect to make off of these games. BYTEPATH for instance made about $10k over its lifetime, and if I were to release a game like BYTEPATH every 2 months and they all did half as well as it did, then that would be considered “making a living from small games on Steam”.
But that’s largely because I live in Brazil and that amount of money here (even accounting for cuts and taxes) every 2 months would be a pretty comfortable salary. If you’re in more expensive countries then perhaps that isn’t such a good strategy, so this timeframe consideration really depends on your personal situation as well.
To finalize this fairly rambly article, one of the reasons people cite for making small games is to hedge their bets. The argument goes that if they make lots of games, chances are that one of those games will succeed wildly and cover for the costs of the other failures. More specifically this article said that using this famous graph:
I similarly reject this notion. In my opinion you shouldn’t make small games for any reason having to do with what that article says. When you’re approaching things from this economic portfolio theory approach you’re mirrorring the biases of our society around the notion of luck and chance and it more likely than not will sap your motivation to work on things without you even realizing it.
Additionally, for a single indie developer like me, I don’t think it’s actually that hard to get a game to sell, say 5000 copies. And if you can do that consistently you can definitely make a living off it. Maybe I’m arrogant and I don’t know what I’m talking about. I probably am, after all I’ve only released one game. But I’d rather be arrogant like that than view things from this lottery/luck oriented approach that so many people seem to fall prey to these days.
This is an insidious mindset that subconsciously takes away your agency and your responsibility for your actions, it takes away your motivation for working on things at all, and it also makes you learn less from each project because if you can just chalk things up to chance, why improve at all? There are many reasons to go for small games, but doing it because of the idea that the market is a lottery, or that things are highly influenced by luck or chance, is a wrong one.
As was best said by someone way smarter than me, you’re not a lottery ticket: