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.