10.5 Game Development Lies the Industry Should Stop Telling
Liar's Poker
Every week there is another hit indie game and my LinkedIn feed lights up with such delights as “Why Cloverpit Has Killed AA Development in 2025!” or “What Megabonk Taught Me About D20 Retention Cadences”.
Now, those are both fake but they feel real and thus have just hyperstitioned their way into reality by virtue of you reading this sentence.
How can I combine my disdain for this style of mushy hot take with my desire to produce attractive content for you, The Audience? Let’s go to The Stats…
The market has spoken - it’s time for another listicle!
Here is a hand-curated steel-cut selection of legerdemain perpetrated by the most nefarious of cultural actors on our lamentable stage: the game developer.
LIE 1: “We put our players first!”
I’ve seen variants of this many times through the years and I think it might be entirely contentless and thus counterproductive. We’ve all heard of Amazon’s “customer obsession“ and you can see how that influenced the early days of the company: should any dev studio truly lay claim to the same ethos?
Making games for actual players who exist, listening to them when they talk and taking care of them are all extremely important: these issues comprise the majority of conversations I end up having with devs. But games are a creative medium: they are not purely functional products which serve a predetermined purpose - as such, they are a dialogue between the creator and the audience. There’s a word for creatives who “put the audience first”: hacks. Perhaps we should put the quality of the work first, the players second and then the other stakeholders after that? Perhaps I shouldn’t have looked at The Stats…
LIE 2: “Players don’t want [genre] any more”
This one has died down more in recent years thanks to being comprehensively debunked by an endless torrent of one billion successful niche games pouring into gaping maw of the market via digital distribution. But still you’ll see Big Genre Opinions trotted out by industry luminaries from time to time: they’re always way too absolute, meaning they inevitably collapse a couple of years down the line.
Gamers themselves aren’t immune from this type of thing by the way: I have ranted extensively about “[Genre] is oversaturated” in the past.
LIE 3: Genre is the most important thing
Yes, there are some genres (city builders etc) that lend themselves to greater retention and thus greater attention over time. Yes, Hooded Horse has done fantastically well by aggressively zeroing in on a few key genres which display these characteristics.
But the problem arises when we attribute everything to genre: “This can be categorised as a deckbuilder so it will sell well” is a deadly trap to fall into. Instead, devs should focus on the conversation that a genre creates with their players, as well as the underlying traits.
LIE 4: Developers should operate on “passion”
It’s relatively rare to find someone still working in games who would rather be somewhere else.
Most technical folks in the industry are choosing to sacrifice some level of financial potential in order to continue to engage in work that they care about. For others in creative roles, games are usually a personal outlet: you have to love games in order to even show up each day.
“Passion”, however, describes a transient rush of emotion: it’s not something that can be relied on for the long term and it certainly shouldn’t be leveraged on a continual basis by employers. It’s a word that’s thrown around coercively within companies or used as a weapon by disgruntled players.
Everyone needs to be emotionally invested in the game they are making - this is a given. But it’s more productive and humane to focus on inputs (direction and support) rather than on outbursts of feeling.
LIE 5: Games is a hit-driven business
This is a hoary old chestnut I’ve trotted out myself many times (particularly to non-industry folks) but I’ve come to both dislike it and believe in it significantly less.
I’ve linked my great friend Jake Birkett’s legendary talk before and there’s so much valuable stuff in there - it’s also interesting in the context that Jake and crew are on course for a hit right now! Equally, Jeff Vogel’s talk Failing to Fail is a case study in a sustainable career in indie games - he’s been operating since 1994:
While hits generate the majority of revenue and create the greatest long-term industry impact, they are often produced by teams of people who have already taken multiple shots. The drive then comes from that sustained effort and the conditions required to produce it.
My concern is that we’re telling ourselves - and particularly new devs - that if you don’t have an 8-figure megahit after a year’s worth of effort then you might as well pack it up and go home. This mirrors the extremely insular startup culture which is pervading the San Francisco / Silicon Valley tech milieu right now: you’re cooked unless you hit $5m ARR by 22.
“Hit” is also a creeping definition - making $100k was a huge deal in indie games originally; now we’re not even paying attention unless something has 4k positive reviews on launch day.
LIE 6: Small = Sustainable
Companies should be sized in such a way that enables them to function effectively while retaining their humanity: this seems like a truism but it is not the way that many devs approach their businesses.
Very small companies are often highly precarious: cracks can start to form from simple founder disagreements or other unforeseen setbacks. Sometimes growth - and the choices involved with nurturing it - can hugely strengthen a company for the long run.
“We want to stay small to be sustainable” often gives way to “we want to stay small because we don’t like management.” The problem here is that game dev founders will often end up doing more management in a smaller business than a slightly larger one which can sustain more layers of production or administrative support.
LIE 6.5: Games publishers make great public companies
Oh no, I’m not touching this one.
LIE 7: You should aim for wishlists
Wishlists are important and they are a helpful heuristic. It’s good to get tactical with your store pages; it’s good to monitor your changes to see if they are having an effect.
Over time, we’ve migrated from total ignorance about wishlists and their mechanics to a maniacal focus on them. It’s hit the point that devs are proudly talking about their wishlist numbers with absolutely no context or benchmarks.
The focus should be on the game itself and how the players you want to attract are responding to it: everything flows from there. Don’t aim for wishlists: aim for something that matters on a more fundamental level.
LIE 8: You should prioritise mod support
You can do mod support - I am not saying you should never do it.
You can plan for mod support if it is beneficial to the architecture of your project.
But if mod support causes a significant delay to either shipping your game, or to supporting active players who want more content then you should not prioritise it.
“But modders will make the new content themselves! It will be a perfect utopian ecosystem where the community serves its own needs!” No, stop. This only works when your game has a very large playerbase and there are either social or technical incentives for modders to make high-quality content. The best person to make content for your game is almost certainly you, the developer of the game.
Want to finish off mod support as a legacy contribution to the community once you’re done with official content? Go right ahead. All I am saying is: do it at the right time.
I’d love to see the edge cases where this isn’t true: if you have a small game where prioritising mod support was a positive move then I’d be very interested to hear about it.
LIE 9: You shouldn’t work on lore first
Tim Cain’s “Setting → Story → System Mechanics” has been tremendously useful to me on my current project and I think offers a great counterpoint to “gameplay first” approaches. It’s worth watching this video to see how he positions those ideas.
Personally, I think it’s better to work on mechanics first if your mechanics are highly original or novel: if you need to understand whether or not gameplay is viable at all then coming up with a load of story nonsense off the bat is going to be extremely unhelpful.
Here is where I would apply Setting → Story → System Mechanics:
You’re working in a bounded design domain where you know that the gameplay broadly works
The game is heavily reliant on narrative for player engagement
You know that mechanics need to relate directly to the narrative
LIE 10: Nobody knows anything
It’s intriguing that both Jeff and Jake mentioned this point in the talks I linked above: while I love their perspectives in general, I disagree with them strongly on this one.
Attempting to prove that “some people in games know some things” will sink into the epistemological weeds instantly so let’s take a different angle. There are processes and frameworks in games which are useful at different times and those can be applied to mitigate this uncertainty: often, more experienced devs have learned those frameworks and have a good instinct about when to apply them.
Taste is also real: look at the recent emergence of publishers like Critical Reflex who clearly have a strong sense of vibes driving their catalogue decisions, for example.
“Nobody knows anything” is great when you want to take a risk; it’s not so great when it causes you to miss handholds as you plummet into the void.
No More Lies
That’s it for now. Still believe these flagrant falsehoods? Well, go ahead and let me have it in the comments.





Thanks! I think we haven't quite worked out the right way to discuss our relationship with feedback and the audience. "They know the problem but not the solution" hasn't felt fully true to me either in recent years.
Well said Paul. An interesting read!
At some point I'm going to dive deeper into "Lie 6". I actually think that small companies are better-suited to launch new IP than big ones. Whereas big companies can often find ways to grow and nurture existing IP that aren't possible for small teams. EGG promotes staying small and agile in the prototype phase until you "find the fun" and de-risk the game loops.
Totally agree though on the small means "no management" fallacy though!