By Rich "Beaker" Wyckoff
Ability to manipulate multi-part objects: Another next-generation feature. Unreal's Editor uses CSG, constructive solid geometry, to create its spaces - you take a shape and carve it out of an existing solid mass, or add it back in. This is very convenient for building interiors, but doesn't work as well when building gigantic indoor/outdoor settings. Furthermore, certain features of Unreal levels, especially moving brushes, are always treated as separate objects and can't be conveniently associated with some other brush (as far as I've been able to determine). In a city level in the next-generation game for instance, designers will almost certainly deal with each building as an entirely separate object, creating its inside and outside, positioning the doors in doorways, making them swing when pushed, open at the touch of a button, be locked until a key is applied, etc. Once the building and all its special contents are created and work, it becomes desirable to be able to move all those parts together. In fact, once your building is sufficiently complicated, it becomes impractical or impossible to ever move it from the position it was constructed in if you can't treat it as a group. Furthermore, as geometry and texture detail increases, it might become necessary for major pieces of a level to be constructed in a separate file altogether, handled by another designer or artist. This makes it all the more crucial that the person assembling the level can load and move the building as a single object. When a new version of the building is issued, the old one in the level can be quickly selected and deleted, and the new one brought in. I haven't seen an editor which can do this yet, but it is desirable even today: I'm already basically stuck with the layout of the Unreal level I've been working on, and at this point can't make a large-scale change without essentially scrapping the whole file and starting again. This situation will arise with many more things than buildings, as well: imagine a box with a hinged lid, a train with multiple, linked cars, or a creature which holds a gun that is an entirely separate mesh. All of these are separate pieces that need to maintain the same relative positions.
Certainly many of the features I've listed above implies certain interfaces, but they could be probably be implemented in a variety of ways. I do believe there are a few specific requirements for the interface of the next-generation editor, though:
Modal view movement controls: To me, the most annoying thing about UnrealEd is how the scrolling and zooming of the views is handled. You can far too easily accidentally select a brush when all you wanted to do was zoom in or out, or accidentally scroll the view when you were just trying to select a brush. All other major drawing or drafting programs I've used, like 3DStudio MAX and Photoshop, require you to use a specific tool which puts you in a different mode for the mouse-based view control. When you are doing precise editing or have a large amount of objects near each other as will be common in the next-generation game, it is critical that the interface keep selection and view-adjusting as separate as possible to avoid user confusion.
View controls: Unreal, and the next-generation editor, also desperately needs tools and/or shortcut keys to zoom the current view to the currently selected object. With a huge level, it is annoying and inaccurate to zoom in and out by hand from the overview to something a small fraction of its size, like a gun. A much better and quicker way to do this is to have buttons and keystrokes to center the view on the extents of the selection and the extents of the entire level, as MAX allows. Also, the "box zoom" feature that most professional art tools and MAX have is a useful additional feature, making it easier to zoom on a specific object without having to scroll the view window all over the place to try to center the object. It is worth noting that in the 3D View, however, Unreal has a better interface than that of 3D Studio.
Hiding and freezing: Unreal seems to only be able to hide the "active" brush, an item which is rather specific to Unreal anyway. The ideal editor should, like MAX, let the user hide anything and everything, and unhiding and unfreezing should be achievable with the same sort of sortable, filterable list mentioned earlier and described in the next entry. Freezing, where the selected object is still displayed but becomes unselectable, is also incredibly useful, allowing other objects to be lined up in relation to the frozen object without the danger and confusion of accidentally selecting it.
Name Selection: Every object of every type should be named. MAX handles this by assigning it a generic name for its object type with an incremented number at the end to make each name unique, allowing the user to change the name at creation or any other time. In Unreal, if you dig through a brush's properties or look at the text at the bottom of the brush creation dialogue, there seems to be some naming going on, but naming alone isn't very useful without a name selection dialogue. It is convenient in almost any kind of application to be able to look at and select from a text list of every object in a file, especially if you have changed the names to be meaningful. MAX's Name Selection dialogue is, unfortunately, fairly primitive and limited. A good name selection dialogue should have the same kind of typing accelerator that all file folders on the Windows desktop have, where you can start typing any number of letters in a name of a file and the first matching file will become selected - but MAX only selects by the first letter of an object name! The ideal name selection dialogue will handle this correctly and also let you sort and filter objects by name, type, or any other criteria that are meaningful. Good selection tools are critical to be able to cope with the huge number of objects the next-generation game will have.
Axis Control: This is an area where MAX (and presumably most other 3D modelling programs) really shines, as it is critical to working in 3D with a 2D input device like a mouse to be able to continually swap around or constrain the axes the mouse is affecting. Unreal actually implements some of this, but not nearly as well. I won't go into the details of it here, but I find MAX's method preferable, because it shows via an icon the currently selected axes and allows you to constrain movement to a single axis easily, unlike Unreal which assigns axis control to combinations of the mouse buttons in a hard-to-manage way, and makes constraining to a single axis difficult in the 2D views (or impossible - I'm still trying to figure out which).
Vertex manipulation: While Unreal does allow manipulation of individual vertices, its interface basically sucks, especially because of its axis control shortcomings. MAX isn't quite perfect, not allowing zooming to the current vertex selection (see above) for instance, but is easy to use. Perhaps not all designers want to get their hands dirty on the individual vertices of game objects, but until we are dealing with objects where polygon count doesn't matter anymore, I find vertex manipulation to be the best way to achieve the shapes I want from the kind of low-polygon models games still rely on for their objects and world. However, depending on how much object creation takes place in the game editor and how much takes place in external editors like MAX, vertex manipulation may not be a great priority for the editor.
Texturing controls: Again, this may depend on the actual nature of the next-generation project. In Quake or Unreal, where the world is essentially constructed and textured by designers, the more controls, the better. If the next-generation game uses a lot of meshes created and textured in modelling programs by artists, the texturing controls may be less of an issue. Regardless, the best texturing controls I can imagine in an editor would work on a per-face basis and be modal, allowing the mouse to directly control the panning, rotation and tiling amount of the selected faces, rather than by clicking on buttons in a dialogue like Unreal, or by manipulating the size and location of a gizmo like in 3DSMAX. Having buttons and type-ins for more precise texture control would still be necessary, and possibly used more often, but the fluid control of mouse-based texture adjustments will become helpful as designers are able to use more small polygons and unique textures.
In Conclusion, I Rant
Writing the complete spec for the next-generation editor would take thirty pages and would be the kind of task I'd rather undertake for an employer than give away for free, and I've covered the important points. Now it's time for a bit of evangelizing and ranting. Presently and maybe perpetually, most of the people budgeting projects and controlling the industry's future want to make their next game without spending any time (i.e. money) writing an editor at all. This is not an exaggeration - I have personally heard this sentiment expressed by many different managers, high-ranked and low-ranked. Many of these, of course, are the same people who keep slavering for the Star Trek license despite the number of cancelled or extremely delayed and unfun (and often fairly poorly-selling) titles which the license keeps generating. For them, let me say it simply: Good game needs good editor. No editor = bad editor. Bad editor = bad game.
Here's another fact which doesn't seem to be understood by management (programmers certainly understand it, until they become lead programmers, at which point they are often required to trade in their brains): custom engines need custom editors. Even if you buy an editor for a similar engine, you will need to do work, a significant amount of work, to make the editor be able to output the data that your game can use and take advantage of all the custom tweaks you put in. Presumably, if you were writing an engine which is similar to or actually is Quake you might still find success in hiring the author of a shareware editor, but while I've heard of many projects buying their 3D engine from other companies and writing or modifying an editor, I've never heard of anyone writing their own engine from scratch but buying an editor, at least not in the FPS world (anecdotal evidence would be welcome, though). I have seen projects in other genres purchase incredibly expensive "commercial game editing systems" and end up abandoning them after half a year because adapting the commercial software to the needs of the custom engine proved more difficult than just writing a specific tool.
Even when the need for an editor is understood, the fundamentally, well, stupid desire to make projects twice as good (where good = sold a lot) in half the time with half the team continues to drive the management search for a cheap way out of making an editor. This is where ideas like using 3D Studio come from. This is another temptation to be avoided, for one reason more than any other: MAX, even in its latest version, is completely unsuited to working with more than about five thousand objects at a time. (I speak from long, punishing experience). Imagine editing an Unreal level where you have to wait thirty seconds or a minute after clicking on one of your brushes for it to become selected, even on a PII-300, and if you impatiently or accidentally click again while waiting for the selection to be made, your second mouse click will be buffered and cost you another huge wait before you find out you just deselected the object again. This seems like a fundamental flaw of the object-handling system of MAX and even if enough custom code could be written to turn this modeling and rendering package into a useful game editor, it is presently entirely crippled in that respect.
There are numerous other reasons not to build your editor on top of a commercial package like MAX. Most importantly, if you do this, you will never, ever have fan-created levels, because the number of game players who also happen to have the correct version of a four thousand dollar commercial modeling program sitting around is close to zero. The number who own the correct version is even less. The other option, releasing enough info for fans to create their own shareware level editors, is becoming less feasible as the data structures of modern games grow more complex, and it will probably become an impossible task to write an editor for the next-generation 3D game "in your spare time." Even if you haughtily decide fan-created levels are unimportant, you may even be reducing your potential licensing deals. If a small developer looking to reduce development complications by licensing your engine has already invested in ten copies of Lightwave or SoftImage, or doesn't even use PCs for their modelling, they may not want to be required to buy five or ten more copies of MAX just to use your editor, and you may find yourself needing to devote your own internal programming resources to porting all of your MAX plug-ins to different platforms or to new releases of MAX when those people could be working on your next game - you remember, the one where your GANTT chart was supposed to show the benefits of having an in-house editor from your last game?
In short, the most sensible move by far for any company writing their own 3D engine is to start writing a completely internal editor for that engine. Leave the commercial packages to model-building, and write a simple conversion tool to get their meshes into your editor. Unreal is sitting on top of the 3D world right now for going in this direction, and the number of Quake II licensees who dumped the license in favor of Unreal is directly attributable to Unreal having the best editor of its generation, an editor which has no extra requirements and whose every feature is designed to take advantage of the engine it comes with. Sadly, I do believe there are less managers far-sighted enough to see this obvious fact and follow the Unreal model on their next-generation project than there are game players who own 3DStudio MAX.
- Rich "Beaker" Wyckoff is a game designer on the game Trespasser for DreamWorks Interactive.
|Credits: Beaker's Bent logo illustrated by and is © 1998 Dan Zalkus. Beaker's Bent is © 1998 Rich Wyckoff. All other content is © 1998 loonyboi productions. Unauthorized reproduction is strictly prohibited, so don't do it. We have ways of making you talk.|