MMORPG map format questions

[mvanga]

I am trying to develop a small scale MMORPG and am having doubts about the map format to use for the levels.

1. While a tile map format is very easy to validate on the server side, the rendering on the client side is very "blocky" and not visually appealing.
2. A quake 3 map format for each map.

I wish to go for the second option, although I'm having trouble figuring out how to validate moves within the game. How exactly can I keep a representation of the map on the server and validate every players move with that representation? I don't want to keep the validation of moves (eg. moving forward causes a collision...so don't move) on the client side in order to reduce cheating.

I was thinking of using a NULL video device with irrlicht and using newton for collision detection *on the server*. Is that a viable option or will it be a waste of server processor time?

[egrath]

Hello,
i can't directly answer your question, but maybe you can take a look at the Source for the Dawn of Light Server (which is a Freeshard Server for the commercial Dark Age of Camelot MMORPG).

I think they already have solved questions like yours because their Project is very mature (stable since 2004).

Egon

[mvanga]

Thanks for that information egrath! I'll take a look at the code!

For now, for a quick prototype, I think I will render the maps into a single huge world on the server (using the NULL device of course) and do all the movements and physics in that world while sending updates to the users.

This brings up another issue. How do I figure out which player objects are actually visible to a specific client in order to send him updates of those players? In a tile based game, one would simply loop a 2D subset of the world around player and send updates to any players on those tiles. How does one do this in 3D? Is there any functionality in Irrlicht to do something like this (finding all the IPlayerSceneNode's within a certain radius maybe?)?

[egrath]

Hello,

1.) Subtract the two position vectors to get the direction vector
2.) get the length of the direction vector
3.) if the length is greater than the radius, the point is outside your "visibility" circle, else it's in.

Egon

[mvanga]

Thanks egrath! While that might work, I imagine it would take a lot of CPU cycles to loop through every point within a radius in all 3 dimensions. To add to that, it would have to be done for every single player and on every event that is generated by a player.

It also does not address how to find out if a scenenode is actually at that point. I would have to loop through all the current scenenode's and check their bounding box and see if they lie in any of the points above.

Easier than that would be to loop through each player and calculate their distance from a client and if they are within the radius...send them an update. Even that would get horribly slow if it had to be done for each player, when a lot of players are connected!

Is it viable that every time a move is made by a player, the player is registered or de-registered from nearby players' "near_players_list"? I suspect even that would be quite CPU intensive.

Any suggestions?

[bitplane]

Any suggestions?

Try a smaller project than an MMO

[mvanga]

A lot is there to be learnt from writing an MMO!

[bitplane]

Okay I'll humour you.

There should be many versions of your map-
1) The visible geometry, for the client. This should have multiple LOD levels (say 3?) so that you can show everything on screen at once. It should be split into tiles for ease of downloading, let's call each tile a "zone".
2) The collision geometry, for the client only. This is a simple version of your map that is used by the physics library, it is sent to the client and must be verified to prevent cheating.
3) The logical representation, for your game logic server. This just says which zones can be accessed and seen from another zone.

Your world editor needs to generate all five of these meshes for each zone. Enjoy!

[mvanga]

I would like all my physics and collision detection to take place on the server side. I think most probably I will run Irrlicht and Newton on the server and keep sending updates to the players.

For simple rendering of the terrain on the client, I can use a textured version of the server terrain file. This can be done easily enough.

As for verifying user maps, a hashing algorithm would probably be more efficient. The hash can be calculated and stored in the server. Every time the user changes to a new map, the hash is calculated by the client and compared with the servers.

What I am wondering now is whether it is wise to run Irrlicht and Newton on the server side with a EDT_NULL device. Is there any other way to do this? How are you veterans doing it?

[CuteAlien]

What does small scale MMORPG mean? For 2 players? I can't really help you with developing a real MMORPG - I don't even know if anyone in germany here has already written one. At least I haven't heard yet of one.

But if you maybe just start with an online-game and ignore the "massive" part completely, then you can actually use a NULL video device and maybe even Newton (I never used Newton myself, but I've been part of a team which used ODE and that worked). This should be fine for the typical case of running a game with one or two handful of players. The system might start to break down with a 2-digit number of players to handle (but then again I didn't try out yet). So it could be already fine for running a diablo-like game when you can afford to have 1 PC per instance.

But for mmorpg - I really don't know how they do it. Probably they start by measuring every part of a typical online game and then start developing architectures based on having those numbers. Maybe they run different collisions on client & server where server collisions are cheaper (like only checking if persons still move in valid areas or comparing the results of different clients) and add a bunch of validation checks (like how fast did the client move). Or maybe they just use enough hardware that they can simply run enough instances (because hardware is often cheaper than developer time).

[m_krzywy]

All the models and stuff should be in the game client. You send their position while connecting/loading. For moving characters you get their position and vertical and horizontal radius. You send it to all playes that can see that character (to all in segment) Large map must be sliced to segments like it is in WoW.

Try playing some WoW and see how it's done there

[mvanga]

