I. Getting Started / The manual / Tips and Details 1

1. The Cube manual (readme.html in your Cube folder) is fairly complete and easy to understand. The pages contain map editing info as follows:

editing: all the basics
reference: most of the commands in text console format, including savemap. Many are also in the menus.
config: mainly the bind command and basic scripting
game: info weapons, enemy, etc.

The biggest weakness of the manual is some info is in bits and pieces and doesn't give much guidance if it doesn't work the first time. The important parts aren't that emphasized. Also the editing key layout is spread throughout. Overall, reading the whole thing is expected.

Some potential pitfalls:
The upperwall texture is 4 and 7 on the numpad but heightfield vertex delta is 8 and 9 on the letter keyboard.
Pay close attention to that "newent" command in the "reference" section of the manual -- there's a big list of entity commands following that that come after the "newent" part.
Note that light levels are 1-255, not 0-255. This is important with colored lights. Example:
newent light 16 255 1 255
...yields a bright pure violet (red+blue) light, but
newent light 16 255 0 255
...yields a white light because only the first two numbers register.

There are a couple omissions relating to commands that rely at least partially on the included autoexec.cfg or the like. One is the sp, dmsp, ffa start game commands are not described. The other is mousewheel editing is not described in the current version (?it was before).

2. I recommend starting with the manual's main editing page and using keys and the editing menu. Then get into the console commands. Some things that are highly variable, such as lighting, simple can't be fully controlled otherwise.

To repeat a console command, enter ~ to again open the console and up arrow to back up through the previous command list. Also backspace a bit to make partial changes. TAB acts as autocomplete for commands -- you'll learn how many letters you have to enter before hitting TAB to get a specific command.

Mousewheel editing is also fun and quick. Select some cubes and look downwards of horizontal and then turn the wheel to control floor height. Look up for ceiling control instead. The default keys for mousewheel texture selection are Q (floor/ceil) and E (wall/upperwall). Hold one and scroll to selection. If you have a heightfield, you can also use Z to scroll the vertex delta. Note, due to the look up/down thing, every once in a while the keyboard may be easier.

3. Powerful techniques:
Copying and pasting is very powerful. Note, both the floor and ceiling are copied together so don't, for example, look up at the ceiling and work away without noticing you're destroying your meticulously made floor. Note also, entity layouts are not included, only the architecture is copied. The only way to copy a section of a complete area, with entities, is to copy the whole map file. But, it's easy to keep the resultant two maps achitecturally in sync by copying and pasting between them in the editor.

4. Savemap compression effects ..........
When a map is saved, compression is done and part of this removes information that NORMALLY would have no visible effect:
-- solid walls are reset to default height and internal textures may be altered to default or made all one texture (or something like that).
-- non visible wall textures (for example under the floor) may be altered.

Sometimes things become visible that normally wouldn't, resulting in the map getting changed during save:
1) wall visibility does not take into account heightfields.
2) when a save is done, tagged cubes are made nonsolid, save processes, and then tagged cubes are made solid (like after loading a map). This is good in that it preserves floor and ceiling textures, even upperwalls, but lower walls -- i.e. the whole texture while in solid -- may be altered. Foolproof way to avoid this is make sure at least one wall of each cube is always visible, either through the tagged bit standing up or a hole in the floor adjacent. You can try making a whole grid area (2x2, 4x4...) a single wall texture, this sometimes works, test it.

