n00b-Q: sending frame data

This is a bit more meta-game-theory than SGS specific but, as I’m familiar with a couple of different ways of doing this, in general, I guess I’m asking in a “what do you guys find works best in the SGS architecture?” sense.

How do you guys send frame data?

What I mean is: do you just set up a periodic task every (1/FPS ms) to send frames to each player, and put one such task in each PlayerClientListener (whatever it’s called)? That seems like it could become a lot of tasks rather quickly.

Similarly, do you just set up a main task (or 2 or 5 or whatever makes sense) to update the simulator, separately from the player-frame-data-send task?

Etc.

I’m not asking for to-the-code details, but more of a broad, white-board description of what trade-offs you guys have made, and why you decided the way you did.

Thanks!

Since players tend to interact with each other or interact with common assets, IF your game is structured around periodic “moves” its best to figure out what the organizational “group” is that has to be handled in-order or interacts with common Managed Objects and handle them all in one “tick”.

In the “Bunny Hunters” game I’m writing (think Bomberman style) there are 4 players per “Game Board” so I do my “moves” as game board ticks that update all of the players and AI and such in each tick. Each game board ticks independently of all others.

In an MMO you might let players and monsters move free… players moving based on player data events, monsters moving based on an AI “tick:”. When they get into combat you might then transfer control to a “combat clock” that ticks off the more rigorously structured combat rounds.

In general the goal is to find your areas of parallelism and make sure that the system can exploit them but also avoid manged object access conflicts as much as possible,