   Engine design question: events?
  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 harderto 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?   
  Okay, I'll take a stab at this...Quote:Original post by amirabiriHi,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".I'm not quite sure what you mean by "replicating state" in the context of a single-player game.  Can you explain that in more detail?On the other hand, an event is, by definition, a change in state.  So I would suggest not replicating state at all, but rather sending events across the network that tell the other players' simulations to update their states correspondingly.Quote:Examples of events, or reasons why I'm thinking of events: [...]Those are all good examples/reasons.  I can't really add anything here.Quote: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 harderto replicate the creation and initialization of these event objects.Regarding events propagated over the network, you're basically dealing with object serialization.  I think the easiest way to do this is to have a base event class with a member field for the type ID.  This field would be the first part of any event object that gets sent over the network (the first part of the packet payload, if you will).  On the receiving end, you'll need code that reads in the type ID field and chooses the correct subclass to instantiate with the rest of the data.  The factory pattern is helpful here.Quote: - 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.If your game is a typical client-server game, then both sides will need to create an equivalent object.Quote: - 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.This sounds more like a refactoring task for your existing codebase.  The code that receives all of the events should either know how to handle all of them, or at least be able to refer to the parts that do.Quote: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?It's always best to make games, not engines. ;)With that said, sending events over the network, as opposed to states, is a no-brainer from a performance standpoint.  Events will typically require less space, thus leading to less network lag time and better performance for your game.   ;  The best multiplayer engine design is the most straightforward: client/server.It then becomes obvious both the client and servers are event-based, how can you react to messages you receive asynchronously otherwise?   