3 ms·
I thought they implemented game network code, scalably. That would be cool. So I was a little bit disappointed when read that they only keep stats using Erlang.
by thesz 15y ago
I thought they implemented game network code, scalably. That would be cool. So I was a little bit disappointed when read that they only keep stats using Erlang.
Other than that, that's pretty interesting.
- masklinn 15y ago> So I was a little bit disappointed when read that they only keep stats using Erlang. Slide 19 lists far more than just stats-keeping: > Our core server for controlling Python > – Managing 100,000s of concurrent TCP connections > – Scheduling/queuing of tasks for python > – Metrics gathering (SNMP) > – Presence server(fragmented mnesia) > – Message passing (nb: this might be the "in-game messaging" service mentioned in the presence server slide 21) > Other standalone game-related servers (expanded on slide 25) > – Transient in-game data (seems to be a k/v store used for e.g. dynamic chat channels) > – Testing bandwidth (estimation of client bandwidth via blasting UDP packets to the server) > – Ranking leaderboards (real-time rankings, >15m users, built on ets and a customized gb_trees) All of this is listed under "How we use Erlang"
- thesz 15y agoI should clarify a bit. I think that contemporary FPS need real-time game server logic. When I saw link title I thought they finally ported some game code to Erlang. All stuff you mentioned has nothing to do with game logic. It does not require hard real-time response like one required from network game server. And yes, I already know that I could use Erlang for non-hard-real-time tasks.