- Comparing with the Model-View-Controller, the server would be the Model.
- The client can handle much of the animations. The server just sends a "jump" message, and the client animates accordingly.
yep. the client may already need stuff like this to handle latency. say, it calculates the likely animation frame based on elapsed time as part of the LERP process. for client-side animation, it would mostly be a matter of eliminating the use of explicit frame-numbers, and have the client assume that the animation sequence will play in a loop until another animation is chosen.
- Don't forget about the problem of cheating. If the client have control over things, they are fairly easy to hack. Even if the average player don't possess the skill to hack a binary, it is enough with one person doing it and giving away the result.
noted. the partial idea here though is that if most of the game-logic code is sent via "stuffcode" events, rather than part of the client's binary, it would be potentially harder to hack, but there is always the possibility that the client could rig up something to load their own script-code designed to hack the script-code sent by the server. (sending VM bytecode is also a possible option, but it wouldn't likely be that much harder to hack).
possible cheating though may just be a price that would need to be paid to support larger numbers of connected clients.
ADD: I went and added "stuffcode", but security is still a possible concern, which is part of why it wasn't used previously... basically, the concern would be WRT the possibility of user-run or hacked servers sending malicious script-code fragments to the clients. note that the script VM does include some language-level security features "inspired" by the Unix security model. probably also relevant would be defining a mechanism whereby network messages can be passed to script-code handlers (probably via handler registration).
- If the server controls the player movements, the client will need to use some kind of interpolation or extrapolation to get smooth movements between updates. This may be needed anyway when displaying other players or monsters.
this part is already done.
currently, server-side player movement is used.
the server does player movement and the client predicts it.
the alternative being that the client could do it, which would mostly save on the cost of all the server-side collision checks.
it does lead to an increased risk of latency-induced interpenetration though (where latency allows multiple entities to be in the same location).
- To determine if a bullet or arrow hits a target requires effort. Not hard for a few of them, but quickly very hard for MMO.
- If the client decides who or what is hit, there are time lag problems. The monster may have moved on the server side. If two players shoot at each other, who decides the winner? This can require complicated hand shaking.
yes, this is also why it could potentially be moved to the clients.
each client would shoot, and from their POV, each shoots the other, messages propagate, and both take damage.
this should work ok since probably explicit quickdraw isn't going to be a game mechanic.
this would likely be more of an issue for slow-moving visible projectiles (like rockets or BFG or similar), which would exist as actual entities, and so would likely need to remain on the server (as would probably any monsters or NPCs).
- Using a time stamp on chunks can be good. In my game, I use a checksum, for the same purpose. That way, reversible changes will require no updates. And small single changes can be broadcasted as delta.
yep. there could be per-chunk timestamps, and per-region timestamps, and regions will be based on the most recent timestamp.
presently, deltas are mostly done via dirty-bits, and the whole world is sent on startup, which isn't necessarily good if long-term client-side caching were used.
a minor question is that of the ideal timestamp format. (real-time absolute, vs real-time relative, vs a version counter).