Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Server side musings
Jimmy_Scythe
Member CommonPosts: 3,586
So I was talking to an unnamed individual about how a particular server emulator worked, when it dawned on me; under the hood, MMORPGs are just like MUDs. In fact, they are MUDs!! The main differences are the use of UDP rather than TCP and the fact that the client sends compressed and encryped flags to the server rather than just text. This explains quite a bit. Not the least of which is how free MMORPGs manage. You can rent a MUD server for about $50 to $70 a month. That makes running a MMORPG out of pocket fairly easy.
Doing a bit of research, I found a statement from sony that the backend of Everquest was alot like DikuMUD. This lead to a sworn statement that it wasn't so that they couldn't get sued but I still had to wonder. Anyway, here are some not-so-trivial differences that I've pieced together so far:
1) Packets are sent UDP. The client just acts as a macro machine for server commands. The commands are usually compressed in some way to keep the size under 500 bytes. My cable connection runs at about 2 megs per second. divide that by 500 bytes and then divide that by two (you have to send responses) and you have the number of users that bandwidth can support. That's all a rough estimate though.
2) The world database is tile-based rather than room-based. This is really kind of moot since any traditional MUD can make each room into a tile containing a mob, player, or static world object with exits in all directions. Since the graphics are kept client side, the tiles can be fairly empty except for mobs, NPCs, players, and interactive objects like chests chairs and doors.
3) Collision detection and line of sight are computed client side. This takes alot of processing load off of the server. This also opens the door for cheaters who can modify the client to allow them to see through and walk through walls.
4) the server has to periodically update the mobs, NPCs, and players in a specific radius around the player. This can suck bandwidth like no one's business. Add in the fact that there are exponentially more mobs on an MMO than a MUD and you get some major gridlock. This is also part of the reason why Mobs always spawn in on place and stay gathered in groups. It's easier on the server and the bandwdth that way.
Aside from that, Everything else is exactly the same. Scripts, Database, chat, it's all the same. The packets are kept low to increase amount of users supported by bandwidth and the scripts kept simple to cut down on the servers processing load. Multiple ports are also used to some degree.
I realize that converting a traditional MUD to a graphical one would mutilate the code to the point of being unrecognizeable. With this being the case however, why are so many open source and indie projects re-inventing the wheel and writing everything from the ground up?
There wasn't any real point to this point other than "isn't this neat!!". I am curious about whether anyone, other than SOE, has tried to convert a text MUD for use with a graphical client and, if so, have released documentation as to how they did it. If you guys find anything, let us know.
Comments
Because the trans-mutated engine would be no where near as effcient as writing your own.
Looking at Diku gamma right now, it looks like the only things I'd have to change would be the would be the comm.h, comm.c, interpreter.h, interpreter.c, and interpreter-quinn.c. That's a pretter tall order, but it's doable. The rest of the code could stay as is. The hard part would be making the client. In any case, you could probably get a korean style MMORPG into testing within three to six months.
For most MMO's there really is a bit more happening under the hood than with traditional Text Based MUDs. Not to say you couldn't extend a DIKU to be graphical, but for a 'good' game you'd want to do a lot different.
Your tile size would need to be really small in order to give any semblance to being able to move freely in the world. You need to add path computing to your monsters, something that takes up a lot more CPU time than you might expect. If you don't do collision detection and the like on the server, it's too easy for some one to hack a client to allow you to walk through walls,trees, etc. There's quire a bit more...
Honestly, it's really easier to design something from the ground up than to hack a text-based MUD to be something it wasn't intended to be.
Reading through a good MUD, and then using that knowledge to help you on your way is much more constructive
I half agree with that. The networking and command processing is definately different. the database could be almost the same. I know most emulators use MySQL as the database so there's no reason why a MUD database couldn't also be used. I'm just trying to avoid rehashing what's already been done. Especially since I'm doing this as a hobby rather than a commercial product.
Collision detection on a tile map is incredibly simple. At least to anyone that can code a tetris or breakout clone. Pathfinding can be a nightmare and require a whole database of path Nodes in and of itself. I was thinking about the client running collision detection for the player and the server storing tiles as rooms with no exits as static world objects. A tree, a wall, and a floor-to-ceiling bookcase can all be the same thing from the computer's point of view.
The size of the tile is abstract and can visualized as big or as small as you want it to be. In this case, the tile should be roughly the size of the base of a player's bounding cube. Or be just able to fit the base of the player's bounding cylinder. Objects could take up multiple tiles though and I'm not sure how that would work. Then there's the issue of facing....... The client doesn't have to be tile based though. It can use BSP or Oct-trees to represent the world. The communication to the server would still have to operate in tiles though. Annoying because it requires a two stage level design. One for the database and another for the client engine. Twice as annoying because the two have to match perfectly. Yet another reason why collision detection should be done client-side. You would then have to make a Punkbuster type app though.
Lastly would be the order of operations on the server. You'd want to process certain things in batch, player actions, mob actions, global world states such as time, etc.... I think all of that is handled in a traditional MUD though. I'm still combing Diku gamma though and I didn't really notice anything like that in TinyMUD.