5 ms·

What are the guarantees about the networking? I saw this in the blog post: > The server state is automatically synchronized to clients, and the data model is t

What are the guarantees about the networking? I saw this in the blog post: > The server state is automatically synchronized to clients, and the data model is the same on the server and client. This means that in the future you can move your code between backend and frontend, or even run it on both seamlessly. Different types of games need different types of networking. It seems like it's going to be hard to reason about how to program the game without knowing the constraints and guarantees on the network code.

deleted 4y ago
[deleted]
whizzter 4y ago
Not necessarily, emulators has been doing this a while I think and with WASM this is the second impl I'm seeing of this. Basically, keep a "full" state backlog and ship user control events, if control events arrive late you simulate forward to "now" from the backlog with corrected input. I've been working on something very similar, gonna comment on the top-level.
- raizer88 4y ago
  Unless they are cooperative games giving copies of the server data model to the client inevitably leads to wild cheating. I give you the example of Escape for tarkov, where not only the data model is shared, but the client is authoritative over the server. A beautiful game ruined by the incompetence of the network-side development team.
  - whizzter 4y ago
    Giving state isn't the problem, the client being authoritive is the problem. What I'm describing is so-called rollback based netcode, the server should always keep an canonical state and deviating from it is at a clients peril.
    - raizer88 4y ago
      Giving full state is still a big problem. Aimbot, ESP, wall hacking are possibile only due to giving full state to the client. Most competitive games avoid this as much as possibile, eg. Dota2, Valorant, etc.
      - whizzter 4y ago
        Right, I agree there but from a development perspective it's a problem that can/should be tackled later if you know you have a hit, and the Ambient design should have no issue in fixing it later. - Aimbots is a problem regardless of state it, as long as you can see/shoot at it then aimbots can exist, stopping that is a separate issue. - On ESP/Wall hacking you're right, it can be an issue - Full snapshot/heap shipping as emulators and Kettlewells WASM sample is hard to patch here. - an DoD ECS grounded design like Ambient could selectively withhold entities (ie out of sight), however I think for starting development it shouldn't be an initial worry as long as you don't design yourself into a corner in such a way that it's impossible to implement later.
        raizer88 4y ago
        At the theoretical level I agree with you about creating an MVP first and then solve these kinds of problems the moment you hit the jackpot at the ROI level. The problem is that in 20 years I have never seen a single game do that. Because revisiting the whole network/data stack in a game that has come of age is a nightmare and the PM probably doesn't see value in it. By now you are a hit. The problem is that instead of milking the cow for 10 years because you have a cheat proof product, you make money for 3-4 and then you close. (possibily damaging your brand as a cheater infested game)
        whizzter 4y ago
        Right, and that's why I like this approach (that I'm doing and it seems the Ambient lib is built for from the examples I looked at) because there is an actual architecture that is designed for networking from day one and visiting netcode isn't as bad an issue because it's mostly just regular game-code as long as the core principles are followed. We've had generations of games that was built as webs-of-objects (and popular engines that still default to it), and yes, adding and maintaining netcode with that is like pulling tooth because you need to manually keep track of so much. This puts netcode mostly as an automatable task with clear default rules, stuff like hiding players/entities out of sight becomes filters (in the same way as not updating far-away stuff).
  - Hikikomori 4y ago
    Tarkov like most games uses client side prediction with some server side checks on actions, it can be hard to see the difference between a predicted action and client authority, they've been slowly increasing checks over the years as cheat developers finds new things to exploit. Since checks can be costly for performance you don't want to check things you don't have to, so doing it incrementally as you need is ok, for a game that is in a heavy development stage. Unfortunately they are not doing lazy loading of loose loot and containers (including player/scav), so ESP is extra powerful in this game. But since Tarkov has complex maps there's little point in trying to hide players that are not visible, CSGO and Valorant are the only FPS games that does this but they also have simple and small maps with fewer players. So player-ESP and aimbot will most likely always be possible as long as you can bypass Battleye, so instead of cheaters rushing for loot they can see you might just go and kill you.
    - raizer88 4y ago
      I agree on most of it. I think the way to do server side check is not in real time during the game, but after the game session ended. You should unload every gamestate on a secondary server that process everything and rate what could be manipulated with a degree of confidence. After this rating drop a lot on a player it should trigger a manual/automatic ban.
      - loup-vaillant 4y ago
        > After this rating drop a lot on a player it should trigger a manual/automatic ban I once heard of a game that instead of banning cheaters, isolated them together in a separate bucket. Cheaters could still play… amongst themselves.
        DizzyDoo 4y ago
        This went pretty terribly for Fall Guys[0] because the moment a false positive slips through, and then that player posts their clip of a game with close to 100% cheaters on Twitter or Reddit, it exacerbates their image of a game with a serious cheating problem. Everyone saw a game taking place jam packed with cheaters and it became a PR problem they had to overcome. [0] - https://www.pcgamer.com/fall-guys-once-had-a-secret-cheater-island-but-had-to-close-it-down/ https://www.pcgamer.com/fall-guys-once-had-a-secret-cheater-...
- meheleventyone 4y ago
  Yup it relies on two things though, the simulation being deterministic which is easier said than done and the simulation being cheap enough you can replay enough frames to correct the missed inputs without derailing the current frame.
