5 ms·

The hardest part is that most game engines are not designed to be networked in this way. Find an open source physics engine that natively supports teleportation

by tinco 12y ago

The hardest part is that most game engines are not designed to be networked in this way. Find an open source physics engine that natively supports teleportation, easing and prediction, they're not there. UE4 is the first engine I've used that seems to have a very nice multiplayer API, and it's only been out for indie developers for a couple of months. So the hard part is not devising the networked scheme, it's building a whole game engine (or thoroughly modding one) afterwards, at least in my experience. I was working on a multiplayer racing game project (like GTA2), and my approach was to run 2 physics engines in parallel. One physics engine would always be authoritive, and be in sync with the server, but because of the lag would always be a frame or two (or more) behind. The other would be working on predicting what is going to happen. Every frame snapping back to the authority, and then applying the (predicted and user) inputs over that. The actual position the user would see would be an averaged position between the current predicted position, and its previous predicted position (to prevent too much jitter/snapback). If you've got a better scheme to do networked physics I'm all ears :)

Cakez0r 12y ago
Have had this problem too with making a racing game. We ended up making remote entities move independently of the physics engine (I.E. cars for remote players were just static objects that had their positions manually updated). This worked to some extent, but we had to do some fudging to make collisions work somewhat realistically.
- Igglyboo 12y ago
  Are you saying that the client determined their own position? How did you account for people cheating?
  - ownagefool 12y ago
    Sounds like you never played Red Faction. I love that game but watching people fly around the map, clip through walls and shoot 1000 rockets a second (much to the dismay of my graphics card) wasn't the most pleasant experience.
  - drostie 12y ago
    It doesn't sound like that at all. The person you're replying to just said that they were sufficiently frustrated with the physics engine's treatment (or lack thereof) of network phenomena that they bypassed it completely, telling the physics engine "this car is just a static object at this location." That doesn't mean that there wasn't some other process which determined how that number was generated before it was handed to the physics engine -- either via a central server or something more distributed. Speaking of the latter, I wonder whether consensus algorithms can be pulled off with a small enough bandwidth that you could incorporate them into a high-intensity game. Your consensus bandwidth is not the slowest-peer bandwidth but rather the median bandwidth, which can be much higher -- the question I'm asking is whether there's a good way for a slow peer to say, "hey, to improve my performance by reducing my bandwidth/latency, can one of you guys act as my server?"
    - Igglyboo 12y ago
      Possibly, but what about collusion? This would be a problem especially with team games, one team has an extra player so 51% so they come to the consensus that everyone on the other team is always dead.
      - drostie 12y ago
        Well, I don't think it's a huge problem. Maybe I'm wrong. I feel like it's core to the idea of "let's go play a game" that we largely agree on its rules -- and if more than half of us deny those rules, they are going to go off and play a different game; we won't want to play with them. So one response is for the reference client to simply say "if I see too many totally crazy things I'm just going to disconnect and ignore those peers who were saying that for a while." But is it really a problem? You've got to imagine that we've got this red-vs-blue team game with two clients: ref and hax. The only way Red will be able to do this is if the red+hax population is greater than 50% among the server-population, because all of the ref clients will reject bad physics. So suppose we've got a game of 21 people. 15 of them use the hax client (~70% participation), and we'll just assume there are no low-latency peers for the moment. The red team gets 11 consistently; the blue team gets 10. Then assuming team assignments are totally random, there's still only an 0.12% chance in any given game of the red team actually having 11 hax nodes and dominating the game. In the vast majority of the games they'll have to play honestly. And that's with 70% of the peers trying to game the system. (It gets a little worse if we include low-latency peers. So let's assume that there are 4 and they get distributed unevenly, 1 on red, 3 on blue. The consensus threshold is now 9. Assuming we lost 3 hax clients in the process, 16% of such games will be vulnerable to your attack. That's enough to make things frustrating.) Meanwhile, the hax-client may make things unplayable unless it behaves like the ref-client when it's not in the majority. The basic point is that the red-vs-blue partition makes those attacks not a concern. But when that partition doesn't exist, then there's a bigger problem. So the more concerning thing for me is denial of service. I don't think I'll get 70% of the legitimate customers to try to hack the game, but I do think that IPv6 support could lead to one person having a block of 10,000 IP addresses being able to take the majority of peers in all of my games. Okay: they may not have enough red peers to win the games for red or enough blue peers to win the game for blue, but suppose that their goal isn't to win, but just to shut down the system. Suppose their modified client, instead of saying "everyone on blue suddenly dies", says simply "everyone suddenly dies". Now 99% of games become unplayable, all of my legitimate users rage-quit, and I'm totally screwed. So the problem is that sign-ups must be relatively closed and everyone needs to be able to validate that independently. I'm not sure how to solve that in a distributed way without some web-of-trust thing going on.
  - Cakez0r 12y ago
    The clients determined their own position, yes. It was not a peer to peer game and the server ran sanity checks on what the client was telling it (is their velocity acceptable for the car they have? did they accelerate too fast? are they in an area of the world that should not be accessible? etc) which worked pretty well. We deemed it was too resource intensive and too slow to run a physics engine on the server (it was a "massively multiplayer" game).
