Erlang MMORPG Engine
next-gen.cc
next-gen.cc
Unfortunately as I'm reimplementing a server for a client that already exists, I had to offload some of the time-sensitive stuff onto C as it's simply too slow in Erlang (in this case, walking + pathfinding).
Edit: Also, hot code loading is f'ing incredible for stuff like this. Get on, walk a bit, notice a bug, update it in the code, make:all([netload]) in the shell, bam, fixed. (Though I had to patch stdlib to fix a bug in c:nc that makes make:all([netload]) useless. I've submitted a patch and it's in the pu branch.)
It's curious that the author uses TCP. Almost every high performance game uses UDP, as you don't care about lost packets or the order 99% of the time. You just want the latest information.
One reason might be to use Flash for the front end. It does not allow UDP sockets at this time.
http://www.gamedev.net/community/forums/topic.asp?topic_id=3...
As an interesting note, World of Warcraft uses TCP.
EvilTrout - Just to verify your previous statements - I remember when I took networks in the 90s my professor told us UDP was the way to go if reliability wasn't a requirement and performance was important. (less overhead, and of course better latency, etc.) That was the how Everquest successfully implemented it. Many of the EQ players were using 9600 baud dial-up and were very happy with network performance when it first came out. Not to say they didn't have problems at the beginning. But they have long had an awesome hybrid (UDP/TCP) solution that's been tested for a decade.
It's interesting that we've hit a turning point with WoW. I can only imagine how much more pleasant it must be to code using TCP instead of a custom UDP protocol. It also may explain some of the odd network behavior that was "solved" circa 2002 in Everquest but occasionally happens in WoW today.
Ruby might be slow, but in my experience as long as you give it a lot of RAM to play with it can give you great performance (we have over 200k registered players). Of course, we also cache data heavily using memcached.
I feel like I'm spamming this point sometimes, but I don't think it can be said enough: If you are a language designer and you want to displace Erlang, you shouldn't be targeting "shared-nothing concurrency" or "message passing"; those are merely the door fee. OTP is what you need to replicate/replace/supplant. All of it, including the cross-machine stuff. Believe me, there's room for improvement.
I would think that the physics is what makes things difficult. Of course, if you can think of a game where physics simulations are not as important, an Erlang engine really starts to make sense. At least that is my impression. I'd really be interested in hearing from anyone who has had experience with physics in Erlang.
However, space-based games would likely require a little more physics to be interesting.
The only 'physics' that need to be calculated is when a player changes speed/direction, and you must calculate the path and detect collisions.
However, to minimize negative effects on gameplay, both the client and the server 'dead reckon' the position of players in their immediate view bubble.
In the client, this is done on a separate thread, on the server, a separate set of processes. Again, I don't expect my algorithms to be cpu heavy, but if they were I'd probably implement them in C and communicate with the erlang processes via message passing. However, this may not be feasible if the latency is too much, in that case, C/C++ is probably more apt. However, you'd have to implement your own scaling, so I'd rather modify my game design than write the functionality that erlang already provides.
Of note: I think your wiki has been hacked.
From Programming Erlang,
For massive numbers of entries that you want to be able to access readily, you might be better off using CouchDB, MySQL, PostgreSQL, or Berkeley DB, all of which have open source Erlang drivers and APIs available. The upper limit of a Dets table is 2 GB. This means the upper limit of a Mnesia table is 2 GB if the storage type is disc-only copies. For other storage types the upper limit depends on the system architecture. In 32-bit systems the upper limit is 4 GB (4 * 109 bytes), and in 64-bit systems it is 16 exabytes (16 * 1018 bytes).
So far I don't know how many users my servers scales to, with some rough test I can have about 2000 players in the same spot, I recently added a quad tree and with that in place I hope that will increase a lot if players are spread out in the area.