4a. While saving often is a good idea, sometimes it is inconvenient to do so and vice versa. Sometimes you have to savemap and reload to get the full picture (also if you pop out of edit and take a powerup it won't reappear and requires such a cycle).

5. Explanation of oddities of heightfields ...........
It has been revealed that if enough vertexes of a heightfield are in a plane (within a grid division), Cube will group them to render as a single unit, reducing load. Example is a sloped plane. The game getting confused about this is one cause of problems -- "seams" cause a "hall of mirrors" effect (HOM). More complex areas are rendered a cube at a time, i.e. a small square in the horizontal plane stretched to slope. You can "break" areas with the aforementioned confusion problem by making them rougher. Either way, , a polygon engine renders the square (rectangular?) area by actually dividing this into two triangles, with a diagonal dividing line between them. The eccentricity of this is the diagonal is always in the same direction, never rotated 90 degrees (which can happen with angled corners). So you end up with stuff like the following:

6. Notes on water ............
a. Basic method: A blank map starts with water set at a level of -128, just below the minimum floor height, so it never shows. To allow water, set waterlevel higher, to a maximum of 127. Entering the command /waterlevel 0 results in water just below the default floor. Any time the floor is lower than the water, water appears. Note, this is the raw floor height, and the decision to draw water doesn't take heightfielding into account. Therefore, heightfielded areas where the raw floor height is above water but the heightfield dips below water height may not draw water consistently. This can be determined by experimentation.

b. The cube manual submits the following:

Performance notes: water is rendered for a whole square encapsulating all visible water areas in the map (try flying above the map in edit mode to see how). So the most efficient water is a single body of water, or multiple water areas that are mostly not visible from eachother.

The last statement is not true for the 10/02 version of Cube where the walls do not occlude the water (my map Shadowland is an example of a map developed for the 6/24 version and is negatively affected by the change). The water areas should be close to each other (relatively -- not an issue on small maps). If you even have a tiny pool in each of two far diagonal corners of a map, water is rendered everywhere in the map -- you just can't normally see it where the floor is above the water due to the floor being drawn in the way. This can have an enormous effect on performance. Flying below the the floor may be more helpful at seeing this than flying above the map. I've had to find that one cube below the waterlevel off in the corner somewhere.

Players can influence how accurate the water is rendered using the "watersubdiv" command (config).

Watersubdiv is basically the size of the waves. Small waves look a lot better in small pools, but are not necessarily better when larger water areas are used. With maps with large water areas, it may be desirable to force a high watersubdiv setting through the map's .cfg file to improve performance (look at the wqd).

7. Random tips:
- after placing monsters, pop out and into of edit to make them appear.
- after loading or saving, pop out (if needed) and into edit to make tagged areas nonsolid. Save to make solid.
- tagged cubes will be made solid at map load and nonsolid when triggered, which overrides any heightfield or corner type, even though you can temporarily have tagged heightfields or corners wile editing.
- to make all vertex delta of an area of heightfield the same, reduce vdelta to nothing and keep going until it's flat. You can then push that flat area (back) to the desired height.
- heightfields are often used for sloped bits, but also can be used for fine height control of horizontal surfaces and also some trickery.
- Paper: you can lay out a level on paper, although I rarely do. It is useful for getting an idea down also. When there are large numbers of triggers or teleports, kepping track of them is essential. Another thing is to take notes during playtesting.

8. Performance considerations ..............
Performance statistics are displayed at the bottom right corner of the game screen (dis/enabled by the command /hidestats 0 or 1).
"fps" is the frame rate on your computer. "wqd" is the main indicator of.

9. Teleports: more than one port can converge on a single teledest, however more than one teledest for a port number is trouble, since the destination becomes neither of the dests and you may not be able to find them. Of course you can delete the ports and use another number. Advanced topics: see Monster Machine "about" and maps for double teleports, search on cube forum for "switchable teleport".

II. Map Config files -- Custom textures and More

1. For now, look at various maps .cfg files for many examples of how to do this. Mine are commented ("//" in a config indicates a comment to the end of the line). The .cfg is normally the same name and location as the map file. All files accessed by the config are relative to the packages folder -- only the map and config files themselves default to packages/base folder. It is preferred to put textures in a different folder; put either all files in this folder (but the player will have to include the folder name when starting the map) or just the map (.czg) and .cfg in packages/base. (In Windows, the forward slash is used in-game, and converted to backslash to access files.)

2. For info on music, search for "mp3 xm" on the Cube forum.

3. With loadgame, all triggers taken already by the player are executed, but the order may be altered. If this matters (music, more complicated), make scripts tolerant of wrong order or lay in the triggers in order as the last step of mapping.

III. Design

1. General ..............
Potentially, anything can go in a level, aesthetically, providing it can be made to seem intentional (Context). Of course judgement will vary as to what works. Realism does provide an advantage of providing real world reference. There is a good reason to desire some thematic consistency in a level. This can take form on the micro level (example, repeating visual details) and/or the macro level (example, overlying concept).

Cube uses a means of building a world that may seem strange at first. One crafts a 3D shape, but the player is inside this shape rather than it being an object(s) that the viewer is outside of.

Cube implements outdoor areas using the concept of skybox textures. This is a texture that acts like a solid surface but looks like a window to a sky and other distant surroundings; it's a bit odd and can be used for both realistic and unrealistic effect (for example, a cube of sky in the middle of a room, or sky you can walk on). Look at existing levels if you have trouble learning to use it, it's hard to explain. One thing to be careful about, when skybox is used at multiple heights, is making sure the player can't move into a position where a projecting bit of skybox blocks normal texture behind. Advanced techniques require care to avoid breaking the illusion. You can even combine heightfields with skybox texture -- the sky won't appear curved but the opening through which it appears will. For examples both good and questionable, see my levels.

Cube can not currently implement bridges (room over room) but jumping allows the player's route to cross a lower one in the manner of a small bridge. Substantial vertical elements can still be used (the maximum vertical size is 256 cubes, which is also about the maximum desirable horizontal dimension of a single room or space).

Remember that skilled players can rocket jump if rockets are present (bauul-rocket jump too, but I don't worry about that). Rocket jumps can lift the player about 20 cubes, maybe even a bit more (normal jump is 4). Consider this with regards to stopping shortcuts and also the player getting stuck, or jumping out of the intended play space when additional areas are used for aesthetic purposes.

2. General -- gameplay ..............
a. Single player levels get their difficulty from a combination of scarcity of resources and monster challenge. One can get hit, but only much since there's limited health. One can not shoot wildly, or waste more valuble types of ammo on lesser challenge parts, but at other times it is more important to think about staying alive. Monster challenge is increased by groups of monsters, ambushes and surprises. Both the positions of monsters and the positions of powerups force the player to move around, as well as the need to progress through the level.

It is generally desirable to require the player to transverse the entire level and encourage the player to kill all or most of the monsters even on a level where the the main goal is to reach the end (see Endings, below). Sometimes an experienced player with forknowledge of the level will be able to "run" the level, running by most of the monsters instead of killing them, but this becomes difficult when the player is exploring for the first time. Besides, the ammo is there, the only reason not to use it is when trying to finish the level too rapidly to use or collect all of it. To this end, often multiple goals are involved that unlock additional parts of the level. The primary means of this in Cube is triggers (carrots) that open tagged walls (simulating doors, but actually in some ways more versatile though less animated). Triggers are the universal switch. They can cause a need for the player to travel into multiple discrete areas (possibly in optional order), and also to travel to multiple areas of a large area (instead of running straight for the exit). The other type of switch is monsters themselves. A large, powerful monster(s) blocking the exit of a room will be difficult to fight without clearing the room first. Cube also has no means of closing doors, but a passage can be blocked later by opening doors to a prohibitive number of monsters to guard it.

Related to this, it may sometimes be desirable to provide for one way passage to keep the player from returning the way they came from. For this one can use drop-offs or teleporters.

b. Multiplayer levels have no final destination, so a looping around, intertwined layout is favored. Powerups and favorable shooting positions drive the player to travel to various parts of the level, both overall and to more risky spots. Note the powerups respawn rapidly, so total number should be limited. Size varies with intended number of players.

3. Endings. Four ways to end a singleplayer level:
1) original method: kill all the monsters. Can be problematic to make this possible in complex levels. Avoidance is not rewarded. Can still be good. Stats are displayed during intermission.
2) script method: provide trigger scripted to go to another level (or possibly repeating). No intermission.
3) end trigger: uses fast spinning carrot (example: newent trigger 99 2 ) for ending which automatically ends level. Stats are displayed. Requires Cube 10/03 version or later unless secondary end is provided (method 2).
4) Dead end.