aaasux 12y ago
> UE4 is the first engine I've used that seems to have a very nice multiplayer API I'm working on a triple a ue4 title and i don't like ue4s replication system at all. It's a step towards making the networking concerns invisible, and that always seems like a mistake to me. If the protocol for keeping clients in sync were more explicit, it would be easier to tightly control what and when things get sent over the network.
- forrestthewoods 12y ago
  Is it roughly the same as UE3? It was usable but god damn did it make a lot of things difficult.
- JabavuAdams 12y ago
  Are you able to contrast it with Tribes' / Garage Games' model? What about RakNet? I'd love to hear more.
jmorrison 12y ago
First time post from long-time lurker. Be kind. Back In The Day (just to show how ancient I am), I personally debugged the first peer-to-peer (vs client/server) networked simulation protocol on the DARPA SIMNET project: http://en.wikipedia.org/wiki/SIMNET http://en.wikipedia.org/wiki/SIMNET Interesting stories notwithstanding (anybody else here ever got to drive/fire a tank, and have fellow engineers get dosed with CS gas, as part of a software engineering job?), when time came to standardize this research protocol as: http://en.wikipedia.org/wiki/Distributed_Interactive_Simulation http://en.wikipedia.org/wiki/Distributed_Interactive_Simulat..., we tried to get them to generalize the protocol thusly: http://www.google.com/patents/US5623642 http://www.google.com/patents/US5623642 The work was supported by a DARPA small-business project, so the IP was left with the company in hopes of commercializing it, and maximizing dissemination. The attempt to get the ideas incorporated as part of the standard was singularly unsuccessful. More's the pity, as I think it would have really helped make the simulations more capable of simulating a wider array of physical phenomena. The commercial uptake was equally unsuccessful. I experienced some culture shock when proselytizing (again, unsuccessfully) at game development conferences.
- angersock 12y ago
  As I recall...doesn't VBS/VBS2/ArmA use this? Anyways, shoot me an email--have some questions not suited for this format.
