The article will remain until I can verify its origination.
— The Management Magus Telliamed 2006/11/21 14:16
And thus the Master Builder spake, saying, “Thy construction using DromEd shall follow these guidelines, as set forth by my disciples, and for the glory of my People and their goals, from this day forth.”
This document is a collection of goals, guidelines, disciplines, principles, hints, and tips meant to aid level-builders in building terrain in DromEd which is easy to understand and edit and which is efficient and fun in the game. It is a collected work of people who use DromEd, so if you wish to contribute lessons gained from your experiences, please do.
Building spaces is a bit like writing code. It requires structure and discipline, and everyone has their own opinions about how it should be done. For this reason, you should take this document with a grain of salt. If you have your own building strategies that aren’t problematic for you or other people working on levels that you built, then they are probably fine strategies (and perhaps should be added to this doc).
This document is intended in conjunction with PrinciplesTour.doc. This document is verbally descriptive, whereas PrinciplesTour.doc takes the reader through some tangible examples. You should make use of both of these documents, based on your learning style (I recommend skimming this document, going over all of that document, then returning this one to read it for real).
This document assumes a fair amount of knowledge and a small amount of experience in building with DromEd. If you haven’t already, please check out the DromEd tutorial.
What is good building?
Good building is:
A couple of meta-level principles exist which are worth mentioning before the categorized principles.
First, “clean” building, as opposed to “sloppy” building, is a style which leads to a lot (if not all) of the desirable qualities listed above (in particular: intuitive, parseable, efficient, passable). Clean building involves making sure everything lines up, is made of regular shapes, sizes, and angles, etc.. Clean building may be not be your preferred style for exploratory building but is strongly recommended for final drafts. If you start to feel a bit anal retentive, you are probably building cleanly. This is not a bad thing.
Second, by the above definitions, there is little or no perfectly “good” building. In all cases, tradeoffs exist between one quality and another. For example, the most attractive architecture is rarely very efficient.
Tradeoffs with time spent on construction always exist. Good building sometimes takes more time than bad building (first pass anyway, bad building usually takes much more time to maintain). In all cases, you must make a judgement call about which quality is more important for this particular construction and how much time you should invest on good building versus cutting corners. Some specific examples of this exist in the PrinciplesTour.doc.
Solid then air then solid then air then… — Remember that the world starts out completely filled with solid. The preferred construction method is to start working on this space by adding large air brushes to create “world” space to build into. Then you add large solid brushes to represent structures inside the air space, such as buildings in the world. Then you add air brushes inside those solid brushes to represent space inside the structures, such as rooms in the buildings. You can continue recursively in this way, adding solid features such as pillars, etc.. Note that this is not very intuitive, since most buildings are actually made of numerous solid walls in air space, not big solid blocks that people carve rooms out of. However, it is the time-proven method, since it compensates for being slightly counter-intuitive with a large number of advantages (which are discussed implicitly elsewhere). Note this method of construction makes the most sense in the context of building something like a handful of buildings with rooms inside them and streets/alleys in-between them. This method also works in other contexts: such as building underground corridors and tunnels. In those cases, you start the recursive process at a different point: you use air brushes to carve the tunnels, which are analogous to hallways and rooms inside a building.
Big parts to small parts/details – This point is similar to the construction method above. You should always start by roughing out the largest features and proceeding to smaller details, for example: the façade and footprint of the building, then proceed to general room shapes and hallways, then add major interior features such as stairs, tubs, and counters, then proceed to decorative details. Constructing in this top-down way means that if your large-scale design is flawed in some way, you will be able to edit it before lots of other features are effected by the change.
Use big, nice numbers – such as 128, 64, 96, 32.. numbers that subdivide well, as opposed to 75 or 131. This is in conjunction with the above points. Since you will start with large features and structures and proceed towards breaking those up into smaller and smaller features, using big, nice numbers means that when you get down to small granularity, it is much more likely that you will still be using units of about 1 foot.
Go into game mode frequently to check your work – You should go into game mode to see and experience the spaces you create. The little editor 3D window isn’t enough. Furthermore, even then the game camera can distort the game’s reality badly, making big spaces look small and such. Looking through the game cameras is not at all like looking through your own eyes. A good way to keep your work in context is to place some reference objects in the space with you as you build. Human AI’s work best for this. Furthermore, you should make use of placeholder lighting as you build, instead of light_bright. Placeholder lighting does a better job of representing the 3D form of the space, breaks up the textures, and in general can have a big impact on your building decisions.
When you start building a spaces, consider the following:
When you do your “large features” initial rough draft of the space, make sure you leave yourself plenty of room. Frequently, as details, objects, lighting, etc., get added to a space, the space becomes more crowded and harder to move around in-game. Some features may wind up being too small and need to expand, crowding into other features. Smaller, more cramped spaces are generally harder to build fun gameplay into and aren’t as attractive. If any of the spaces in your rough cut are sized such that they would be difficult to reduce in size, you probably haven’t allowed yourself enough room for the space to mature.
To avoid major headaches when room brushing, be aware that the following types of spaces are tricky to room brush (therefore attempt to avoid building lots of them). Spaces that are very close together through thin walls of solid. The best example of this is exterior walls of buildings that have window alcoves with skinny windows (made out of terrain) set into them. To get the right sound propagation, the room brushes on either side of the window must encompass the alcove and extend into the thin window solid without touching. This point is one of many reasons that most walls should be about 2’ thick in general. Irregularly shaped shells of solid that the player can be on either side of. Room brushes deal best with square corners. Other types of angles may require some real room brushing aerobics. For an example, you can check out the exterior intersection of the transepts and south nave of the cathedral of thief 1.
Strange intersections of solid and air that make lots of use of 3D space. A big room that has a solid, enclosed catwalk wandering around the 3D space of the room is a good example of something like this that is hard to room brush. In cases like this, its often good to provide some rational why the sound would propagate out of the catwalk (such as windows and other openings) so you don’t have to room brush the catwalk separately. Combinations of the above – basically the hardest thing ever to room brush would be two cigar-shaped submarines that intersect at an odd 3D angle with thin solid hulls.
Anything you put into the game might ship, unless you are very careful to avoid that. Sometimes you just don’t have the time to go back and do it right. Make sure any placeholder stuff can ship, or be so clearly undesirable that it would be impossible to ship it. For example, if you have a boring cubical room as a placeholder for some cool architecture you want to build in that space, then texture the room with __scale or something to make sure someone will make you finish it correctly before it ships. If you want a placeholder object, try either a giant block of cheese or a floating, spinning skull.
Sometimes DromEd isn’t behaving the way you want it to and you can’t figure out why not. Or sometimes you will have made the wrong building decision and are confronted with the idea of rebuilding part of your space over from scratch. You may be tempted to solve your problem by using “band aid” solutions which fix the immediate problem. This is generally not the right thing to do. It is better to figure out what is wrong or to come up with a correct building plan. Band aids are generally not flexible and not intuitive.
A doorway in DromEd is made up of an aperture and a door object set into the aperture. Here are some things to know about doors: The size of the aperture should exactly match the size of the door object in the aperture. For this reason all doors should have regular sizes. Door objects whose width and height are not multiples of 0.25’ should be reported as bugs. The so-called “standard” door size in Thief is 3.5’ x 7’, but we have plenty of non-standard door sizes, too, which are fine to use. Doors displace when they open, either by rotating or translating. In either case, you must make sure that the door moves into air space and doesn’t intersect in any way with solid space. For translating doors, this often involves making a little pocket of air in the doorway for the door to slide into. Note that this space must be room brushed. Solid doors (as opposed to portcullises, which you can see through) have a performance-increasing characteristic that when fully closed they block the tiny portal that they are in, such that the renderer does not waste any time rendering behind it. This tiny portal is created by the door when the level is portalized If a door is set into an aperture that is too big for the door (even by a little bit), then this render-blocking characteristic will block views that should actually be rendered. This can lead to weird colors or trippy vision effects around the edges of the door, which is called “cracking around edges.” Because of the way these doorway cells are created, you sometimes get very skinny cells in doorways, which we call “sliver cells.” When the camera is in a silver cell, you can see trippy vision effects (similar to what happens when you go out of the world with physics off). If you encounter a bug like this, have someone show you how to move the door to fix the bug.
Sometimes it can be hard to take an existing level and sort through the visual brush list to see how the level was built, for example in order to edit it. This might be because the visual brush list is too complicated and busy, because the person who built the level built a feature in a way that you wouldn’t think to build it, because the feature you are looking for is made up of a bunch of brushes, not all of which are really close to the feature, and so on. You might experiment with changing textures and moving and resizing brushes and find all sorts of side-effects emerging. This can happen even if you are the one who built the existing level. Good building, by contrast, attempts to be really clear in and of itself by being intuitive, understandable, and easy to edit. Remember that you can’t always be there to explain your building choices to whoever is looking at your work. Your work should explain itself. A lot of these concepts are thoroughly illustrated in PrinciplesTour.doc and will only be touched on here.
DromEd gives you 2 decimal places of resolution to input numbers for sizes, locations, and rotations. Good building never ever needs more resolution than this. This means that all features you build should be bound by multiples of 0.25 feet. If you grid snap all of your features to a grid size of 12, you will be assured that everything lines up to the right resolution. As explained above, you should start building with a larger grid size, such as 14-16 to make sure your larger features can be divided up cleanly multiple times. If you make a room that is 23.25’ x 16.75’, then when you will have a hard time putting other features exactly in the corners and so on. The same room 24’ x 16’ will be more flexible and look essentially the same. Note that every operation brush should be grid-snapped. Therefore, you should leave the grid on at all times. The only exception is rotated brushes, which should be grid-snapped whenever possible, but the grid does not offer lots of resolution for rotation amounts, so you may need to go below it at times.
DromEd understands amounts less than 0.01, even though it doesn’t express them in its dialog boxes. So, for example, a brush may say that it is 4.00 feet wide, but it is really 4.000267 feet wide or something. This can be fixed by grid snapping your brushes. If you leave the grid on at all times, you can be assured that whenever you create a brush, drag a brush with the mouse, or type in a value, that the value you see in the dialog is exact. If you turn the grid off, drag the value in the dialog to change it, or deal with multi-brushed features at all, then you may have subtly unsnapped brushes. To fix them, you should turn the grid on and “touch” them by dragging the brush by a tiny amount. Whenever you do any multibrushing, you should make sure all of your features are grid snapped. One way to do this is by using the following hilight tools: hilight_clear to clear any existing hilights, hilight_check_snap which hilights all unsnapped brushes, and hilight_do_snap which snaps all hilighted brushes to the current grid size. Note that the grid has to be on for these commands to work.
DromEd brushes have a notion of their “default” face, which is conceptually what the brush is “made of”. Work with this feature, not against it, but giving each brush a valid default texture (a texture which is not the test texture). Furthermore, the default texture should be the one that appears on a majority of the visible brush faces.
This warning applies both to cloning brushes and also to creating a brush when another brush is selected. In either case, the new brush will automatically inherit many properties of the old brush, including the default texture, per-face textures, and texture rotations and offsets. Since this inheriting behavior happens very often when you are building a level, you should be aware of any unintentional effects it is having on your brushes. Rotating and offsetting textures is a great tool, but shouldn’t be done without a good reason, and “because the offset was inherited from the last brush for which it was actually important” is not a good enough reason. If you make a brush that has interesting texturing information, watch the next brush you create: after it is created, make good use of the reset buttons - reset the brush’s default texture and the offset information for each face.
Don’t accidentally clone a brush and leave it exactly overtop of the original. This has no disastrous side-effects, but wastes a brush and is sort of easy to do.
Are powerful filtering tools; make good use of them. Encompass all major features of your levels (such as individual buildings, important large areas, etc.) carefully with area brushes and name them appropriately. This way when someone loads up your level and wants to find the library to edit it, they can just search through your area brushes for “library”, “me-only” the area brush, and get right to work.
Don’t put light brushes inside solid space, since they will have no effect in the world (this sometimes happens when terrain gets edited). Don’t put lights exactly on planes where solid and air meet, since they will not light the plane correctly.
The tools to search for objects (such as find_obj) assume that object names are one word. For this reason, you should not put spaces or strange characters in your object names. StartingPoint not Starting Point. West_Guard not West Guard.
Attempt to keep your brushes well-organized in time. If you have a row of pillars, you should be able to select one pillar and tab through time to go through the other pillars in order. You shouldn’t jump from one pillar in the middle of the row to the other side of the level to some other brushes. Note that this is a minor point. Time-organized levels are easier to edit, but not tons easier. Furthermore, levels tend to be time-organized naturally as a result of building.
When building, check the stats of your work frequently (show_stats). During the rough cut, don’t forget that adding details, polish, and objects will add to your scene complexity. You want to leave yourself plenty of room to add polys. If you can’t figure out where a bunch of your polys are coming from, try toggling render_backward to see what polys are being rendered behind the visible polys.
Performance guidelines for Thief were as follows. Most views should stay under 150 polys. The maximum poly view for gameplay-relevant spaces is 250 polys. Spaces in which no gameplay are likely to occur can touch on 300-350 polys. In general, the more gameplay-relevant a space is, the fewer polys the scene should have. Don’t forget that polys are not the bottom line. Objects, cells, and portals are all renderer performance hits.
The optimized stats are the important thing, not the portalized stats. The level will ship optimized, not portalized.
In some cases, you may have tiny individual views that if you get yourself in just the right position you will have too many polys, but everywhere else near the view is not too expensive. This is shipable, since players would usually have to be attempting to reduce their own performance in order to experience this performance hit.
The best way to avoid efficiency issues that will need to be addressed is to not build any overly-expensive stuff in the first place. Avoid having more than one expensive feature per scene. Expensive features are large (such as long sight lines) or complicated (such as intricate 3D space). If you have a staircase with railings (complicated), don’t put it in the same scene as the very long hallway (large). If you have a scenic overlook (large), don’t put it in the same scene as the row of ornate columns (complicated). If you are creating a large space, don’t plan on adding any complicated features. The reason building facades are always dangerous is because they usually involve both complex architecture and long sight lines.
Open spaces are not handled efficiently by the portal renderer. Avoid them; find other solutions when possible. The city streets in Thief 1’s Assassins mission were not made by carving a huge air block then partially filling it in with solid building brushes. Instead, the city streets were essentially corridors that were textured to look like building facades. Since you can never be inside those buildings, the fact that they were fake was unimportant.
Features that don’t line up correctly, ungridnapped features, etc., add to your complexity and can be very hard to notice. This is discussed in detail in PrinciplesTour.doc.
Unused, empty “dead” spaces sometimes appear under stairs, behind walls, in the corners of building complexes, etc.. These spaces are “dead” because they are not polished for gameplay and often times the player has no physical way of getting into them. These spaces are undesirable because they increase the memory size of a mission, since they need to be represented in the world rep, the pathfinding database, the lightmap, etc.. Sometimes they lead to AI confusion and misbehavior. Try not to build them in the first place. Often times filling them in with solid works well too.
For Thief 1, you could save polys on faces that had the “skyhack” texture by scaling the texture on that face up to 24, thus reducing the need for the poly to be broken up for light mapping purposes. This probably won’t be a concern for Thief 2, but there isn’t a good reason not to scale your skyhacks up to 24.
What do you do if you have a scene that is too complex? It depends on how many polys you have to cut. If you have few polys to cut, you should try to reduce some complexity by merging 3D features into the same plane, lowering the number of sides in cylinders, yanking out an expensive brush or two, etc.. In this way you can whittle down to the right number. If you have lots (> 50, perhaps) of polys to cut, don’t bother trying to whittle down. You need to go for the big numbers – make changes that will eliminate lots of polys at once. You probably should attempt to restrict the player’s view somehow… if the view happens to render down a long hallway that isn’t important to the scene, try occluding the hallway with some terrain, such as by introducing a corner or two in the hallway close to the view. If a building is being rendered in the background, try introducing a wall that will fully block the view to the building. If you have a large window that overlooks an expensive courtyard, try making the window skinnier so that only part of the courtyard needs to be rendered at once.
Everyone has their own idea about what makes spaces look good. However, there are some aesthetic guidelines we follow to keep spaces looking realistic. Furthermore, this section has some ideas and things to keep in mind when designing spaces. Note that even if you are mostly concerned with gameplay and would rather have some else add the aesthetic polish to your level, roughing out the level involves making some aesthetic decisions, such as the general 3D form of the space.
First of all, steal things! Professional architects spent lots of time on designs that are easily accessible either through personal experience, books on architecture, the internet, etc.. Modeling your designs on real world architecture is faster and usually winds up looking more realistic and more attractive.
Monitor the feeling of the space. Go into game mode and walk and look around. Does the space make you feel any particular way? Are you eyes drawn to any particular features? Does the space make you want to explore to see more of it, or obtain different points of view? Does it feel cramped, boring, or irritating anywhere, and if so how could you fix that?
Be 3d. Vary the ceiling height and/or shape as the player moves through the space. Break up flat planes on the walls and the ceiling with interesting features such as trim, columns, alcoves, arches, windows, etc.. Allow the player to see places above and below him. Change the plane of the floor by a handful of steps occasionally.
Lighting is low-cost way to add pleasing aesthetic breakup to a space. A boring cubical room can look pretty good if draped in the right kind of lights. Try to make good use out of the raycast lighting model by allow features to cast prominent, interesting shadows.
Some textures come with distinct features – such as a frieze, a decorative block, a carving, etc.. These look best when they are carefully aligned with the brush face they are on. Most textures are composed of elements that have regular DromEd dimensions – they repeat in a 4×4’ square or something. These qualities of textures make them look best when they line up with other features – e.g where the wall meets the floor. Lining up textures is easiest when you use regular, grid-snapped terrain, such as 16x24x8’ rooms and so on.
Changing the scale of textures is a good way to make features look better when they are very large or highly-detailed. The default texture scale is 16. In most cases, you shouldn’t change this to be above 17 or less than 15.
Regarding textures on stairs or other irregularly-shaped terrain: try to use textures whose repetition is hard to detect – more granular, jumbled, or flat textures – as opposed to 4×4’ tiles or something, which will look strange on stairs.
Most walls should be at least 2’ thick. This is especially true of stone and brick walls. Interior wooden walls can probably get away with about 1’ thickness. Exterior stone walls should probably be more like 3 – 4 feet thick, although 2’ is ok too. Along these lines, watch out for spaces where different types of air brushes intersect at angles, such as where a cylinder meets a cube. These can come to an unnaturally sharp point. One solution is to chop off the point with an air brush.
The ceiling overhead should not be really close to the player’s eye level. When the player is standing up, the ceiling should be at least 6.5’ above the floor. Ceilings that are at least 7-8’ high are best.
Its an obvious but important point that players shouldn’t be able to see (or get to) areas that are “backstage” – ones that aren’t polished or which contain things that aren’t meant to be seen (such as AI’s waiting to enter the world).
Regarding the “logically consistent” quality mentioned far above. This applies only to normal cases in which strange reality-distorting fiction isn’t in effect. Buildings should be same inside as they appear to be outside - e.g. – assuming you can get to all of the rooms in the building, you should be able to get to every room that you can identify from the outside. Lines of sight should be consistent – e.g. – if you pass by a tall tower then go through a gate in a wall and then turn around, you should be able to see the tower. That issue can come up when you don’t use the “skyhack” texture carefully. The skyhack can also lead to strange effects whereby a big chunk of sky seems to occlude a chunk out of a building.
Regarding natural spaces such as caverns and tunnels. Note that you can make satisfying-looking natural spaces with regular shapes and sizes (that won’t be too hard on the renderer). The trick is to use multiple, intersecting shapes. A single dodecahedron will always look like a bit mathematical, but if you intersect two of them and/or introduce some protruding pyramids and so on, the space will start to look more natural.
If you want to make a space look realistic, be aware that using a restricted choice of textures often make spaces look more realistic – a bunch of buildings all constructed with the same sort of stone tends to look more realistic than them constructed with lots of different types of stones.
Be wary of oversimplified building footprints. The archetypal house is a cube with a triangular prism on top of it. Any building that you intend as an interesting building in the game should not have such a simple floor plan. Most real buildings are made up of a pleasing jumble of simple intersecting elements.
Your levels should be possible and fun to play the game in. Although much of this design happens in mission breakouts, be aware that when roughing out a level you are constantly making decisions that will impact the gameplay of the mission. You should have this in mind as you build: what might the player do when the player is in this space? What challenges will exist here and how might the player detect and respond to the challenges? What options does this space allow and what options does it not allow? Don’t forget that the player can potentially be in any of a number of states: near death, chased by guards, extra cautious, distracted, searching for something, away from the computer, etc..
Playtest the spaces you build and populate with challenges to make sure that it is possible to get through them without exploiting secret designer knowledge.
In most cases, aesthetics are subordinate to gameplay. A great looking space isn’t as enjoyable if you get killed in it frequently. It is possible and very desirable to build good architecture which also supports good gameplay.
The level needs to be well-lit enough for the player to navigate around in, even if they put out every possible lighting source that they can interact with. This doesn’t mean that every space needs to be lit. It does mean that from any spot in the level, the player should be able to look around and see some light spot that they can walk to successfully. In other words, you can use “beacons” of brightness to guide players through dark spots, as long as you don’t ever leave them stranded. It is also noteworthy that levels have ambient lighting to make sure that some non-black pixels are being rendered at all times. The standard ambient level to achieve this for Thief 1 was 20.
Make sure the player can get around in the world the way you expect. Check to see what the player can jump onto, duck under / into, mantel, rope arrow into. Allow them to do things you want them to do, and prevent them from doing things you really don’t want them to do (such as get “backstage”). Note that making the player feel empowered is a good thing, as is easy busy work the player has to do when moving through space. Therefore, little steps, small jumps, occasional simple climbing obstacles, simple rope arrow use, etc., are good ways to add interest to the simple act of walking through a space.
As an important corollary to the above, ladders suck. They are difficult to use in pretty much any 3D game and even more so in 1st person games. Falling off ladders can lead to player injury and death (which should be on a warning sticker on the ladder). As a level-builder, take responsibility here. Work with the design of ladders, not against it. Design ladder experiences that are as easy and forgiving as possible. If you accidentally build a frustrating ladder experience, make a strong effort to fix it.
Your space needs to be one that the AI’s can get around in pretty easily. AI’s cannot climb up or jump down cliffs that are very high (something like 2’). When you want AI’s to change altitude, you should provide them with stairs or ramps. Try not to let the player get someplace where an AI can see him but not get to him. If you do, try to allow the AI to fire projectiles at the player. Remember that AI’s can’t crouch or jump. On platforms, walkways, etc., watch out for tiny cracks in the solid floor that the AI will either refuse to walk across or fall through. The AI is much happier with spaces that are regularly shaped and have simple, flat floors. Therefore, if you have some complicated tunnels or something and the AI doesn’t seem to like them, it is often helpful to carve a little cubical path down the middle of the complicated tunnel for the AI to use.
Thief is a game that has very complicated AI’s that have very complicated relationships with all aspects of your levels. In time you will learn more on this topic than you probably wanted to. These thoughts are just to get you started thinking about how to build levels that the AI can work with.
Don’t feel like you need to go out of your way to confuse the player. A very simple overhead maze is a very tricky 3D, 1st person maze. It is much more likely that the player will be confused in places that you thought were simple than it is that the player will think any purposeful maze you build is easy. Although some amount of player confusion and misdirection is cool, very confusing spaces that are hard to get oriented in can really suck. Along these lines think about landmarks such as architectural features and objects to help orient the player. Be wary of homogenous spaces that are hard to tell apart. Also be warned that very symmetric spaces can be a lot more confusing than you might think.
Use the textures for what they are intended for. The “oven” texture might look like a good one to use for trim of the house, but only use it for ovens. A certain rock texture might look like the bark of a tree, but use it as rock. You can always ask the artists to make you new textures based on what you think the texture looks like. The reason for this is because textures have specific gameplay properties – what sound they make when collided with, whether arrows stick in them, etc..
Sometimes the player seems to get stuck on walls that they collide with, instead of sliding along them. This is usually because the ground underfoot is sloped towards the “sticky wall” in question. Flattening the ground is the first step you should take.
Building levels that are fun in stealth games in particular is a whole other discipline. One of the biggest points is identical to the first point of the last section: as you build, think about what options the player has. If you were a player in this space and a guard was coming and you wanted to be undetected, what would you do? Is there a place to hide?
Here is some stealth-gameplay knowledge that was used successfully in Thief 1:
Playtest your spaces to determine how stealth-friendly they are – If you expect the player to sneak through an area, see if you can sneak through it yourself without exploiting any secret knowledge about the patrol routes and such.
Little dark niches in the walls that the player can stand in. These are effective in otherwise dangerous flat hallways, open rooms, etc.. They can be integrated into the architecture in pleasing ways. They are very effective stealth-supporting tools and easy to build.
Counters, pillars, statue bases, bars, etc.. Things the player can get behind to break line of sight. Bear in mind that unless the player is in darkness, anyplace the player can see the AI, the AI can potentially see the player.
Be aware that the AI is very good at tracking players who are making a lot of noise. Since loud surfaces force the player to make a lot of noise wherever they go, they are not at all stealth-friendly. Any really big expanse of loud surface is a gameplay danger. When you use those spaces, be sure to break them up with comparable expanses of soft surfaces.
There are two ways to allow the player to avoid bright spots. One is to provide a path of darkness (or otherwise out of sight) around or through the light. The other is to provide the ability to put the light out. Be aware in the later case that when the lights are out, the level still needs to be lit well enough to get around in.
Binary Lighting – Binary lighting has very sharp, distinct borders between light and shadow. Binary lighting helps to eliminate ambiguousness in visibility issues. It also tends to have pleasing shadow effects. However, it isn’t always exactly the thing you want. Spot lights and lights set in niches in the walls and ceiling help to create binary lighting. Unclamped omni light brushes in open space tend to lead to ambiguous locations for which it is hard to tell how well-lit the space is without entering it.
Ideally the player will be able to tell how bright a spot in the world is by looking at it. If it looks dark, the player should be dark when in it and the opposite is also true. Although lighting exists in 3D space in the game, the player’s lighting value is measured at his feet, in an attempt to maximize the correspondence between apparent lighting and actual lighting (since lighting most often appears on the ground). Therefore if the player walked into a horizontally-aligned spot light that was brightly illuminating the player from the waist up, the player’s lighting value for AI’s would be measured without considering this. As a designer, you should avoid creating situations that run counter to that assumption, like bright horizontally-aligned spotlights. If you encounter some places in which your lighting value doesn’t seem to reflect the apparent lighting on the terrain, move your lighting model towards one which is more binary, as described above.
One of the key tenants of being a thief is that you can see guys who can’t see you and therefore you can observe them in safety. Empowering this activity requires building safe observation spots into your levels. The easiest way is to give players dark spots to stand in and look into lit areas that the AI’s are in. It can also be done with alcoves, AI’s who are conveniently facing the wrong way, etc.. Most potentially dangerous stealth situations the player encounters should be observable from a distance in this way.
Small spaces are hard to sneak around in. In a small plain room, there is no place to hide where it won’t be easy for the AI to find the player, especially if they get suspicious and start looking around. If you ever expect the player to be able to sneak through enemy territory without being seen, the space will need to be pretty large. Hallways need to be pretty wide if you expect the player to be able to hide from an AI who is patrolling through them. The actual sizes depend on other stealth characteristics of the space, such as lighting, loudness, and hard cover.
Patrolling AI’s cover more territory to potentially detect the player, but also provide more opportunity to avoid or sneak up on. Stationary AI’s control less territory, but more rarely provide opportunities to defeat.
Blind Corners – Blind corners can be hard on stealth because the player may turn the corner and bump headlong into a patrolling or stationary guard. It is good to drape blind corners in shadows to avoid this type of nasty surprise. These are also a good place to encourage the player to stop and listen for nearby AI’s. Blind corners are not undesirable, since they are good tension builders, but the player needs to be able to explore reasonable strategies and options to safely get past the corner.
Be aware that although the player is weaker than a couple of AI’s when they are in a bright room together, the AI is usually at the player’s mercy when in total darkness. Although you don’t want the levels to be too unforgiving for the player, neither do you want the AI’s to be too easy to defeat.
The player may need to avoid confrontation at any time, any place. Any space you build which has no stealth-supporting features – which is bright, has no hard cover, loud surfaces, etc. – should definitely be built with a particular gameplay consequence in mind. Don’t accidentally build lots of stealth-unfriendly spaces.
