Entity 3D Presentation and Structure


In this paper the entity 3d representation and structure from server perspective are discussed. The in game building (of houses etc) is not covered.

Structure

The representation and structure of entities are relevant parts of server design both speed and memory consumption vice. Entities must be constructed from parts so that it is possible to break them apart or move parts relative to each other (animated entities). It is also necessary to be able to construct parts from small often used 3d models.

Some cases require connecting entities to a central entity but this goes beyong this paper. An example of this could be equipment which are essentially own entities having own state variables and are only attached to some part of entity. This does not work with equipment needing to cover many parts like pants or shirts. On the other hand helmet would be suitable equipment to be realized this way. It is certainly less efficient to have equipment as separate entitities and it is propably better to integrate them as parts of entity 3d model as long as they are weared.

The rules (blueprints) how to build a certain part could be written as proposed in the following picture. Parts can be constructed from both models and other parts.

Illustration of Blue Print System

The proposed syntax follows the atlas syntax and would be thus easily implemented and written to file or database via atlas (Serialization).

Runtime Modifications

During runtime there will be at least three categories of modifications to entity 3d representation:

1) Modification of part/model locations and orientations (Animation type 1). (Example: walking)
2) Adding/removal and changes of parts/models. (Example: Wearing)
3) Changing of selected "frame" of animated models (Animation type 2). The animation of models via coordinate manipulation, face manipulation, and textures is beyond this paper. (Example: Blushing)
( 4) Modification of Model itself. (Example: arrow hole on a shield.) )

Server-Client Considerations

When we allow arbitrary not predefined changes of entity models we cannot predict what client databases should include. It is necessary to send modifications to models and textures to all clients or clients nearby. This creates situation where client approaching new entities always need to check if these entities are made of new/modified models which it needs to download. In practice the result can be annoying for player: You meet a party of new people and your client slows down terribly for little while. Another big problem is that after small game period almost all game objects become individual as they are scratched or polished etc. This will use up all server memory in an instant.

Persistence

What things of models are to be saved when entity is saved. Ideal case would be that the hole state of entity is saved. This could create practical problems with for example running animations which are most likely executed semiautomaticly so that the server does not tell clients when to change animation frame. When entity is saved in the middle of an animation process the state of the animation should be saved and on load clients sensing this entity should be notified of at what point the animation should start.

Most practical approach is propably to save modifications of type 1 and 2.