| Author |
Message |
< Erlang questions mailing list ~ Let's start a project for a (MMO-)Game in Erlang... (inspir |
| daleharvey |
 Posted: Fri Jul 09, 2010 6:11 pm |
 |
|
|
User
Joined: 14 Sep 2007
Posts: 17
|
| On 9 July 2010 18:55, Boris M |
|
|
| Back to top |
 
|
| Guest |
| Posted: Fri Jul 09, 2010 7:35 pm |
|
|
|
Guest
|
It would be feasible to do the client side using wxWidgets and/or esdl.
However, I think having a web frontend is the way to go.
I'm too busy on my own project to help, how about perhaps contributing
to existing mmorpg engines such as: http://www.next-gen.cc/
There goes a lot into making a game, not just programming. A lot of
art is needed, plus people to design characters and story lines. One
would have to think carefully as to what type of mmorpg to make before
even getting started.
On Fri, Jul 9, 2010 at 11:10 AM, Dale Harvey <dale@arandomurl.com> wrote:
> On 9 July 2010 18:55, Boris M |
|
|
| Back to top |
|
| raould |
| Posted: Sat Jul 10, 2010 12:23 am |
|
|
|
User
Joined: 18 Dec 2008
Posts: 20
|
On Fri, Jul 9, 2010 at 5:14 PM, Michael Truog <mjtruog@gmail.com> wrote:
> DSL for game scripting, etc..
http://github.com/rvirding/lfe
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Multiverse |
| Posted: Sat Jul 10, 2010 12:38 am |
|
|
|
User
Joined: 07 Mar 2008
Posts: 14
|
I'll join. I can do Physics/AI, or some other part.
Regards,
-Gene
On Fri, Jul 9, 2010 at 5:21 PM, Raoul Duke <raould@gmail.com> wrote:
> On Fri, Jul 9, 2010 at 5:14 PM, Michael Truog <mjtruog@gmail.com> wrote:
>> |
|
|
| Back to top |
|
| bsmr |
| Posted: Sat Jul 10, 2010 5:42 am |
|
|
|
Joined: 31 Mar 2010
Posts: 9
|
Thank You for the first responses in such a short time.
Where should we set up a project? Would "Google Code" be a good place
to start at? Maybe use "Google Groups"/"Google Wave" for
communication? What other alternatives are there? I currently only
know of C#/.Net places... An "no", I don't work for Google, still I
like the tools they provide...
I had a brief look at some sites. Many need a "license" for a project.
Which one should be used?
What kind of repository system should be used? Would "Git" be ok?
- boris
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| ttmrichter |
| Posted: Sat Jul 10, 2010 6:33 am |
|
|
|
User
Joined: 21 Mar 2008
Posts: 17
Location: Wuhan, Hubei, PRC
|
On 10 July 2010 14:09, Michael Truog <mjtruog@gmail.com> wrote:
> I vote for "Google Groups"/"Google Wave"/GitHub/BSD_License
> I am neutral on "Google Code"
>
I vote AGAINST Google Wave and Google Code. I've never had a good
experience on Google Code and Google Wave is painfully slow and incoherent
for anything serious IME.
--
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Jul 10, 2010 9:18 am |
|
|
|
Guest
|
bitbucket ?
On Sat, Jul 10, 2010 at 7:32 AM, Michael Richter <ttmrichter@gmail.com>wrote:
> On 10 July 2010 14:09, Michael Truog <mjtruog@gmail.com> wrote:
>
> > I vote for "Google Groups"/"Google Wave"/GitHub/BSD_License
> > I am neutral on "Google Code"
> >
>
> I vote AGAINST Google Wave and Google Code. I've never had a good
> experience on Google Code and Google Wave is painfully slow and incoherent
> for anything serious IME.
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions
> of
> entering China our focus has really been what's best for the Chinese
> people.
> It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
--
Dawid
Post received from mailinglist |
|
|
| Back to top |
|
| ttmrichter |
| Posted: Sat Jul 10, 2010 9:52 am |
|
|
|
User
Joined: 21 Mar 2008
Posts: 17
Location: Wuhan, Hubei, PRC
|
BitBucket, GitHub both sure, although I favour the former.
On 10 July 2010 17:15, Dawid Figiel <dawid.figiel@gmail.com> wrote:
> bitbucket ?
>
>
> On Sat, Jul 10, 2010 at 7:32 AM, Michael Richter <ttmrichter@gmail.com
> >wrote:
>
> > On 10 July 2010 14:09, Michael Truog <mjtruog@gmail.com> wrote:
> >
> > > I vote for "Google Groups"/"Google Wave"/GitHub/BSD_License
> > > I am neutral on "Google Code"
> > >
> >
> > I vote AGAINST Google Wave and Google Code. I've never had a good
> > experience on Google Code and Google Wave is painfully slow and
> incoherent
> > for anything serious IME.
> >
> > --
> > "Perhaps people don't believe this, but throughout all of the discussions
> > of
> > entering China our focus has really been what's best for the Chinese
> > people.
> > It's not been about our revenue or profit or whatnot."
> > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
> >
>
>
>
> --
> Dawid
>
--
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Post received from mailinglist |
|
|
| Back to top |
|
| bsmr |
| Posted: Sat Jul 10, 2010 11:23 am |
|
|
|
Joined: 31 Mar 2010
Posts: 9
|
I will have a look at bitbucket and github. Does bitbucket have a
"free plan" for many users? I didn't see it at my first glance...
I know Linux doesn't have any problems with git, mercurial, or
whatever. How about Windows and Mac OS X? Sometimes I use subversion
on windows, but I don't have too much experience about git or
mercurial. I also have an old G4 Mac, even with Mac OS X, but I never
did any programming on that machine.
Also how should we name the project?
Somehow I don't want to have the term "Game" in the name, because I
think a general approach wouldn't only be interesting for games (like
Fantasy-/SF-MMO[RP]Gs), but also "Virtual Worlds" (like Second Life),
maybe it could also be of interest for "Virtual-Classrooms".
Maybe we need more than one project. Like one for the major "backbone"
components (cluster management, monitoring, load balancing,
accounting, reporting, tools) and other for "instances" like "Erlang
Vast Exploration Online", "Universe of Erlang", "My Erlang Farm",
"Erlang Mafia Disputes", "Erlang Aquarium", "Erlang Life", "Cafe
Erlang"...
Should we discuss those things using "erlang-questions" or move to
Google Groups or another mailing list? I don't want to annoy to many
people with crazy thoughts...
- boris
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Jul 10, 2010 2:20 pm |
|
|
|
Guest
|
| --- On Sat, 7/10/10, Boris M |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Jul 10, 2010 3:57 pm |
|
|
|
Guest
|
I would love to contribute however I legally cannot due to my current
contract. While I cannot code, I can still give advice.
IMO that sounds like a great idea. Since you'll likely create a custom
protocol over TCP, you'll be able to make a frontend in just about any
language. I would advise against a web solution if you ever want to achieve
any kind of meaningful performance. For heavy scenes, you'll almost always
have to end up shifting a lot of work off the server and onto the client
(stuff that doesn't need the server, like vfx particles bouncing off physics
objects (ie: destructible)) and you'll have a hard time doing efficient work
in javascript (I use it in my project for rendering tasks and it is terribly
slow still..). Good luck trying to have your browser call c++ code locally
(as in external library) without creating a custom plugin.
If however you don't aim to support hardcore gaming and more for casual,
slow paced games like second life or farmville, then yes, a web frontend
would be ideal. While I haven't tried webgl yet, I've found that svg was
faster overall than canvas for heavy scenes.
An other problem you'll hit if you go the web frontend route is that you'll
find javascript poorly suited for binary parsing and you'll most likely want
to have your underlying protocol use json or some delimiter based strings
(to save on bandwidth and parsing time).
That might not be such a bad idea in fact, just have all the protocol
messages be in json (later on you can always add a message to request binary
messages for efficiency in games that require it). Most languages have
libraries to parse json and it'll integrate well with javascript if need be.
You could even, have javascript be the game's scripting language both on the
server side and client side.
Do spent a good amount of time designing the authoring tool(s) and how they
will tie in with the rest of the engine. Those are usually critical for
acceptance. (ie: Unreal3 has a horrible engine, code wise and performance
wise, but because it has good tools for artists, a lot of games go for
unreal) That could very well turn out be the most critical part of the
project. While you may be able to build most supporting tools and pipelines
(in fact I would vote for you to use erlang for the data building
pipelines), you may have to use something else for the authoring tools.
You'll need to be able to render large scenes in low res and have it be very
responsive. You'll definitely need opengl/directx support for it. Perhaps
python or c# could be good fits here, I'm not sure.
Likewise, spent a good deal amount of time designing the data building
pipelines. This is where designers/artists spend a good deal of their time
(waiting for things to build). You'll most definitely want to have assets
build separately and be cached to avoid needless rebuilding. You may wish to
bundle them together but only referencing a hash or key. You'll then be able
to stream them to the clients on demand when they load a level. (There might
be an opportunity to abuse javascript caching in browsers if you go the web
frontend route (ie: when loading assets, dynamicaly add <script> tags
pointing to your server with their hash, if the url is the same, the browser
can read from the cache instead, saving bandwidth))
Anyhow, 2cents
Nicholas
On Sat, Jul 10, 2010 at 9:18 AM, Ed Keith <e_d_k@yahoo.com> wrote:
> --- On Sat, 7/10/10, Boris M |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Jul 11, 2010 4:24 am |
|
|
|
Guest
|
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 |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Jul 11, 2010 4:28 am |
|
|
|
Guest
|
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@gmail.com> 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 |
|
|
| Back to top |
|
| bsmr |
| Posted: Sun Jul 11, 2010 7:18 am |
|
|
|
Joined: 31 Mar 2010
Posts: 9
|
I have choosen "PEMMOX" as an (interim) title for this "project".
"PEMMOX" is the abbreviation for "Project Erlang Massively Multiplayer
Online eXperience".
For further discussions I created the Google Groups group named
"PEMMOX". People interested in further discussions should visit
"http://groups.google.com/group/pemmox/", please.
- boris
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Jul 11, 2010 11:14 am |
|
|
|
Guest
|
I think you should call it Yopia. Because you can't call it Myopia -- the
visual acuity condition caused by hacking game software 18 hours a day.
(Or, by playing the games it would host, yes, it'll become that popular!)
No, you can't call it Myopia. It's not allowed.
Or, in the spirit of Yaws, how about "Goiter"? Games Online In The Erlang
... uh ... uh-oh, I've got Mnesia again.
-michael turner
On Sun, Jul 11, 2010 at 4:14 PM, Boris M |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 2
Goto page 1, 2 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
