Vision of Ephenation
- Use of guilds. This would be a larger group of players, where you know the others.
- Temporary teams, used when exploring. It is more fun to explore with others.
- Use of common territories. It shall be possible to cooperate with friends to make territories that are related and possibly adjacent to each other.
- High performance (compiled language)
- Object oriented and static typing
- A concept of gorutines (light version of threads)
- A very high quotient for "it works when it compiles"
- Garbage collection
It is the server that has full control over all Model data. Player attributes, melee mechanisms, movements, etc.
The world consists of blocks, voxels. This is difficult to draw in real time with high FPS, as the number of faces grow very quickly with viewing distance. Considerable effort was spent on transforming the list of cubes into a list of visible triangles. It is also difficult to make a level of detail (LOD) algorithm that gradually reduce details on long distances.
Another technical difficult with a world based on cubes was to make it look nice, instead of blocky. Some algorithms were investigated that used a kind of filter. As the view distance is limited, there can be a conflict when being underground.
The game engine can't know whether the far distance, which is not visible, should be replaced by a light background (from the sky) or from a dark background (typical to being underground). A compromise is used, where the color of the distance fog depends on the player being at a certain height.
Adventure design and mechanics
|Early version of the game, where a player abused the monster spawner|
|Early attempt to create automatic monsters. This was later replaced with fully animated models.|
As the server is responsible for all object atributes, the clients need to be updated frequently. Player and monster positions are updated 10 times per second. This generates some data, so the update is limited to nearby players. Because of this, the client need to do interpolation to be able to show smooth movements, and the client need to be able to manage stale information about other players and monsters. The advantage of having the server manage all attributes is that it is not possible to cheat. The client source code is available, and it would have been easy to do changes.
Document update history2013-02-22 First published.
2013-02-24 Added discussion about using voxels on the client side.
2013-02-27 Information about entity attribute management and communication.
2015-05-04 Pictures failed, and were replaced.