A while ago I explained why game design is important. A reader asked in the comments: What do you do if you don't have a game designer on your team?

There are a number of reasons why you might be in this situation:

1. You don't have the budget for another person on your team.
2. The people making recruitment decisions are not convinced you need a game designer (that's why I wrote that essay).
3. You were not capable of finding the right person, but you have to keep developing your game. (Bonus points if you had a game designer but he or she left.)
4. You have a game designer, but he or she is not senior enough to really be effective. Kind of a special case, but keep reading anyway.

If you can't have a full-time game designer on your team, you can still make sure game design happens. What counts is that the job gets done. Having a full-time game designer is typically the best solution for this, but producing a game is all about knowing what your risks are, where to allocate resources (whether that be the team's, or your own) and how to make the best of situations that are not ideal, because situations are never ideal, and the best is the enemy of the good.

Here's a very simple breakdown of what a game designer does on a typical game development project:

• Generate the game's design.
• Maintain the game's design.
• Implement the game's design

Let's look at each in turn:

Generating the game's design

This usually begins in the concept phase and continues in the preproduction phase. Typically, you start with an initial brief (which rarely comes from the game designer). This might be something like 'Make a game based on this license' or 'Make a casual game that is finished in 4 months or less' or 'Make an exciting action game using this setting'. From there, an initial set of features, mechanisms, level concepts, etc. is developed. Hopefully, this initial design will lead to a game that fulfills the brief, is implementable, and is entertaining.

This can be almost completely outsourced, but you should take the following into account:

1. The buy-in from your team can be lower than when you generate the game design in-house. If your team is not too immature, this typically can be dealt with by managing expectations and involving them in the reviews of the game design as it is being produced (this should happen anyway).
2. A game design document is not a perfect blueprint for a game. If you don't have the author of the game design around during production, there is a risk you're not building the game that was envisioned, because the design document is not clear enough, and because you can never fully predict what game you're making in a document. Outsourcing the game design during preproduction effectively means you're choosing the waterfall model, with all that that implies. A good free-lance designer can compensate to some degree. You can also organize follow-up reviews with the designer during production.

Maintaining the game's design

Typically, during production, you will find out that parts of the game design document are unclear or don't work. The more ambitious your project is relative to your capabilities, and the shorter your preproduction phase was, the higher the risk is that this will happen. Additionally, new ideas will come up that need to be considered.

All of the above will lead to changes in the game design document. If you don't have a full-time game designer, you can still have a game design process. Essentially, it's a change management process:

1. The need for a change is identified. Normally, this just means someone on the team walks to the game designer and asks a question. When you don't have a game designer, you can still designate someone to be the contact person for questions about the game design document. This can be the person who owns the game design process (e.g. the producer), but it doesn't have to be.
2. Possible solutions are generated. A game designer could do this alone or he or she could ask for feedback from the team. Without a game designer, this can be done by a group of people or the entire team. The important thing is to make sure the process doesn't stall.
3. A decision is made about which solution will be used. This is probably the hardest part. Again, you can use a group (for instance the leads) to discuss the possible solutions. However, it is vital that you have one person making the final decision. This greatly clarifies things, it helps keep the process moving, and it increases the odds that the decisions are made in a consistent manner. Also, this person can then own this process and be accountable for it, which is good. The producer is typically a good candidate to make these decisions. He or she may not have game design sensibility (about which more later), but at least the decisions should take cost and feasibility into account, and the producer's focus typically generates a certain disinterested pragmatism that helps here.
4. The solution is documented. Finally, the solution must be written down and communicated to the team. This can be done by anyone who is capable of clear expression. Just be sure it gets done consistently.

Make sure people know how to bring up questions or issues regarding the game design. Since you have less game designer time to work with, you can avoid wasting time on trivial questions by funneling the questions through the leads, who hopefully can answer some of them before escalating them into this process.

Additionally, make sure the process keeps running. Try listing all the currently open questions (for instance in a wiki) and handle them on a regular basis. I recommend weekly meetings for this. Make sure people see the process is active.

Implementing the game's design

By this I mean balancing and tweaking: data needs to be conceived, entered and adjusted. I can't think of a generic solution for how to do this without a game designer. It really depends on your team. If your game design process described above works well, try partially running it through that. If you have someone on the team who is interested in doing it, have them do it. It might be a gameplay programmer, a level designer or a project manager. Just make sure it gets done.

As with any work delegation: be sure everyone involved knows what is expected. You probably want your project manager to go back to managing the project after tweaking enemy data, so watch out when he shows up for work wearing a black beret. Your lead programmer needs to know how long the gameplay programmer will be entering weapon data. And you should especially be clear about what the outcome of the balancing / tweaking tasks will be. For instance, in a realistic shooter, you probably don't want shotguns to blow people through walls.

The risks of not having a game designer

It is important to remember that the solutions I've described above are essentially crisis management techniques. Assuming a typical industrial approach to making games and a certain team size (say, 10 to 20 people), you may be able to make a decent game despite the lack of a dedicated game designer. However, you should be aware of several risks.

For one, you may not have design capability on your team. Call it talent, skill or awareness: game design is not easy. You can outsource game design to some degree, but you still need a minimum of design sensibility. Also beware that many people think they understand game design, but they really don't, just like many people think they can write, only they can't.

Second: Game design tasks may not get done. If there is no clear responsibility for game design, there's a good chance it won't happen. Values won't get tested and tweaked, decisions won't be documented and communicated. The lack of a game designer is probably not the only problem in your project, so there will be stress and urgency. Under these conditions, people will focus on their own areas of responsibility, because that is so much safer. The worst case occurs when player entertainment is no longer the focus of development. Every feature or asset is ticked off, but nobody cares anymore whether the game is fun. If you find yourself in this situation, you have a tough choice to make:

1. Pull the emergency brake. Force everyone to take a step back, reorient, and refocus. This costs an enormous amount of courage and energy (especially if you're not the producer) as well as time and money.
2. Finish the project anyway. Sometimes this is the best solution. Your team, your publisher and your players may hate you for it, but at least it's over and you can try to do better the next time. Finishing the project may ensure there is a next time.
3. Cancel or quit. Some projects can't be salvaged. Some projects won't finish. Some organizations won't improve. Don't throw good money after bad, or good years of your life after bad ones.

Welcome to the games industry. You just got a look at how those sausages are made. Like I said: it's a tough choice. Try not to end up in a situation where you have to make it.

Every team and project is different, so what works in one case may not work in another. I could go into way more detail, but this post has already become very long. Still, I hope I've given you some ideas for what to do if you don't have a full-time game designer on your team. Please let me know what you think in the comments.