|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Jumping
into the Game For
games where the player is manipulating a character through a world,
it is important for the designer to be easily able to know how the level
"feels" to navigate. To
this end, in addition to having the player's view of the world represent
what the player will see in the game, it can be quite useful to allow
the designer to actually maneuver in this view as she would in the actual
game. With this sort of addition,
the designer is able to test whether the player will be able to make
a certain jump, how it will feel to navigate a particular "S"
curve, and whether or not the player's character moves smoothly up a
set of stairs. In addition to this "gameplay" mode,
the level editor should still allow the designer to navigate the world
in a "flight" mode, where she is not constrained by collisions
or physics variables as the player will when he plays the game. The
Vulcan editor for Bungie's Marathon engine was particularly well suited to allowing the designer
to test the "feel" of the level while constructing it. The Marathon
technology was similar but a bit better than Doom's, and was licensed for use in a number of other games, including
my game Damage Incorporated.
Vulcan was subsequently revised, renamed Forge, and released with the
final game in the series, Marathon
Infinity. Vulcan/Forge allowed for a "visual mode"
which functioned as a player's view window. In visual mode the designer could navigate
the world just as the player would in the final game. The shortcoming of this was that the designer was unable to edit
the world, aside from texture and lighting placement, while in this
view. This was no doubt due to the speed of processors
available when the editor was created, and the comparatively small size
of affordable monitors at the time.
Nonetheless, the visual mode in Vulcan was quite useful, and
the switch from editing mode to gameplay mode was fast enough to allow
the designer to make a change, see how it felt, and then switch back
to make more changes as necessary.
Of
course one might conclude that the next logical step is to allow the
designer to actually play the game in the player's view. In this way the designer can see how well different
mechanisms function, and what sort of a challenge different adversaries
will present. However, this
opens the programmer up to a large amount of implementation difficulties. In order for game-world objects to function
as they do in the game, many objects will move from the position they
start out in when the player begins the level.
For instance, an aggressive Troll might run toward the player
and attack. Do these moving
objects then actually move in the level editor as well?
And what happens if the designer saves the level in this new
state? Surely that is a bad idea, since all of the
locations in which the entities have been carefully placed will be changed.
What a designer wants is to be able to quickly test a level at
any given location, and once he is done play-testing, have the level
revert to its "unplayed" state. This may best be accomplished by allowing the
designer to quickly enter a "test mode" and then allowing
him to exit it just as quickly, instantly returning him to level editor
functionality. The quicker this
transition the better, for the faster and easier it is the more likely
the designer will want to go back and forth to test and re-test the
playability of his level. If
the designer has to wait a minute or longer to play-test, he will not
be able to try as many different changes to the level before he runs
out of time. For this reason, it makes sense to have a programmer focus on smoothing
out and speeding up this transition as much as possible. Any
seasoned game designer will tell you that a large part of whether a
game succeeds or fails is dependent on how well it is play-tested and
balanced. Even the most brilliant
initial game design can be completely destroyed if the implemented game
is not play-tested thoroughly. And
I do not mean just for bugs, but for gameplay, for how the game feels
to play, for how it captivates the player.
Play-testing is an iterative process which involves trying a
type of gameplay, then modifying it, then trying it again, and repeating
this loop until the game is fun. It can be very hard, then, to properly iterate
through play-testing if the level editor does not facilitate the modification
of the game's levels, and then easily allow the designer to try out
what has been changed. The easier
it is for the designer to jump into the game, the more likely she is
to repeat the play-testing cycle again and again until the game is as
perfect as possible. And if
the level editor does not facilitate such testing, the designer is likely
to become frustrated or simply not have the time she needs to sufficiently
balance the game. Editing
the World The
best development tools for a game are composed of a delicate mix of
off-the-shelf programs and proprietary editors. A good team will know just how much to use
of each so that they are neither wasting the time of their programmers
by having them develop overly sophisticated tools when a good commercial
package is better suited, nor unreasonably restraining the efforts of
their designers by not allowing them to refine the game's content from
within the level editor. Though
no team should be forced to develop a game without a level editor, it
is equally foolhardy to force the team to do all of the game's content
creation from within proprietary tools. When
I started working on Centipede 3D, the level editor we had was really more of a game entity
manipulator than a proper level editor.
The geometry for a given level was derived from a grayscale,
square height-map, with those used in Centipede
3D all consisting of 32 pixels square.
Each pixel therein represented a height value on the landscape. These height-maps could be created in Photoshop
or any other pixel-pushing tool, which was a good way to create an initial
version of a level's geometry. But,
unfortunately, at the start of the project that was the only place the
height-maps could be modified; they could not be edited in the editor
itself. This was a shame, since
looking at a top-down 2D representation of a 3D level is not exactly
the best way to get an idea of what the level will end up looking like. As a result, the levels that were created early
in he project were simple and a bit flat. It was not that the level designers were not working hard to make
the levels attractive, merely that there was only so much that could
be accomplished with the tools provided. However,
midway through the project, the functionality was added to the tool
to allow the designer to edit the height-maps while in the level editor.
The height-maps could still be created in Photoshop and brought
into the game, and this remained the best way to make a first pass on
the level's architecture. But after that first pass the geometry was
easily manipulated in the level editor, where the designer was able
to see the level in 3D while modifying the height map.
As a result the designers were able to tweak the geometry until
it was perfect. The change
in the quality of the levels was dramatic.
As always, time did not allow for us to go back and redo the
earlier levels. And since the levels were made in the order
they appeared in the game, anyone playing Centipede
3D will be able to tell at what point the level designers were given
the new and improved tool. It
was not that the designers could not create levels with the previous
incarnation of the editor, it was just that level editing was so much
more difficult that the levels failed to look as good the designers
wanted. There
is a lot to be said for being able to create fancy level geometry in
a fully featured 3D package, and even level editors with sophisticated
geometry editing capabilities would benefit from the ability to import
externally created architecture. The
key to creating quality game art assets, whether they are 2D sprites
or 3D models, is being able to import from commercial packages. I do not know that anyone was ever forced to
create 2D sprite artwork for a game using only an in-house tool. Yet it seems that many unfortunate artists
have only been allowed to model characters or other objects using proprietary
modeling tools. I have discussed
how important it is to allow the level designers to manipulate a level's
architecture in the editor. But
certainly forcing game designers or artists to model every game-world
element in the level editor is a big mistake.
Artists should be able to create game world objects such as trees,
weapons, or trash cans in their favorite modeling package, after which
they can import them into the game.
Simply put, there is no way a game's programming team is going
to be able to code up an art editing package with all the power, robustness,
and stability of a Photoshop, 3D Studio Max, Maya, Softimage, or any
of a number of other popular off-the-shelf products.
Without the many features found in these packages, artists will
simply be unable to create the best quality art possible.
Furthermore, most artists are already familiar with one or more
of these packages, and so when they come on to the project they will
be that much closer to being "up to speed." At
the same time, the team will need to be able to manipulate this art
using proprietary tools. Having
an in house editor with which to set up animations, nodes on a skeleton,
collision data, or other information is essential to making the art
function properly within the game.
Teams who attempt to avoid setting up any sort of art editing
software will frustrate their artists, designers, or whoever gets stuck
with configuring the art and its animations to work in the game. A proprietary art-manipulation tool that does exactly what the game engine needs it to is a key ingredient
in a bearable game development experience. ________________________________________________________ |
|
|
Features
