Our game play structure relies on three core components: Entities, Actions, and Server Events. The main reason for this abstraction is to allow easy communication with the server. By wrapping our core components in well-defined structures we can easily expand them while ensuring that they can always be serialized and deserialized correctly.

Entities

Any object in our game is an entity. This includes a spaceship, its weapons, and the components it holds. Entities can have children and a single parent and will usually have a top entity that is a Player entity. Entities can also hold properties, which are objects that wrap around data types, but add the ability to easily serialize and deserialize them.

All entities are stored in an Entity Manager and are identified by a GUID as their ID.

Actions

Operations that act on entities are actions. An action will have up to two parts, one to run on the client side and the other on the server side. This allows us to quickly do things like check ammo on the client before sending a “Fire Weapon” action to the server and then concluding on the client by playing the visuals and sound effects. Like entities, the actions can also have properties.

While we support the concept of client-side only actions, these are not very common. Operations that are purely for UI purposes can usually be implemented directly as methods that acts on local data.

Server Events

While actions go from client to server, the events go in the opposite direction. They are our server’s way of notifying the client code that something interesting is happening. They also contain properties and are handled by an event handler which a factory creates given given the incoming event. We have different event handler factories based on the situation to allow us to handle the same event differently, for example in different screens.

Examples of events are getting hit by a projectile or getting a message from another player.

Comments

comments