FredrikNoren 4y ago
Ambient CPTO here; We're working on expanding the docs on this, here's the GitHub issue: https://github.com/AmbientRun/Ambient/issues/150 https://github.com/AmbientRun/Ambient/issues/150

deleted 4y ago

[deleted]

whizzter 4y ago

Not necessarily, emulators has been doing this a while I think and with WASM this is the second impl I'm seeing of this. Basically, keep a "full" state backlog and ship user control events, if control events arrive late you simulate forward to "now" from the backlog with corrected input. I've been working on something very similar, gonna comment on the top-level.

raizer88 4y ago
Unless they are cooperative games giving copies of the server data model to the client inevitably leads to wild cheating. I give you the example of Escape for tarkov, where not only the data model is shared, but the client is authoritative over the server. A beautiful game ruined by the incompetence of the network-side development team.
- whizzter 4y ago
  Giving state isn't the problem, the client being authoritive is the problem. What I'm describing is so-called rollback based netcode, the server should always keep an canonical state and deviating from it is at a clients peril.
  - raizer88 4y ago
    Giving full state is still a big problem. Aimbot, ESP, wall hacking are possibile only due to giving full state to the client. Most competitive games avoid this as much as possibile, eg. Dota2, Valorant, etc.
    - whizzter 4y ago
      Right, I agree there but from a development perspective it's a problem that can/should be tackled later if you know you have a hit, and the Ambient design should have no issue in fixing it later. - Aimbots is a problem regardless of state it, as long as you can see/shoot at it then aimbots can exist, stopping that is a separate issue. - On ESP/Wall hacking you're right, it can be an issue - Full snapshot/heap shipping as emulators and Kettlewells WASM sample is hard to patch here. - an DoD ECS grounded design like Ambient could selectively withhold entities (ie out of sight), however I think for starting development it shouldn't be an initial worry as long as you don't design yourself into a corner in such a way that it's impossible to implement later.
      - raizer88 4y ago
        At the theoretical level I agree with you about creating an MVP first and then solve these kinds of problems the moment you hit the jackpot at the ROI level. The problem is that in 20 years I have never seen a single game do that. Because revisiting the whole network/data stack in a game that has come of age is a nightmare and the PM probably doesn't see value in it. By now you are a hit. The problem is that instead of milking the cow for 10 years because you have a cheat proof product, you make money for 3-4 and then you close. (possibily damaging your brand as a cheater infested game)
        whizzter 4y ago
        Right, and that's why I like this approach (that I'm doing and it seems the Ambient lib is built for from the examples I looked at) because there is an actual architecture that is designed for networking from day one and visiting netcode isn't as bad an issue because it's mostly just regular game-code as long as the core principles are followed. We've had generations of games that was built as webs-of-objects (and popular engines that still default to it), and yes, adding and maintaining netcode with that is like pulling tooth because you need to manually keep track of so much. This puts netcode mostly as an automatable task with clear default rules, stuff like hiding players/entities out of sight becomes filters (in the same way as not updating far-away stuff).
- Hikikomori 4y ago
  Tarkov like most games uses client side prediction with some server side checks on actions, it can be hard to see the difference between a predicted action and client authority, they've been slowly increasing checks over the years as cheat developers finds new things to exploit. Since checks can be costly for performance you don't want to check things you don't have to, so doing it incrementally as you need is ok, for a game that is in a heavy development stage. Unfortunately they are not doing lazy loading of loose loot and containers (including player/scav), so ESP is extra powerful in this game. But since Tarkov has complex maps there's little point in trying to hide players that are not visible, CSGO and Valorant are the only FPS games that does this but they also have simple and small maps with fewer players. So player-ESP and aimbot will most likely always be possible as long as you can bypass Battleye, so instead of cheaters rushing for loot they can see you might just go and kill you.
  - raizer88 4y ago
    I agree on most of it. I think the way to do server side check is not in real time during the game, but after the game session ended. You should unload every gamestate on a secondary server that process everything and rate what could be manipulated with a degree of confidence. After this rating drop a lot on a player it should trigger a manual/automatic ban.
    - loup-vaillant 4y ago
      > After this rating drop a lot on a player it should trigger a manual/automatic ban I once heard of a game that instead of banning cheaters, isolated them together in a separate bucket. Cheaters could still play… amongst themselves.
      - DizzyDoo 4y ago
        This went pretty terribly for Fall Guys[0] because the moment a false positive slips through, and then that player posts their clip of a game with close to 100% cheaters on Twitter or Reddit, it exacerbates their image of a game with a serious cheating problem. Everyone saw a game taking place jam packed with cheaters and it became a PR problem they had to overcome. [0] - https://www.pcgamer.com/fall-guys-once-had-a-secret-cheater-island-but-had-to-close-it-down/ https://www.pcgamer.com/fall-guys-once-had-a-secret-cheater-...
meheleventyone 4y ago
Yup it relies on two things though, the simulation being deterministic which is easier said than done and the simulation being cheap enough you can replay enough frames to correct the missed inputs without derailing the current frame.

FredrikNoren 4y ago

Ambient CPTO here; We're working on expanding the docs on this, here's the GitHub issue: https://github.com/AmbientRun/Ambient/issues/150 https://github.com/AmbientRun/Ambient/issues/150