MMOG tutorials?

[Unnsse Khan]

Can anyone recommend any good tutorials for learning how to create an MMOG using Java?

With thanks,

[Mike Isano]

Here is how I would go about making a massivliy multiplayer game.

Start by choosing a database.

Design your database first. MMOGs are all about data. Think about how your going to have your tables, how your going to track the items of a character. There are many different ways to do it. Also think about what will NOT go in the database. Maybe certain monsters will exist only in memory and as they roam the land you don't care about tracking their paricular info.

Next you can start with your java classes. A simple design that fits well in many circumstances (but not all) is to have a java class that represents a table of the database. For example if you have a "Player" table in the database, you'll have a "Player" class in the java. Let's say the the table has HP, MP, Name. Your class will have members int HP, int MP, String Name. Make getters and setters and other methods. In the constructor you will pass in some identifier (such as a primary key) and that will automatically retrieve the Player info from the database and stick it in your class. You'll also have a saveToDatabase() method which will automatically save the current info in the class to the database. It's a little tedious to get everything working but once it's done you'll be able to retrieve and save player info very easily from there on out.

It would look soemthing like this:
Player p = new Player(primaryKey); //player logs in
p.changeHP(-5);//player takes damage from monster
p.changeHP(-50);//ouch, big hit. player is dead
p.saveToDataBase(); //save to database. maybe lower thier exp level for dying

The above scenerio would have to be made dynamic. The calls to the methods must be done automatically (when a monster attacks) not called manually like i'm doing here. You'll have to work out the design.

Doing an MMO shouldn't be that much different than any other kind of application. Just make classes to give everything an easy interface.

[Gregg Bolinger]

"Lordly Caliber"

I can't help but disagree entirely with your mild aproach to something as complex as an MMOG framework. And what you discussed really didn't have anything to do with MMOG's specifically. It's a good DAO design pattern, however.

But imagine your scenerio. 1000 concurrent users. All Fighting each other or NPC's. For every single swing of the sword, shot of the gun, kick in the face, you are processing hit points, mana, energy, skills in defense, archery, swords, hand to hand combat, armor point reductions, spell casting...and you want to make a call to a database to update all this instantly? No way is that going to work.

From an MMOG perspective you are going to have to worry about two main perspectives. The client and the server. And you have to figure out how much the client will process and send to the server vs how much the server needs to process what it receives from the client. You'll need superb caching mechanisms in place and deal with all sorts of syncronization issues. Not to mention security.

On a higher note, I do know that Blizzard uses Java for nearly all server side code for World of Warcraft. And it has been very successful. So obviously, it can be done. I personally don't know of any tutorials that talk in detail about this at all. But there are tutorials for peer to peer network gaming which is where you might want to start anyway. Just google for it. Finding anything specific for Java will be difficult though as Java has yet to prove itself as a real platform for gaming.

Good luck.

[Mike Isano]

But imagine your scenerio. 1000 concurrent users. All Fighting each other or NPC's. For every single swing of the sword, shot of the gun, kick in the face, you are processing hit points, mana, energy, skills in defense, archery, swords, hand to hand combat, armor point reductions, spell casting...and you want to make a call to a database to update all this instantly? No way is that going to work.

You only update the database when the player dies, logs out, or is idle for 30 minutes, etc. Everything is stored in memory and is not saved to the database until death/logout/etc. Do you have to do processing whenever someone gets hit? Of course. But this MUST be done server side. If you have HP changed on the client, then cheaters can take advantage of this. (if it's just a hobby RPG it won't matter). HP on the client is just for display purposes. The "real" HP is on the server sitting inside the Players object. If the user tries to hack their HP they are only hacking some ficticious display. The server knows the truth.

If it's a serious MMORPG, then the client should only be for display and making requests to the server. I know a few commercial RPGs that are suffering from cheating becuase they put too much client side. Tibia comes to mind. They had to give up and incorporate into the game things that used to be considered cheating (auto aim magic, etc.)
[ January 20, 2007: Message edited by: Lordly Caliber ]

[Mike Isano]

