10,000 players

#21 I don't see any huge flaws, other than the fact that you only have one admin server with write access to your database. Of course, you mentioned that your login servers will have their own databases, but you'll need to tie that to your central account validation as well.

There shouldn't be too much of an issue with a good db backend to allow for multi-user write to a history database either, but it may not be needed.

#22 The admin server does player validation. There can be multiple admin servers running and all are for reading but only one for writing.

#23 Interesting, although I disagree with the rdbms comments, ive been writing middle tier products for DB's for a couple decades now, its easy, its fast, and doesnt break the OO nature of your code.

You can do the same thing with a middleware server process that caches the data in memory using the format the application uses, then feed that in memory data over to the rdbms either as a write through cache or at certain intervals(depends on the critical nature of the data).

Been trying to teach this to MMO's out there, most never get it right because they never spend time addressing the problem, they think they can just throw hardware at it and it will be ok, *chuckle*

but anyway, I think torque will do what your looking for, and you could even go get the torque networking library (TNL) and write the rest of the services using it (will save you a bunch of time).

#24 Just came across something that may be of interest:
mekensleep.org/
It's written using [from what I gather]
openscenegraph.org

Gary (-;

#25 You should be able to whip up a quick test app with TNL and find out how high you can scale. :) Use the adaptive protocol to limit your bandwidth usage, of course. Let us know what you find out. ;)

#26 I can now handle 135,000 players on my PowerBook G4. I'm using Erlang (http://www.erlang.org) on the server side, though, and I will probably have to run a cluster of servers for good measure. Details at http://wagerlabs.com

#27 Most of the time when people get advice they don't come back to report how things went... I am very glad to see that you came back to keep us up to date... Im even happier that you achieved good results.

#28 I'm curious did you switch over to t2d or implement it in tge like you started with? Pretty amazing though that you can hold 135,000 on a laptop.

#29 I switched over to T2D on the client side. I'm a lazy guy and there's no need to used 3D when you don't have to. I want to roll out the first version quickly so I'm going with 2D.

I should also emphasize (for those who missed the point ;)) that I'm using Erlang on the server side. Erlang is the stuff that Ericsson and Nortel use to write software for their telephone switches. It has fault-tolerance, failover, etc. built in and everything is modeled using processes. It's a concurrent programming language.

Simulating 27k running poker games creates 405,000 processes and eats up to 600Mb of memory. It also takes about 40 minutes to run through the simulation. Each game takes about 0.05-0.07s to start but the number of games is huge.

Overall, Erlang is the platform to build massively scalable stuff on, IMO.

#30 Are you using your own network protocol, something that Erlang provides, or TNL? (Specifically, to communicate with T2D - I realized Erlang has a lot of its own primitives for this sort of thing. ;)

#31 I'm using straight TCP and skipping the Torque network protocols. And then I'll be upping the number of open sockets per process drastically which is needed on the server side. Not sure if this is possible under Windows, though.

#32 Thats cool.... That could be extremely useful for some of the T2D people I imagine, if it allows for more attachments then the TNL... You should consider posting your architecture as a resource (if it's possible)

#33 @Chris:

I'm don't think I can post the server-side architecture in its entirety but I'll be posting bits and pieces to my tech blog at http://wagerlabs.com/tech. The problem is that handling that many players is very Erlang-specific on the server side and it's just straight TCP connections and pushing strings or binary packets on the client.

#34 @Joel... Well I didnt thikn you would post EVERTHING... Just an overview of where and what you did... maybe along with code snippits of what you did to T2D .

Maybe how Erlang ties in, and an overview of how to use it.

#35 @Crhis... The thing is that I did NOT modify T2D to increase the number of players, at least I don't think there's a need for this. As for Erlang... How many people here are interested in it?

Erlang is available at http://www.erlang.org and you could think of it loosely as "concurrent Python". Very loosely. I wrote the whole server in Erlang and everything is modeled as a process, this is the Erlang way since it's a concurrent programming language.

Here is a summary of what Erlang is: http://www.erlang.org/faq/t1.html#AEN9

Maybe I'm misunderstanding you and you could ask some specific questions to get me started in the right direction.

#36 I thought you manipulated T2D to attach to the Erlang written server... I thought you bypassed the network code and wrote your own client side TCP network controller.

I dont have T2D... Nor do I know how your client /server system works.

I am quite interested in hearing more about Erlang.

See, my ignorance to how you did what you did is just another reason you should post a plan or resource explaining what and how you did it...

#37 T2D has basic TCP networking built in and the Erlang server accepts TCP connections. Erlang basically looks like any other network server. You could write one in C, C++, Python, etc. So long as it accepts TCP connections and the protocol is published it would not make a difference.

The difference is in the server internals. Some platforms/languages force you to employ workarounds, others have limitations. Try 400,000 threads in C++ for example. Erlang lets me model things the natural way. Players are processes (extremely lightweight threads if you will), games are processes, etc. All communications between processes is done by message passing.

I like it so much thus far that I'm scratching my head over why no one is employing Erlang to write massively multiplayer game servers. And I didn't even mention that Erlang makes writing fault-tolerant servers simple. Ericsson and Nortel are using it to write software for their telephone switches and these can't just fail, they must employ fail-over, take-over, etc. Erlang is designed with this functionality in mind.

It also has a distributed database called Mnesia which I'm also employing. It can be in-memory and use disk-based tables as well. It's not a relational database but can store any Erlang "terms"/structures and replicate changes across a server cluster.

#38 Cool... Thanks for the info.

#39

Quote:I like it so much thus far that I'm scratching my head over why no one is employing Erlang to write massively multiplayer game servers.

We plan on using it for our AI messaging and processing actually. Create a process for each NPC, and write an AI Manager that dispatches events and information back and forth between the AI processes and the game world.

#40 (Do note that TNL does not use TCP and therefore can scale to very large numbers of users - numbers in excess of what any TCP solution can do.)

Nice work, Joel. Erlang is cool tech, and it's neat to see it playing nice with Torque. :)