diff options
author | Bjørn Lindeijer <bjorn@lindeijer.nl> | 2005-02-18 23:59:43 +0000 |
---|---|---|
committer | Bjørn Lindeijer <bjorn@lindeijer.nl> | 2005-02-18 23:59:43 +0000 |
commit | 93780e52a05ead59154811767edfd5573617a65f (patch) | |
tree | 18d5a0552f5fd8056e67b797c467044c3bac3797 /docs | |
parent | b814d15b1796e20696659b171182a135ba9efce5 (diff) | |
download | mana-93780e52a05ead59154811767edfd5573617a65f.tar.gz mana-93780e52a05ead59154811767edfd5573617a65f.tar.bz2 mana-93780e52a05ead59154811767edfd5573617a65f.tar.xz mana-93780e52a05ead59154811767edfd5573617a65f.zip |
Updated architecture.txt document a bit and added the minutes of this Friday's
developers meeting.
Diffstat (limited to 'docs')
-rw-r--r-- | docs/architecture.txt | 47 | ||||
-rw-r--r-- | docs/meetings/dev-20050218.txt | 50 |
2 files changed, 80 insertions, 17 deletions
diff --git a/docs/architecture.txt b/docs/architecture.txt index 14e77401..53117bf1 100644 --- a/docs/architecture.txt +++ b/docs/architecture.txt @@ -11,13 +11,14 @@ SERVER ARCHITECTURE 7. DATABASE 8. REGISTRATION + 1. INTRODUCTION -One of the most important thing in a online game is the architecture of -the server system, which reflects in permormances (lag and denial of -service), scalability, fault tolerance. In this article we will examine -the pre-existing model and we will evaluate a way to improve it and to -add custom fetures. +One of the most important thing in a online game is the architecture of the +server system, which reflects in performances (lag and denial of service), +scalability, fault tolerance. In this article we will examine the pre-existing +model and we will evaluate a way to improve it and to add custom features. + 2. RO REVIEW @@ -25,25 +26,30 @@ Let's start by taking as reference the current server system used to play Ragnarok Online on the euRO server. (www.euro-ro.com) RO works by using 4 kinds of server: - - Login Server (L): takes care of verifying accounts with - username-password system, allows also encrypted login. - - Char Server (C): saves every player status (stats, items, equipment, - skills and so on. + - Login Server (L): takes care of verifying accounts with username-password + system, allows also encrypted login. + + - Char Server (C): saves every player status (stats, items, equipment, skills + and so on. + - Map Server (M): the real game server, work as interconnection between - clients, manage chat, monster AI, damage calculations and everything - you can see in game. - - Inter Server (I): probably manages the messages between the other type - of servers. + clients, manage chat, monster AI, damage calculations and everything you can + see in game. + + - Inter Server (I): probably manages the messages between the other type of + servers. In euRO there are 1 login server, 1 char server, 1 inter server and 14 map servers. + 3. EATHENA MODEL The eAthena system mirrors the way used by official RO servers. eAthena implements 3 servers: login, char and map. It is allowed to have more than one map server at a time. Every server communicates with all the others. + 4. TMW SERVER The basic idea of TMW server architecture mainly is the same as the one used by @@ -60,6 +66,7 @@ The login server manages new connections and stores all the informations about the player. The map server is pretty the same as the eAthena one. The login server manages also connections to a new map server when changing map. + 5. TCP - UDP RO is TCP based, mainly because you use the mouse to move the player. When you @@ -67,12 +74,15 @@ want to reach a point on the map, you click on it and the client send a packet to the server with destination coordinates. The server replies with an agreement if there's a path to that way. Using this way you don't need high speed nor a lot of packets, so TCP it's pretty enough. + With our custom server we want to achieve pixel movements, by that we mean that the player is not always positioned in the center of the tile, but will have fine coordinates. + Asking the server if every destination coordinates is walkable means a lot of traffic from and to the server and probably will result in lag. Using UDP will probably help avoiding this problem. + An idea could be using the system used for racing games where speed is fundamental. When you press a key to move, the client sends a packet with starting coordinates, direction and client time. When you release the key (or @@ -80,6 +90,7 @@ change direction) the client sends another packet with current coordinates and client time. According to the player speed the server check if the coordinates are right, if not reply with a packet with the correct position. + 6. SECURITY Solutions to keep the server working and avoid unfair players. @@ -90,14 +101,16 @@ Solutions to keep the server working and avoid unfair players. - Cheating/Botting: * First of all just keep every calculation done by the server. - + + 7. DATABASE Player data should be stored using databases, probably MySQL. This way player infos could be easily accessed trough web. + 8. REGISTRATION -Still to decide if we want to use a dialog (client registration) or to use a web -based interface (web registration). -
\ No newline at end of file +Still to decide if we want to use a dialog (client registration) or to use a +web based interface (web registration). + diff --git a/docs/meetings/dev-20050218.txt b/docs/meetings/dev-20050218.txt new file mode 100644 index 00000000..5f254ffa --- /dev/null +++ b/docs/meetings/dev-20050218.txt @@ -0,0 +1,50 @@ +---------------------------------------------------------------- +Minutes of the TMW Dev Meeting at Friday, 18th of February, 2005 +---------------------------------------------------------------- + +Presence: Hammerbear, ElvenProgrammer, zenogais, Rotonen, maci +Timespan: 0.75 hours (21:00-21:45 GMT+1) + + +* We agreed to try a monthly release schedule. So with 0.0.9 released on 30th + of Januari, 0.0.10 is scheduled by the end of this month, with the next + version the month after that, etc. This should remove any doubt about when + the next release is from both team members and players. + +* With the 0.0.10 release less than 2 weeks away, we have still set the + following set of goals to be reached by then, on top of changes already made + since 0.0.9: + + - PhysicsFS usage for loading data from packages (zenogais) + - XML map loading so that Tiled is supported (Hammerbear) + - New GUI look (Bertram) + - More functional inventory/equipment (ElvenProgrammer) + - New tileset (the artists) + - New, expanded, city map (Chetic) + + These are all important milestones in the development of The Mana World, + and they don't go too far in the sense that things will need to be re-done + a great deal when we start working on our own server. Whatever isn't finished + by the end of this month will have to wait for 0.0.11 or 0.1.0. + +* If you haven't noticed already, we have a new team member, his name is + Kyokai. He's been writing on the forums, wiki and has been in discussion on + IRC, in order to involve everybody who would like to get involved in the + planning of our own skills and advancement system. A general concensus seems + to be almost reached, with specific parts still being discussed. Pretty soon + Kyokai could start to implement this system. Be sure to stay informed about + this development if you care about where TMW is heading in this area. + +* Rotonen is in need of a co-director in the art department. Rotonen is + currently the central contact point for the artists. The co-director will + have to know what needs to be done and what has been assigned to each artist. + The most important part may be to comment on the work of the artists, to + answer their questions and to give them directions. + +* maci asked wether Tiled has a feature to export the map as an image, and this + feature is indeed available. It would be nice if the result could be used to + create a nice looking minimap of the area. + +* Elven Programmer added an interesting part about server architecture in + docs/architecture.txt. Anybody who's interested or involved in development + of the server part should read this. |