Game Development process reviews, Part 2

The last blog I wrote on this subject was a simple "metapostmortem" of game development at the AAA level to see if the big studios had any issues that were unique to their tier, or if they had the same issues as Indies do.

The Preliminary Result: It seems that most problems boil down to preparation. From initial design and scoping of the project to the scheduling, pipeline, and even testing issues, game projects seemed to live and die internally well before they were released (to live or die) in the wild.

Now, shortly after posting the blog, I was informed about a similar metapostmortem conducted by Gamasutra itself, and I'll be compiling some of that data here. But, as Indies, we also have our own unique problems, and having come across another nice article, I'll be summing up tips for those looking to join teams as well. Links are in the section headers below...

Gamasutra's take on AAA development issues (Full Article Link):

1. "Not structuring time for game playing": I think this can firmly be placed in the "testing" category, as it involves teams not playing the games that they make. Iterative game development can help with this, as the game is play-tested during these iterations, but follow-through with bug tracking and coding tasks also goes a long way.
2. "Placing too much importance on paper designs": Again a preparation issue, designers who get "married" to their designs and stick with them in the face of misgivings, peer or team advice, or player feedback (during testing) are doomed to bad game design. No one should be cocky here- we're all susceptible, and we should all have some level of self-questioning when it comes to our designs.
3. "Peer review not taken seriously": This category basically makes the case that people who play more games get exposed to more ideas that they can then use in their own games. 'Nuff said.
4. "Decision-Maker picked for his Producer skills": This issue is related to, in a more generic sense, putting people in positions that they are not (yet) able to cope with. This also occurs in other industries, with what amounts to incompetent managers, but here relates to designers who are more skilled in administration than producing good content and mechanics.
5. "Not taking advantage of Placeholders": I see this here as well, especially with those newer to game design and not yet exposed to the idea that game mechanics are not tied to eye-candy, but also with others who should reasonably know better. A DIF or DTS box can save a game project by allowing designs to be tested against something, while plain shapes and stock UI art can help place GUI components.
6. "Allowing the story to control the game design": I'll be forward and say that while I understand the point and it is certainly valid, this can also speak to design flaws or the need for more innovative and imaginative designs and mechanics. That said, this category speaks to story with objectives that go against designed features being shoe-horned into the game, resulting in a bad game where the design was otherwise good.
7. "Not giving designers enough tools": At the Indie level, teams tend to lean on outside entities to create tools for them in far more cases than should be the case, while at the AAA level, there is a disconnect between giving designers the power to create tools, and the debuging that coders must do with that code. A good solution would be to have the designer collaborate with coders to get tools created to the specs needed- and this goes for both Indies and AAA's.
8. "Entering production without something fun": This is about designers crapping out on basic game mechanics. Now, if your game isn't fun with placeholder art, it won't be fun with normal mapping and 2048x2048 texture maps, and anyone who disagrees with this simply does not understand what fun is (and he's probably the guy who writes the checks!).
9. "Not keeping design-documentation up to date": A communications issue at its core, this issue shows how teams can get out of sync by not documenting changes to the design in documentation that is referenced by team members who may not be privy to the meetings where these changes take place. And when they don't see changes reflected in the documentation, they won't use it, and then when you do start updating it, it still won't be used, because the team figures that it's wrong.
10. "Not making outside playtests part of the process": More eyes equal more quality, and that goes for more than just games. Rigorous testing of software, vehicles, clothing, appliances, and more ensure that they will work as advertised when thrown into the wild. Games are no different, and if you don't playtest your game outside of your team (who are all "true believers" in the project), then you risk releasing an inferior product.

Words from the wise. The article goes into much more detail, and I've paraphrased and added my own slant on these issues both because I'm not just aiming to repost the whole article, and to tailor it somewhat to the Indies who populate this site. That said, we can still learn a lot from the AAA's, who are much more willing to dissect their own failures than we are. And speaking of we...

Choosing an Indie team to join: Here's an article I found at GameCareerGuide.com concerning guidance on choosing an Indie team to work with. Here's the short version, or click the previous link for the full article...

1. "Bad management": I've said this in one of my other threads, if the leader of a team has no skills, the project is going to go nowhere. Being an "idea person" just doesn't cut it, and is lazy to boot...
2. "Don't be lured by art alone": The truth is, a project may have great artwork, but bad management, or bad design ideas, or just a bad team dynamic. Art alone should not be luring people in, though it does. That's not knocking teams that are trying to bring coders in and use art to show that they have skills, but it shouldn't cover up for bad designers or coders.
3. "Take a strong look at the programming team": Many teams form and disband every month around the world due to this. Basically, you get people talking a great game, and then the rest of the team realize that the coders are trying to learn C++ while trying to make the next great game engine. Nothing wrong with learning, and nothing wrong with having goals, but combining the two is usually a bad mix. Unless you have a goal to learn, in which case you're just fine...
4. "Management Advertising That They Are Going To 'Make It And Go Retail' Early On ": Oh, and this is usually accompanied by wild claims of beating WoW, excessive use of exclamation marks, bad grammar, l33tspeak, textspeak, or other indications that these people need to sober up before posting. These people usually have ego issues as well, leading to bad team dynamics.
5. "Poor Organization": Less to do with documentation or how smooth meetings and management go (though it does factor in), this pertains to teams with too much flexibility. Changing engines, changing designs, and an aversion to solidifying anything are key hallmarks.
6. "Bad Designers": While the article says that this is a bit difficult- I'm not so sure. How many people have you seen on the forums that, when describing their game, listed a half-dozen other games, and yet could not single out which mechanics of which game fit into their design, nor how their design would work at all? Or do they give you the impression that that task of making so vague a description of design the work of the coder to complete somehow? If they can't say "the player clicks this, does this, and then gets this", then you have a bad designer.
7. "Pay Attention To Public Opinion About The Team ": Quite easy to do, with the profiles here showing the blogs, threads, and forum posts of the person asking. You can quickly follow these links to do a quick bit of research on what team members have said and asked on this site, and other sites can offer up much of the same information.
8. "Identify The Audience And Platform, Make Sure The Management Is Sane ": Because making a WoW-killer MMO for Windows Mobile/iPhone/Wii/XBox/Windows/Linux/Mac and within six months is just not feasible. Nor is making many game types within six months, when you get right down to it...
9. "Self-Proclaimed Experts": This is all about people who talk about being experts at what they supposedly do, and yet have only the barest knowledge of a beginner when you investigate what they've been saying on the forums. Get past their BS, and you find someone with a lot of ego looking to lure people into a destined-to-fail project, wasting their time and talent for their own ego boost.
10. "A Group With A Really Long History ": FULL DISCLOSURE- My own project falls under this, and I'll tell you why: It failed twice because of insufficient planning and preparation (see the first part of this blog). We're much better this time around, and have even lived up to some of the early hype about our tech, but in looking for people, we do take a bit of a hit on this point. The fact is that the longer a project is in development, the longer the odds of it being released. Just look at Duke Nukem Forever (or whatever the real project name was).
11. "How You Get Along With The Team": Egos, immaturity, backstabbing. This all goes on routinely in many of the Indie teams that fail. Some team leads are the source of it, and some are too weak to put an end to it and keep their team members acting professionally. Occasionally, some don't know about it until it's too late. But any which way you cut it, talk to the team you're thinking of joining before you make a final decision, or you may regret it. And be wary of team leads who discourage you talking to their team before joining.

And now, I'll add some of my own to this list:

1. Secrecy: Beware of teams or team leads who refuse to post any detailed information on their game design when asking for team members because they fear those designs being stolen. Aside from the general wrongful thinking behind the fear of having an idea stolen and turned into a game, this can also represent people who have problems with being forthcoming with information at many levels. I remember talking to several different people who, while I was trying to give a pricing estimate, was so averse to giving complete details that I finally gave up. Paranoia is not a good trait to have in a leader.
2. Grammar/Spelling: If you cannot properly write in your native language (in the case of examples I see, English), expect for that to reflect on your professionalism. Many people can forgive non-native English speakers' communication difficulties and will actively work to bridge those gaps, but not so with people who simply do not put in the effort to communicate effectively where they obviously can. This is a rule regardless of which language is spoken, so if you are an English speaker, write proper English. Spanish? Write proper Spanish, etc.

And with that, I finish up this two-part blog. There's enough information in here for everyone to learn something, because no team is immune to these issues. Preparation helps your game's quality and success rate, but so does the way that you present yourself to Indie communities for attracting people. The most important rule, not covered above, can best be summed up by an unofficial motto the United States Marine Corps goes by, and which serves as a principle for any team or organization that wishes to stay relevant in the fact of problems:

Semper Gumby (Always Flexible)

That's right- stay flexible. If you see a problem brewing, address it. An opportunity, jump on it. A tough road ahead, focus and stay the course. Be flexible, be agile, and above all: Be Successful!