Lessons learned from 10 game postmortems every developer should read

Even though computer games might look simple, they are extremely hard to design. A book I read summarized this perfectly when it described a computer game as a combination of everything. You have to be a psychologist to understand your users, you have to be an engineer to meet the technical demands, you have to be a designer to make the game pretty, you have to be an architect to design realistic environments, and so on.

A good way to improve your skills is to study what other developers have learned. I've already studied the game Antichamber: Breaking down the seven-year development of Antichamber by Alexander Bruce, and Chess: Why is Chess so popular? But now I've found an article called 10 seminal game postmortems every developer should read. It links to 10 other articles where game developers are summarizing what they learned when they developed their games. This will be a summary of the most important lessons learned:

1. Deus Ex

• Don't give up your ideas. If there's a game you really want to make, don't give up on it. Someone will be foolish enough to give you the money eventually.
• Follow the rules of role-playing, including: 
• It's not fun to watch an NPC do something cool. If it's a cool thing, let the player do it.
• If there's no need to look up and down - constantly - make a 2D game!
• You have to be willing to change your thinking and goals. Part of the challenge of the game development process is making the tough decisions along the way, leading to many difficult junctures when you have to determine that something that can't be done right in the game shouldn't be done at all. These questions are knotty and solutions are far from obvious. To answer these questions you should:
• Build a "proto-mission." This is the first implemented mission, playable start to finish, and it should capture everything you want your game to be. Get this mission working as early as possible, so you can see all the things you thought would work that didn't. For example, they thought the real world would be interesting as a gaming environment. But the answer was a tough-to-swallow "not very." So decided to not use the real world.
• Have an early milestone. When you have reached this milestone you will understand the elements that really make the game work. They could go through their 500-page design document and cut everything that was extraneous, ending up with 270 pages. Less game? Not at all. What was left was the best 270 pages - the stuff that worked. If you wait until a few months to go before the ship date, it will be much more difficult to make changes.
• By licensing technology, you will not always save time. You'd think cutting a year or more of engine-creation off a schedule would result in an earlier release date. On Deus Ex, that didn't prove to be the case. Time that would have been lost creating tools was lost instead to learning the limitations and capabilities of "foreign" technology.
• Know your limitations. Always work within the limits of your technology rather than trying to make your technology do things it wasn't meant to do. Big budgets, lots of time, and freedom from creative constraints are seductive traps. Don't fall into them. Don't settle for less than greatness, but don't think too big. Balance should be the goal.

2. System Shock 2

• Using your own game engine is both good and bad. The engine exposed them to bugs that another team introduced (who used the same engine in their game), but it also gave them the ability to fix bugs and add new features to the engine. It allowed them to change it to support the game's specific features in ways that a general engine never could.
• Know your limitations. They first analyzed the game engine's technological capabilities and then they decided on a design that would work with it. This process is almost mandatory when reusing an engine. Many of the times when they did deviate from this rule they had problems.
• Finish the game on time. They focused on moving forward, and they didn't allow themselves to be bogged down because they desperately wanted to ship a game. While there are features in System Shock 2 that could have been better if they had not rushed them, they still believe that the game as a whole was made better by their resolve to finish it on time.
• If you don't have the resources, use simple, reusable game-play elements. When you throw together many such systems, you end up with a lot of game play. They didn't have the time, resources or technology to develop the scripted cinematic sequences used by the then popular game Half-Life.
• Keep what's working and improve the rest. As the name of the game says, System Shock 2 was a sequel, so they identified the key elements that made the first System Shock a good game and reinterpreted those elements using current technology.
• Understand that running a business while participating in the development process of the game will be difficult. Neither of the founders started the company to be businessmen - they wanted to make a game. But you also have to make payroll, organize taxes and expense reports, and participate in business negotiations and contract disputes. So they decided to work harder, which destroyed their personal lives, even though they still devoted less time than they desired to every aspect of their work.

3. Diablo II

• Provide a constant source of simple pleasures. Offer a steady stream of goals and accomplishments, and try to make every single action fun:
• Players continually kill monsters and get rewarded with treasure and experience
• There's always a quest that's almost finished, a waypoint almost reached, an experience level almost achieved, and a dungeon nearly cleared out 
• Moving around inventory items produces pleasing sounds 
• Monsters die in spectacular fashion, like piñatas exploding in a shower of goodies
• Randomness is your friend. Use randomly generated levels, monsters, and treasure. The player will more likely replay the game, but randomness also makes each player's game his or her own. They will tell their friends about what they have just done in the game, knowing for sure that their friends have not done the same thing.
• The game should be easy to play. They used the "Mom test:" could Mom figure this out without reading a manual? Many games have different controls and key combination for all different actions when simpler is always better.
• Make the game playable as soon as possible. Their initial priority was to get a guy moving around on the screen and hacking monsters. This is what players would be doing most of the time, so it had to be fun. For example, they realized that players would be killing large amounts of the same monsters, so they could plan for multiple death sounds and monster animations. If they hadn't experienced the core gameplay as early as they did, combat would have ended up feeling more repetitive.
• Be the audience. You should like the game you are making. If after two years of making it (while playing it), and you are not bored to death, the game is clearly going to be a winner.
• But randomness is also your enemy. Testing a game with randomness is not an easy task. The QA team created a web-based bug-reporting database through which they categorized and tracked all bugs, balance issues, and gameplay suggestions. In the end, this list included more than 8,300 issues and suggestions.
• Make it easy to upgrade the game. Diablo II got criticism for having outdated graphics. When they began producing art for the game they had to use a specific graphics system. But when they released the game, the graphics was outdated. "We probably should have built in a scaling technology to take advantage of hardware that could display the same graphics at higher resolutions."

