29 ms·

YMMV, but: - Memory consumption in production peaks at like 300 MB for us - Scalability (i.e., being able to go wide on, say, a 64-core CPU) was more importan

by s3cur3 5y ago

YMMV, but: - Memory consumption in production peaks at like 300 MB for us - Scalability (i.e., being able to go wide on, say, a 64-core CPU) was more important to us than raw, synchronous speed - Garbage collection is not something I've ever had to think about with Elixir (which hasn't been my experience with Python and Java) - Because it's a sim and not something like a FPS, we don't have to worry about cheating (what would cheating even mean?), so we don't have to do any physics on the server side - Despite being way more familiar with C++, I can't imagine going from zero to production in 6 months (or even 2 years) if we'd tried to do this in C++

andrewmcwatters 5y ago
> what would cheating even mean? This is such a rudimentary question in game development that I don’t know how you can’t answer it. Mainstream server authoritative design has been a thing since 1999, and probably even longer when you look beyond Quakeworld. All it takes is a few malformed packets from a script kiddie and then you realize you have to do distance checking and other anti-cheat functionality. “Cheating” in gamedev doesn’t specifically mean there is a win scenario and you need to make sure people don’t shortcut that and play unfairly. It means in this case that someone can’t connect to your server and transport their plane to another nearby player and wave it around in their flight path to annoy others while they spam chat to grief people for fun and to produce a YouTube video. And those checks are pretty simple.
- s3cur3 5y ago
  Sorry, to clarify, our thinking on this point was: our players aren't particularly motivated to lie to the server since there isn't a "goal" to a flight simulator. Given the choice between shipping (much, much) faster and completely locking down the experience against the vague, yet-to-be-realized threat of people sending fake packets to the server, we opted for the former.
  - networked 5y ago
    Have you had any reports of multiplayer griefing so far? I wonder if griefing happens in serious flight simulators like X-Plane and what form it takes if it does. (If there are griefers, then they might conceivably find a way to exploit this. But I am asking mostly because I am curious about what the player community is like.)
    - s3cur3 5y ago
      Griefing, yes. The audience for our mobile app skews young and, shall we say, less "serious aviators" than the desktop sim, so to some degree people like that you can buzz a 747 on short final in an F-22. :D Long-term we've talked about things like a reputation system, where flying responsibly would earn you points to get into a separate "world" filled with people who also want to do more serious flying.
    - nerdponx 5y ago
      I would also wonder about vectors for causing vandalism (botting your client to write racist words in the sky with a fleet of stunt planes emitting smoke trails), or other general forms of malice (trying to DoS or otherwise crash the server). Presumably X-Plane is small enough and "boring" enough that your only malicious interactions would be only lazy drive-by attempts, but those kinds of situations would be more concerning to me than someone modding the client to make their plane fly at Mach 7.
- andy_ppp 5y ago
  You’re misunderstanding, there isn’t the concept of winning in a simulator like this. It’s not goal driven it’s practicing modelling the real world not showing how many points you get when you land a plane.
  - andrewmcwatters 5y ago
    I’m not misunderstanding, it’s just clear that they have virtually no requirements. As soon as you have any meaningful requirements, this entire architecture probably falls apart, let alone the fact that you can’t hire for it, as no one is going to want to work on your obscure game server. The criteria are also so brittle at those concurrent numbers that if the game decided to do any more than what they do today, you would face engineering challenges more difficult than other game server software. As you deal with more and more concurrent clients there are calculable limits to how you can facilitate more features and how bandwidth and server frame time budget limits you.
    - Zababa 5y ago
      That's just a "No true Scotsman". Your definition of "virtually no requirements" also seems to be circular with this architecture failing or not. People have created a chatroom with 2 millions people connected at the same time with Elixir on a single box https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-.... Your ideas about performance are not based in reality.
      - andrewmcwatters 5y ago
        As soon as you have to broadcast deltas on object properties to visible sectors, you immediately hit precisely measurable metrics on what is possible on various types of connections. If you broadcasted 8 bytes of deltas to 2 million “players” concurrently 120 times per second, you’re going to have problems. Experience shows there’s just no reason to talk to people about these specifics because even though they’ve never implemented it before or even done the math, you definitely know better than I do. @rehm: I mean, you can call me an armchair specialist because you’re angry, but I’ve shipped this stuff and it’s still used today. I employ people who can do that sort of basic math. Your truisms aren’t helpful in engineering discussions, it’s just noise. Yes of course products’ requirements vary: that’s not the discussion. @Zababa: It’s not a “fantasy,” unless you’re not doing anything besides recording vec3 and transmitting it on a regular rate, most games have these concerns today. It is a specific function of major game engines to deal with this type of processing and more bespoke than not to not deal with it at all. Show me a real-time game that runs at even 20 tick that doesn’t deal with these constraints. I’d love to know what fantasy world you live in where these things are not engineering problems that people haven’t worked on for decades. I wish people who didn’t have any experience whatsoever with these systems would stop trying to hold discussions with people who do on HN because it just makes the experience pander to the lowest common denominator.
