4 ms·

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

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.
    - remh 5y ago
      You are being disagreeable. Requirements are requirements, sometimes they are easier, sometimes they are more complex. But you dismissing an engineer who successfully shipped something on production that met their requirements because you think you have "industry advice" is pure arrogance. Every piece of software is written with the actual requirements in mind, defined (usually) by the people who know the context they are working with the best. Not by armchair specialists.
    - Zababa 5y ago
      I don't understand your point, you're building a strawman and then attacking it. This architecture works for them, and will probably keep doing so as you can see on the other response. > 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. But they DID implement it and it works perfectly well for them. I don't understand why you're splitting hairs about fantasy scenarios. If they had a different problem, they would solve it differently. If you've faced something like that, feel free to share you story, what were the constraints and how you solved them.

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.
  - remh 5y ago
    You are being disagreeable. Requirements are requirements, sometimes they are easier, sometimes they are more complex. But you dismissing an engineer who successfully shipped something on production that met their requirements because you think you have "industry advice" is pure arrogance. Every piece of software is written with the actual requirements in mind, defined (usually) by the people who know the context they are working with the best. Not by armchair specialists.
  - Zababa 5y ago
    I don't understand your point, you're building a strawman and then attacking it. This architecture works for them, and will probably keep doing so as you can see on the other response. > 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. But they DID implement it and it works perfectly well for them. I don't understand why you're splitting hairs about fantasy scenarios. If they had a different problem, they would solve it differently. If you've faced something like that, feel free to share you story, what were the constraints and how you solved them.