4. Thief: The Dark Project

• Make it as easy as possible for everyone to contribute. Their goal was to create a set of tools that enabled programmers, artists, and designers to work more effectively and independently. Non-programmers should have a high degree of control over the integration of their work, without requiring the direct involvement of programmers. Designers with moderate programming skills should be able to create complex object behaviors.
• Focus, focus, focus. Their original plan was full of features, including various multiplayer modes. But they discarded these ideas to instead focus on creating a single-player, linear, mission-based game centered exclusively around stealth.
• Solve major problems as fast as you can. The game had problems with the AI, which was a core part of the game, but they didn't act fast enough. They had to throw away 80 percent of the AI code, and after a 12-week stretch the AI was ready for real testing.

5. Baldur's Gate II

• When developing a sequel you are measured differently. You have to make the game better, and not just to make the same game over again. To do that you need a mechanism to quantify your previous mistakes and learn from them. If you don't figure out what you did wrong last time, you're not likely to fix it the second time around. They used post-project reviews to analyze both the strong and weak development areas of their earlier projects, and they also asked the fans what they wanted to see in the next game.
• Use design guidelines. To make everyone work against the same goal, use a set of design guidelines, like "The player must always feel as if it is HIS actions that are making him succeed. He should feel that through his smart decisions and actions that he has solved a puzzle or battle." You can see their entire list here. But these are only guidelines - and not the law!
• Don't forget your fans and the game after you have completed it. One of the most important things they have learned in their years in the industry is how important it is to support the fans that buy their games. This means first shipping a bug-free product, and second being completely available to help people that are having trouble with the game: on message boards, via contact emails, and everywhere else. What's the point of making games if you can't make sure people can play it - and who's better to work through technical issues than the people who made the game?

6. Myth: The Fallen Lords

• Do more with less. It doesn't take 50 people to create a major cross-platform software title. For example, they had no big quality assurance department because the public did the testing for them, and they listened to them as seriously as if they were coworkers on the project.

7. Unreal Tournament

• An update can become a real game. After the original Unreal was completed, they wanted to update the game with a multiplayer mode. But as the feature list grew and patches to Unreal were released, the add-on turned into a complete and independent game.
• Use the community. They held polls on popular Unreal message boards to decide what to add or remove. The results of these polls were taken into consideration when the feature in question was implemented. But they also read the discussions of the fans of their lead competitor's game Quake III. 
• Don't always use the community. The hardcore community is very vocal, but small. Designing a game to appeal to that community alone is a mistake. When they designed tutorials, they tested them on the parents and grandparents of team members to demonstrate that the tutorials were useful for attracting and keeping new players.

8. Age of Empires II: Age of Kings

• Don't make any bold promises. Their original plan was to finish the game in a year, which failed, and it didn't make the publisher Microsoft happy. But they managed to save the day by making an expansion for the original Age of Empires. 
• Take care of your employees. Crunch time is a period where you realize you have f*cked up so you have to work really hard (sometimes for months) to finish the project. But your social life will suffer. They solved this by scheduling crunch time well in advance at multiple points in the development process. The hours were 10 a.m. to midnight, Monday through Friday, with Wednesday nights ending at 7 p.m. so they could go home to their families. They had weekends off and meals were provided during the week.
• Monitor your play-testers. They discovered that a play-tester had turned cheats on, playing to win not to test, in almost every game for over a month, which invalidated all the feedback from that group for the prior two months.
• With success comes a responsibility to behave appropriately. Nothing lasts forever (the company shut down in 2008). Behaving in an exemplary manner and being friends with the industry at large is far more important than chest-beating about your current success.

9. Rainbow Six

• A good license won't help a bad game. But it can give a good game the visibility it needs to be a breakout title. 
• Rely on proven technology. Their external unproven solutions for rendering and networking both fell through and had to be replaced with internally developed code late in the development cycle.

10. Black & White

• Begin small. A core team of about six was formed, and at the start of Lionhead they worked in Peter Molyneux's own house. 
• Take risks. At the time they started, you couldn't have done what they did. No-one knew if the graphics could run on the computers, no-one knew if the AI would work.
• Everyone has bugs. At one point they had 3000 bugs, and for each bug they fixed, three more appeared.