forums.smartfoxserver.com

Hi all,

I'm very new to SFS2X (last friday), so apologies if these questions seem banal. I've read through pretty much the entire documentation, but if I've missed the answer please just direct me there and feel free to call me an idiot!

So far I've done a basic client and extension set up so I can move something around in my flash using the keys and the co-ords are sent to the server then broadcast to the room, and then reflected on my colleague's screen and vice versa. Which seems to be a nice proof of concept for what I want to ultimately do.

It has however raised a few questions. The most obvious is how often should I be sending messages to the server? At the moment it's firing off a message every 200milliseconds and as expected the animation on the other screen is very jerky (5fps). However this will eventually be going on a very busy website so I don't want to set myself up for problems in the long run by sending too many messages.

Is that even the best way of doing this? I move my character around in real time, then a timer event in the background grabs the position and fires it off to the server at set intervals. Or should I be doing it entirely differently?

I've looked in the Battlefarm example and it talks of queueing messages, but that seems to refer to a situation where messages are arriving faster than the animations can complete, so it drops interim movements. I'm more concerned about the other end of the spectrum, where I'm not getting enough messages because the server is being slowed down. Is that even feasible or am I worrying over nothing?

Basically it seems I've sort of got the basic mechanical understanding of what follows what, but I'm not sure of the logic I should be implementing.

Are there any guides which talk about best practice for this sort of thing or is it more of a suck and see?

Thanks in advance for any help,
Si

You should stick to sending only key information to other clients.

Don't send it on a timer based event. Instead, send the information once you have a "new position" set to the character. This way you will reduce a lot the amount of data sent.

Probably this will change a bit your logic, but this is the best practice!

To specifically address your character movement, if you're not running any sort of pathfinding (like A*) and its just normal updating of an avatar's position you should use some sort of predictive movement model.

What I would do (feel free to correct me anyone) is send the message the avatar has STARTed moving, including the direction. Account for your latency and have the receiving clients execute movement that you just slowly update with additional packets containing coordinate data. Be sure to include a STOPped moving msg with the final coordinates.

[START]->[COORDS]->[COORDS]->[...]->[END]

In between each step just interpolate. If the response is too slow or the movement too fast you'll of course still see some sort of jerk in your smooth interpolations, but you can account for this based on how your characters move, the normal distance they're moving, and the speed they're moving at.

Play with the amount of updates you fire as well, and the time between. You'll find a good balance and may be surprised at how many concurrent users you can have pathing around with a good amount of accuracy.

Search on the web for this sort of algorithm and you'll come across a lot of stuff.

Note:
OpenSpace (the isometric engine that uses SmartFox) pathfinding uses A*, and so all they need to do is send the new coordinate based on where the user clicked to move his or her avatar too. This allows them to move the avatar independent of its "actual" or true position.

Thanks guys.

pauloamorimbr, thanks that makes a lot of sense. I've changed my logic so it now only broadcasts the position if it has changed from the previous one. Cuts down on a huge amount of traffic.

Gloryride, that sounds complicated but bloody genius! It wouldn't work on all the games I'm looking at (for instance electronic tag/tig where you're trying to catch the other player and they're making erratic evasive manoeuvres) but as a general theory it sounds brilliant. I'll go do some proper research into this.

Thanks again.

Just for you to know, Gloryride said the same stuff I tried to in more developed way!

But it DOES varies from game to game.

Anyway, as a general rule you will ruin your network if you try to send every frame/animation/position/effect/whatever everytime through the net, so the commom sense (and some patterns that I don't know by name) says to isolate whatever you do when your main user hits a key or does some action.

This way, you only send over the action done by some part.

The general rule is something like:

- You store a "world image" on server
- Every client knows how to create the world from the "world image"
- Every client knows how to modify this world based on events
- Events are generated by other users or server logic and are dispatched from server to all clients.
- Clients receive the event and modify their worlds. (and so on...)

Now...whatever logic you gonna implement on your clients or server can fit on this rule, using pathfinding or whatever.

Good luck!

Hope it helps!