Beaker's Bent:
Building the Next Wave of 3D Games

By Rich "Beaker" Wyckoff

I've been designing games professionally for three years and thinking about designing them for most of my life (when not playing them). I tend to present strong opinions, but I want to make it clear that these are only opinions, and I don't want to come off like some of the famous names in the industry who seem to think that selling a lot of copies of a game and getting attention from the press makes them an expert on everything about making games. My tenet is that if you claim to know everything, you're missing out on the fact that there's always something new to learn, some other opinion which is worth considering, some experience you are still lacking...

he lifespan of the current most popular style of 3D engine, that which has been used in the many first person shooters (FPS) to have been published since Wolfenstein 3D, is almost at an end. Two features in particular that are common to just about all the FPS engines out there are beginning to become extremely limiting to designers: the "indoors" slant of the engines and the relatively low object density. It has primarily been the limitations of technology which has restricted FPS games to indoors engines with few moving objects. However, with new technology it is finally becoming possible to represent true outdoors areas with a distant horizon and a high amount of detail, rather than relying on the clever but unrealistic indoor-engine design tricks of circling level layouts among twisty paths through tall hills and urban canyons, which prevent the player from wandering far and keep their lines of sight short. It will also soon be possible to have movable objects everywhere and make "truly interactive world" mean more than "you can blow up all the TVs." All of this will enable designers to create much more expansive, detailed, and interesting environments than ever before, allowing new kinds of gameplay that may finally break us out of the FPS design rut.

However, building levels for the next generation of 3D games will also require the next generation of 3D editors. I've seen and used quite a few different editors in the years I've been in the industry, recently as an assistant designer on a major project which was assembled entirely in 3D Studio MAX, and in the last few weeks with the Unreal Editor while broadening my skills as a designer and trying to learn the kinds of benefits and problems faced by others in the industry. After this work, it has become clear that neither forcing a 3D modeling and rendering program into service as an "editor" nor the fairly slick but still clearly FPS-oriented UnrealEd are really appropriate for building a next-generation game. Yet each has its strong points, and an ideal editor would be a mix of both. At a minimum, it needs to be able to do the following:

Major Features

Connection to the engine: The first and most important feature of a game editor is it needs to be connected to the game engine. The best possible connection between editor and game is to have the game be playable in a window of the editor. Currently this is a difficulty for non-Direct 3D developers because of the popularity of the disappointingly inflexible Voodoo cards, but perhaps 3DFX will finally smarten up with the Voodoo 3. At any rate, if the game can be played in a window, the rest of the screen can be used for debugging information. Better yet, if the game can be played in a window and actually run under the editor (i.e. feeding information directly back to the editor instead of being a completely separate application), than it can be paused, tweaked and resumed, for the kind of instant feedback that designers dream about - though of course leading to the increased risk of crashing your computer and losing your data. Even if windowed playability under the editor can't be achieved, it is mandatory that the editor at least be able to use the game's renderer. If designers can't see the changes they're making reflected in a fully-textured view that is nearly identical to what players will see, than any editing becomes guesswork. This results in sloppy levels and, as the project progresses, the eventual creation of many arcane tools to cope with the situations where guesswork doesn't suffice and things have to be positioned precisely (which of course eats up time from the programming staff, tending to negate most of the schedule savings made by not attaching the renderer to the editor in the first place). Shockingly, as I said in the intro, recent major projects have been made without editors at all, but perhaps I was a bit spoiled to have had my first industry job at Looking Glass Technologies, who had just published System Shock and whose custom-built editor for Shock and the Ultima Underworld games had features like the renderer view which are still not universally present in every company's internal editors, let alone in the publicly-distributed or shareware ones which fans can use.

Connection to the game database: Next most important is that the editor have the entire database of objects and textures used in the game easily available to it. This sounds pretty obvious, as when you purchase and install Unreal all the data it uses is tidily held in a couple dozen files in a single directory, but during the development of a game data can be spread all over the place, in various states of completion. It becomes critical for a professional designer to be able to constantly and easily have access to the most recent versions of everything. Usually this means loading certain files from certain locations, and tracking and updating those files is a project management issue. What the editor must be able to do is allow that data to be loaded in the easiest manner possible and provide a browsable list of the game data that can be placed with the editor. The designer shouldn't have to do anything more than a load a single file to start using the data, and the editor should only be able to load files which are valid (This sounds basic, but I have seen projects where just getting the data together to start a level is a complicated and peril-fraught process). Unreal does about half the job: once you have (very easily) loaded in a texture pack or sound pack or script file, you can apply it from the browser, which has some rudimentary filtering controls. However, on a next-generation game or even a complicated Unreal level which has hundreds or thousands of objects, textures, and sounds you really want not only to be able to look at a list of what you can place in the level, but also to see the list of what you've already placed. This is where the developers of next-generation editors should take a look at 3D Studio MAX and see how it handles its objects - its interface for name-selecting objects is a bit awkward and limited, but even awkward and limited is better than not being able to name-select at all.

Easy modification of the game database: The editor must allow the designer to easily change the database. Better designers, and I would even go so far as to say any designer worth hiring, will be anywhere from slightly to incredibly skilled at the creation and alteration of any of the types of data that a game uses. This could include editing sounds and textures, creating or modifying scripts, even creating new models or animations in external programs. Designers are the jacks-of-all-trades in game development, and often need to do a little polishing or adaptation of the data they are handed. Some designers even create some of the game data from scratch themselves, and there are companies that don't even hire "level builders" at all, but only artists or programmers who also have design skills. If a game editor does not, for instance, allow its users to import in seconds a texture which they have just been changing in Photoshop, it diminishes their ability to put in the richness and polish that can make a mediocre game good or a good game great. I've seen designers who find that getting altered data into an editor is too difficult give up on altering data altogether, essentially demoting themselves to mere level assemblers. A good editor should encourage designers to demonstrate their creativity in every way possible.

Ability to "plant" objects: Here is the first feature that is most specific to the next generation of games. In the current crop of FPS games, there are very few objects in the world. Those that do exist are usually just pushable or explodable objects like barrels or crates, the standard floating powerup, and creatures, and the placement of these objects is limited and largely handled by the engine. The bulk of level editing in a standard FPS is creating the geometry of the level and not placing the objects. However, in the next wave of games there will be more objects with real-world behaviors, objects that can be tipped over, thrown around or perhaps even wielded by the player. There have certainly been some attempts at this already, like the limited but interesting sphere-based physics of System Shock and the slow, often-interpenetrating box model of Trespasser. These are the first steps towards games where things behave exactly as you would expect in the real world, and eventually some game will be made with fast and completely reliable real-world object physics and sell as many copies as Quake. Having a lot of moveable objects vastly changes level-building procedure, though, and to make this blockbuster physics-based game will require an editor that can run the physics model selectively as designers place objects in worlds, so that when players reach the object in the game it will be properly settled on the ground or whatever it is stacked on and won't explode into the air or suddenly drop down as is often seen in Trespasser. This editor feature would also help designers create their physics-based puzzles by allowing them to repeatedly drop their objects, tweaking their placements, sizes, and masses until the desired behavior is achieved. Designing and constructing puzzles for real-world physics is a nightmarish task which deserves its own column, and designers need an editor which gives them as much assistance as possible or else design becomes guesswork and hope rather than testing and polishing, pretty much eliminating the chance of making a great game.

(Continued on next page)

.