(This post is basically a duplicate of one I posted over on the gamedev.net forums, just for posterity)
I've been thinking about this idea for networking in Elium for a while. At this stage we haven't even thought about networking the game, so whether it'll become reality or not is something we'll have to see...
Now, the basic idea of the combat in Elium is that it's mostly fast-paced and close-combat: swords & shields kind of thing. You'd have basic attacks like slash left, slash right, stab low, stab mid, etc, as well as corresponding blocks: block left, block right, etc. You'd also have combos (left, right, slash for a spinning attack or something). Because this is fairly fast-paced, my initial thought was that this would not translate to client/server style of networking. You can't really expect to block attacks with 300-400ms of latency!
At this stage, we're only looking at PvE (not player vs. player). So I thought, why don't I just make it so that the client simulates the combat and simply broadcasts the results to the server. The server can do some verification that the fight wasn't totally unrealistic, but from the client's point of view, it'll be completely in control.
So just to go through some basic scenarios, I'll start off with the simplest and move on to more complicated scenarios. Under normal circumstances, the client is only sending movement information for the player under it's control to the server. NPC movement and control is normally handled on the server.
One player, one NPC
When the player gets "close" to the NPC, the server will send the client a message: "you're in control of this guy". So the control of that NPC will pass to the client. The client will get to decide whether the NPC becomes angry and start attacking the player, whether it runs away or whatever. As the fight proceeds, the client will send to the server all the movement information for both the player and the NPC. At this point, the server is in control of only two things: when the NPC (or player) dies, and whether control of the NPC should be taken away from the client.
Control of the NPC will be taken away if the player moves away from the NPC (i.e. if they run away). The server will be running the simulation as well and so it will calculate when the NPC dies and transmit that to the client.
Because the client is in control of the NPC, the combat can be as complex as we'd like: multiple attack moves, blocks, combos, whatever. Also, an NPC in a client's control will only ever attack that player. So if another player comes over to watch, the NPC will basically ignore them until the player it's fighting dies. If the watcher starts attacking the NPC, we get into the second scenario:
Multiple players, one NPC
This one seemed tricky to me at first, but I think if we just stick with the server passing control for the NPC to one client (i.e. the one the server deems the "most deadly") it'll still work out OK. The other players will be seeing a delayed simulation (because of the latency) but it shouldn't matter: the NPC will only be able to block attacks from one player at a time anyway, and if one of the players not currently in control starts to damage the NPC too much, the server can transfer control to that player's client, and the NPC will start trying to block his attacks instead.
This scenario is only going to be common with relatively weak players against a strong NPC, but I think in reality it won't be that common - certainly, we can design the game to avoid this situation and make the next situation more common:
Multiple players, multiple NPC
In this scenario, the server will "load-balance" the NPC so that each client controls an approximately equal number. That way, if 5 players attack 10 goblins (say), the server will transfer control of 2 goblins to each client. The way the AI would work is that when your client has control of an NPC, the NPC is going to attack you, so you'll have to fight off the first two goblins. If you kill them, then the server might decide to transfer two more goblins from one of the other client's to you and you'd have to fend off those.
One player against multiple NPCs is just a special case of this scenario.
Game Design
Now, the game will be designed such that the most common scenario would be the multiple player/multiple NPC one. The idea is that all characters are basically humanoid and you don't have creatures who are insanely powerful compared to the players (so there'd be no point ganging up on a single NPC).
Cheating would be alleviated by the fact that the server is duplicating the simulation, and NPC death is controlled by the server.
The advantage, as I said, is that the combat can be as complex as we like - multiple attack moves, multiple block moves, combos, etc - and the game is not affected by the client's latency to the server.
The downside is that there is a lot of extra uplink traffic from the client to the server when the client is in control of multiple agents. I'm not sure if it would be unacceptable, and I guess the only way to know is to try it out.
The other downside is that it requires a reasonable amount of CPU simulation on the server. Obviously, the server is only simulates a cut-down version of what the client sees (basically just for cheat detection and deciding when characters die, etc). But this is not going to be an MMO game, so I think that's acceptable.
So that's my basic idea. We'll just have to wait and see where it takes us...