Game designer Fisch looks into the process of making games, suggesting the ten biggest reasons why a game's production doesn't end up working out quite as hoped, and possible fixes for those issues.
[Game designer Fisch looks into the process of making games, suggesting the ten biggest reasons why a game's production doesn't end up working out quite as hoped, and possible fixes for those issues.]
If you look at which games succeed and fail critically, you will notice the outcome is generally not due to a great mechanic or a new idea, but from competent execution from the moment of boot-up to the end credits.
Countless games such as Spider-Man 2, Stranglehold, and Assassin's Creed present the player with innovative concepts but fall apart when it comes to filling up the 10-15 hours of gameplay.
On the other hand, you have games such as Call of Duty 4, which brings almost nothing new to the table, but excels greatly when it comes to pacing and level structure -- keeping the player hooked throughout the entire experience. Even games considered to be innovative -- Portal or World of Goo -- would not have had their success were it not for superb execution.
I've worked with a number of teams that start with a very nice concept but run into problems when it comes to translating it into a compelling video game experience. I've noticed that certain practices tend to crop up that hamper a developer's ability to get the most from its design team.
I've organized these into the 10 "design process pitfalls" below.
This first pitfall seems trivial, but can actually have a large impact on the quality and efficiency of the design process. Ideally pre-production would include a set amount of time for everyone on the design team to play games in the genre they are about to take a shot at.
I've never seen this happen in a structured way. "Play time" can be hard for some producers to wrap their heads around, and the idea of scheduling a week or more of "research" for a five-person team can seem like a rather expensive play session.
Instead, designers are expected to already have a strong knowledge of what's out there. Unfortunately not all game designers have enough free time to play every game out there. Generally, the older the game designer is, the less free time he'll have. Furthermore, the games a designer chooses to play in his free time may not line up with the games he should play for development purposes. Many mediocre games, for example, contain interesting ideas and are valuable as learning tools.
Devoting time to playing other games in your genre can lead to a better product and save a tremendous amount of time. I worked on a project where a designer happened to play a game in the genre we were working in and "discovered" a better player navigation system than the one we had already spent months on.
On another project, someone "discovered" a third-person cover mechanic implemented in an unpopular game that was exactly like the one we argued about including. Weeks of debate could have been saved had we played this game and had known that the mechanic wasn't as fun as it seemed on paper.
Nintendo/Retro Studios' Metroid Prime 3: Corruption
When the designers all have experience playing the relevant games, their ability to express ideas to one another is greatly enhanced. One designer can say to another "We could have the lock-on system from Metroid Prime, except toggleable by pushing in the right thumb stick".
If the other designer has played Metroid Prime, he immediately understands what the one designer is thinking. The lock-on system does not need to be explained to him. Not only that, but he knows how it feels in his hands - something that cannot be conveyed with words.
I once worked with a lead who deemed the Gears of War grenade throwing system too complex when explained to him on paper. Once he finally sat down and tried it himself, he saw that it clicked and approved its inclusion.
It's important that the lead designer himself takes part in the research along side the rest of the design team. If the lead designer deems it "lesser important" the rest of the team is likely to follow suit. Furthermore since the lead is usually the main decision-maker, it's important that he is able to speak from the same lexicon as the other designers.
Implementing a period of structured game playing may require some persuasion. A producer will be more likely to get on board if there are tangible results -- for example, each designer could be required to present notes to the lead at the end of every day.
Students of mathematics may know that one of the fundamental ideas of Chaos Theory is that some systems, such as the weather, are so complex that it is impossible to make accurate predictions of their behavior. There are too many interacting variables, any one of which could lead to a major change. I feel that games are the same way.
A designer can try to imagine how a level is going to play in his head, but any of the hundreds of interacting elements -- the environment, the controls, the game mechanics, the physics, or the AI can each make a huge impact on the overall fun. This is one reason that I don't put too much weight on paper designs.
The second reason is that, in my experience, the best ideas are discovered through experiments and happy accidents. I'll often be building a level based on a paper design when I notice that when the AI interacts with the environment in a certain way, I get a really cool little experience.
I will then modify the level to make this something that most players will encounter. This form of discovering fun through interacting with the game's systems only works when the designer has the freedom to modify his level from the original paper design.
Unfortunately, designers don't always have this freedom. I've worked on teams where designers were given equal time to create a level on paper as to create it in 3D. Once a paper design was finished, it was presented at a big meeting, analyzed and approved.
If a designer wanted to make a large change during the 3D phase, this was treated as correcting an error he had made in the paper process. The paper design had to be reedited and another approval was needed from the department leads.
Designers were expected to get it right the first time. The end result of this process was environments that didn't fit with the game. For example, some environments featured enemies that the player could see and pick off from a mile away. Others featured enemies that the player couldn't see until they were two feet from his face.
If you've worked at a game company you've probably heard the phrase "more people need to play the game" tossed about at a meeting or two.
These calls are generally made to the artists and programmers, yet I notice that designers have a habit of not playing each other's work. I've definitely fallen into the trap of being so focused on my own work that I neglect to play the work of others.
Regularly playing other designers' levels leads to cross-pollination of ideas and generally makes a better game. Often I've seen one designer play another's level, think an element is cool and then include it in his own level with improvements.
A healthy sense of competition is created in the team where each tries to take another's idea and one-up them. By playing levels other than their own, designers also gain a better feel for how the game will play as a whole rather than just seeing it through the perspective of his personal chunk.
Peer review is something that will fall apart unless it is strictly enforced by a lead. I recommend that a team have weekly scheduled peer review sessions where all designers are told to put down their own work and spend the afternoon reviewing the work of his teammates.
The peer review day shouldn't be too close to a deadline. For instance if milestones are usually on Fridays, schedule your peer reviews for Tuesday afternoon.
There are many different roles on a design team and many different types of designers. It's been my experience that the designers promoted to the role of lead have been almost exclusively the types that gravitate toward the administrative tasks -- such as creating the spreadsheet that dictates which enemy type will be included in which levels.
Those that gravitate toward content creation usually stay there. A designer who excels at making levels will not be rewarded with a promotion -- and thus will not have the opportunity to make the big game design decisions. While both types of designers are equally important, this imbalance can be harmful to a project.
The reasons for this imbalance are obvious. Being a lead requires a sense of responsibility for people's work other than your own. It requires good people skills. It is difficult to demonstrate either when your head is in an editor eight hours a day.
It is easy to demonstrate these, on the other hand, when you are handling tasks that involve the entire team -- for example if you are responsible for making sure design requests find their way to programming in a timely and organized manner.
Unfortunately, it can be bad for a project if the person making the design decisions has never made compelling content himself. He is less likely to choose wisely when it comes time to deciding what ideas get included in the game and what get left on the floor.
Worse, having spent little time in the trenches, he will not have first-hand knowledge of what processes lead to good content creation. For instance he may not place importance on peer review since he's never benefited from it in his own work.
Picking a good lead is difficult, and a team is lucky if it has a lead who is a responsible leader and has a good sense of what makes good content. Since these are two different skill sets, I recommend that they not necessarily fall on the same person.
The lead designer could devote his time to maintaining design processes, reviewing the other designers' work, and hopefully getting some hands-on time with the tool set. Meanwhile the administrative tasks, such as creating task lists and weekly reports, would be handled by a producer that works closely with the design department.
Placeholder assets and code are used a lot in this industry, yet placeholder use often greatly diminishes once production starts. It is understandable. If a developer is working for a publisher, it's very important to show progress. Going from a nice shiny vertical slice to builds filled with jerky animations and flat-shaded backgrounds can look like a step backward.
Internally, team members, particularly artists and animators, generally prefer working on final assets than low-quality ones that will have to be replaced later. Producers generally prefer something done once rather than twice. Unfortunately under-use of placeholders reduces final game quality and slows down the design process.
The basic scenario goes like this: a designer wants to see an asset in game -- be it a 3D model, an animation, a gameplay mechanic, etc. Rather than wait a few hours for a placeholder, he must wait a week for the finished asset. If what he receives isn't as fun as he had imagined, that will be a week of work wasted.
To avoid this from happening, long approval processes are often implemented with the intention of weeding out all but the best ideas. In practice the approval process can shear off all but the least risky elements of the idea until it's lost its originality.
So now instead of trying out an idea with a placeholder and moving on, the designer must wait a week to receive a final asset that is often far less interesting than what he would have discovered through experimentation with placeholders.
Working without placeholders wastes time in many ways. Levels made up of hundreds of 3D meshes take longer to load and test than those that are made of simple BSPs. They take much longer to modify because they're made of 100's of pieces instead of a few simple shapes.
Finally less experienced mission designers will waste time showing off their interior decoration and lighting skills when they should be focusing on making fun gameplay. Some flat-shaded textures, a pool of placeholder 3D objects, and a watchful eye of an artist to make sure things are architecturally sound should be all a mission designer needs to make fun environments.
A placeholder-heavy game design process requires a lot from a lot of people. It requires a studio that can shuffle artists to other duties while the design team settles on what they want for the "final" level.
It requires faith that the higher-ups (be they an external publisher or an internal studio head) are not as superficial and can appreciate the value of a fun, if ugly, level filled with placeholders. If you don't have this faith, outside playtesting can be used to quantify the "fun" in lieu of showing polished graphics.
In television and film a writer writes a script and hands it off to a producer. The crew then uses the script as a map for telling a story to the viewer. This process can work for video games so long as the main purpose of the game is to tell a story to the player.
Games such as those in the Final Fantasy series as well as many JRPGs and adventure games can succeed on a great story alone. If the main purpose of your game is put your player into the middle of a highly interactive experience, than this method is inappropriate.
If your game is Halo, Call of Duty, or God of War, the script should be shaped around the gameplay and not the other way around. Things such as level design, play mechanics, and pacing are the most important factors. If these things aren't solid, no amount of storytelling can pick up the slack. This is not to say story isn't important, but rather the writer should be flexible enough to change the story based on what presents the player with the most compelling interactive experience.
Giving the story priority over other elements of game design can lead to trouble. A classic example is the 2003 title Enter the Matrix.
The plot of the game and its live-action cutscenes were made to weave in and out of the movie The Matrix Reloaded; the movie's creators were heavily involved.
The result was levels that made sense from a story perspective but had no purpose from a gameplay one. Furthermore the dev team was stretched thin creating three different game types -- in car, on foot, and in hovercraft -- because the story demanded it.
I once worked on a third-person action project with a script that was handed down to us by a Hollywood writer. While an interesting story, it conflicted with a lot of the gameplay elements that had been designed. The script called for levels in intimate locations with a handful of enemies when the game mechanics were set up for huge firefights large cover-filled locations.
The game had been designed with a partner in mind that the player could give orders to, but the script demanded that the player should be alone for a large part of the game's second half -- destroying the learning curve. The cancellation of the project was largely due to the design team being forced to follow the Hollywood script.
The story of an action game should be the responsibility of a game writer. A game writer is someone who's written for games before or at least is a gamer himself. A game writer will be with the team full time and understand why his story needs to be reworked continually.
He won't get flustered if the design team decides the airport level makes more sense in the beginning of the game rather than in the end. Writing for games is not the same as writing for films. Simply cutting a Hollywood man a check to deliver a script is not the way to go.
There are many sound arguments for limiting what a designer is capable of doing with a game's tool set. The more functions and variables a designer has access to, the more he can do wrong.
There's nothing that a programmer dislikes more than having to debug poorly organized designer code. Furthermore, designers aren't trained to program so, the logic goes, they'll waste time trying to do what a programmer was trained to do.
These arguments make sense, but the problem must also be looked at from the designer productivity side. If a designer can work on a level uninterrupted, he is generally more focused and more productive.
If a designer has to petition a programmer every time he needs a new functionality, his rhythm is destroyed. Instead of being able to focus on a single level, he has to slowly pick away at all the levels on his plate until he runs into walls that only programmers can overcome.
I can speak from personal experience about the difference in my own productivity when I was a level designer. On days when I wasn't able to make much progress in my levels, I took more frequent trips to the snack machine, spent more time chatting with coworkers and generally had one eye on the clock. On days when I could work uninterrupted, I wouldn't leave my chair until well past quitting time.
I think a healthy balance should be struck between what a designer can and can't do. Messy designer code can be alleviated by having strict coding standards that are created by the design and programming team and enforced.
There needs to be a dialogue between programming in design in order to create the best system for everyone, rather than just assuming that every designer is a bull in a china shop.
In creating Mario 64, the creators spent months working on the feel of moving Mario around a simple garden environment. They wanted to make sure that this basic act was fun enough to keep a player engaged as he adjusted to the concept of 3D gaming.
Like Mario 64, many great games are still enjoyable when stripped to their base elements. Metal Gear Solid 2 is fun even without the cinematics and set pieces, as Metal Gear Solid 2: Substance proves with its VR Missions.
Even the basic one-mouse-button combat of Diablo is fun enough to engage new players before they discover the deeper RPG elements to the game.
Unfortunately, many projects go into full-steam-ahead production mode without having created anything that's actually fun.
Having a prototype or vertical slice that's fun can be a great boon for a project. It can act as a guiding light. When the project is months into production and the team is so accustomed to the game that nothing seems fun anymore, the designers can boot up that prototype and remember the feelings they had when first playing it.
On the other hand, going into production without something fun can be horrible for morale. I worked on a project that entered production with a vertical slice that was not fun -- but with the hope that the actual game would be fun once everything was implemented and balanced. As the months dragged on, ideas were piled on top of that vertical slice without ever achieving anything fun.
Most people outside of the design team did not have a clear idea of what game we were making, and people inside the design team were unable to form a unified vision. Since there had never been anything fun to begin with, there was no faith that the course chosen by the game's director was the correct one.
It's interesting how many indie projects created on a shoestring budget have more raw fun than some of the hulking multimillion-dollar projects out there. This proves that fun doesn't have to be expensive. Starting without something fun can be.
How many times have you heard someone say, "Don't read those. They're not up-to-date"? If the answer is zero, you're either not in the games industry or you're very lucky. Out-of-date design documents are a common fixture in development teams.
It may seem like an unavoidable failing. Features almost never ship exactly as they were designed on paper. Rather they change many times after their original implementation. Keeping the documentation in step with the changes can be a real chore. Time-consuming as it may be, the consequences for not doing so are fairly serious.
When documentation is not kept up-to-date, people lose faith in it. They assume that whatever is in the source control isn't valid. They don't bother using it as a reference when they have a question.
Rather they will prefer to ask a member of the design team directly. Once the designers realize that their documentation isn't being read, they will put even less energy into maintaining it. Eventually the team will come to the clichéd conclusion that "design documents are worthless".
There are inherent problems with transmitting ideas through word of mouth. A designer may give a programmer a description of the feature that isn't exactly what was originally agreed upon.
The programmer will then implement that feature based on what he remembers of the designer's description. This will cause conflicts when the lead designer looks at an implemented feature that's different from what was discussed.
Another issue is that information becomes fragmented -- with only one or two people knowing how everything is supposed to work. I was four months into the production phase of a project when I needed a list of which levels were to be included in the game and their order.
The only method of getting this info was to email the design lead who then emailed me a spreadsheet from his desktop. The two level sequence documents in the source control were out of date.
Keeping design documents up to date isn't easy, but technology can help. I worked for a company that had a system for automatically giving a document an "out-of-date" tag if two weeks had passed since the document had last been modified. Out-of-date documents couldn't be opened until a designer marked them as current. It was a success, for the most part.
More and more companies are realizing the value of making regular playtesting part of the design process. Valve, for example, is well known for the rigorous playtesting it used in the creation of Half-Life 2 and Portal. Ubisoft is also well known for placing a high priority on playtests.
Unfortunately this practice is not as widespread as it should be. A lot of developers see it as unimportant, and some as downright harmful. An experienced game designer should see playtests as one of the most valuable tools in his tool belt.
If the intended player is not within the traditional "hardcore" demographic -- casual gamers or children, for example -- then playtesting is indispensable. Attempting to see a game through the eyes of a casual player requires the designer to block out 15+ years of accumulated game-playing knowledge. In other words, it's impossible.
Even if you think you've made the most straightforward interface possible, you'll be amazed how much you take for granted the first time you hand the controller over to a 40 year old mother.
If you're making a children's game, then prepare for an even bigger adjustment -- a six year old will have trouble with anything more than the most straightforward concepts. Their brains just aren't developed enough to comprehend things we understand naturally.
Even if designing for a hardcore audience, playtesting is still incredibly important. Over the course of production every game designer will become a master of the game he's developing.
Things that would challenge a new player will become boring to the designer. He'll start to create setups that he can complete with a little bit of finesse but are way too hard to be included in the shipped game.
If the team doesn't start outside playtesting until beta, these bits will have to be smoothed over hastily. Often the result is a game whose changes in difficulty level doesn't seem to follow any plan.
If playtesting is part of the design process throughout, on the other hand, the design team can carefully craft an experience with a difficulty level that steadily climbs until the game's climax.
I've worked with designers that prefer not to do playtests during development because, they claim, relying too much on playtests during development is akin to making a movie through focus groups -- it will water down the artistic vision. This argument only considers a game's fun factor and ignores the comprehension side.
If the designer doesn't care if Billy thought the game was fun or not, don't ask him. If he can't get past the first level because he can't get his head around the dual analog stick aiming system, then we have a problem. And it's better to know that sooner than later.
If you work as a game designer, I imagine you've come across some, if not all, of these design process pitfalls. I've been in situations where the money was there and the talent was there, but the project still failed to come together because of bad design processes.
The most important thing to take away is that a lot of the important elements mentioned in this article, such as peer review and keeping documents up to date, do happen come naturally -- they require discipline and enforcement.
When the game development is being managed by individuals with the experience necessary to recognize and practice good design processes, there is the potential for truly amazing content to be created.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
