The first version I produced maintained client state locally. The client would "tell" the server what its location, velocity and rotation were and the server would broadcast this to other players in the area. This worked fine but was worrying from a security point of view. When adding asteroids and collisions I discovered the server needed to caculated the collision results and hence needed to reset the clients position and velocity. So I then had this problem of knowing which side (client or server) had the appropriate and accurate information about the players position.

Since then I've started work on the MMO version, and decided to look at the networking again. I've just implemented a version where the client maintains only its controls. The client "tells" the server if its thrust, rotating or firing. The server runs all the players updating them as appropriate and broadcasts the results to the players (including the original client). This give me a wonderful central control of the world but at high latency its going to give the player a lack of control of the ship.

I was wondering if there is a more appropriate half-way house, or if I just have to choose between the two.

So there are 2 views that you described:1. Simulation all done on the server 2. Simulation all done on the clients

There are advantages and disadvantages to both schemes. You asked if you can do some of the simulation on the server and some on the clients. I think thats valid.

This is one of the subjects that I am currently looking at for my Master's Thesis (I haven't nailed this down yet though).

So something to think about for the combined thing (oh yea, how you break it up is dependent on the type of game)...Do all AI on the Server (treat AI/NPC's like human clients on client side).Let Clients do their own movement collision detection - just update server of their location.

This can be done multiple waysWhen attacking, the attacker can determine if he hit somethingThe attackie (is that a word) can determine if he was hitOr the Server can determine that the attacker hit the attackii

Also note, security is an issue whether you do 1, 2, or combination of them. The benefit of doing 1 is that since the server holds the current state, then if the client does something invalid then only that client's simulation is invalid, this doesn't effect anyone else.

So to attempt to answere your question, I really don't know. I hope to find out...

Doing everything on the server is certainly your most secure option and the easiest way to go as far as synchronizing multiple actions between players. Doing things on the client can reduce latency, thereby increasing responsiveness, but also leaves you open to cheating.

If your game is such that you actually have the option of doing it in either place (your not CPU restricted on either side) you may want to consider running as much of the local simulation as you can on BOTH the client AND the server and then periodically reconcile the client with the server as it drifts out of sync. In this case, the server is the ultimate authority so you always assume the server is right (just as you would in the scenario where only the server is running the sim) Obviously, there are some tradeoffs to doing it this way, but there have been a number of articles on doing this adjustment gracefully, so this may be the best way for you to go. I'll poke around my bookshelf and see if I can find a couple good ones to point you to.

Im an expert, by no accounts on such an issue. but Im sure you've already looked em up.

I think it depends on the type of game, the architecture you're supporting, the pace of your game, the amount of data that must be synchronised and the inherint network latency.

Im sure you can analyse your system and try hone down your data synchronisation to the bare minimum. Moreover, you can identify which data are continuous or require immediate updates (e.g. velocities) and which data doesnt (e.g. new player login). But Im sure you've done all that.

The simplest solution would be Athomas Goldberg's suggestion which would be to replicate processing on both client and server.

The only other solution I can think of is, writing some sort of rules-engine on the server which determines whether a new velocity, etc. value from a client is "legal" taking into account its previous state and states of other objects in the world.

If you can find a collision which can be only beneficial to client, maybe you can check for this collision in client and if it happens, have server doublecheck that. In this way, you don't have to check misses on server. No reason to hack, because false positives would be catched on server, while false negatives would be a penalty for user.

Of course, you can do this only for things which are clearly beneficial to player. In case of laser/ship, you probably should ask client which fired whenever there was a hit, not the victim

Of course, there is a question of difference of time/position between server and client.

One idea I've been thinking of is to predict local movement on the client (the ship accelerates when you press forward, and turns left when you press left and so), then sending the keypresses and keyreleases to the server with a timestamp.

The server can then run the exact same code as the client, figure out exactly where the client has moved his ship, and be sure that it's all been done "legally".

To prevent rounding errors from adding up, the client can just send it's exact position to the server at regular intervals (timestamped as well, of course), and then the server just checks if the new position is close enough to where it thinks the player is, then uses that position instead.

Hi It's what I had pondered for my game, I wouldn't check *every* client as the plan is there will be too many to check them all , but at some point every client would get checked in a ten minute period for example, this leaves some server cpu for other things, like AI etc, without requireing a cray to run the server

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org