next »

[kamac]

Hey there.

I've been wondering, how do MMORPG games like World of Warcraft, Runescape ( I know, I know ) and such store their users data..
Those websites require registration on their website, whileas when you login, you do that from the client.
There are definitely only two ways where the data might be stored...

a) The game's server
b) The website's server

Whereas a) option would make it easier for the server to safely modify user's data, it probably wouldn't allow the same account to be played on few servers, but would limit that account to only one (runescape's example). So I guess that runescape stores accounts & their data on website server?

On the other hand, we have WoW, which requires you to transfer your account to another server if you want to switch (which is paid, I think), so that probably is option a)

I believe that if we pick option b), we would have to make a PHP script (or any language that is server-side) and by it, process server's commands. (Save user's profile, read user's profile), and that it would slow down things alot..

Any details on these?


And the second part of my question, is - how to store user's data? Does mySQL fits? How would one store each player's items? (if each player has 32 item slots, [1D array] we could save it as string: apple,cake,sword,shield... But what if he can stack items? Do we have to save it like that?: apple_x_32,cake_x_1,sword_x_1,shield_x_1)

Those things are really bothering me, and if I would have to pick, I'd go for option a) (store user's data on game server) along with mentioned way to store user items.



Anyone wishing to share their knowledge on these topics? 

[Daid]

I pick option 3:
3) Database servers.

When you log into the game, the game server pulls the data (all of it, or just the common, depends on the amount of data) from the database server, and marks this player as "online". The online flag helps you on the webserver side that you know that you cannot modify the player data.
When significant actions happen to the player, you push the update to the database server. You don't want to be running queries all the time as this makes the game code slow, but pushing updates could be small and happens without you have to wait for the result.
You don't want to push every update, like a health change to the server, depending on the game.

[Dr. Cooldude]

I'm in no way an expert in MMO games (I don't even play them), but I'm most likely sure they use databases.

[kamac]

Okay, so that means mySQL is the way to go there, right?

Also, Daid, does that mean a minimalistic MMO should have a database server, a game server (that the whole thing runs on), and a website server? That's quite a bit of servers.  
Or I did not get that right?

[ஒழுக்கின்மை (Paul Eres)]

i thought that was kind of common knowledge that mmo's use databases? i mean how would you even do it without databases

[kamac]

i thought that was kind of common knowledge that mmo's use databases? i mean how would you even do it without databases

I thought so too, was just making sure.
My main two questions were:
- Where to store these databases (game server or website server)
- How to write down certain data such as items

[ஒழுக்கின்மை (Paul Eres)]

i imagine it'd depend on the size of the game. if the game only has a few thousand users, one server could probably handle all the traffic (the website/database/game servers would all the the same server). if it has millions of users like league of legends, you'd need to specialize

as for how you store individual things in the database, couldn't you just make one field per item slot or something? like if there are 40 item slots, each one would have two values: the item type and the number of items that are in that slot. so it'd basically work like an array

you'll notice that many mmorpgs seem to limit your number of item slots, and make you have to buy or earn new slots over time (world of warcraft for example)

[pluckyporcupine]

- How to write down certain data such as items

I'd personally do one column in a database per piece of info, like one for username, one for password, and then one for inventory and save the inventory as a JSON, since there are a lot of libraries that make it easy to encode and decode JSONs.

[Dr. Cooldude]

A user and it's inventory could work with three database tables for example.

Code:

[Users] 1--* [UserInventory] *--1 [Item]

The items in the Item table could each contain an ID that points to an item in the game data (server-side), and the UserInventory table could work as a Many-to-many relation between the users and the game's items.

This is only theory though, I have no idea how they actually work. The system would most likely be way different in a game like World of Warcraft for example.

[kamac]

Okay, so I've now got all information needed.
I have one more question though - in what language should the server be coded, assuming that it's going to run on a low-end device (~512RAM, 1.2GHz, 1 core)? (It would also have to send queries to mySQL database)

I am thinking of Erlang and C++, but of those two I only know C++ on intermediate level, whileas I don't know Erlang too much. I guess that it requires more memory though, as it runs on a VM? Or atleast more processor cores would be good for it, as I read that it has those processes thingies that work parallel, but require many cores or so.

Or are there any other common standards?

[Dacke]

I'm plan to write a multiplayer game server in Go.

Go was designed at Google as a systems language. It has first-class support for concurrency (like Erlang), lightning-fast compile times (unlike C/C++), is compiled (unlike Java) and is garbage collected. It should theoretically be a great fit for game servers, but it's pretty young and untested in that regard. You can check it out (and run code on the webpage) if you are interested:
http://golang.org/

[Gregg Williams]

A lot use databases. Others use custom serialization, like if you ever take a look at the UO emulation scene, world state and so forth are serialized to binary flat files. Then you also get into the design issues of how much is loaded into game server memory at once. Are items only pulled from the database and loaded into ram on demand? Is the full world state always loaded?

With databases depending on the load you typically end up with dedicated database servers. Just as you end up with login servers, game servers, patch servers and so forth.

