RE: Editor GUI design

Uffe Friis Lichtenberg (
Fri, 7 Jun 1996 01:13:46 +0200 (METDST)

Date: Fri, 7 Jun 1996 01:13:46 +0200 (METDST)
From: Uffe Friis Lichtenberg <>
Subject: RE: Editor GUI design
In-Reply-To: <9606061623.32444C@lat1192.l...>

On Thu, 6 Jun 1996, Olivier Montanuy wrote:

> Comment is simple: Quake levels are closed. just like Descent mines.
> how the heck do you think one creates a mine? You walk inside and you
> cut your way throught the walls, using a suitably shaped object.

I don't think you're right. (Have you ever tried using Devil to create
Descent levels? Tedious at best, undescribable at worst.)

Construction of a level would probably be easier if you had only the
`constructive' approach, not the `destructive'. There will of course
always be situations where the destructive approach could be easier/more
intuitive, but I think this is fewer times than the other way around. (Am
I making any sense? Sorry, it's late.)

Any editor worth it's salt will have both options of course. What we'll
really need for Quake Editor Development is a set of CSG library
functions. (Doing the union/intersection/negation calculations, converting
to meshes for display, saving as .map primitives, and so on.) Once I get
some time on my hands (yeah right) I'll probably start there and work my
way up to the GUI later on.

> The .MAP format made of filled convex blocks isn't suitable, in my not
> possibly humble opinion. That's the way you build houses in the open,
> not the way you dig mines. What do we care about the exterior of the level?
> How come it's even calculated? It can even cause errors (leakage).

Another facet of good editors -- scene validation. Leakage should be
simple though. John Carmack even told us (somewhere) how he does.

> And of course, you should be able to edit the level while walking
> inside, not via some lame combination of 2D views or delayed camera view.

I agree on you totally here. After trying out Build (although it is
severely limited) I have become convinced that this is the only way
really good levels can be built. (It makes it so easy to add that final
touch, and placing the really cool details.)

> That screams for a portal based scheme.


The Way My Ideal Editor Would Work

(And no I am not implying that I will ever try to implement this. It could be
fun, but I could never find the time for it.)

* Basically there should be three modes for editing level layout:

1) Brush editing

A library of `building blocks' will be necessary to create levels
in a reasonable amount of time. Also this is handy to create a
consistent look throughout the levels. (Placing similar looking
columns, furniture and so on helps maintain a theme.)

These brushes has to be creatable and editable. Also CSG must be
present to combine brushes. Basically union, intersection and
negation is necessary.

In my experience CSG eases editing very much. It allows you to
create simple to semi-complex stuff in no time and has a very nice
learning curve for beginners (or non-techies).

2) Map editing

Using the brushes to add to the scene (place stuff) or subtract from
the scene (drill holes). Also some operations to translate or
rotate large parts of (or perhaps the entire) scene must be present.
Moving and deleting individual brushes after they are placed must also
be possible.

This is used to build architecture, place furniture and other such

Also textures and lights can placed at appropriate places. Lights
are of course only used in pre-processing. I am guessing dynamic
lights will be entities.

3) Entity placement

Placing monsters, health, dynamic lights, switches, doors, bridges
and what not. All the rest, so to speak.

All these three modes should ideally be accessable at the same time
so you don't have to spend time switching screens or even programs. All
modes must also be able to work on subsets of the level so the user can
concentrate on the task at hand.

All editing should be possible using the following views (now this is
where I get out of hand):

a) Isometric

Generic isometric with a view-vector and view-window defined. Hot
keys or menu items for `snapping' the view to +X, -X, +Y, -Y, +Z and
-Z must be available. Also you must be able to snap to the nearest
45 degree vector so you can get that typical isometric top-down view.

b) Perspective

The well known view-point and view-direction scheme. As used in
Quake. Also hot keys for `snapping' the view should be available.

If possible a `Quake Simulation' would be ideal. It doesn't have to
simulate AI or any such stuff. But trying the level out
(even just in wire-frame) with scene-gravity, and other such server
parameters set, could be very useful. (For instance: checking to see
whether the player can reach a ledge by jumping or getting a feel
for the size of the level.)

Both views should be available in wire-frame and textured modes.
Texture mapping does not have to be very accurate (ie. perspective
correct in perspective mode is not necessary). Just enough to enable proper
texture alignment. Both modes should be able to use colour to enhance
depth perception and minize drawing overheads.

Anyway, this is probably best doable in an environment where 3D API's
are available that will allow hardware accelleration and so forth.
Wire-frame (with hidden surface removal) should be possible anywhere
though. ("Put away that Speccy, Kiddo" :)

All editing must be done with an editing plane defined (moving vertices
and so forth parallel to it). And for rotation, arbitrary axises (sp?)
must be placable.

Note: I think a properly done isometric view-scheme is more important
than the perspective ``walking in the level'' view-scheme. Also texture
mapping, z-buffering and even projection is a lot easier in this.

* For the CSG routines it is of prime concern to:

1) Keep precision high, so brushes don't become more and more
complicated because of repeated intersections and unions. 3D Studio
has this problem to a high degree.

Math should probably be integer were possible. (Isn't this why John
Carmack chose to have plane definition vectors integer in the .map

2) Fast. We do not wish to wait all day just because we tried to cut a
cube out of a wall. Internal map representations should probably
maintain a strong position coherence between brushes, so we don't
have to check every brush against each other everytime we move

3) Perform closures correctly. (Is this the wrong term? I'm rephrasing
from memory.) [Foley, et al, Principles and Practice...] has some
nice comments on this. Don't know how implementation friendly all of
the algorithms are though.

* This is of course without considering .mdl editing, .qc editing (seems
like a lot of the switch logic and similar stuff has to be placed
here), texture-editing, sprite-editing, sound-editing, etc.

Any comments?

Uffe. [uphfe]

"Doom was fun, Quake was fun. Now for a *real* challenge... REAL LIFE!" 
  - Anonymous moron
"That sucks, let's burn it!" - Beavis (Non-Anonymous moron)