To view the documentation from the current version of the game instead, click here.
AssaultCube is based on the FPS Cube and so (apart from all the changes and also the backports from Cube2/Sauerbraten) it works in quite the same way as Cube did.
The AssaultCube/Cube engine is simplicity itself. The whole map consists of a large 2D array of "cubes", each with a floor and ceiling height, textures (for floor/ceiling/wall) and other properties. These cubes are grouped 2x2 at a time recursively into a "quad tree", which is used to hold bigger cubes which can be rendered faster. For those who have edited doom, this is very similar to having a lot of square sectors but at overlapping sizes. This results in a map that can't have room over room (yet), and is pretty cubic, except for the odd slope/slant here and there.
The floor size of a single unit (single cube) is similar to about 16x16 units in games such as doom & quake, so a staircase step is usually 1 unit, a wall 8 units high etc.
AssaultCube/Cube renders this world by first determining which cubes are visible using a "dynamic occlusion culling" algorithm and frustum culling. You can see the effect of this when you switch to edit mode (E), and then fly out above a map: you'll see parts of the map dropping away as you move. The remaining cubes are then rendered in their most efficient size (i.e. cube will render a mixture of 1x1 2x2 4x4 etc. size cubes, depending on whether they have the same properties: height, texturing etc.).
If you are on a fast system, or you are playing a simple/small map, AssaultCube/Cube will simply render all of these visible cubes (this is indicated by LOD at its maximum of 250 on the hud). AssaultCube/Cube can however make complex maps run fast even on slower computers by a technique called LOD: this will render cubes that are further away using bigger approximations (2x2 and up), even the properties of the constituent cubes don't match exactly. This reduces the amount of polys to be rendered tremendously, and thus allows even slow machines to have a consistent frame rate (cube will adapt the LOD figure every frame to aim for the fps you specify). The downside is of course, that if the approximations are visible closeup, this can lead to ugly graphical glitches (this is called "popup" because it changes as you move). So in the end, the choice is up to you: good FPS or constant visual quality (most engines only cater for the latter).
You will notice that AssaultCube/Cube plays better on a high ping connection than most games out there. The reason for this is that many things in AssaultCube/Cube are done clientside, not just movement (as is common in games today) but also aim (the fat-client/thin-server model).
The benefits of this are that the effects of lag are minimised, and someone on a 200 ping can compete on an almost even playing field with someone with a 20 ping, the disadvantages are mainly in that its harder to combat cheating. Recently though, AssaultCube has become slightly more server side to add some cheat prevention into the game, but still does many things client-side. Advantages for server administrators are that AssaultCube/Cube servers use virtually no CPU and very little bandwidth, even with a lot of clients (you can host a 4 player game on a modem!).
It is impossible to completely hide lag however, and these are some of the effects that can still show lag if you or someone you play with has a high ping / bad connection:
If the connection has packetloss. There is no direct indicator of packetloss, instead the "packet jump" figure is provided on the scoreboard. Packet jump says as much as the amount of milliseconds that pass between updates from the indicated player. If it is significantly unstable or very high (>80) then your gameplay may be hampered (players jumping from place to place). Ideally it is a steady 40 or lower. A consistent packet jump is more vital to gameplay than ping.
AssaultCube uses player prediction based on extrapolation using the physics model, in an attempt to be both as up to date as possible with regard to the game state, and as realistic with regard to physics. However, under packet loss this model breaks down and player movement becomes choppy.
If ping is high (either yours or someone you play with), some actions may appear lagged. The effect of ping is generally that the players in a game are effectively playing more and more separate games, as someone with a high ping is "playing in the past". The local effects of this are masked out by client side movement & shooting, but may become noticable across players:
You may get hit by someone even though you are already out of his view. This is because he is aiming at your movements of a while ago, and his hits take a while to arrive back at you. You may therefore be hit by gunfire up to his lag + your lag milliseconds after you leave his FOV. In a similar way, you may get killed by another player seemingly after you killed them.
Item pickup: you may be denied an item if you try to pick it up at virtually the same time as someone else (the server decides who was "first"). Item pickup is server side, only when you hear the sound effect have you actually picked up the item.
Players dying appear lagged. This will improve.
If a player is severely lagged (or you are) he temporarily becomes a "ghost" that cannot be hit (if >1sec packet jump).
All map editing is done internally within the game itself. Press E to enter map-editing mode. In-game map editing promotes easy learning of how to edit maps, as well as co-operative map editing. It also makes testing the map (using bots, seeing how it looks like within the game's environment, etc.) quite easy. Creating a new map is quite easy, but it takes time to learn the skills needed to create one of fair quality.
More information about map editing can be found here.