[MMO] Questions about Maps, GUI types, Team needed, etc...

[Nekusagi]

As many of the people that are visiting here, Im also interested of "My Own MMORPG". But Im much more working in a Game Logic that makes me satisfied, not exactly working in something big/huge, so, don't speak about 'how hard is it', just answer the questions (aka: I want HELP, not give up from my ideas).

[Mapping]
1 & 2) Does the mapping system change anything to the server-side? I mean, RO use a lot of 400x400 maps (almost can say that it is 2d cause you can't have same X, same Y and different Z in the same map), this is logically much more easyer to the game, but, WoW use a huge map, where you don't switch throug portals that load up the map, how hard is it?

3) In RO-type, does the size change much? I mean, make 1600x1600 instead of 400x400

[GUI Type/Modelling]
1) Speaking with Baldurk on IRC, he told me that probably (certainly?!) the engine will define the GUI type. Staying with the WoW vs RO example (my main experiences with MMO), WoW is very complex, but allows a lot of customizing, RO is much more simple, almost doesn't customise, but I know that this simple characters may be much more easyer to PC/server deal with. Now, would be harder to make a RO-like game more customizable (change character's look based in equipent) than make a WoW (or Ethernal-lands') like game?

2) I know that the characters is based in sprites (something like a lot of animated gifs), character's equipments are
A) Sprites layered over the character's sprite
B) A different sprite than the charaver's last sprite
C) Can be used both (in this case, could you explain how it work?)
D) How many sprites a character need (at last)?

[Development Team]
1) I read an arcticle about the team that developed EL, it made me wonder: To develope a RO-like game, how many time and professionals would be needed?

Obs:

I know those aren't exactly easy questions, also know that I should read a book. But in Brasil we don't have enough material (I think this year has started the first Game Dev University here), also, I want make the game logic, if start reading soon I'll leave my plans and give up about it.

Thanks for the attention

[geon]

Mapping: The size of your world should be irrelevant if properly implemented. Of course, i it is tile based and you use int's to store the coordinates, you would have a built-in limit of ~2x2 billion tiles. But you would run out of memmory far before that... Still, if your world consists of a less than a million tiles, it shouldn't really be a problem.

If there is a limit smaller than that, it is probably to make it easier to implement. And you should ask yourself how big maps you actually need/have time to make.

GUI:

1) I wouldn't consider charakter customization part of the GUI. The gui would of course be involved, but as long as you have the basic GUI widgets, it should be enough.

2) The charakters don't need to be sprite-based. The RTS games my brother plays all have true 3D charakters. Sprites vs. 3D is simply a choice in style and technology.

C) Have a look at www.elouai.com, it should give you some ideas about how a charakter can be built up from several sprites.

D) Depends completely on your own requirements. How fluid should your animations be? from how many angles shoul you be able to see you charakers? How many (visible) items do you want? Multiply these, and you should have a rough estimate.

Team: Several years and tens of proffessionals.

[Nekusagi]

Mapping: So, based on this, I could make a 10kx10k kingdom map, with 400x400 feudals (google translated), and it wouldn't be a problem? What about the client memory load?

Im researching about 3D x Sprites, at this time seem that there's no difference using one or another, but, having a lot (100+) characters on screen, wouldn't it be a problem in any of them? Ragnarok use sprites, I see cause it has 4 main angles, but with ~100 people in the screen even a 700+ MB Ram PC start getting slow... even more if using skills

About game engines, does it limit the skill system that I can use? What about stats(atributes)?

[geon]

I could make a 10kx10k kingdom map, with 400x400 feudals (google translated), and it wouldn't be a problem? What about the client memory load?

