The 10 Commandments
Welcome to the 10 Commandments. When you design and make
a level for AvP you must not break these 10 laws. If you do break them,
your level will not run on most systems, AI will not navigate properly, and you
will want a few cans of Raid to fix all of the bugs you will generate.
- Polygon Count
No more than 1000-1200 visible (i.e. module-linked) polygons in the environment at any time. Never go over 1500 polygons - things are just getting out of hand and the environment is probably just too ambitious if you are approaching these kinds of figures. Conversely, if your polygon count is too small then you may have too little detail in the environment. A small
poly count is not a problem in itself if the environment still looks cool - in many ways it's a bonus because things should generally run more smoothly.
Make nice small modules that reduce visibility - meaning that if you look into a room, you only need to see what's directly in view rather than draw the whole thing. Small modules also make it easier to maintain a steady polycount.
You will have to design your environments (especially big rooms) with the express intention of splitting them up. It can be good practice to imagine a series of 'cutting planes' aligned to the axes when you first design an area, and ensure that all subsequent polys have edges on these planes. It makes life an awful lot easier than trying to cut stuff up later with 3dMax's slice tool.
- Overdraw
Overdraw is the enemy. Overdraw is where you have built modules badly and the engine busily lights and calculates a load of polys and then draws one whopping great big poly on top of them because they're behind a wall. This is a serious waste of processing power and all the more annoying because it's almost always avoidable: walls tend to be good places to split modules - good design of modules will prevent overdraw in most cases.
An exception to this is when you're using polys involving transparency (termed translucency in the tools). The effect of transparency excuses overdraw - for example where you have destructible windows or rusted mesh fences (which would most likely use a texture with a
color defined as invisible). If you want to use these effects, try to keep them in low poly areas.
- Polygon Count Stability
A fluctuating framerate tends to occur when a level has been built as a series of beautiful set-piece rooms connected by very boring box corridors. Try to aim your
poly count to be stable around the 1000 mark. If it fluctuates between 200 and 1500 as you run around the level - i.e. sudden changes between low and high polycounts (or vice-versa) you will see sudden changes in framerate which the player will notice and perceive as the game being 'chuggy' - even if framerate is actually improving.
Test your environments frequently by exporting your work in progress as a rif from 3dMax (remembering to include a dummy object at (0,0,0) named 'nucleus' and a 2 metre tall object named 'Hudson' for scaling) and running some of the testing tools. The automatic module-linking function can give a quick idea if you are on the right track poly-count wise (no more than around 1200 visible
polygons visible/module-linked from any one module). And running the module-overlaps tool gives advance warning of major problem areas.
- Scale
Hudson is a good model for the scale of marines but it is important to remember that the predator and particularly aliens need tons of room to
maneuver quickly. If anything create a few corridors and rooms that are too large - these are generally more fun to have firefights in.
Hudson (our reference character) is 2 meters tall. This is roughly the bounding box size (collision volume) for all characters when stood up. Crouched or crawling characters are smaller.
As a rule of thumb, make ceilings in standard sized rooms 2.5 or 3 meters high to allow a decent amount of head room. Airducts, particularly those intended for the alien to crawl through, can be smaller - say 1-1.5
meters high.
All the characters in AvP move unrealistically fast - the Marine's walking speed is comparable to
an Olympic runner at full sprint; the alien in a full-on running jump approaches a significant fraction of the speed of sound. The effect of this is that an environment realistically scaled to Hudson can seem a bit like toy town. I would recommend building environments somewhere around 1.5 times the size you would expect to see them in 'real-life' as a reasonable compromise. The exception to this is any instantly recognizable
objects that you may see directly adjacent to a game character (like chairs or tables) - make these scale realistically to Hudson.
- Interior Environments
The AvP engine is specifically designed to deal with interior environments and predictably many of the advantages of the engine are lost when we try to do an exterior setting. An obvious problem is that the alien player can climb anywhere so will always be able to reach the edge of the environment and fall out into nothingness or crawl all over a beautiful fake backdrop you may have engineered. In addition, we have no fog to block off visible environment beyond a certain distance so large open expanses will usually put too much pressure on the engine to run smoothly.
Don't do something like make a football stadium to fight in and then scale it as
to make you ants in the environment.
- Lighting
The lighting algorithm runs by calculating intensities at polygon vertices. Thus small polys (or at least a consistent size) make the
lighting system look much better. Avoid the situation where you've built lots of nice fine detail and then use huge polys to make up the rest of the room/scene as these light in a very ugly manner - you will see a spiky lighting effect that really detracts from the look of a game.
- Environment Features
Doors -
Doors are a false economy. We have to assume that all proximity doors can be open at any time because they can normally be opened by any character running through or nearby (there are exceptions to this which involve specific door strategies). So don't use them to 'block off' areas but feel free to put windows in them.
Corridors -
Corridors should always be quite large and concave so that aliens can move around them easily. For this reason also, 'sticky-out bits' should be avoided in high-transit areas - pipes and other decorations built into the walls are cool, but not in central corridors where most aliens travel towards you - they tend to fall off or get stuck if they encounter small polys in their way.
Airducts -
On the whole, almost all rooms should be connected by airducts to give the alien a way of getting around the level. This is important for AI aliens so that they can hunt you down from any part of the level; it is important for player aliens so they have an alternative route around where they are unlikely to encounter marines or predators with big guns (it's only fair).
- Steps and Stairs
Each step must be two units deep if it is one unit high - i.e. a 0.25m high step should be 0.5m deep. Keep them around this sort of scale - it gives a vaguely satisfying 'judder' to the camera when you run up and down them. Sometimes steps appear not to work for no apparent reason and the player gets completely stuck; in this situation, you will probably just have to rebuild them exactly as you did before and they will then work. There is no known explanation.
- AI Navigation
The creatures in the game have two sorts of distinct AI - 'near' and 'far'. The aliens do not actually exist in the environment as far AI, but are spawned in a visible module when they enter it. They then become near AI.
If you consider the modular environment as a series of boxes, the aliens basically know where their target - i.e. you - is (in terms of which module) and where they are. They move from adjacent module to adjacent module until they enter a visible module, at which point they become actual creatures with bounding boxes and
behaviors, and actually start navigating through the environment - they are now near AI.

The first concern for an AI is moving from module to
adjacent module so it is important to split the environment into sensible navigable chunks (modules). Within a module, an AI will move from polygon to polygon - always forming a kind of join-the-dots route between the
centers of the polygons. Essentially, the AI looks at the poly it is on and works out where it can go depending on the
center of the polys bounding it. For this reason, true 3d mesh floors will always work better than z-buffered shapes.
With near AI, we have to be quite careful how we design modules as it is quite easy for the aliens to get stuck - a situation we must avoid. U-shaped modules are unacceptable, as are L-shaped modules unless they are not too extreme. This applies in all dimensions - vertical U-shaped modules are also unacceptable. Thus, a basic
box room with a gantry running across the middle is out of bounds, because if you stand on the gantry the aliens will run up underneath and hover directly beneath you on the underside of the gantry.
The marine and predator AI cannot run on the walls (although they do have projectile weapons, so it's not so important that they are able to get to the player) and they have great difficulty navigating the environment if each module is too complex. This can be solved by very clever module design, but often it's easier not to build the stuff in the first place, or make sure that complex rooms are well split up into their component modules.
- AI and Objects
AI's have a bit of a problem with placed objects. Essentially, when they see you they will attempt to run directly at you. They do consider the environment close to them (it helps them not to hit the walls) and so if there is a table built into the mesh in the middle of the floor they'll go around it or over it. However, if there is an object in their path, they will have difficulty as they can't actually see it. If it's moveable, they'll move it, if it's destructible, they'll destroy it, but it tends to be a problematic situation. As such, try to place detail and placed objects around the edges of rooms where it is more out of the way.