Maintaining Focus

Once you have a focus down on paper and can read it over and say with confidence, Yes, certainly , that s what I m going for, it is time to share it with the other members of your team. It is important that you get everyone on your team to sign on to your focus. You want them to acknowledge that, yes, this is the direction the team is taking, and to agree that they see a compelling game coming out of it in the end. If no one on your team thinks your focus is very captivating, and despite your best efforts to campaign for it no one can get excited about it, you can come to one of two conclusions. First, perhaps your game idea is not all that good. Hard as this may be to admit, it could be that your focus statement and possibly the game it describes are simply not original or enticing. If the idea in your head is still exciting to you, maybe you did not capture the correct focus properly on paper. You should go back and try to figure out what about the game excites you but did not come across in your focus.

If you persist in thinking your game is compelling and that your focus properly reflects why, it may be that people on your team are not excited by it because they were not involved in creating it. When working in a team environment, it is important to include people in early brainstorming sessions so that they can feel that they contributed to the birth of the idea. Even if not everyone s ideas end up being used, if you honestly listen to people and use not only your own ideas but the best ideas regardless of their source, you will end up with a happier team that respects your leadership. In the end, all projects can benefit from a strong central vision that is maintained by a single person, but that does not mean you need to lock yourself into a room to be brilliant all by yourself. It is often said that the best lead designers on large projects act primarily as filters, taking in ideas from all sources and molding them to fit into a single, unified vision. It may be that the focus you have come up with is quite strong and will produce a great game, but selling people on it will be trickier if they feel like they were needlessly excluded from its creation.

It may also be the case that the team assembled is simply the wrong one to develop the game you have come up with. Not every team can develop every type of game. A team that has been making sports games for years , likes working on sports games , and knows how to make a sports game fun is probably not the best team to enlist to create your nineteenth-century economics simulation. If you have the option of finding a new team for your game, you probably should. If not, you may need to come up with an idea that most of your team is going to find compelling. It is important that everyone on your team sees the value in your focused idea. Because of the collaborative nature of modern, high-budget computer games, it is virtually impossible to create a good game if you do not have the majority of your team excited to be working on it.

If you are working on a project largely by yourself with others contributing significantly less to the game than you, you may not need to sell your focus at all. Indeed, games created by lone wolf designer/programmer/ artists can be among the most focused of computer games. Since one person is creating the vast majority of the game s content, he is able to exert absolute control over every nuance. Solo game development is typically not something at which one can earn a living these days, but I know of a few who manage it. Of course, the fact that a game was created largely by one individual does not assure that the game is going to be focused. If that individual is scatterbrained and unfocused himself, chances are good the game will not be very focused either. Even if he is a more sane, organized person, if he does not keep track of his game s focus over the course of the project, his game may end up being just as unfocused as the most uncoordinated, over-budgeted, fifty-developer game.

If you are working as a designer on a game with a team, it is essential to make sure the other people on your project, whether artists, programmers, or producers , understand the nature of the game s focus. Without a strong focus to guide their actions, programmers and artists may have a misunderstanding of what the game is supposed to accomplish, and may be thinking of some other type of game as they work on yours. Through no fault of their own, their work may deviate from what needs to happen for your game to become a reality, and you will be forced to say, No, that doesn t fit, redo it. If the team has a focus to follow, a focus they have signed on to, then they are far less likely to create work that is inappropriate for your game. Having a strong focus does not get you out of keeping a watchful eye on the artists and programmers work, of course, but it will save you the trouble of having to redirect them too frequently.

Fleshing Out the Focus

Once the team is enthusiastic about the project, has signed on to the focus, and has a clear understanding of what the game is supposed to be, you can proceed to more fully flesh out your idea through a complete design document. You may even want to make your focus the beginning of your document, as a sort of summary of the nature of the game that people can read quickly. (The nature and creation of design documents is more fully explored in Chapter 19, The Design Document. ) The design document should take the game suggested by your focus and expand on it, detailing how the goals in your focus will be accomplished by gameplay and precisely how that gameplay will function. You will also be sketching out the flow of the game, what the game-world will be like, and what sort of entities the player will encounter. Of course, while you are working on the design document, there will be countless points at which you have to struggle to come up with the correct solution to a given problem. Should the control system use method A or method B? In what sort of environments will the player be interacting? What sort of challenges do the enemies present? A properly designed focus will allow you to refer back to it to answer many of the questions you encounter during the design process. As these elements of the game are fleshed out, you should continually refer back to your focus to see if the additions you are making match with that focus. Through the focus, you can carefully consider if you are adding gameplay that takes the game in a new direction. It is important to identify which additions to your game cause it to deviate from the focus, and then to change or eliminate those erroneous elements.

