
Erlang and First-Person Shooters (2011) [pdf] - Tomte
http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf
======
tombert
I saw this deck mid-2014, and it single-handedly made me want to learn Erlang.
I felt that any system that can handle COD's load is, at the very least, worth
checking out.

About a year later, I got a job doing Erlang full-time, and OTP is about as
good as that slideshow indicated...So, if anyone at Demonware is reading
this...Thank you! You introduced me to my second great love (after my wife)!

~~~
oneweekwonder
How did you get into erlang, like in project wise?

Because I played around with rabbitmq plugins, a nehe opengl examples port and
some erlang notepad someone implemented. I also own both o'reilly hard copies.

But other then that I don't really have a project I can see myself use erlang
for(one man shop).

~~~
tombert
The Cowboy webserver is fairly easy to get started with and I really recommend
checking it out, since a web server feels like a "very Erlang problem" to me.

To answer your question though, I got started by playing with TCP and building
a basic chat server. I spawned a new Erlang process for each user, used
Erlang's internal messaging to share messages between processes, and then
passed those messages along to TCP to the user.

A basic rule of thumb on whether or not it's a good Erlang problem is seeing
if you can visualize the problem in terms of a bunch of tiny, self contained
things (like cells), and you don't want one of those cells failing to have any
risk of breaking anything else.

~~~
mabbo
Got a good book or website recommendation for learning Erlang?

How does it compare/contrast with something like Akka (which I've got
rudimentary experience with in Scala)?

~~~
lostcolony
Akka was basically the Scala implementation of Erlang's actor model.

The key differences are, for me, Erlang is easier to reason about (this is
mostly how my mind works; Akka it felt like everything was reactive, that
nothing is doing any work until it gets a message; Erlang it felt like the
opposite, that every process is doing work until it decides it needs a
message, and then it can check its mailbox, and optionally block until
something ends up in it), and because of its functional nature, things that
require special keywords in Akka, just fall out 'for free' in Erlang. For
instance, 'become'. 'Become' is just calling another function in Erlang, that
has different behavior. Erlang also has more reliability characteritics (not
as efficient, but, no stop the world garbage collection, shared nothing, so
the only way an exception in one actor can affect another is via an OOM, or
specifically hooking up links/monitors such that it causes it to affect the
other actor). Akka, however, gives you the speed of the JVM (which -is-
better, in pure number cruncing, than Erlang), more libraries (though Erlang
is no slouch there, and they all kind of fit the Erlang model), and OOness, if
that's your thing.

------
deevus
From a gamers perspective, the peer-to-peer lobby system used in the CoD
series is one of the worst things about it.

I can remember constantly having to migrate hosts, getting owned by the host
because everyone else has a ping much higher than zero, and horrible lag when
the host it chose had a bad connection.

Cool technology, but at the cost of fun.

~~~
chuckdries
Eh, I played CoD for a long time in middle and high school The community loved
to complain about the whole lack of dedicated hosting thing but I rarely had
bad experiences with it. Plus, CoD 4 and CoD WaW both had dedicated servers
but are mentioned in this slide deck, so it sounds like they'd be using this
middleware regardless.

At CoD scale I'm sure the ability to not rely on first party hosted servers
saved enough money to justify the occasional service interruptions, and this
system is better for groups of players that might be close to each other but
far from an official data center.

------
Sytten
I wonder if they have considered moving to elixir since some of the problems
they have highlighted are resolved in elixir.

That would be easier for new employees and they could still keep their Erlang
code base until they make the full switch.

~~~
stanislavb
I'm wondering the same :)...

~~~
gjmacd
In 2011 Exlixir didn't exist. More than likely they've stuck to Erlang as the
incremental benefit is really on the language side only. If you're only moving
to Elixir because of the language sugar, the only thing you're going to gain
is maintenance and updates -- with a system that probably doesn't need all
that much in the way of "tinkering".

~~~
pmarreck
Elixir doesn't just add "sugar" though; it has full-fledged first-order
macros, through-and-through UTF8 support, sensical argument placement (the
thing being acted upon is always the first argument, making possible the |>
operator), sigils, great tooling, and possibly best of all, the best Rubyists
are fleeing to it. ;)

------
Thaxll
Keep in mind that those are online services and can be developed in every
languages since it's not hard real time ( aka C++ gameservers ). Most online
services for the video game industry are actually made in Java.

~~~
m0th87
Game servers don't do hard real time. That would be overkill, and requires
specialized operating systems typically used for niche applications like
robotics; e.g.
[https://en.m.wikipedia.org/wiki/RTLinux](https://en.m.wikipedia.org/wiki/RTLinux)

~~~
mattferderer
I've been reading up on VR after trying an Oculus Rift. It sounds as if VR
game servers will need something a bit closer to "hard" real time than current
servers. I suppose it still wouldn't technically be "hard real time" but much
"firmer real time". I guess this leaves me wondering if games will ever
progress to needing "hard" real time.

~~~
mmfZ4e4OqQ7RRwP
That doesn't make much sense, think about lag, playing with somebody who is
far enough that the speed of light makes a difference. You want a near real
time graphics pipeline for each user to avoid vomiting, but other than that
you will still get terrible terrible network problems one way or another which
you can't control and will show up as ghosts in the game, stopped players,
etc.

------
bobajeff
Question for those of you who are game programmers. Is the message passing of
erlang slower than shared memory threads in c++?

~~~
hderms
Everything I've ever heard on that front is that Erlang should be considered a
control layer which has any CPU-bound tasks run in C. Actors/message passing
is a good synchronization primitive but there is apparently a whole host of
issues with memory leaks regarding it in the "Erlang in Anger" e-book.

I personally lost interest in Erlang because of it only supporting actors as a
concurrency mechanism. They're good for some things, and probably
exceptionally good at what Erlang was designed for (Telecom systems), but I
think they're just one tool in the toolbox. If the recommended solution for
CPU-bound tasks is to start writing C, I have to wonder if there's a better
way.

~~~
qaq
Well short answer long term it's the only viable model you are not going to
use locking and STW gc on 500+ core system with few TBs of RAM.

~~~
ianopolous
Lock based concurrency is perfectly fine on 800 core systems with a
_pauseless_ gc and many TiB heaps. See Azul for an example using the JVM.

------
signa11
here is the video of the talk:
[https://vimeo.com/26307654](https://vimeo.com/26307654) and hopefully,
provides a nice complement to just going over the slides...

------
jonalmeida
Since some people were asking on how to get started with Erlang, some time ago
this MOOC was posted on HN for an intro to learning Erlang/functional
programming.

What I liked about it is that it assumes you have an imperative programming
background so it isn't entirely like learning at a very slow pace (which leads
me to lose interest): [https://www.futurelearn.com/courses/functional-
programming-e...](https://www.futurelearn.com/courses/functional-programming-
erlang/)

The next course after this is on the concurrency part of Erlang which is also
on FutureLearn that I'm currently taking. It has video clips from Joe
Armstrong teaching concurrency (one of the creators of the language).

------
z3t4
An important take-away is that's it's very hard to know the bottlenecks
beforehand. As an experienced programmer you can have a hunch, but you still
need to test and measure.