- elteto 5y ago
  No need to get aggressive. It's a high fidelity simulator. There is no goal, no missions, no points, no wins or losses. You just fly. There is probably very little the server is actually doing. Player state as seen from the server is probably just x,y,z coords, plane type, etc. Just the bare minimum to be able to draw another player in the game. For that use case Elixir (or Go, or maybe even Python with more computational resources) is a very good fit.
  - jay_kyburz 5y ago
    Yes but lets acknowledge that it's not really a game, and that nobody should do this for any kind of public game with winners and losers. A multiplayer server needs to run the simulation for every player and be the authority, the clients should simply collect input from the player and run a "lite" simulation to hide latency.
    - JoeyJoJoJr 5y ago
      No, not every multiplayer game needs an authoritive server. It depends largely where your priorities are. For myself, having a base of players with some cheaters would be a great problem to have.
      - jay_kyburz 5y ago
        Yeah but, the solution to your great problem is to write the authoritative server, so I would recommend you just do that in the first place. It's not really any extra work if you are starting a new project. (An authoritative server is just a headless client after all :) )
    - setr 5y ago
      RTS games typically run deterministic simulations locally, and only sync inputs, with no real need for an authority. The anti-cheat mechanism is simply the fact that simulation state has to stay in sync, and artificial changes would trivially desync. Of course, this leads to the standard RTS cheat — map hacking — because the client has to have everything by definition. But you have enough entities in an RTS that syncing full state, or even delta, gets ridiculous quickly, so it’s just something that has to be dealt with. Fighting games also tend to do something similar — deterministic lockstep with rollback — which also sensibly runs with no authority (again, you can’t teleport/wallhack because you’re only passing player inputs, and moving just your character is the same as the sim desyncing) But my main point is that an authoritative server is not a guaranteed architecture for multiplayer games — the game design should definitely factor in (as it does in OP’s case).

by s3cur3 5y ago

andrewmcwatters 5y ago

> what would cheating even mean? This is such a rudimentary question in game development that I don’t know how you can’t answer it. Mainstream server authoritative design has been a thing since 1999, and probably even longer when you look beyond Quakeworld. All it takes is a few malformed packets from a script kiddie and then you realize you have to do distance checking and other anti-cheat functionality. “Cheating” in gamedev doesn’t specifically mean there is a win scenario and you need to make sure people don’t shortcut that and play unfairly. It means in this case that someone can’t connect to your server and transport their plane to another nearby player and wave it around in their flight path to annoy others while they spam chat to grief people for fun and to produce a YouTube video. And those checks are pretty simple.

s3cur3 5y ago
Sorry, to clarify, our thinking on this point was: our players aren't particularly motivated to lie to the server since there isn't a "goal" to a flight simulator. Given the choice between shipping (much, much) faster and completely locking down the experience against the vague, yet-to-be-realized threat of people sending fake packets to the server, we opted for the former.
- networked 5y ago
  Have you had any reports of multiplayer griefing so far? I wonder if griefing happens in serious flight simulators like X-Plane and what form it takes if it does. (If there are griefers, then they might conceivably find a way to exploit this. But I am asking mostly because I am curious about what the player community is like.)
  - s3cur3 5y ago
    Griefing, yes. The audience for our mobile app skews young and, shall we say, less "serious aviators" than the desktop sim, so to some degree people like that you can buzz a 747 on short final in an F-22. :D Long-term we've talked about things like a reputation system, where flying responsibly would earn you points to get into a separate "world" filled with people who also want to do more serious flying.
  - nerdponx 5y ago
    I would also wonder about vectors for causing vandalism (botting your client to write racist words in the sky with a fleet of stunt planes emitting smoke trails), or other general forms of malice (trying to DoS or otherwise crash the server). Presumably X-Plane is small enough and "boring" enough that your only malicious interactions would be only lazy drive-by attempts, but those kinds of situations would be more concerning to me than someone modding the client to make their plane fly at Mach 7.