You want to avoid having your game become too bloated with features, components that may be cool in some way but that do not support the game s main focus or that distract the player s attentions. Using your focus as a tool, you can prevent this overexpansion by cutting away the chaff in your game design to leave only the core gameplay for which you were striving. Many of the ideas you or members of your team have may be fine concepts, but if they do not fit the game you are currently working on, they are not worth exploring or implementing. Do not throw these incompatible ideas away, however. Write them down in your notebook for the next time you are working on a game design. If they are good ideas, there is probably some game with which they will work well. If they are very good ideas, you may even want to design an entire game around them. But for the current project, by referring back to your focus you should be able to determine whether these extra, cool features are helping or hurting your game as a whole.

Once the design document is finished and other elements of preproduction are completed, full production can start on your game. Your team of programmers, artists, and other personnel will begin attempting to implement what you have set out to accomplish in your design document. As the project proceeds, there will be countless times where questions arise. Your design document will not cover everything needed to actually make the game playable ; it cannot possibly. Questions will come up about how to implement a feature, in addition to new ideas about how to improve the game. For each of these, again, you should refer back to your focus to clarify your team s direction. Is the implementation that is being suggested going to keep the game on track with the focus or will it distract from the main thrust of the game? Is the distraction going to be too much of a diversion ? Using your focus statement wisely throughout the course of the project will keep the game on the right course, and will result in an end product that is better because of it. Players will know the difference between a game that is properly focused and one that is not, even if they do not communicate their feelings in so many words. They will play and enjoy a focused game and will quickly cast aside one that is unfocused.

Changing Focus

Of course, either while working on your design document or when the game is in full production, it may become apparent that the goals of your game need to change. This can happen for a variety of reasons. You may come to see shortcomings or failings in your original focus. Through the act of creating your game, you may come to recognize a more compelling experience that the game can provide that is outside the scope of your original focus. Depending on where you are in the project s development, you may want to change your focus. This is particularly painless to do when you are still in the preproduction phase and the design document is not yet complete. In fact, you should expect your focus to change several times, if not on a daily basis, while you are working on the design document. There is nothing like trying to write down all the important information about your game to expose holes and failings in your original concept.

Even beyond the design document, when you are working on your game s first level you may begin to see weaknesses in your design, holes you had not anticipated when you were just working with an idea of the gameplay in your head instead of a playable game on the screen in front of you. At this point making changes to the focus is still not catastrophically damaging to your schedule and will not involve redoing much work. Better to fix problems in the game and your focus now than to be stuck with them for the rest of the project and end up with an inferior game.

When changing the focus, you should take the same care as you did when you initially came up with it. Make sure the focus fully represents your new vision for the project. Of course, if your focus changes radically , you will need to tell the team about the change and make sure they all agree with it. Remember, the team needs to be behind the project in order for it to succeed, and if you change the focus in such a way that the team is no longer interested in working on the project, you need to rethink that change or rethink your team.

For whatever reason or in whatever way you may change your focus, it is important to examine what parts of the game may already exist and see how far they diverge from your new focus. Look over the design document and realign it to your new goals. Consider whatever game mechanics may be in place and see if they are sufficient to carry the new focus. Look over whatever levels may exist (hopefully not too many have been created at this point) and see if they fit with the new focus. Whether it is in documentation, code, level design, or art, anything that does not fit will need to be reworked so that the new focus is properly supported.

If too many assets need to be reworked, or if it is too close to the ship date to change them, or if there is not enough funding available to get them changed, you may need to rethink changing your direction. Is it really necessary? Often, after you have been working on a project for a long time, you may want to change your game just to keep it interesting to yourself. What seemed fun to you a year ago may seem dull now, not because it fundamentally is not fun but because you have been buried in the project too long. Avoid changing things just because you are tired of them, since your players, seeing it for the first time, will think it is fantastic and throwing out all the good work of your team would be a tragedy.

However, even late in the project you may find out that your game truly is not what you had hoped, and a refocus is necessary to fix it. At this point you need to move into a damage control mode. Can you make the change in direction less drastic while still solving the problems, such that the old assets can still be used? The worst decision you can make is to create whatever new assets the game needs following a new focus, while the old assets still follow the inferior focus you had embraced previously. Instead of focusing the game, your two focuses will end up creating a game with a split personality, one that is entirely unfocused. Try your very hardest to come up with a refocusing plan for your project that will not put you over budget or schedule, if these are pressing concerns (as they almost always are). Realizing your project is not as good as it could be, but lacking the time or money to fix it properly is a tough position to be in. Finding the best solution in such difficult situations can be extremely challenging and frustrating.

