Game Development Misconceptions: Why 95% of Games Never Make It Past Alpha

Before you jump into game development, keep in mind that 95% of games never make it past the Alpha stage. Let's find out how such problems as misconceptions and false expectations can be avoided.

Well, we hope that this article will start a whole new series dedicated to the behind-the-scenes of the game development industry and will be useful to indie developers that are just starting their career as well as to the ones that already have something in their portfolio.


Just before you jump into game development, keep in mind that 95% of games never make it past the Alpha stage. It’s OK when a game idea is ditched during the prototyping phase, but dropping the project in Alpha means you made a mistake somewhere down the road. But how can so many games fail without even making it to the shelves?


The main reasons for that are misconceptions, false expectations, underestimation of efforts and process management issues, which lead to chaos. With the help of Pavel Shylenok, CTO at Knocknock Games, we tried to dig deeper into each of those reasons and find out how these problems can be avoided.


Game Development Misconceptions


If you are just aiming to become a profitable game development company or just a professional, you will probably read a lot of thematic forums, most likely related to Unity 3D or Unreal Engine. On those forums you’ll see a lot of inquiries starting with words like: “I’m making my own game”, “I have a problem with my game” and countless variations alike.


That’s what we call a misconception. Those people aren’t actually making games (even if they honestly think so) they are just playing with development tools. You see, having a spinning cube in Unity or walking with the First Person Controller from standard assets doesn’t mean you’re making a game. Games start with a concept and art, not with the code which, essentially, simply brings visuals to life.



Based on our vast game development experience, we have yet to find a developer who can write beautiful dialogues and adequate narrations as well as create all sorts of art (both 3D and 2D). Same applies to writers and artists — they don’t code.


So let’s stop lying to ourselves and accept the fact that as long as you don’t have a team, you aren’t making a game — just playing around. That’s one of the reasons why Unity Asset Store has so many low-quality assets.

False Expectations

What makes games fun to play? A great idea? A presentation? A story? Competition?

To answer this question, just take your favorite game as an example (of any genre, of any style, of any age). Let it be Starcraft Series and PS4 Exclusive Horizon: Zero Dawn.


Now, imagine that units in Starcraft would be presented as geometric figures (i.e. cubes, pyramids, etc.) on a solid color-filled map with default material, created as a plane object. Instead of a command center, there will be a big cube, barracks will be a smaller cube of a distinct color. Then let’s take out the sounds and music and replace them with a pop-styled or royalty-free track, remove story and narrative, and put only “a dialogue line 1, “a dialogue line 2”, etc.


If you look at this game now as we “patched” it, would you imagine something similar to Starcraft you all know? It will by no means resemble the game we love, even though the core gameplay mechanics will remain intact.

Would it be fun to play?

We doubt it. The fun and addictivity of the game is a combination of all factors we removed, where no half-baked disciplines are allowed.


This brings up a really interesting question: Why do many indie and one-man game development teams think that their incomplete prototypes can be interesting to users? They don’t! It’s just false expectations. How to avoid that? A quick answer is to make a high-grade game that’s is fun to play. However, in reality, to fully cover this topic, a book-size discussion would be required; we’ll discuss some of the aspects as we go.

Underestimations of Indie Game Developers

So, how long does it take to make a game?

So, for you to fully understand the importance of this question, let us give you some time figures and numbers that are required to produce a single game asset.


In a project we’re currently working on — a turn-based strategy title Rise Of Colonies — players build mech units and use them to dominate maps. And there are 14 different units planned for the title. Here’s a brief development efforts breakdown for a single unit:



Scout Unit:

  1. Concept art — 4 days (if you are lucky to find the correct look and feel within this time frame)
  2. Modeling (High-poly + low-poly models) — 10 days
  3. Rigging — 2 days
  4. Animation (units have to move, attack, rotate) — 3 days
  5. Texturing — 3 days
  6. Exporting and importing into the engine — 1 day
  7. Particle effects (for different states, i.e. dust when walking, fire during attacks, etc.) — 5 days
  8. Unit Behavior Logic coding (proper movements, animations timing, etc.) — 10 days
  9. Unit Sounds — 4 days.


