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

[Michael Turner]

Oops, sorry for the scrambled final edit.  Take this up *after* my first
sig.



On Sun, Jul 11, 2010 at 1:21 PM, Michael Turner <
michael.eugene.turner@REDACTED> wrote:

>
> 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
>>
>>