When I worked on Centipede 3D , we ended up changing our focus near the beginning of the project. This resulted in some amount of work needing to be redone, but it also led to a significantly stronger game in the end. Centipede 3D was something of a special case since it was a remake of a classic and much-loved game, the original Atari Centipede , created by Ed Logg. When doing a remake or a sequel, it makes sense to take a look at the original game you are working from, and get a clear understanding, for yourself, of what its focus was. This is necessary so you will have a good idea of what exactly you are remaking. Of course I was not present when Logg was making the original Centipede in 1979 and 1980, but I can try to guess what his focus might have been:

Centipede is a fast-action shooting game involving a variety of adversaries that the player must kill in order to avoid being killed by them. The enemies move in completely predictable, predetermined patterns, but the combination of the movement of these creatures and other objects in the game-world creates a challenging experience for the player. The player can attempt to change the game-world to make the adversaries movements less threatening , and the player can see the entire game-world at once. The game continues until the player dies a specific number of times, with points accumulating to represent how well the player did in that particular game; there is no winning or finishing Centipede .

That focus is probably too long and too detailed to be a proper game focus, but it is hard for me to read Ed Logg s mind to know what his core concerns were when making Centipede . So I have included all of the crucial parts of the game I can find. Of course, the focus he used may bear no relationship at all to the one above, if he used a focus at all.

The focus of the 3D version of Centipede was to create a game that captured the arcade game-play of the original Centipede in a three-dimensional, level-based environment.

When development of Centipede 3D initially got under way, the idea was to take only the most basic characters of Centipede ” the player s shooter ship, the centipedes, spiders, fleas, and mushrooms ” and have them interact in a 3D world. The decision to move the game to 3D was already a foregone conclusion when we started working on the project. It was a choice whose appropriateness was certainly debatable given the fundamental mechanics of the original. Indeed, from conception through the earliest versions of the game, not much attention was paid to the game mechanics and behaviors of the original. The elements from the original Centipede were being used more for aesthetics than anything else. When our initial game prototype turned out not to be very fun, we decided to try to emulate more of the original game s gameplay in the new 3D version, wherever possible imitating and updating whatever the 1981 Centipede did in a 3D, level-based world. As we started pursuing our new focus, we found that the more we emulated the classic, the more fun the new game became. Though it was not written down at the time, you could say our focus was along the lines of the following:

Centipede 3D is a remake of the arcade game Centipede , and attempts to take what that original game did well and transplant it to a 3D environment. The original Centipede featured fast-action shooting combat in waves, with the player s deft maneuvering of the ship being the key to success, and with enemies that moved in completely predictable patterns. Instead of being on one level for the entire game as Centipede was, Centipede 3D takes the player through a progression of levels. The new game also embraces certain gameplay norms of modern console games, such as replayable levels, bonus objectives, and obstacle navigation. The action and combat portions of Centipede 3D , however, will be extremely reminiscent of the original game, employing identical AI wherever possible, and thus retaining the gameplay feel of the original.

With our new focus, the game assets we had developed thus far were readdressed, and a number of levels had to be discarded, while others were significantly reworked. A small amount of coding that had been done had to be modified, but fortunately no change in the artwork was necessary. All told, our refocus resulted in some loss of work. However, in the end this lost work was worth it because the final Centipede 3D had a consistent, focused style of gameplay. And as a direct result, it was fun to play.

It is important to note that our focus for Centipede 3D was not a standalone focus as I advocated earlier in this chapter. The focus for Centipede 3D refers to another game, the original Centipede , and thereby does not stand completely on its own. Of course, Centipede 3D is a remake, and as such it makes sense to refer to the game the project follows. For either a remake or a sequel, the game you are making has a direct relation to the other game you refer to in the focus, and a large part of whether the game is deemed a success or not will rest on how well it follows up its predecessor. As such, throughout the game s development, the team members should be asking themselves how their work relates to the original game, and whether what they are trying to accomplish in terms of gameplay is a logical and worthy successor. Since this is such a central concern, it belongs in the focus. In working on a sequel or a remake, your entire team should have played the original game through, and hence can be expected to understand it reasonably well. Note, however, that the focus for Centipede 3D includes a brief description of the primary appeal of the original Centipede , so that the focus can stand by itself better than if the central concerns of the classic game were assumed. If the focus must refer to another game, it is important to make sure everyone involved with the project understands the focus of that other game as well.