The gaming industry is still a relatively new one.

In most industries, there are some parameters for success, guidelines that delineate what will make a good product versus what will make a bad one. For an industry whose projects often times start in garages, developers don’t necessarily have the resources or the decades of trial and error to create this formula that other industries possess for their product. Furthermore, because being a developer is just as much being a creative as it is taking a role as programmer, many developers don’t necessarily want a clear cut formula, as it may interfere with the creative process. There are, however, a few tell-tale signs that a game might fail.

Brett Norton is a game developer for Trendy Entertainment, and has been in the industry for over a decade. He is recently working on projects such as Dungeon Defenders II, but before Trendy, he was an editor and gameplay designer from the now inactive Time Gate Studios, and has a lot of insight on what could make or break a game.

In 2004, after the critical success (though tragically low sales) of Kohan II, he started working on Axis & Allies, a strategy game published by Atari, but developed by Time Gate. Atari was looking at making the game closer to Starcraft or Warcraft III, a micromanagement-heavy gameplay where the player can control individual units, presenting the game with an action-oriented feel. This had been successful in the past, and Atari wanted to work off of the model that already worked. Time Gate, on the other hand, was looking toward making a more strategic game, working with supply lines in a grand war scheme, closer to Company of Heroes or Dawn of War. “The easiest way to get a crappy game made is when you have no clear organization of hierarchy,” Norton says. There are conflicts between developers and publishers all of the time, and conflicts inside each entity, as well, but when there is no clear strategy for conflict-resolution, the game almost always falls flat. Axis & Allies’ sales did pretty well, but the critics tore the game apart. Norton describes it as, “and ugly but well-built house.” It won’t collapse, but it’s also not very aesthetically pleasing.

Jump to 2011, Norton came across the same issue, this time when Time Gate was contracted by Gearbox to work on Aliens: Colonial Marines. All of the decision-makers in both Gearbox and Time Gate seemed to have their own ideas of how the game should turn out, and because there was not a lot of role-clarity for who has the final say, the game suffered. Some people were pushing a strong multiplayer aspect, while others saw that their engine would run a single-player campaign beautifully, but would struggle under a complex multiplayer campaign. This brings up another fatal flaw of game development: “You’ve got to build the game to the strengths of your technology,” Norton claims. Games evolve in development, and sometimes change completely from the original design. A mistake that a lot of new developers make is they try and force this new idea for the game to fit into the technology that they already had set up, effectively jamming square shapes into circular holes. Aliens: Colonial Marines sold relatively well at first, due to the marketing campaigns that Sega had covered, but received the Metacritic score of 45 and had a huge backlash from the fans because of the hype that had surrounded the development of the game. “It drained all the joy from the guys that were working on it,” Norton remembers, “and that can have a huge effect on the outcome of a game.” What did Aliens: Colonial Marines do right? Surprisingly, because of the small team of tightly-knit developers surrounding it, the multiplayer campaign came out on top and was very well-received.

After working on quite a few development teams over the years, Brett Norton can spot the pitfalls that can await even the most careful developers.

First, whether it be between development companies, publishers, or individual game developers, some sort of process for decision-making and conflict resolution must be put into play. Though it can be tricky to nail down this sort of process in a creative endeavor, there should be some sort of authority that has the power to make the final say. “If you don’t,” Norton says, “projects will keep getting scrapped and then started over in the middle of development.” This slows the process down, and a lot of the time, the level or project in question doesn’t need to be completely thrown out but just tweaked. This tacks on weeks, sometimes months, to development.

Secondly, the game has to be molded to fit the technology, not the other way around. It’s much easier to program a game to fit the engine you already have than it is to attempt to force an engine that isn’t necessarily compatible with the game style to compensate.

The third fatal flaw that Norton described speaks especially to small indie developers: Overscope. Indie designers are known for having incredibly creative ideas that are often times challenges to the form. The issue comes along when the developer has an amazing idea, but vastly underestimates the time, work, and money involved with taking that idea to fruition. “You’ve got to kill your babies,” says Norton. If the developers come up against this problem, the only way out of it is to simplify the idea and cut scope. It may mean cutting one of their favorite aspects of the game, but at that point, it’s either cut it out, or scrap the project as a whole.

Conversely, the fourth way a game can fail is in a large-scale development team if the owners of the project and the upper management aren’t highly tied to the project. “They need to play the game a lot.” This aspect goes hand in hand with the first fatal flaw, because if the higher-ups are actively involved with the game, they tend to rely less on the programmers to make final decisions. If they have first-hand knowledge of how the game is progressing, the decision-making process is streamlined.

The fifth and final flaw that Brett Norton has seen in the gaming industry is one that stands out because it doesn’t have a specific formula or set of steps. The game must have a genuinely fun, solid gameplay. It has to have soul. “You have to spend the time to find the soul of the game before you ever try to finish it.” Even if a developer gets all the others right, if the game isn’t fun, if the premise isn’t enticing, the game is going to flop. The key? If the programmers and developers are having fun making the game, the player will probably enjoy playing the game. It takes us back to the silver lining on ACM: the multiplayer. The team that worked on the multiplayer was a small group of tight-knit programmers who were all relatively on the same page about the aspect of the game that they were designing. When the other programmers’ joy drained from the project, the multiplayer team came through.

There is no handbook on how to make the perfect game.

It’s a fine-tuned art, with an insurmountable amount of risk, and often times, even after years of work, little reward. However, it’s important in any industry to identify the pitfalls and avoid them at all cost. If an experienced team can know how to do this, they can take the time that they would’ve spent fixing problems and plugging leaks, and use it to focus on making their game the best game possible.