A Beginner's Guide to Creating a MMORPG

A Beginner's Guide to Creating a MMORPG
Author: Radu Privantu
Description: An introduction for beginners on how to get started with building a MMORPG.

Find it very useful - really! Especially the dispelling myths part, which i think will be useful for the 3/4 of the developers....Anyway, nice job Entropy! Can't really play Eternal-Lands no more because of a slow connection but the article is pretty good!

'A Beginner's Guide to Creating a MMORPG' Now you've opened newbie flood gates

Nice article, after reading a bit about network protocols in Game Programming Gems, someday I'd like to learn more about networked games.

OT: As soon as I started reading, it reminded me of Eternal Lands! I've downloaded and played that game so many times.. It's artwork is gorgeous too

While the author's heart is in the right place, this is, I'm afraid, a very poor article.

Just in one minute of skim reading this article, I noticed glaring errors.

- C++ is NOT the most popular choice for MMOG's. It is the most popular client-language; Java is the most popular server language, and arguably Python is second most popular. Seeing as most of the game is written on the server, you can forget C++

- All the leading C and C++ networking libraries have been ommitted, not to mention the cross-platform ones. The author apparently has no idea what networking libraries are *actually used* by MMOs

- Files are NOT fast compared to databases

- In fact, you never ever use files for storing data, even in a hobbyist game

- TCP is NOT slower than UDP - this is a myth perpetuated by those who have no idea what they are talking about (if anything, TCP is faster. Fact.)

- You never choose between TCP and UDP. You always choose between TCP and an RDP-esque custom protocol built on UDP

For an example of a decent article, here's one from my bookmarks:

"This isn't a step-by-step guide to building an MMOG (do you have the next 6 months free?)"
http://stratics.com/content/articles/mmoguide.php

But at least it's not actually wrong!

I would like to find a really good one. If anyone has a bookmark for a step-by-step guide that is good, please post them!

i agree with you partially. i have no actual data veryfing this but i doubt that commerical MMOGs ala World of Warcraft are written in Java on the server side. probably you could provide a siginficant example ?

I would like to find a really good one. If anyone has a bookmark for a step-by-step guide that is good, please post them!

and if you find step by step instructions on how to build an UFO please let me know
seriously there are no step by step instructions because the topic is broad and you can porbably only come by it with a lot of experience.

as far as i can tell the author already implemented an MMORPG which should give him credit alone.

All the leading C and C++ networking libraries have been ommitted, not to mention the cross-platform ones.

he mentions SDL_net, DirectPlay. that is enough for a hobbyist system. real companys most likely have their own network libs.

Files are NOT fast compared to databases

no they are not. they should be equaly fast. a database does nothing more than store it's data on a disk just as a file does. the difference obviously is that the logic of manageing the data is moved to the database server. by using files directly you merely move the database logic into your server. you might argue though that it will be hard to beat the experience and knowledge of the databse programmers and that you are also reinventing the wheel but that's beside the point here.

what i personally don't like about the article is that it lacks depth but reading this the author might feel compelled to write a follow-up exlpaining in depth implementation details and problems he encoutered

Originally Posted by rfejkhryxnq

- C++ is NOT the most popular choice for MMOG's. It is the most popular client-language; Java is the most popular server language, and arguably Python is second most popular. Seeing as most of the game is written on the server, you can forget C++

If you don't really care about the speed, then go ahead, use Java or Phyton. Anyway, let me know of a commercial MMORPG that uses Java or Phyton.

- All the leading C and C++ networking libraries have been ommitted, not to mention the cross-platform ones. The author apparently has no idea what networking libraries are *actually used* by MMOs

Such as?

- Files are NOT fast compared to databases

Did you do any tests, or you are speaking from what you've heard?

- In fact, you never ever use files for storing data, even in a hobbyist game

Eternal Lands uses flat files.

- TCP is NOT slower than UDP - this is a myth perpetuated by those who have no idea what they are talking about (if anything, TCP is faster. Fact.)

TCP CAN BE slower than UDP, especially if you don't need your packets to arrive in the same order, and/or you don't need reliablility.

- You never choose between TCP and UDP. You always choose between TCP and an RDP-esque custom protocol built on UDP

"RDP-esque custom protocol built on UDP" is UDP.

