Networking & Events for a TBS

Started by
1 comment, last by kandie 14 years, 2 months ago
Hello, I'm currently in the design phase of my project, and I'm trying to take a top-view down to an in depth look at how my game will be running, but I'm having difficulties designing the flow between the game events and the networking module. I will be keeping the post free of implementation details when possible, because it's not what concerns me right now. The game, as mentioned, is a turn-based strategy/"combat" one. Not a complex gameplay, each player controls a hero, and they cast spells. Everything in the game is a spell; spells summon units, hurt units or heroes, etc. However, it gets a bit unclear when I'm thinking of this in terms of events and how they will be handled. Let me start first by listing what I'm planning to use and how, I will start by explaining my event module, and through a scenario of a Hero casting a Spell: There are 2 types of events: 1) Game Events, 2) UI Events .. the second propagates the first. GameObjects act as listeners to events, and transmitters themselves. When an event is transmitted from an object, the EventManager enqueues it, then dispatches it to the game Server through the NetworkManager. The server processes the event, then dispatches it to 2 clients connected to it. Once received by the terminal EventManagers, they will be broadcasted to the listeners, and handled as needed. Now in the case of a hero casting a spell to summon a unit, things became unclear to me; both clients need to be in sync in terms of the GameObjects ... so it must be the server's job to: a) create the object and store it b) tell each client to create the exact same object. Do I need to use some global identifier generated by the server for all the objects in game? Because that seemed like the only viable solution: whenever an object is to be created, the server generates a GID, then orders each client to create an object and attach that GID to it. I've been digging a lot for information regarding what should be the server's job, and the clients respectively, but all I could find had to do with action games, with their complexity residing in keeping the positioning in sync, which in my case is irrelative. * Are there any clear guidelines to determine the server's job from the client's? * How do you handle game events, and be sure all objects under each client are in sync in terms of state and object ID's ? * Should I be streaming full GameObject instances over the network (from the server to clients) or should I make the clients somewhat "smarter" that they do it on their own given an ID? Below is a link to an image of the client design diagram I'm planning to use, so far. Please take a look to get a clearer picture of my system, if needed. http://elementum.wdfiles.com/local--files/diagrams/Elementum-Client.png Thank you for reading, and sorry for the long post. Looking forward to your input. /k
Advertisement
Quote:Original post by kandie
Now in the case of a hero casting a spell to summon a unit, things became unclear to me; both clients need to be in sync in terms of the GameObjects ... so it must be the server's job to:
a) create the object and store it
b) tell each client to create the exact same object.
Do I need to use some global identifier generated by the server for all the objects in game?

Yes, it's common to ensure that the identifiers that the server uses for all the objects in the game are the same identifiers that the client uses for those objects. Often what happens is that the client creates the object based on a message from the server, and that message would contain the required identifier.

Quote:
* Are there any clear guidelines to determine the server's job from the client's?
* How do you handle game events, and be sure all objects under each client are in sync in terms of state and object ID's ?
* Should I be streaming full GameObject instances over the network (from the server to clients) or should I make the clients somewhat "smarter" that they do it on their own given an ID?

Generally, the server should handle the game logic, and the client should handle the presentation.

Keeping clients synchronised with the server is usually a case of one or both of the following:
- send events so that an object can be updated in a way appropriate to the event
- send property updates to specify precisely how the object should be changed

Having clients create GameObjects is a special case of the above. The client needs enough information to recreate the GameObject that exists on the server. This may mean the server just has to say "Create a new GameObject of this type", if all objects of that type are identical. Or the server may have to say "Here are all the properties of a new GameObject" and send every single property necessary to construct that object. Which you choose will depend on the object.
Thank you for your reply, that pretty much cleared it up for me. I am already using Factories for creating the objects, given a GID and a "model id"; when the factory receives the model id, it clones a copy from its model pool and assigns the identifiers to it. That will fit perfectly with this solution, since I'll only have to send the GID, model id, and the position.

Maybe I'll have to enforce some sanity checking from the server-side on the rest of the created object's attributes, afterall, or just send it all (it's not much data, anyway) but I'll see to that.

Thanks again,
/k

This topic is closed to new replies.

Advertisement