So I've been thinking of how to implement multiplayer in my vapourware ARPG. The best way (or so I thought) appeared to me to be just doing client prediction by running the same game code on both client and server, but then sending updates from the server and correcting the client. This way there would be no lag on the player movements, but an occasional reset when multiple players interact with the same objects. Delta compression combined with things like room/view clipping (objects that the player can't interact with or see wouldn't be sent to the client, thus preventing things like wallhacks and whatnot) would be used to reduce the bandwidth usage.

I thought about this some more, I realized that this method is complicated immensely if I add scripting into this game. Scripts can add non-obvious and far reaching object dependencies... e.g. I might have a global script that does something depending on the state of an object quite far away from where a player is, which means that the clipping idea I described above wouldn't work: it just is no longer obvious how I would determine what parts of the world need synchronization when I allow scripts with a global view of the world. The only thing that is guaranteed to work is updating the entire playable world, and that might be infeasible.

So yeah... anyone who coded multiplayer games with scripts have any advice? Did you scrap full client side prediction, and settle for a more limited kind? Or the bandwidth requirement ended up not being an issue?

Note that this is an ARPG, and I decided that the latency requirements are similar to those of an FPS... so client side prediction pretty much has to be there in some way.

Yeah, for example, a script might cause the player to shoot a bullet (player 'movement') and after that, knowing the vector of the bullet, the client can predict where it might head and interpolate its position.

I do not think that a script would ever do anything that would not result in some sort of primitive command.

If yours needs to then make those special cases that the client cannot predict, but in cases like that it probably results in an animation execution, where prediction is easy then.

Why would they make jumping and other people's movement subject to prediction?
That sounds more like a bug.

[EDIT]

Oh. You don't mean actual jumping... I'm slow sometimes.

Yes, that's what I wanted to prevent (well, at least in terms of NPCs jumping).

I don't trust the client with anything other than keyboard/mouse input.

Here's an illustration of my issue. I have 3 objects, A, B and C. A is directly visible by the player, while B and C are in a different room and their data would not normally be sent to the client. Now, I have a script that affects A given B's state. B's state also depends on C indirectly and in a way unknown to the script. Now, the original idea was to run the same script both on the client and on the server, and for there to be any hope that it runs the same (without player's input) then we need to send data about A, B and C to the client. The question is... how do I know, given the script, that B and C need to be updated.

Now, I guess the server might know because it can check whether the script is accessing any object's data. Then it can run the same culling algorithm that was run on the player to get other potential objects that might be of interest. I guess that could be done. The bigger issue is then the client knowing everything there is to know about the world... now there can be things like wallhacks because the client is given all this information that it ostensibly needs for prediction to work, but something that the player shouldn't really know directly.

So yeah... at the end of the day it seems that perfect prediction can only work if you trust the client quite a bit more than I think I am willing to. I'll probably use dumb prediction as was described in this thread... if it's good enough for AAA games, it's good enough for my vapourware.

If latency wasn't significant, then I wouldn't be doing prediction.

So you're making a claim that games that use client prediction only do that prediction on the local player characters and not NPCs and remote players? That seems really unlikely to me.

In my game I only predict the local player as well. In my limited testing that's all that's needed. Without any prediction it feels very unresponsive (I do something and it only happens half a second later). With the prediction it feels completely smooth even with 300ms-500ms (400ms + 100ms jitter, that's what I experimented with in my lag simulation as worst case). Other players are of course not exactly where they are, but in a 2D RPG that doesn't matter at all. In an FPS I could see more need for also predicting other players (so you know where to aim).

Uneducated opininion.
You are assuming the script effect is instantaneous. Chopping the actions in predictable parts would help a lot. Even with 'room clipping' there would be little harm done for a player to wrongly extrapolate an NPC, once in a while, when something in another room changes.

It's a shame that you don't actually read my posts. The client will always lag behind the server and there is nothing you can do about it. If anything, trying to predict the future will only cause more errors and paradoxes, especially when dealing with unpredictable humans. I actually described how real shmups handle projectiles in a previous post. The server buffers all the game states from the last second or so. When it receives a time-stamped shoot command from a client, it estimates the state on the client at the time of the shot and checks if there was a hit from the client's point of view. I'm not just pulling things out of my ass. I know that this is how real shooters work from multiplayer modding experience and from having implemented a few of these techniques myself.

You're talking as if recently-arrived player input changes the past and you need to "re-simulate" everything to account for that. Player input only affects the currently simulated state. When the server detects a hit, it damages the player who has been hit. What else could it do?

It's just the only way to get the motion of other players and the props they interact with to look smooth on the client, unless you want to extrapolate their old motion while waiting for the new info to arrive. I guess they do use it to prevent paradoxes. It wouldn't be cool to see a player moving towards you only to see them ducking in a corner the next frame, or to see a player bumping into the wall when they try to pass though a doorway and disappearing from sight on the next frame. And what will you do when the clients shoot these "ghosts"?

I never claimed to know how every game in existance works. I've already made it clear what games I'm referring to when I say that "real" SHMUPs do this and that, so I don't need to reconcile every counter-example with my "expert" knowledge. It's nice that you bring up this particular example, though. This is exactly what arcade emulators do, mainly because they can't do it any other way. Download MAME and Kaillera and see how well it works in practice. Then consider how much better it would work with 20 players instead of 2.

Anyway, I wanted to help and ended up arguing with you, which is kind of ridiculous. I guess all I wanted to say is that if you want FPS-grade performance, check out the time-tested techniques used in games like Quake and Counter-Strike. I'm not saying we should all just stick to that and not try to come up with anything better. I'm just saying that the ideas you mentioned here are neither new nor that great in practice (and I explained why) and it's going to take you a hell of a lot more thought and experimentation to 1up the standard techniques. If your goal is to come up with a revolutionary networking engine, by all means stick to it! If you just want to make a playable game, don't reinvent the square wheel.

I described a general method to detect a hit. It's irrelevant exactly what the server does when it detects one.

My bad. I thought "shoot em' up" refers to games focused on shooting things up in general. I was talking about Quake and Source derivatives. You mentioned somewhere that your requirements are similar to those of a FPS, so it stuck.

I think it's because all too often, when people here ask how to do something, they're just looking for approval of their own predetermined ideas. If you're convinced that your original idea is the way to go, just say so and let's call it quits. You have more context to decide what's better for you anyway.

Agreed. If you don't have hitscan weapons, all my hitscan-specific talk is irrelevant. I'm sorry. I think other things may still apply, though.

Because these things are irrelevant for most Source MP games.

Anyway, the problem with your ideas is that they all involve trying to predict the future. You obviously can't predict the future of other players with any reasonable degree accuracy and consequently, you can't predict the future of things that have complex interactions with players, like NPCs. Not only is it logically impossible to solve the problems you want to solve that way, but you are likely to make them worse by:

1. Showing the player a discontinuous and inconsistent world due the synchonization errors
2. Making the player react to imaginary state generated by the prediction algorithm