Ironically, having player information centralized on the server allows players to fight each other efficiently. If this information was stored on the client you would have to go over the network to the players computer each time there was a swing of the sword. What if the other player unplugs his power cord to escape death?

The fight should take place on the server. Display info (just an array of a few integers used as enumerations which the client will use to show the whether you should see the other guy's blood splatter, shield block, etc.) will be sent back to the client.



Let's imagine a fight between two players. We have player A and player B.

Let's define some display enumerations. We could make these bytes if your worried about bandwidth.
1 = enemy is hit
2 = enemy was hit hard (lots of blood)
3 = enemy has blocked

Player A hits the attack button on his client program. This sends a request to the server. Server gets the request and the fight is on!!! A swings his sword server side. It's a hit!! Server sents back the number 1 to the client. Client sees the number 1 and shows a little blood on the enemy. Player A's sword is swung again on the server. Enemy blocks it!! The number 3 is sent back to the client. Client knows that 3 means to show the enemy blocking with his shield.

Really you would want to pass back an array of integers, bytes, or whatever becuase there will be several display infos that are needed. Like how your own player should be displayed when he gets hit, blocks, etc. Or instead of passing back an array, you could pass back a single byte and use bit manipulation to store all the display info.

You will put as much as you possibly can on the client without allowing cheating. Player info will exist client side but the "offical" player info must be in the servers memory. There's always trade offs.

[Gregg Bolinger]

Originally posted by Lordly Caliber:


You only update the database when the player dies, logs out, or is idle for 30 minutes, etc. Everything is stored in memory and is not saved to the database until death/logout/etc. Do you have to do processing whenever someone gets hit? Of course. But this MUST be done server side. If you have HP changed on the client, then cheaters can take advantage of this. (if it's just a hobby RPG it won't matter). HP on the client is just for display purposes. The "real" HP is on the server sitting inside the Players object. If the user tries to hack their HP they are only hacking some ficticious display. The server knows the truth.

If it's a serious MMORPG, then the client should only be for display and making requests to the server. I know a few commercial RPGs that are suffering from cheating becuase they put too much client side. Tibia comes to mind. They had to give up and incorporate into the game things that used to be considered cheating (auto aim magic, etc.)

[ January 20, 2007: Message edited by: Lordly Caliber ]

I'm not sure if by quoting me you are trying to refute what I stated. But I agree and never said otherwise. I was merely pointing out that the overly simplistic example you gave wasn't very realistic. It's not an avenue I would suggest beginning with if trying to learn how MMORG's work.

[Aaron Roberts]

I'm going to be overtly sarcastic and say this is a bit silly.

<sarcasm>

There's no such trivial example of MMORPG, because the problem, the data, the everything is basically not trivial.

Arguing over pseudo code or general design doesn't advance the technical implementation much.

If you want to do network game play, then I'd suggest the following -

- go write a game that allows 2 or three players to interact. Cards, shooting, whatever. Learn from the experience and see what issues came up.

- Try using somebody's framework. Frameworks are great, why reinvent the wheel I say. One such is Project Darkstar from Sun.

Once you've done that, then come back to the forums and ask specific questions on implementation details, framework architecture, etc.

</sarcasm>

Now, I must be off to do some work on a pet project.

[Unnsse Khan]

Mike, Greg, and Aaron:

Thanks for the enthusiasm that all of you display by responding to my thread!

It was a really good read!

Despite the fact that there are other pre-existing MMOG frameworks out there, I was just seeking a tutorial on how to make one.

Here's some good MMOG frameworks (open source and free), which I found:

ICE

GameGardens Toolkit (used to create this famous and successful MMOG - Puzzle Pirates )

Sorry for not responding sooner...

Thanks all for the discussion!

Cheers,

[Nathan Leniz]

I think another good example (I know you said you didn't want them, but examples can be useful) is CoffeMud. The message handling and data management implementations the author used may be worth checking out. After all, every visual MMOG is a text based game at heart.


Nate
[ January 22, 2007: Message edited by: Nathan Leniz ]

[Justin Fox]

another good server/client framework is at lloseng.com created by two guys that wrote a software engineering textbook on java. I used it in SE to make
an online battleship game, and it was really good.

Justin