03 Mar, 2013, Rarva.Riendf wrote in the 21st comment:
Votes: 0
>But then when you look at a game like legauge of legends or world of warcraft; you know they are using a multi-layered approach to handle the volumn of players.

They use instance, and different unconnected 'world'. Ie: they decided that they wont scale up to a point they know they could not do it with the hardware they got.
03 Mar, 2013, Tyche wrote in the 22nd comment:
Votes: 0
salindor said:
Ha, ya. I forgot about just plain parallel computing. Back in college I took a parellel computing class targeting a beawolf cluster. Never really used the knowledge much, and the techniques they taught don't seem to be useful for a mud.


Starting with the IBM 3081, businesses could chain up to 32 mainframes together. DASD (disk) and Tape storage was shared as well as Network controllers. Load balancing software allowed batch jobs to be scheduled to run on whichever mainframe was least busy. OLTP type applications like TSO, CICS, QMF, DB2 could also be balanced and scheduled to run on multiple computers. Later in the 90's IBM marketed it as "parallel sysplex" and introduced "hypervisors" like PR/SM that could partition individual or collections of mainframes into LPARs (logical partitions), that allowed you to run applications across many machines with shared memory. Running multiple versions of operating systems on the same box actually dates back to 1970's with the VM OS. It's really the same as what's being called a "private cloud" today. I saw very little in the way of purely parallel applications though in the business enviroment ("embarassingly parallel" I think the term is) which Beowulf clusters were invented to address. Mostly we did parallel transaction processing, which is virtually identical to today's internet http REST applications.

But back to muds…

salindor said:
But then when you look at a game like legauge of legends or world of warcraft; you know they are using a multi-layered approach to handle the volumn of players. Even though I have zero aspirations that my game would require such an approach, its fun to think and contemplate "What if I did?" How would I do it? I am still baffled on how to grow a server beyond a single computer. I mean I guess you could easily split the database off (and cluster it as necessary). But then what?

Oh I guess you would have to make your pipeline to your database really good, then as long as no two objects interacted directly and only through the database, then you could just simply run multiple instances of the game. Then you would need a layer in front… but it would only be to redirect clients to load balance the servers. Then the last part would simply be using the new found 'cloud' api's to bring up or down servers based on demand which would need to be tracked so as not to pay for unneeded servers.

I am meandering a bit, but above is my raw thought process.


Ultima Online, EverQuest, WoW control their clients so they can redirect to any server.
Muds that support telnet clients and mud clients don't have a lot of client options for redirection.
It would require them to implement a new standard option.

But distributed mudding has been around for a while..
See this post:
http://www.mudbytes.net/index.php?a=topi...

There's a usenet quote from Marcus Ranum that I'll paraphrase since I can't find it:
"I invented distributed mudding back in 1992, nobody gave a shit."
04 Mar, 2013, salindor wrote in the 23rd comment:
Votes: 0
Tyche said:
There's a usenet quote from Marcus Ranum that I'll paraphrase since I can't find it:
"I invented distributed mudding back in 1992, nobody gave a shit."


I could see that… after all, the only time it matters is once you have a player base high enough for it to matter. Until then who cares.

Thank you.
20.0/23