Note #3 is not the same as using a fast spinning carrot with a change maps command scripted to it, which is still method 2, and skips intermission.

For multi-map episodes, a script is needed to forward play to the next map. This command is used for 1 and 3:
alias nextmap_<thismap> <nextmap>
... if the maps are in a folder off of packages other than "base":
alias nextmap_<folder>/<thismap> <folder>/<nextmap>
... while the following is used for method 2:
alias level_trigger_<triggernumber> [map <nextmap>]
... note the trigger alias also can trigger other things, including switching game modes from SP to DMSP.

To avoid the a kill all the monsters end (which can happen anywhere in the level), place some monsters where the player can't reach them. To avoid the monsters remaining message, place 6 or more where the player can't get them. Some maps allow this ending, but add an end trigger in case some monsters are missed.

4. Use of heights can make for dramatic effect. There are some difficulties, since extreme heights or depths result in working in a hole in the surrounding ceiling or floor. It helps to start with an overlarge hole and build in it. Otherwise, you caould have trouble even getting back to the section later. Also, you can make a wall by, for example, making a hole in the floor and then lowering the ceiling into it. However, for performance considerations, this is not a real wall -- a solid wall should still be used. See also "savemap compression effects" above.

5. Playtesting. It is desirable to test a map well. It is hard for a mapper to test his own level. The map will be easier than for others and the mapper will avoid doing stupid things and generally not test for every potentiality. Test for technical issues and also just to see if it's fun! For the latter it may help to get drunk or something to get some space from it being your own creation ;). Enlist others for final test if possible.

Large levels make testing more lengthy and difficult ... one reason to divide large projects into multiple levels.

There can be some variation of play on different computers. Slow computers cause a slight increase in difficulty due to slower feedback in aiming, even though the player and enemy move the same speed in all but the most extreme cases. Fast computers make it hard to test for the limits of acceptable performance.
.

IV. Extras

Reduction of wall fog artifact in tall rooms This tall room produced this artifact: the view distance is long, due to height, yet fog affects whole vertical wall, including nearby wall at same height as view. The effect increases when looking up or down and goes away when looking horizontally, which looks odd (which might be OK, but it's excessive here). This artifact occurs rarely, I think is LOD dependent, and its noticability varies with texture colors, but it can happen.

"Original" Strong fogging effect here. Starting at bottom left, strong fog of room entrance at bottom, solid wall, entrance to room towards left, solid wall ...

"Fogproofed" Here all solid walls have been changed to a partial lower and upper wall meeting at a slot at mid-height, with solid wall behind. These have a slight fog. Other sections are entrances at various heights and are unchanged. (also I changed a tag which changed the upper wall texture at top right and its fogging.)

feedback is desired!
email: spentron@draac.com (or use form)

CUBE LEVELS     CUBE GUIDE     BACK TO MAIN

Copyright 2003 Bill Spencer.