10000x10000 = 100 millions. If you need one byte per tile, that's a 100 MB allready! To much. A better idea would be to just store the coordinates of all your objects. Let's say you actually use a million objects (you won't), they could require maby 16 bytes, I dunno. Thats 16 MB. Quite handy.

BUT! Your client will only need to know about the world in the immediate neighbourhood. Make the server keep track of what the client needs to know, and only send that part.


About game engines, does it limit the skill system that I can use? What about stats(atributes)?

This should not be a part of your engine, but the game logic. It might be a good idea to script it to be able to quickly prototype a working system. Once you are done, you can decide if you nned to optimize it or if the script-based code is OK.

[Nekusagi]

BUT! Your client will only need to know about the world in the immediate neighbourhood. Make the server keep track of what the client needs to know, and only send that part.

So, I could use server-side a 10kx10k, but client-side about 300x300 (most of times it would be about 30x30) without much problem in memory load?!

This should not be a part of your engine, but the game logic. It might be a good idea to script it to be able to quickly prototype a working system. Once you are done, you can decide if you nned to optimize it or if the script-based code is OK.

Very interesting this too... where may I find information about how the server's scripts would contact the engine? Or (maybe the silliest question) when we talk about engine is the client-side engine and only client side? everything else will be up to my script system?

[geon]

Yes, you could have the client handle a much smaller world than the server. A good idea could be to divide the world into "blocks", so the client can unload blocks it is not currently using.

To prevent cheating, everything "important" should be handeled by the server. This includes any transactions, such as money and items, but also who kills who etc. Since this is what the scripts would manage, they need to be on the server side only.

A general rule of thumb is that the engine should include anything that is needed to make a game of a similar "genre". For a socker game, you might not make a socker engine, but a "team sports" engine. An engine is usually more general than the actual game.

I was playing with some code for puzzle game a'la Tetris. I decided to not make an "engine" for it since the advantage would be pretty low in that particular case. However, a possible engine would include a playing field of 8x16 pieces, possibility to move the pieces from cell to cell, add new pieces, time limits, find pieces to delete (full rows), count chains, count points and generate "garbage" pieces. An engine wich manages all these features on the server side, could use the same engine to play virtually any "falling blocks" game.


I recomend you to read this: http://www.devmaster.net/articles/mmorpg-postmortem/part1.php

[Nekusagi]

Yes, you could have the client handle a much smaller world than the server. A good idea could be to divide the world into "blocks", so the client can unload blocks it is not currently using.

I see, your information is really cleaning the path to me!

I just got curious about this map thing, using blocks, would I need use 'warp points' to travell between the blocks? cause I want avoit it as I can :-/

[Polar Sleuth]

No, you don't need to use warp points. Anytime the client's character gets close to a block edge, the client requests the neighboring block. The graphics from that block can just be added to the on screen graphics as needed. It has the advantage that the client only needs the immediately visible area, plus maybe an extra block or two. Block size should be large enough that travelling acrossed it will provide ample time for any neighboring block to be loaded.

Warp points should be used as a means of controlling the rate of the players' movements. And to keep them in an area of adventure for a desired amount of time.

Blocks are just a means of dividing the map into chunks that the client can more easily handle.

[Nekusagi]

I see...

Well, thanks a lot for the 'class', it helped a lot to understand how the game works.

[AticAtac]

One interesting question in MMOs with "true" 3D is who should do collision detection ? I think and believe that in all existing MMOs now the clients do the majority of collision detection. For the server where some 1000 players are connected it would be just too much. But maybe there can do some "checking" from time to time to prevent cheating. "Performance" vs "No-Cheating" is an important and big trade-off you have to do.

[Nekusagi]

it makes sense... I believe that in server side could be made a small version of it, not much complex, but, like a lazy code, avoiding use the same space, something like that.

Anyway, don't servers host a "imaginary map"? I mean, a logic map the textures, wich would help on it?!

[MickJagger]

it makes sense... I believe that in server side could be made a small version of it, not much complex, but, like a lazy code, avoiding use the same space, something like that.

Anyway, don't servers host a "imaginary map"? I mean, a logic map the textures, wich would help on it?!

Hello Nekusagi!

Absolutely! When developing a MMO game, always keep in mind that you should never trust the client. The Server is the main authority, unless you do not care about cheating and hacking. While the client may have a local copy of the maps - containing only information about static objects - to reduce bandwidth consumption, the server has the complete copy of the map containing all crtical information. The server must be able to verify the validity of every input coming from the client. So, whenever it receives a packet containing something like the latest x movements of a player character from the client, it must verify the validity of that input. For example, is the path described by the client compatible with the map position where it should have taken place? If the player character, in order to perform the movement sent by the client to the server, has walked through an impassable object like a mountain, then something is not working, and the server must take action. The kind of response can vary according to the severity of the infraction and the threshold you have set for these infractions (for example, if your client engine is still buggy or imprecise, a small error could be acceptable).

But if you think about it, if the server hand't all maps stored in a well ordered format, how could it spawn enemies? How could it control them? And so on.

Remember, in a safe MMORPG environment, the server is god. The client can try to fix the holes in between packets in order to render a smooth experience on screen, but all critical decisions (and map layout is obviously the basis of a simple MMORPG) happen server-side and are enforced on all affected clients.