New Multiplayer Theory
Miscellaneous Forums/General Discussion/New Multiplayer Theory
So late last night while designing a cool multiplayer physics-based game (one that hopefully I'll actually finish, as opposed to every other time), I was wondering how best to deal with internet gameplay issues such as lost packets and lag. All of a sudden, I was hit with an epiphany. Unless someone else has already come up with this that I'm not aware of, I believe I invented this new technique, and would henceforth like it to be named after me. :)
Anyway, I was wondering... does it actually matter who "wins" an online game? Would it be awful if, say, two people won? Continuing this thought, would it be bad in any way if everyone thought they had won an online game, rather than the traditional one-winner-only idea? What if no one won? The reason for these questions is thus: what if each player's computer receives input (keyboard, mouse, joystick, etc.) from every other player, and the game is computed individually on each player's computer? But here's the catch: when lag creates a problem (i.e. one player sees themselves get hit by a bullet, another sees a miss), instead of trying to fix the problem, you simply let it go? Everyone who sees a player die has him die, and for all computers where he lives, he's still alive. If the player on his own machine dies, and some machines see he's still alive, then on those machines, he either becomes a computer opponent, or dies as soon as possible (i.e. Computers calculate it so he tries to get hit with bullets, etc.). In this way, every player could see himself become the "last player standing," and there's really no downsides, except for the fact that talking smack might be interesting when everyone thinks they've won.
Tell me if you guys understood that, and tell me what you think.
and would henceforth like it to be named after me.
The Buggy Internet Messaging Technique? Somehow I doubt it'll catch on...
I think the name is rather descriptive. I can see how it might work for certain hippie games, but most games revolve around competition, and the purpose of competition is to divide people into unambiguous groups of losers and winners.
I used to program PLCs for a living, and remember coming across one of these thinking the same to myself "Who would ever use a junker?"
http://www.junker-usa.com/eng/1409.aspx
It would be excellent for network players who may be in the same room...Hurrah for the fist fights!
Pretty soon everyone would be playing a single player game using that technique. Since even a single player getting killed on one and not on another would very quickly snowball into everyone (as the "dead" player kills other players and so on...)
This is kind of how GTA worked on the PC originally, the network games would completely go out of sync with each other so you'd have the player on one screen driving around in a car, and on the other screen, he'd be walking aimlessly around the streets.
Major problem is that things would get in an unpredictable state real quick. For example, is player -x- dead or not? If your computer thinks he is but really he's running around doing things, then those actions would have no effect either. It's little bits at first, but things would get further and further out of sync with actions not having the proper reactions, that the game would be next to unplayable in no time.
you'll have a bunch of people playing 1-player games while pretending it's not. the whole point of a network game is the interactions with others, so once that breaks / gets taken away, so does all the fun and challenge of playing a network game in the first place.
With the exception of a *very* few types of games (can't really think of any right now), I seriously doubt this could ever catch on.
Another problem: if each individual computer decides if a hit is really a hit or not, it's also trivial for people to cheat -- one of the tasks of a game server/player hosting the game is that there is a single traffic cop making sure everyones info is consistent with each other.
the 'proper' way of handling lag and such is to use prediction: if a player if running a long stretch from point X in direction Y and you don't hear from him in a short while, assume he's still running that direction unless there is something else in the way. then when you get an update with his real location you normally wouldn't be off by much and you can relocate the character to the proper spot. (as opposed to freezing him in place until you hear again, in which case the jump in location is likely to be significantly larger)
the 'proper' way of handling lag and such is to use prediction: if a player if running a long stretch from point X in direction Y and you don't hear from him in a short while, assume he's still running that direction unless there is something else in the way. then when you get an update with his real location you normally wouldn't be off by much and you can relocate the character to the proper spot. (as opposed to freezing him in place until you hear again, in which case the jump in location is likely to be significantly larger)
I have been having a limited degree of success with a similar topic using a physics engine with cars in a 3D world. I have went for TCP/IP as oppossed to UDP server, which has it's limitations. I'm using 512 byte packets, which can contain info for up to twenty players...
The way I have implemented the control so far is the clients make a control 'request' to the server, only when the server replies i when the client actions the move request. The problem is the physiscs engine has 'holes' in the control information.... so at the moment I'm implementing an 'aging' array which will record when a client has made a control request and attempt to fill in the gaps so that the car acceleartes smoothly instead of the physiscs engine detecting movement for brief periods.....
Yep, my current implementation has a problem with different clients having slightly different versions of whose where... I'm just impressed I've got a B3D physics engine working to the extent that it is with TCP/IP. a UDP Server may make it quicker.... almost sure it would.
While I've no problem with a game that isn't all about winning, this idea doesn't really work. If I'm understanding it correctly, a player that dies on his own machine get to play on, but with the computer artificially increasing their chances to die? However, their original chance to die is based on lag? That's two mechanisms for killing a player off, neither of which are really under his control.
Doesn't really sound like fun. I think creative team games are a more worthy path than trying to make everyone a winner. Plus, people would then just think back through the game to work out who was the "real" winner. If the game had more team objectives, or a specific thing to do that didn't include beating other players, then there's merit in allowing everyone to shine. Putting players in a "kill the other players" situation and then not really delivering on that premise is a pointless exercise.
Unless the idea is for the player to feel like he's won, but for the victory to have no meaning. In which case, why not just play against bots? As you said, the social aspect is nullified as everyone is playing a different game.
Also, in a low lag environment wouldn't it would play fairly normally?
I'm not sure I quite understand you, Glenny-boy. If a player dies on his own machine, he's done playing. On other machines, if for some reason there's an error and they don't see him die, instead of the player being killed by nothing, he becomes a computer player that either (a) plays on normally, or (b) actually tries to die. The idea is that although there wouldn't always be one "clear winner," the game would be perfectly smooth on each player's machine.
Xlsior, I'm really not worried about cheating at this stage, but thanks for the heads-up. I had forgotten all about that, but if my design is correct, the games would be so casual that cheating is pretty much useless. I also realize that this method would have tons of drawbacks. For instance, as you say, things would get "out of sync" rather quickly (if, that is, there's a lot of lag. No lag = none of this stuff), and the social aspect would undoubtedly be diminished. But one of the good things is that, even if things get out-of-sync, as long as someone's hitting the keyboard somewhere, even if their player's in a completely different scenario on my computer, they're still moving about in ways a computer opponent's unlikely to be able to simulate.
It has tons of drawbacks, and I may never use it, but it's just something to ponder.
It has tons of drawbacks
Yeah, i'de say a lot more drawbacks then the traditional way of thinking would result: how to synch gameplay.
Knowing that the system works like this (which everyone would, very quickly), it would lose interest extremely quick.
This is something that was 'emulated' for me, by a snes 'emulator', using udp packets instead of tcp, where on my screen I would beat the person I was playing via netplay, and they would think they were beating me, until 10 minutes later we realise we arent even in the same game as we completely lost synch long ago.
More pissed off then impressed, and I can't see a better reaction then that to such a system.
This approach makes me think of the extraordinary tangle you can get into when trying to figure out the complex consequences of time travel and changing things in the past. If each person is going off on their own tangent then surely this would separate players from each other and break their participation in a meaningful game? The game would become a 1-player fantasy for each player, so then why be online at all?
Boop ^
Fair enough. I was going for the "if it's fun, don't complain" audiences, but I guess that was wishful thinking.
It's great that you're experimenting with crazy new ideas and hell, it might even work. These are just our opinions. If you have the time, and maybe the money, depending on how far you want to bring it, it can't hurt to experiment first hand.
Imagination has led to success in many cases people never would have expected.
If humans knew that their victory was not real, or not recognised by others, it would lose its fun.
I like your thinking. I've often thought about stuff like this. The crux of it for me is, the player's experience should be all-important. For instance, I don't want to keep dying in a game and having to go back to the last checkpoint and start again. That's okay in certain old-school type games, but in new cinematic immersive worlds, it just pisses me off.
I've been on and off designing a cinematic game where you can pretty much never die - you can make all kinds of mistakes that have dire consequences, but all of those consequences lead to immersive and exciting story branches. So I'm intrigued to hear about brainstorms like this. I think that playing around the boundaries of the normal game experience is the only way we are going to advance beyond space invaders with specular lighting.
I'm not sure I quite understand you, Glenny-boy. If a player dies on his own machine, he's done playing. On other machines, if for some reason there's an error and they don't see him die, instead of the player being killed by nothing, he becomes a computer player that either (a) plays on normally, or (b) actually tries to die. The idea is that although there wouldn't always be one "clear winner," the game would be perfectly smooth on each player's machine.
Ah, right, I misunderstood you. Fair enough. Nevertheless, I still think it would make for an unnecessarily fragmented and unsocial experience for the players. And still doesn't solve rubberbanding issues, etc. that are also a problem with lag.
Rubberbanding? What's that?
Thanks all for the input everyone, both positive and otherwise. I really do appreciate it, and I'm sorry if I came off as defensive earlier.
Oh, and by the way, anyone is willing to use this system (would they want to), provided they pay me 110% of their earnings as royalties.