Jump to content
  • Advertisement
Sign in to follow this  
amirabiri

Engine design question: events?

This topic is 3414 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
Okay, I'll take a stab at this...

Quote:
Original post by amirabiri
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".


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 harder
to 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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!