andy_ppp 5y ago
You’re misunderstanding, there isn’t the concept of winning in a simulator like this. It’s not goal driven it’s practicing modelling the real world not showing how many points you get when you land a plane.
- andrewmcwatters 5y ago
  I’m not misunderstanding, it’s just clear that they have virtually no requirements. As soon as you have any meaningful requirements, this entire architecture probably falls apart, let alone the fact that you can’t hire for it, as no one is going to want to work on your obscure game server. The criteria are also so brittle at those concurrent numbers that if the game decided to do any more than what they do today, you would face engineering challenges more difficult than other game server software. As you deal with more and more concurrent clients there are calculable limits to how you can facilitate more features and how bandwidth and server frame time budget limits you.
  - Zababa 5y ago
    That's just a "No true Scotsman". Your definition of "virtually no requirements" also seems to be circular with this architecture failing or not. People have created a chatroom with 2 millions people connected at the same time with Elixir on a single box https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-.... Your ideas about performance are not based in reality.
    - andrewmcwatters 5y ago
      As soon as you have to broadcast deltas on object properties to visible sectors, you immediately hit precisely measurable metrics on what is possible on various types of connections. If you broadcasted 8 bytes of deltas to 2 million “players” concurrently 120 times per second, you’re going to have problems. Experience shows there’s just no reason to talk to people about these specifics because even though they’ve never implemented it before or even done the math, you definitely know better than I do. @rehm: I mean, you can call me an armchair specialist because you’re angry, but I’ve shipped this stuff and it’s still used today. I employ people who can do that sort of basic math. Your truisms aren’t helpful in engineering discussions, it’s just noise. Yes of course products’ requirements vary: that’s not the discussion. @Zababa: It’s not a “fantasy,” unless you’re not doing anything besides recording vec3 and transmitting it on a regular rate, most games have these concerns today. It is a specific function of major game engines to deal with this type of processing and more bespoke than not to not deal with it at all. Show me a real-time game that runs at even 20 tick that doesn’t deal with these constraints. I’d love to know what fantasy world you live in where these things are not engineering problems that people haven’t worked on for decades. I wish people who didn’t have any experience whatsoever with these systems would stop trying to hold discussions with people who do on HN because it just makes the experience pander to the lowest common denominator.
elteto 5y ago
No need to get aggressive. It's a high fidelity simulator. There is no goal, no missions, no points, no wins or losses. You just fly. There is probably very little the server is actually doing. Player state as seen from the server is probably just x,y,z coords, plane type, etc. Just the bare minimum to be able to draw another player in the game. For that use case Elixir (or Go, or maybe even Python with more computational resources) is a very good fit.
- jay_kyburz 5y ago
  Yes but lets acknowledge that it's not really a game, and that nobody should do this for any kind of public game with winners and losers. A multiplayer server needs to run the simulation for every player and be the authority, the clients should simply collect input from the player and run a "lite" simulation to hide latency.
  - JoeyJoJoJr 5y ago
    No, not every multiplayer game needs an authoritive server. It depends largely where your priorities are. For myself, having a base of players with some cheaters would be a great problem to have.
    - jay_kyburz 5y ago
      Yeah but, the solution to your great problem is to write the authoritative server, so I would recommend you just do that in the first place. It's not really any extra work if you are starting a new project. (An authoritative server is just a headless client after all :) )
  - setr 5y ago
    RTS games typically run deterministic simulations locally, and only sync inputs, with no real need for an authority. The anti-cheat mechanism is simply the fact that simulation state has to stay in sync, and artificial changes would trivially desync. Of course, this leads to the standard RTS cheat — map hacking — because the client has to have everything by definition. But you have enough entities in an RTS that syncing full state, or even delta, gets ridiculous quickly, so it’s just something that has to be dealt with. Fighting games also tend to do something similar — deterministic lockstep with rollback — which also sensibly runs with no authority (again, you can’t teleport/wallhack because you’re only passing player inputs, and moving just your character is the same as the sim desyncing) But my main point is that an authoritative server is not a guaranteed architecture for multiplayer games — the game design should definitely factor in (as it does in OP’s case).