User defined objects

These are the design ideas for user defined objects (UDO). A user defined object is something that the player can design, upload to the server, and then instantiate anywhere inside the players territory.

Client side

1. Define a data structure that knows the way an object is assembled. This would be the physical representation of the object, and so belong to the Model. We should use a similar data structure in the client as in the server.
2. Set up a object design mode in the game client that enables the player to create objects. The GUI for this need to be discussed further.
3. The state of objects, in the client, need to be managed by a new class (belonging to the Model side of the MVC). Something similar to how monsters are managed today.
4. Add drawing logic in the client (this would be based on the BlenderModel as already decided).
5. The new objects should be built from cubes, just as the main world is. At least for a start. However, they don't necessarily need to use the same block types (bricks, stone, etc.). But I think we will start with the same representation. The limitation here is that only 256 types of blocks can be used.
6. Define a simple type, or sub class, of object that would be the first target. That is, not a fully capable transport ship, but something much simpler. Maybe a small inanimate thing, just to show. If scaling is allowed, and possibly the use of smooth presentation of blocky objects, then it should be possible to create small nice looking things.

Communication protocol

1. Extend the communication protocol with a mechanism where the client can tell the server about the assembly of an object, and vice versa. For now, I think the same message can be used in both directions (between the client and the server).
2. Extend the communication protocol with object state information. That is not the complete object assembly, but rather the position of the object, rotation, etc. This need to be a compact message, as it may be needed to sent frequently (to every near player, every time the object changes state). Currently, players and monsters are update from the server 10 times per second (if they move). I am not sure what is needed for this new type of objects.

Server side

1. Add logic in the server for loading and saving the assembly definition of objects (to the MongoDB I think we said).
2. Add logic in the server to manage objects that are present in the game. There is also a need to throw away instances of objects if no player is nearby (just like monsters). Otherwise, the memory use of the server would grow too much.
3. A mechanism is needed on the server for object instantiation. That is, if there is a defined object, a drawing so to speak, then it shall be possible to make an instance of it.

#Design - Client Side

1. UDO representation(common to server/client): The UDO is represented as a list of blocks. The blocks that belong to the UDO are stored as offsets from the chunk(stored relative to the chunk). Now, we have two representations of the UDO. a) Model::UDO b) View::UDO

• Model::UDO: Contains the data in which the blocks are stored as relative offsets to chunk. This data cannot be used for drawing with the view. It also contains the ID of the object. This is 0 when the player creates an object first time, but will get a unique number when the client receives the object definition from the server.
• View::UDO: Contains data that can be used by the view for drawing. This data needs to be in a format/mesh such that BlenderModel can use this for animations.