archagon 12y ago
Interesting. After reading this Gamasutra article[1] on how online multiplayer can literally add years to your development time, I got a little scared. Will UE4 allow developers to avoid this setback? (On the other hand, developers like Carmack and Michał Marcinkowski only took a matter of months to add it to their games, and they were among the first. So maybe it's not as big of a deal as it seems.) [1]: http://www.gamasutra.com/view/feature/217434/the_ups_and_downs_of_doing_online_.php http://www.gamasutra.com/view/feature/217434/the_ups_and_dow...
- Ogre 12y ago
  I only skimmed it, but I didn't see anyone in there who took years. They were all on the order of months. Entirely possible I missed it. That said, adding networked multiplayer to a game is very difficult. But designing a game around networked multiplayer is not nearly as hard. Single player or local only multiplayer games can get away with lots of assumptions that completely break multiplayer, and detangling all of those assumptions is the most time consuming part of converting a game. If you do it "right" from the start, you don't ever allow yourself to make any of those assumptions and everything just works. If you know you're going to build a multiplayer game, then write it as a client server architecture from day one even if you know you're not going to play with other people for the first several months of development. Future you will thank present you.
  - archagon 12y ago
    In regards to SpeedRunners: "Implementing online multiplayer was very difficult," developer Casper van Est tells me. "People always warn you about it, and even with that taken into account, it turned out more difficult than we expected. We're a small two-person development team, so we already knew implementing it was going to take a while, but it ended up taking us several years."
- tinco 12y ago
  Yes, definitely, but only if UE4's network model fits your game. It takes a lot of research and I'm afraid some experience also to design a real time networked action game. This goes for all nonconventional features though, I saw for example that Cubical Drift announced last week that they underestimated their needs and will have to swap out their graphics engine mid game. Not fun stuff I'm certain .
TheLoneWolfling 12y ago
Not so much an alternative as an implementation, but this is where immutable structure-sharing data structures become very useful.

by tinco 12y ago

Cakez0r 12y ago

Have had this problem too with making a racing game. We ended up making remote entities move independently of the physics engine (I.E. cars for remote players were just static objects that had their positions manually updated). This worked to some extent, but we had to do some fudging to make collisions work somewhat realistically.

Igglyboo 12y ago
Are you saying that the client determined their own position? How did you account for people cheating?
- ownagefool 12y ago
  Sounds like you never played Red Faction. I love that game but watching people fly around the map, clip through walls and shoot 1000 rockets a second (much to the dismay of my graphics card) wasn't the most pleasant experience.
- drostie 12y ago
  It doesn't sound like that at all. The person you're replying to just said that they were sufficiently frustrated with the physics engine's treatment (or lack thereof) of network phenomena that they bypassed it completely, telling the physics engine "this car is just a static object at this location." That doesn't mean that there wasn't some other process which determined how that number was generated before it was handed to the physics engine -- either via a central server or something more distributed. Speaking of the latter, I wonder whether consensus algorithms can be pulled off with a small enough bandwidth that you could incorporate them into a high-intensity game. Your consensus bandwidth is not the slowest-peer bandwidth but rather the median bandwidth, which can be much higher -- the question I'm asking is whether there's a good way for a slow peer to say, "hey, to improve my performance by reducing my bandwidth/latency, can one of you guys act as my server?"
  - Igglyboo 12y ago
    Possibly, but what about collusion? This would be a problem especially with team games, one team has an extra player so 51% so they come to the consensus that everyone on the other team is always dead.
    - drostie 12y ago
      Well, I don't think it's a huge problem. Maybe I'm wrong. I feel like it's core to the idea of "let's go play a game" that we largely agree on its rules -- and if more than half of us deny those rules, they are going to go off and play a different game; we won't want to play with them. So one response is for the reference client to simply say "if I see too many totally crazy things I'm just going to disconnect and ignore those peers who were saying that for a while." But is it really a problem? You've got to imagine that we've got this red-vs-blue team game with two clients: ref and hax. The only way Red will be able to do this is if the red+hax population is greater than 50% among the server-population, because all of the ref clients will reject bad physics. So suppose we've got a game of 21 people. 15 of them use the hax client (~70% participation), and we'll just assume there are no low-latency peers for the moment. The red team gets 11 consistently; the blue team gets 10. Then assuming team assignments are totally random, there's still only an 0.12% chance in any given game of the red team actually having 11 hax nodes and dominating the game. In the vast majority of the games they'll have to play honestly. And that's with 70% of the peers trying to game the system. (It gets a little worse if we include low-latency peers. So let's assume that there are 4 and they get distributed unevenly, 1 on red, 3 on blue. The consensus threshold is now 9. Assuming we lost 3 hax clients in the process, 16% of such games will be vulnerable to your attack. That's enough to make things frustrating.) Meanwhile, the hax-client may make things unplayable unless it behaves like the ref-client when it's not in the majority. The basic point is that the red-vs-blue partition makes those attacks not a concern. But when that partition doesn't exist, then there's a bigger problem. So the more concerning thing for me is denial of service. I don't think I'll get 70% of the legitimate customers to try to hack the game, but I do think that IPv6 support could lead to one person having a block of 10,000 IP addresses being able to take the majority of peers in all of my games. Okay: they may not have enough red peers to win the games for red or enough blue peers to win the game for blue, but suppose that their goal isn't to win, but just to shut down the system. Suppose their modified client, instead of saying "everyone on blue suddenly dies", says simply "everyone suddenly dies". Now 99% of games become unplayable, all of my legitimate users rage-quit, and I'm totally screwed. So the problem is that sign-ups must be relatively closed and everyone needs to be able to validate that independently. I'm not sure how to solve that in a distributed way without some web-of-trust thing going on.
- Cakez0r 12y ago
  The clients determined their own position, yes. It was not a peer to peer game and the server ran sanity checks on what the client was telling it (is their velocity acceptable for the car they have? did they accelerate too fast? are they in an area of the world that should not be accessible? etc) which worked pretty well. We deemed it was too resource intensive and too slow to run a physics engine on the server (it was a "massively multiplayer" game).

aaasux 12y ago

> UE4 is the first engine I've used that seems to have a very nice multiplayer API I'm working on a triple a ue4 title and i don't like ue4s replication system at all. It's a step towards making the networking concerns invisible, and that always seems like a mistake to me. If the protocol for keeping clients in sync were more explicit, it would be easier to tightly control what and when things get sent over the network.

forrestthewoods 12y ago
Is it roughly the same as UE3? It was usable but god damn did it make a lot of things difficult.
JabavuAdams 12y ago
Are you able to contrast it with Tribes' / Garage Games' model? What about RakNet? I'd love to hear more.

jmorrison 12y ago

First time post from long-time lurker. Be kind. Back In The Day (just to show how ancient I am), I personally debugged the first peer-to-peer (vs client/server) networked simulation protocol on the DARPA SIMNET project: http://en.wikipedia.org/wiki/SIMNET http://en.wikipedia.org/wiki/SIMNET Interesting stories notwithstanding (anybody else here ever got to drive/fire a tank, and have fellow engineers get dosed with CS gas, as part of a software engineering job?), when time came to standardize this research protocol as: http://en.wikipedia.org/wiki/Distributed_Interactive_Simulation http://en.wikipedia.org/wiki/Distributed_Interactive_Simulat..., we tried to get them to generalize the protocol thusly: http://www.google.com/patents/US5623642 http://www.google.com/patents/US5623642 The work was supported by a DARPA small-business project, so the IP was left with the company in hopes of commercializing it, and maximizing dissemination. The attempt to get the ideas incorporated as part of the standard was singularly unsuccessful. More's the pity, as I think it would have really helped make the simulations more capable of simulating a wider array of physical phenomena. The commercial uptake was equally unsuccessful. I experienced some culture shock when proselytizing (again, unsuccessfully) at game development conferences.

angersock 12y ago
As I recall...doesn't VBS/VBS2/ArmA use this? Anyways, shoot me an email--have some questions not suited for this format.

archagon 12y ago

Interesting. After reading this Gamasutra article[1] on how online multiplayer can literally add years to your development time, I got a little scared. Will UE4 allow developers to avoid this setback? (On the other hand, developers like Carmack and Michał Marcinkowski only took a matter of months to add it to their games, and they were among the first. So maybe it's not as big of a deal as it seems.) [1]: http://www.gamasutra.com/view/feature/217434/the_ups_and_downs_of_doing_online_.php http://www.gamasutra.com/view/feature/217434/the_ups_and_dow...

Ogre 12y ago
I only skimmed it, but I didn't see anyone in there who took years. They were all on the order of months. Entirely possible I missed it. That said, adding networked multiplayer to a game is very difficult. But designing a game around networked multiplayer is not nearly as hard. Single player or local only multiplayer games can get away with lots of assumptions that completely break multiplayer, and detangling all of those assumptions is the most time consuming part of converting a game. If you do it "right" from the start, you don't ever allow yourself to make any of those assumptions and everything just works. If you know you're going to build a multiplayer game, then write it as a client server architecture from day one even if you know you're not going to play with other people for the first several months of development. Future you will thank present you.
- archagon 12y ago
  In regards to SpeedRunners: "Implementing online multiplayer was very difficult," developer Casper van Est tells me. "People always warn you about it, and even with that taken into account, it turned out more difficult than we expected. We're a small two-person development team, so we already knew implementing it was going to take a while, but it ended up taking us several years."
tinco 12y ago
Yes, definitely, but only if UE4's network model fits your game. It takes a lot of research and I'm afraid some experience also to design a real time networked action game. This goes for all nonconventional features though, I saw for example that Cubical Drift announced last week that they underestimated their needs and will have to swap out their graphics engine mid game. Not fun stuff I'm certain .

TheLoneWolfling 12y ago

Not so much an alternative as an implementation, but this is where immutable structure-sharing data structures become very useful.