Hacker News Reader

Comment by whalesalad | Hacker News Reader

I wonder if any game servers are implemented in Erlang?

I am currently doing this! Working on an MMO game server implemented in Elixir. It works AMAZING and you get so much extra observability and reliability features for FREE.

I don't know why its not more popular. Before I started the project, some people said that BeamVM would not cut it for performance. But this was not true. For many types of games, we are not doing expensive computation on each tick. Rather its just checking rules for interactions between clients and some quick AABB + visibility checks.

I distinctly remembered that Eve Online was in Erlang, went to go find sources and found out I was 100% wrong. But I did find this thread about a game called "Vendetta Online" that has Erlang... involved, though the blog post with details seems to be gone. Anyway, enjoy! http://lambda-the-ultimate.org/node/2102

Eve used Stackless Python.

CoD Black Ops used/uses Erlang for most of its backend afaik. https://www.erlang-factory.com/upload/presentations/395/Erla...

There's the real answer. This should be a reply to the original question!

You'll never get a modern FPS gameserver with good performance written in a GC language. Erlang is also pretty slow, it's Python like performance. Very far from C#, Go and Java.

The other reason is that the client and the server have to be written in the same language.

> The other reason is that the client and the server have to be written in the same language.

This isn't true at all.

Sure, it can help to have both client and server built using the same engine or framework, but it's not a hard requirement.

Heck, the fact that you can have browser-based games when the server is written in Python is proof enough that they don't need to be the same language.

Browser game don't need performance, I'm talking about AAA online games here, which 99% are built in c++ and the rest in c#.

> Browser game don't need performance

Mobile users will hate you when your game drains their battery much faster than it should.

> I'm talking about AAA online games here, which 99% are built in c++ and the rest in c#.

It still doesn't apply. There's absolutely nothing stopping you from having a server written in Java with a game client written in C#, C++, or whatever.

I'm really curious why you think client and server must be written in the same language. A TCP socket is a TCP socket. It doesn't matter what language opens the connection. You can send bytes down from one side and decode them on the other. I mean, sure, if you're writing the server in Java and use the language's object serialization functions to encode them, you might have a hard time decoding them on the other side if the client is in C, but the answer then is to not use Java's object serialization functions. You'll roll your own method of sending updates between client and server.

Because games are built with engines, and you're not going to re-implement all the simulation / systems in a different engine or language. Why would you? A gameserver is basically a game client stripped from rendering with a bit more logic.

I'm talking real time games here, not an .io game over websocket/json.

You can just turn off GC for the duration of the match, or during rounds.

I don't know about Erlang, but in other GC languages I've used, the GC only matters if you allocate; if you pre-allocate all of your buffers when the game is created, the GC doesn't matter. The other points remain true though.

I've been told that Erlang is somewhat popular for matchmaking servers. It ran the Call of Duty matchmaking at one point. Not the actual game servers though - those are almost certainly C++ for perf reasons.

It sounds like they're so heavily invested in Unreal Engine that it's become the entire stack.

I was imagining some blindingly fast C or Rust on bare metal.

That UE4 code snippet is brutal on the eyes.

Network connection, lobby, matchmaking, leaderboards or even chats, yes. But the actual simulation, probably not for fast paced twitchy shooter.

Also not just for performance reasons, I wouldn’t call BeamVM hard realtime, but also for code. Your game server would usually be the client but headless (without rendering). Helps with reuse and architecture.

IIRC, Activision/Blizzard uses Erlang for their matchmaking systems (or used to... I saw it in a very old talk)

In the case of Call of Duty: Black Ops 1. Thee matchmaking + leaderboards system was implemented by DemonWare (3rd party) in Erlang.

Erlang actually has good enough performance for many types of multiplayer games. Though you are correct that it may not cut it for fast paced twitch shooters. Well...I'm not exactly sure about that. You can offload lots of expensive physics computations to NIF's. In my game the most expensive computation is AI path-finding. Though this never occurs on the main simulation tick. Other processes run this on their own time.

The biggest hurdle to a game server written entire on the BEAM is the GC. GC pauses just take too much time, and when you need to get out (for example) 120 updates per second, you can't afford it. Even offloading stuff to C or C++ does not save you, because you either have to use the GC, do a copy, or both.

Game servers typically use very cheap memory allocation techniques like arenas and utilize DOD. It's not uncommon for a game server simulation to be just a bunch of arrays that you grow, never shrink, and then reset at the end of the game.

Good point. Yeah I guess it wouldn't cut it for any fast-paced twitch shooter. Especially with a 120 update per second deadline. A non-deterministic GC pause could have disastorous effects, especially in a tense shootout. I don't know much about GC theory but the GC in BEAM is per process and heap-based? I'm not sure exactly what that entails, but can you not structure the main simulation process to take advantage of this fact?

I find myself interested in developing multi-player simulations with more flexible deadlines. My MMO runs at 10 ticks. And its not twitch-based. So the main simulation process can have pauses and it wouldn't have a big impact on gameplay. Though this has never occurred.

As long as: (tick process time) + (send update to clients) + (gc pause) < 100ms, everything is fine?. (My assumption).

Btw what does DOD mean? Is it Data on Demand? Since my game is persistent I can't reset arrays at some match end state. So I store things either in maps on the main server process or I store it in the dedicated client process state (can only be updated via server process).

Reply on news.ycombinator.com