[erlang-questions] Let's start a project for a (MMO-)Game in Erlang... (inspired by "Erlang: Who uses it for games?")

[Michael Turner]

If you have a personal itch to write game development systems in Erlang, do
it.  However, if you have a personal itch to make it so good for that
purpose that other programmers will learn Erlang just to use it, you should
never forget what the sales points need to be -- and the inevitable
drawbacks, too.  As Eric Raymond also says,

  When you lose interest in a program, your last duty to it is to hand it
off to a competent successor.

Open source software survives in large part because the code gets handed off
by the first torch-bearers to worthy and enthusiastic successors, to carry
onward.  Do it for fun, but keep that long-term responsibility in mind as
well.  If it starts to look like you can't meet that responsibility, well
... no blame.  At least you tried.  And had some fun.  And learned some
lessons about what doesn't work,  And got better at Erlang.  So you really
can't lose.

-michael turner

My vague sense is that Erlang is actually very good for this purpose
(server-side, anyway).  As desktop multicore populations grow, it could even
become competitive in games on the client side.  If you don't aim to write a
successful *game* (that's like producing a feature film), it's not too
ambitious.  But there are risks.

Since this would be an open-source project, you have to think about how such
projects succeed.  I always go back to Eric Raymond on this.  Not that he is
God, or even infallible when he's talking about Open Source.  But he had a
good point when he wrote:

  Every good work of software starts by scratching a developer's *personal
itch*.

What's an itch?  We know it when we feel it.  And a lot of us feel the same
ones.  As programmers we work with a lot of the same kinds of programming
tools every day -- languages, compilers, interpreters, editors, shells,
IDEs, debuggers, checkers, version control systems, operating systems, and
so on.  As programmers, we think about a lot of things in very similar ways.
 So if I "scratch my itch" caused by some tool, I've probably invented a
back-scratcher that would give a lot of other programmers relief.

Of course, some things are a matter of taste.  But we solve that with
tolerant diversity -- I call your Python module from my Perl code, you call
my C++ code from your Ruby code, I call your Java module from my Erlang
code, I call your COBOL code from -- wait a second: *your* COBOL code?
 How'd *you* get in here?

But with the end results that ultimately gets programmers paid, which is
what makes programming a profession -- i.e., with products that users will
use -- tools are invisible.  Whether it's written in COBOL or Python is
invisible.  Was it written using vim or emacs?  Users won't know.  Users
don't care.  That's the water's edge, where taste starts to matter.

Look at how it worked out in open source where the "itch" was really more a
matter of taste than implementation: window systems.  (Yes, you could even
write a window system in 99% COBOL.  Theoretically.)  The programmer's idea
of a window system that scratches many itches was the infinitely
customizable one.  Users didn't agree: they mainly wanted something
predictable and uniform.  Not only was an historic opportunity for open
source OSes lost in the desktop computer space, it even took forever to get
some kind of convergence within the (relatively very small) open source
desktop OS world.  There is a window system *product* that gets a large
number of users while sitting on top of an open source OS.  But it's running
on the Macintosh.  And it's closed-source and dictated by Apple.  Luckily
(well, it's not really luck), what gets dictated by Apple is actually pretty
reasonable.

With an open-source game system, the game-players won't care that it's
written in Erlang.  They won't even know that.  So you have to think: what
does Erlang do so much better that it would persuade existing game
developers to move away from whatever system they have now?

Don't say "free" (as in beer).  There are plenty of those already available
for free.  That's not enough.

Don't say "free" (as in speech).  There are also plenty of those already
available in that sesne of "free" as well.

Erlang actually starts from behind in the "free as in speech" respect,
because "free speech" only works when people understand what you're saying.
 Very few programmers can look at an Erlang program, with no experience in
Erlang, without some head-scratching.  And it's head-scratching that
relieves no itches by itself: you have to go read about Erlang, and even
write a fair amount of it, before you can really get what the code is
saying. [*]

Eric Raymond also said:

  When you lose interest in a program, your last duty to it is to hand it
off to a competent successor.

So keeping that "sales objection" in mind (i.e., that "this programming
language looks -- and feels -- very weird") will help in you meeting that
final responsibility.  If it turns out you can't meet it, well, no blame.
 At least you tried.  And learned something about what doesn't work.  And
got better at Erlang and game system architecture.  And had some fun.

-michael turner


[*] To be sure: I don't think this added barrier exists because Erlang is
*inherently* obscure.  In a way, the problem is that it's so *natural* -- in
the sense outlined by Joe Armstrong in chapter 7 of his book.  That chapter
is very short, very easy to read, but deeply philosophical in the best way:
as someone once said, nothing is more practical than a good theory.
 Erlang's relative naturalness is a big part of what makes it look so
unfamiliar to most programmers, because most programming languages are so
*unnatural*.)

On Sat, Jul 10, 2010 at 2:55 AM, Boris Mühmer <boris.muehmer@REDACTED>
 wrote:

> It looks like some people are interested in Erlang game programming.
> On the other hand getting started in Erlang and OTP isn't too easy.
> Especially for people with a strong C/C++/C#/Java/etc background.
>
> Inspired by the "Erlang: Who uses it for games?" thread I thought about
> starting a community project to implement a MMO game in Erlang/OTP.
> The goal would be to collect some "best-practices" for different tasks.
>
> Actually I am more interested in the server side than how to implement
> a top-notch-state-of-the-art client. Also I think Erlang is more suited
> for the server side. But I am also interested in how to interface the
> "server-side erlang" using a (C/C++, Java, Python) cross-plattform
> client (using wxWidget or Qt as a base and OpenGL for graphics).
>
> What I would like to see are reponses from other people who may also
> be interested in such a project. Not only beginners with Erlang/OTP,
> but also (or especially) experienced people to guide and support the
> others. And most of all, to have some fun practising Erlang.
>
> Well, what do You think about it?
>
> Best regards,
> Boris
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>