Thanks for both of your replies! The game I am building is basically something that students can play on the LAN at my school. I'm expecting numbers to be around 30-50 players. That's what I meant by small scale!

Also, with 3D terrain, I don't see any other way except to run all the physics calculations on the server side (eg. with newton). Which is why I asked in case there was a better way

I've started building the server using the NULL device for now and it seems to be working decently enough with 2 clients connected (lol!) and I'll just try to optimize this architecture as I go along

Thanks for all the help

[Dark_Kilauea]

Alright, I'll humor you and explain some of the basics. First of all, if you want to be able to edit this easily, I might suggest you set up a database (could use mysql) to store the positions and properties of objects in the world, instead of relying on text/xml files (or worse, hardcoded maps). Although you could distribute said map files to your clients, you'd have to do so every time you make a change, which gets painful. When a client connects, it can then receive information about the properties of objects upon asking and load the world.

If you really want to go with a non-database solution, then you need to make a region file type (since you probably don't want to use the base irr scenegraph xml files and you definitely don't want to use them unmodified). This file should contain all the properties of your game objects. Just keep in mind that outside of very minor changes, every update requires you to hand out new copies of these region files.

Since your player base is so small, you shouldn't need to design your servers to be clusterable, so a single application may be appropriate. However, you need to handle a few things.

1. Login in, Registering new accounts, creating characters (including downloading available options for creation from server), selecting and using a character. You might also want the ability to ban an account for an amount of time or support giving someone special commands, which case you need to support permissions on either an account or character level.

2. Sending update packets to and from the clients. World update packets should probably be sent on a time step and updates to objects should be batched together so one packet contains updates for several objects. Otherwise, routers tend to get behind if too many packets (especially UDP) are in flight.

3. All gameplay related calculations should be done on the server. This means movement, casting spells, shooting projectiles, trading, whatever. NEVER TRUST YOUR CLIENTS. If you insist on the clients sending the position their character is at, double check that with the server's interpretation and if there is a difference detected, the server should always win. You have no idea how many games have problems with trusting their clients too much, and not all problems are do to potential cheating. Syncing the world state is a pain if clients are trusted to be right. You do need to do physics on the server. (Why do you think most MMO's don't have realistic physics? It gets expensive fast.)

4. You need a reliable way to send updates to your client software and content. Either do this automatically with your client, or host the latest version somewhere and have a reliable way to tell everyone to get it. Make sure you have a version number in the client executable (or verify the hash/version number of each content file) to make sure everyone has the latest version. If someone is not at the latest, they should not be able to log in.

Now, if the world is any decent size you should probably split it up into regions. Each region should have its own definition file (if you go that route). Either setup portals that clients need to cross to get to the other region, or load the other regions on the fly. The server should count each region as a separate instance when doing gameplay calculations, unless your world is seamless (no loading screens), then it gets much more difficult. I'm going to go ahead and assume you are not trying to do a seamless world.

Another thing, don't rely on irrlicht scenenodes for gameplay calculations! I know they are extensible, but you really should wrap them in a class of your own and treat the scenenodes as just a component. Each separate type of gameplay object should be its own class, all inheriting from the same basic interface (ie. A IGameObject base class, then CPlayerObject would inherit from it and add a scenenode pointer and some other things). Your server might be able to get away with not using Irrlicht at all, but using the null device should be fine and allows you to take advantage of Irrlicht's utility functions and classes.

[ariejan]

On the topic of a 'small MMO':

It's a *very* good idea to make one. Basically, you first decide how your core mechanic is going to work. Most RPG use some form of combat.

Your MMO has two main parts:

Infrastructure: this includes your hardware infrastructure, but also the server code, client code, including using the core mechanic and secondary mechanics for your game.

The other part is content. Maps, levels, items, NPC's, quests, etc.

Your aim should be to get the first part done correctly, while keeping the second part small.

During the pre-production phase, you should build the infrastructure and only a small, but AAA quality, part of your content. This will allow you to show others (other developers, modellers, investors, your mom) how the game will look and feel.

Build the infrastructure incrementally by adding one feature 100%, then move to the next feature.

When you decide the 'small MMO' is fun, you can hire more artists, developers to produce the content for your MMO (production phase). And you'll be on your way

[asparagusx]

This is very interesting reading.

What would the proposal be for the server side implementation - use C++ for speed and reliability or use some other development language such as Java?

What about the client? Should this also be a C++ custom app, or should it be browser based e.g. using Java?

If you placed your world inside a MySQL database, you would obviously include ALL the properties of characters etc in e.g. modelling data (SMeshBuffer?) would be stored as a BLOB of some kind?

How do you prevent cheating - every packet that is sent needs to be encrypted to ensure that it sent/received by an actual client and not some kind of hacker device?

What about terrain? Is that also stored in a MySQL table?

Reading all this, does show you what is really involved in developing any kind of successfull system - there is a huge amount to think about. I think people nowadays simply do not appreciate the amount of work/dedication that is really needed to develop anything worthwhile.

Asp