Original Post
Hi, I am currently in the process of designing my second engine. My first engine was good for single player, but didn't do so well for multiplayer. One of the things I've noticed when trying to switch from single player to multiplayer, is that replicating state isn't enough. It seems to me that it is necessary to support both replication of state of a given object, but also to support replication of "events". Examples of events, or reasons why I'm thinking of events: - Spawn actor, actor destroyed, fire laser, collision, etc. - UI events. These would not be replicated, however beside replication they resemble other events. - The handling of the multiplayer game itself seems to map well to events: new connection, player connecting, player connected, etc. - It is far easier to replicate events than to infer their occurrence from changes in a replicated state stream. - With time-based lag-compensation techniques, events are essential. I.e I'd like to replicate the event "player fired" with a timestamp of when that happened, so that the server can compensate for the lag when processing the event on its end. This is impossible to do with simple state replication (of a flag in this case), and requires events. - Replicated events come from the network while the origin could be something else. However in both cases they should be handled similarly. Events lend themselves to this abstraction. For example, let's say "Player started turning right" is an event that is generated by the keyboard on the client, but received though the network on the server although in both cases the game logic (beyond lag compensation) is the same. It follows that ideally the same piece of code should handle both regardless of the source (keyboard/network). Some problems I can think of with an events-based approach: - Events require information (mouse position, spawned actor details, the colliding objects, etc). Each event requires different information. This implies different classes for different types of events. This makes it harder to replicate the creation and initialization of these event objects. - There might be an impact on performance: instead of creating an object, I now generate an event about its creation, then some other piece of code handles that event and actually creates the object. - Events may introduce delays and asynchronization. For example one piece of code generates an event that says that a certain object needs to be created. This piece of code, in that point in time, is the wisest about how to initialize the object. However, instead of doing so some other piece of code, potentially in the following game tick, is the one the actually creates and initializes the object. So my question is if you guys think it's a good idea to design a game engine on events which are then processed and optionally replicated. Or if that is not a good idea and if there is a better design for these goals?
