Hacker News Reader

Comment by s3cur3 | Hacker News Reader

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++

View on HN

> 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.

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.

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.)

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.

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.

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.

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.

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-.... Your ideas about performance are not based in reality.

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.

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.

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.

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 :) )

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).

Reply on news.ycombinator.com