Choosing a Tech Stack for a Multiplayer Action Game: Part 1 – The Backend

Ah yes, starting a new project. All roads are open and the potential is limitless… I’ve got a rough idea of the thing I want to build, but how to choose a tech stack? The cartoon above captures the essence of the choice really. In this three part series, I’ll go through my thought process of choosing the tech stack, starting with the backend and finishing with the frontend.

My Background

I’ve been a Rails developer now for quite some time, and increasingly it’s started to feel like the first picture. Now don’t get me wrong, I love Rails and Ruby. I think they’re the most programmer-friendly framework/language combo as far as community, ease of plugging libraries, code readability, syntactic sugary goodness, etc. Perhaps this is familiarity beginning to breed contempt, maybe it’s the 7 year itch, but I’ve been looking to build a project in something else and this game seems like the perfect opportunity.

And so the search begins…

As any developer with zir head on straight will tell you, to get the right tech stack you need to know the requirements. The project I’m writing about is our flagship game, Breakfast of Champions. It will be similar to many of the popular .io games popping up these days:

  1. Accessible through the browser
  2. Accessible through iPhone and Android apps
  3. Multiplayer

Because this game is multiplayer, I’ll need to run it on a central server and broadcast out the game state to all the players involved. To accomplish this, I’ll be using web sockets.

Great, now that that’s sorted, let’s take a look at:

The Backend

C++ right? It’s a game, you should use C++. C++ is used for like every game server. Well, yeah, that’s true, but I guess I’m a spoiled Ruby developer, and I really just don’t want to code in C++. Does that make me a horrible game dev? TBD I guess. Someday I will probably make a game that has a C++ backend server… But it is not this day.

So what’s left? Well the fine folks at Hashrocket did us all a favor and compiled this excellent article on websocket performance by language. The results were C++ coming out on top, Clojure a not-terribly-close second, and Go and Elixir sort of tied for third.

Given that the Elixir framework, Phoenix, has channels built in, the language is sort of Ruby-looking, and the performance is passable, I think I’ll go with Elixir!

Next up, the frontend…


What do you think? Am I in for a world of pain or is Elixir the best thing since sliced arrays?

Leave a Reply

Your email address will not be published. Required fields are marked *