Anyway, if you have more xperience in this field, by all means, please write a better article.

Originally Posted by anubis

what i personally don't like about the article is that it lacks depth but reading this the author might feel compelled to write a follow-up exlpaining in depth implementation details and problems he encoutered

That's because it is the first article, which is supposed to be a prequel to the others. My next one will be focused on debugging.

Looking forward to it

That's because it is the first article, which is supposed to be a prequel to the others.

sorry, i must have overread that. anyway, keep it up

TCP indeed can be slower than the UDP and in the most cases - it is. Especially with big data transfers, which are broken into smaller packages the TCP is spending big amount of time making sure they'll apear in right order...

Besides if TCP was really faster than UPD than i guess that phone network companies would've prefered it but they didn't .... WAP is instead based on some UPD-like protocol

first, props to Entropy for a good read. the article was skinny on the details but you assessed what it takes to make an MMO. I certainly look forward to your next article.

now, on the networking stuff:

Originally Posted by Mihail121

TCP indeed can be slower than the UDP and in the most cases - it is. Especially with big data transfers, which are broken into smaller packages the TCP is spending big amount of time making sure they'll apear in right order...

Besides if TCP was really faster than UPD than i guess that phone network companies would've prefered it but they didn't .... WAP is instead based on some UPD-like protocol

[snapback]9130[/snapback]

the first thing you said is correct. TCP is slower than UDP. and the reason is because TCP is connection-oriented [aware] and UDP is connection-less [unaware].

it's a matter of philosophy and tradeoff. if you choose to use TCP, data is guaranteed to arrive from server to client, at the cost of "aware-overhead". with UDP, you reduce overhead but then data is "recklessly thrown" and is highly susceptible to corruption.

often overlooked are the unpopular protocols out there - one of which is multicast protocol. now, unlike sending the same data to all connected clients at a high-level [basically, round-robin context switch], multicast protocol works at the switch level [low level] that you send each data once and the switch themselves send the information to more than one destination, per client. this is possible because a common multicast-protocol-packet has more than one _destination_ address.

now, getting switch-level routing isn't exactly easy. one method is to go indie/garage style and use a bunch of old computers and program them to do switch-level routing. another method is to call up cisco or foundry and see how much it costs for their machines. I don't imagine they would be cheap...

...woah, i'm getting carried away here!

sorry for the long reply, just my 2 cents i suppose.

personally i don't like people who critisize and then disappear. i mean... if they feel like starting a discussion what's the point if they never show up to see the answers

yeah.. that dude was pointless.. he stated wrong facts, and doesn't exist really..

just forget about him

Originally Posted by anubis

personally i don't like people who critisize and then disappear. i mean... if they feel like starting a discussion what's the point if they never show up to see the answers

[snapback]9175[/snapback]

I hope that wasn't directed towards me
although my response has dropped, I do frequent this site [as I have always]. second, I wasn't critisizing anyway - if anything I was commending entropy for the article.

Originally Posted by davepermen

yeah.. that dude was pointless.. he stated wrong facts, and doesn't exist really..

just forget about him

[snapback]9180[/snapback]

and if this is [also] for me, multicast does exist - i'm not at liberty to discuss what I do at work but I can say that my team and I design and implement routing solutions. in fact, shoutcast[tm] is something we've developed for [using multicast protocol].

but if not, then yes, do "just forget about [me]"

it's for rfejkhryxnq who stated ... stuff..

i would never talk this way about you donBerto... honest

hehe yeah I knew better than to doubt you two.

I know davepermen and I butted heads way back but I respect you. and anubis, we never butted heads but I respect you too

donBerto: in fact, you have provided constructive input and feedback which I'm sure the author will appreciate.

'rfejkhryxnq' apparently registered with a random username just to critisize the article without providing a real discussion.

nobody has anything against you donBerto. really not!

and 1000 posts by davepermen...

Originally Posted by davepermen

and 1000 posts by davepermen...

[snapback]9207[/snapback]

Let's not start that again :P

Yeah, well, I'm quite proud of my post-100 postcount.

Originally Posted by baldurk

Let's not start that again :P

[snapback]9210[/snapback]

hehe.. just because you are scared i could catch up

nice article, looking forward for the sequel. I hope you discuss about mmorpg design, instead of the implementation(MMORPG economy,story,etc)