As a result, we need approximately 42 days of work for a single unit! Now, multiply that by 14. You’ll get 588 days or 4,704 hours of work just to create units, which alone can do little to make a game. A minimum number of people required is 4: a 3D modeler/animator, a concept/texture artist, a developer, a sound engineer. Mind that it’s only a ballpark estimate that does not include any extra iterations and technical challenges that might arise on the way.

Have any questions?

Ask us

So, how long does it take to make a game?

Well, we have 5000 hours for units; let’s add environment, maps, campaign, AI, sounds, menu, HUD, multiplayer, cutscenes, visual effects, story narrative on top of that, and you will easily get past by something like 50,000 hours for a Turn-Based Strategy title, which just has a chance to be called “decent”. A one-man company (provided the developer is a maestro and can do anything alone) would spend 20-30 years to create such a game.


That is called underestimations, and it’s the main reason game projects are dropped in the process several months into the development. It usually happens when amateur developers start seeing the scope clearly, the eyes finally open and the fear of the work ahead head-shoots any trace of the remaining motivation.


The solution? Invest in some serious planning before you start any development activities. Spend a couple of weeks (or months if necessary) to create an accurate plan while paying close attention to the smallest details, write down all necessary content and activities related to its creation. Then, roughly estimate what it will take you to get it done. The numbers will then speak for themselves.




Process Management Issues

Just ask yourself a couple of questions:

  • Do you always have a working code in your game repository? Do you even have a code repository?
  • Do you have defined project folder structure and content submission rules that are clear to everyone on the team?
  • Do your game development studio have daily commits? Is there a mandatory requirement for everyday commits?
  • Do you have separate content/design/development meetings?
  • Does everyone in your team have knowledge of tools used to develop a project?


The number of questions is huge, and if you answer “No” to at least one of those, just a single one – it usually means that something isn’t right with your processes.


What will you do if there’s an urgent need to demonstrate the game and it doesn’t compile? How will you handle the case when an artist commits a level and brings down the whole project or corrupts project so that it stops working? This is an especially actual problem with Unity scene merging.


Long ago we personally had an issue when our artists were so engaged in with the process, that they forgot to make commits for a couple of days and then, out of a sudden, one of them replaced the level’s splat texture they’d been working on for the last few days, with a blank one.


What happens next is a lesson taught by the operating system: the OS file system doesn’t keep a history of modifications, so the results of the last two days’ work were lost.


What does that mean to you? At the very least:

  1. 2-3 days additional days to the development budget
  2. Lower quality product, because redoing anything usually results in a worse outcome than the original work.
  3. Release delays.

Team qualification, human factor, and unorganized processes are the biggest holes in your development budget, so the first thing you’d want to do is to structure your work so that the human factor is reduced to a minimum. Have everything… we mean, literally, EVERYTHING under control. Every submitted asset, every line of code should ideally be inspected by the department leads, because a typical game contains a hundred gigabytes of raw assets and hundreds of thousands of code lines. Let it go for a moment and you’ll never catch it!


If that’s something new for you – then it is great, because you still have time to rethink your processes. Don’t take these words as absolute truth, just go ahead and read different game postmortems and memoirs of failed game projects. The one common reason that will be there for sure is “mis”management.


So, should you stop making games?

Well, if you are a one-man game development company, the answer is probably yes. The best way for you is to join an existing team and help them make a game and, if everything goes smooth, you can push the ideas of your own games to the team. Believe us, if they are really interesting, the chances of being accepted are quite high! And you will have a team behind you to back you up.


If you are an indie game development studio with no successful releases under your belt, then provided that you have roles distributed correctly across your team — you still have a chance to succeed.

Latest news