Hello reader.
This blog marks the beginning of a project that has the objective of producing a massive multiplayer online project written in Erlang. Actually the project started in 2005 with a lot of research, but not much code was produced until 2007.
Is it Vaporware ?
For all those in knowing whether this is real or not, be calm don't argue, it is vaporware ... until the day we publish code, so in the meanwhile, don't get anxious or annoyed.
When you say MMO, do you mean MO or MMO?
MO stands for multiplayer online game and the second M puts the massive into it. We classify hereby that any engine that only supports some 15-20 users as an MO and engines that can handle 1000+ users as MMO. Nowadays you see many announcements of people claiming to have built MMO engines, when truly they start to choke on 20+ connections. This is mostly due to a bad initial design because of a platform that cannot handle massive requests and also due to limits of a single server being used. The goal of the project is to produce an engine that can handle multiple servers and at least 1000+ users in real-time, being the limit basically only the throughput of a LAN and CPU power or the speed requirement of the application, so if a given application can live with less updates per second, thousands of users must be supported simultaneously. We don't want another toy, we want a serious MMO engine instead.
Why limit the project to 1000 users ?
This is not really meant as a limit, rather a minimum requirement and something achievable, but one thing for sure, if the Smash framework can handle 1000 its uses are unlimited, because in order to produce a 2000 user framework, you only would have to communicate 2 networks, so assuming that 1000 works, a million is easily within our grasp, too. The current tests have shown that the framework does not even choke on 50'000 test users, although sending out 50'000 messages takes some time, so 1000 really isn't a problem to accomplish and overshoot, but we need to set a target, so 1000 is the initial target, that's all.
Time frame
There is no specific time frame, which is why we classify ourselves as vaporware. The complexity of this endeavor is quite high, so trying to extrapolate a date is too difficult at this time.
Project components
Defining the development platform is vital, so Erlang is defined as the server platform and Apoxalyx for the GUI.
Why Erlang ?
* It runs on several OS like windows, Linux, BSD, MacOS and others.
* It is concurrent on the very heart, creating threads is easy and independent from the OS
* It's soft real-time, which is what we need
* One can share easily information across threads
* The Mnesia database replicates across the connected nodes
* You can update the application during normal operation
* It can be operate fault-tolerant
To mention a few advantages of Erlang, more on http://erlang.org.
Why Apocalyx ?
Because it is easy to use through LUA scripts, it's fast and it's pretty, more on http://apocalyx.sourceforge.net.
Why this blog ?
It sometimes helps to write stuff down as you go and often a loving comment of a reader/listener can help to improve things, so for now I will write here on progress and ideas and if there is something you want to contribute, please message me, note that flame posts or any unrelated posts will be deleted without question.
Bye bye,
Sunweaver