Games are a great example of how "if you build it, they will come" just doesn't work in crowded market place. You need 2 other things: a way to build a communi

Games are a great example of how "if you build it, they will come" just doesn't work in crowded market place. You need 2 other things: a way to build a community and a way to convert that community into incoming cash. It's important to understand that indie game devs usually don't have a huge runway of capital, so both of these things are necessary right from the start. I don't exactly know how you do this because I haven't done it before, but my naive feeling is that it's a huge risk to sit down for 3-4 years and just write code. You have to find a way to engage your potential future audience while you are developing the game. Many of the most successful indy games have the same development ethos of open source software: release early and release often. Second, I think it's important to ask for money very early on in the process, if that's your ultimate goal. I think the article is good to point out the economics. Users have played 1000 hours (roughly 1 hour per user) and the dev has made less than $30. That's 3 cents per hour. There are plenty of games that cost $4-$5 that have no demo at all. Even at 1/10th of the engagement, you're still talking about $400-$500 rather than $30. Finally, as others have said, I think the idea that you are going to strike it rich with your first game out of the gate is naive. Indy game development is about the long tail. Don't throw 2K hours into a game. Throw 200 hours 10 times and try to build up a revenue stream. At the very least, it allows you to pivot a lot earlier if you find that your are getting absolutely no engagement. But at the end of it (and I haven't played the author's game, so I'm making no judgement here), a game has to be fun. You don't need a finished game to demonstrate the fun. That first proof of concept needs to be distilled down to pure fun. Once you've got that sorted, you can start working on the rest. I think it's temping to build a whole infrastructure of code (or write a game engine ;-) ) and then once you are hundreds or thousands of hours in discover, "Wait a minute... this game is actually kind of boring". Only now you have a legacy code base and it's really slow to start trying to morph it into something that is fun. I was just looking at Kenta Cho's blog the other day and earlier this year he was doing a 256 byte JS Browser game challenge [1]. What interested me about his blog post is that he concentrated entirely on game mechanics. He tried a couple of game mechanics and then tried to mix and match them to find interesting variations. I think this is the kind of thing you need to do very early on in game development. Then once you have a core game mechanic that is really fun, you can start building a game around it. [1] - http://aba.hatenablog.com/entry/2018/03/07/174528 http://aba.hatenablog.com/entry/2018/03/07/174528 (Sorry, Japanese only -- but has some interesting gifs)