[pluckyporcupine]

Or are there any other common standards?

There is no standard. Just look at MUD servers, for instance. They're written in anything from C to Java to Python to Pascal. There's a strategy MMO that I can't remember the name of right now that has its first version open sourced that was written in Visual Basic 6. I'm pretty sure there are even MMOs in GameMaker using 39dll.

Use what you're comfortable with and, failing that, use something that has libraries and/or features that support how you want to set it up.

With your system specs, though, no programming language is really going to end up supporting more than a few hundred people, I'd think.

[Gregg Williams]

Okay, so I've now got all information needed.
I have one more question though - in what language should the server be coded, assuming that it's going to run on a low-end device (~512RAM, 1.2GHz, 1 core)? (It would also have to send queries to mySQL database)

I am thinking of Erlang and C++, but of those two I only know C++ on intermediate level, whileas I don't know Erlang too much. I guess that it requires more memory though, as it runs on a VM? Or atleast more processor cores would be good for it, as I read that it has those processes thingies that work parallel, but require many cores or so.

Or are there any other common standards?

Really impossible to guess at, without knowing the game requirements. Your also missing an important bit there called network speed.

[Rusk]

This thread reminded me of a blog I read a while ago (probably linked to from these forums tbh).

Have a look at http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ and so on, especially part 5 about storage.

[eigenbom]

Also check out protobufs. The SQL part of it could just be simple, storing a couple of things like name, password hash, last login date, and then a serialised protobuf with the actual game data.

If I were building it I'd also take a hard look at Go.

[Singleton]

Many others have mentioned already that database is the way to store the data in most of the MMOGs. In many cases, the server is hosted on Linux. Often, there are tools written in Python to accommodate the server and database needs. To reduce the load of the server and database, a zone is needed to limit amount of transactions and packets going into from/to server/client plus computing of necessary algorithms. Each time a packet is received the server will decide what to do either store or just handle the packet etc..

Take a look at this diagram at http://www.bigworldtech.com/bigworld-server. It's a good example how they set up their MMO server.

[kamac]

Thanks for all the comments, guys

Really impossible to guess at, without knowing the game requirements. Your also missing an important bit there called network speed.

With your system specs, though, no programming language is really going to end up supporting more than a few hundred people, I'd think.

Oh, I would be happy if it could hold a few hundred people online
I am asking about these things either for the future, or if the current thing I am working on evolves and is able to go outside. Since I am not a wealthy guy, I'd go for the cheapest solution possible. In this case the server would either have these parameters:

PROCESSOR - 1 vCore (2.0 GHz+)
RAM - 512 MB
STORAGE - 25 GB
CAPACITY - 100 Mbps / (max. per month) 1 TB
ARCH. - 64 bit
SYSTEM - Ubuntu, Debian, CentOS

( In this case capacity is summed up the information that went out from the server, in this case it's maximally of 1 TB per month, if you cross that, you can still go up to 20% of that 1 TB, but the internet speed will be reduced down to 10 Mbp/s )

Or these (more expensive):

PROCESSOR - Intel Celeron/Atom, 1 core, 1.2+ GHz
RAM - 2GB
STORAGE - 500GB
CAPACITY - 100 Mbps / (max. per month) 5 TB
ARCH. - 64 bit
SYSTEM - probably some linux, haven't checked yet

The first one is a VPS, while the 2nd one is a dedicated server. Both really cheap
Anyway, I don't count that I will have more than 10 users online (wow, that would be something ), so as said, if my project ever evolves to a state where I can show it, I'd still probably go for the VPS, and eventually upgrade (if needed)


The Go programming language really looks interesting. I am happy that Google is it's parent, as that makes it more reliable, I think.
Will still have to look into it, though.

@EDIT

Just had a look at Go. Well, it has some of it's own rules
Went through 35 pages of tour and didn't really want more. Well, we'll see.

[OneMoreGo]

Yep, i'm using a DB along with some in process caching for mine. Some is normalised data, some is stored serialised, it varies based on use. I haven't gone overboard with optimisation but I do know the path I will take should I need to (then you get into fun aspects like realising you could do with wildcard SSL).

512mb is fine for a linux server running a DB, a web site and something that serves up game data, you could run 100 users on it depending how intensive your game is.

I wouldn't use Erlang or C++ - both seem a bit hardcore for an already difficult project.  I would personally use Go out of the languages you mention - but start with what you can get going as easily as possible. If you know one language well use that.  You can always change slow bits later and you should save your mental bandwidth for the many challenges ahead 

[kamac]

Oh, I have the ease to learn new programming languages.. Yet. (as long as I have the motivation)

512mb is fine for a linux server running a DB, a web site and something that serves up game data, you could run 100 users on it depending how intensive your game is.

That is good news. In fact, it shouldn't be that intensive (a grid-based 2D RPG). I hope.
I'll must go for Go then, I guess. Looks the most appealing, and GC is really good to have.

@EDIT
Tee-heee. Did I say something about the ease of learning languages ?
Well, Go breaks all the rules, unfortunately