The 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 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 is results in a map that can have
no room over room (yet), and is pretty cubic, except for the odd slope/slant here and there.
</p>
<p>
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.
</p>
<p>
Cube renders this world by first determining which cubes are visible using a "dynamic occlusion culling"
algorithm and frustrum 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 wether they have the same properties: height, texturing etc.).
</p>
<p>
if you are on a fast machine, or you are playing a simple/small map, cube will simply render all
of these visible cubes (this is indicated by LOD at its maximum of 250 on the hud). 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).
</p>
<h2>Networking</h2>
<p>
You will notice that Sauerbraten plays better on a high ping connection than most games out there.
The reason for this is that just about everything in sauerbraten is done clientside, not just
movement (as is common in games today) but also aim (the fat client / thin server model).
</p>
<p>
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. Further advantages for server admins are that sauerbraten
servers use virtually no cpu, and very little bandwidth for a lot of clients
(you can host a 4 player game on a modem!).
</p>
<p>
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:
</p>
<ul>
<li>
<p>
if the connection has packetloss.
There is no direct indicator of packetloss, instead the "packet jump" figure is provided on the hud (use "showscores").
Packet jump says as much as the amount of milliseconds that pass between updates from the indicated player.
If it is extremely variable, or is 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.
</p>
<p>
Sauerbraten uses player prediction based on extrapolation using the physics model,
in an attempt to be both as up to date as possible w.r.t. to the game state,
and as realistic w.r.t. to physics. However, under packet loss this model breaks
down and player movement becomes choppy.
</p>
</li>
<li>
<p>
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 seperate games, as someone with a high ping is "playing in the past". The local
effects of this are masked out by client side movement & aim, but may become noticable across players:
</p>
<ul>
<li>
<p>
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.
</p>
</li>
<li>
<p>
item pickup: you may be denied an item if you try to pick it up at virtually the same time as someone else (server decides who was "first"). Item pickup is server side, only when you hear the sound effect have you actually picked up the item.
</p>
</li>
<li>
<p>
players dying appears lagged. This will improve.
</p>
</li>
</ul>
</li>
<li>
<p>
if a player is severely lagged (or you are) he temporarily becomes a "ghost" that cannot be hit (if >1sec packet jump).
