diff options
| -rw-r--r-- | docs/architecture.txt | 130 | ||||
| -rw-r--r-- | docs/items.txt | 139 | ||||
| -rw-r--r-- | docs/progression.txt | 33 |
3 files changed, 254 insertions, 48 deletions
diff --git a/docs/architecture.txt b/docs/architecture.txt index 53117bf1..7cd54d53 100644 --- a/docs/architecture.txt +++ b/docs/architecture.txt @@ -10,6 +10,9 @@ SERVER ARCHITECTURE 6. SECURITY 7. DATABASE 8. REGISTRATION +9. SERVER CONTROL +10. OPERATING SYSTEM +11. ADVANCED DATA TRANSMISSION 1. INTRODUCTION @@ -23,7 +26,7 @@ model and we will evaluate a way to improve it and to add custom features. 2. RO REVIEW Let's start by taking as reference the current server system used to play -Ragnarok Online on the euRO server. (www.euro-ro.com) +Ragnarok Online on the euRO server. (www.euro-ro.net) RO works by using 4 kinds of server: - Login Server (L): takes care of verifying accounts with username-password @@ -64,16 +67,47 @@ melt togheter. 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 +server manages also connections to a new map server when changing map. Having +only one server (L) to manage all the connections between clients and map +servers is a bad point: if the login server crashes players won't be able to +play anymore. In fact new connecting players won't be able to connect to login +server, while map server will disconnect every player, since they can't save +their infos. +The solutions are: + + - implementing a distributed login server which can manage crashes and + redirect new connections to another login server. This way means a more + complex implementation and probably the need to other computers since we + want the login servers to be independent from each other crashes at all. + (Remember this is a free project so we should limit the number of + computers to act as servers) + + - RALS (Redundant Array of Login Servers): we can have two login servers, + only one of them is active at a time and they share the same database + where to store infos about players. If one of the map servers loose the + connection with the login server enables the other, while the crashed one + restarts. Even if it restarted is it now considered disabled. The new + active login server will send messages to every map server to inform them. + Every time a client connects check both of the login server and connect to + the active one. The bad points of this system are that will imply a lot of + data consistency checks: map servers should resend last data since it + was lost when the login server crashed, the new login server should check + if some of the data was already stored before the crash, what if both of + them crash? + + - waiting it's the only solution! Let's design the login server as much + simple and stable as possible and create a smart restarting system. + This way we will have less frequent crashes and a very low restarting + time. Obiouvlsy this is the easiest and less expensive solution. + + +5. Network protocol: TCP RO is TCP based, mainly because you use the mouse to move the player. When you 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. +speed nor a lot of packets, so TCP it's 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 @@ -81,19 +115,39 @@ 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. +probably help avoiding this problem, but having a reliable protocol such as TCP +will make things easier and more stable. We just need to design an efficient +prediction system (probably also a linear one will suffice). -An idea could be using the system used for racing games where speed is +An idea could be using the system I used for a racing game where speed was 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 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. +client time. According to the player speed and the difference of client times +the server check if the coordinates sent by the client are right, if not reply +with a packet with the correct position. The server also check if the time +interval sent by the client is right: if not it means that the values have been +hacked or the lag corrupted them. We can set a tolerance value: if the time +interval exceeds the tolerance then the whole movement is discarded and the +server send a packet to tell the client to place the player at starting coords. 6. SECURITY -Solutions to keep the server working and avoid unfair players. +To certificate authenticity of the player we can use a system based on digital +signature and hash (encrypted login). + +Better security can be provided by encrypting payload of packets using RSA +algorytm. When logging in the client generates both its public and private key +and will send the public one to the server. The server acts the same: when it +starts it creates both the key and replies to login with its public key. +Using encryption will reduce client/server performances because this will need +a lot more calculations. +Furthermore if using digital signature will introduce a lot of overhead. +So there's still the need to discuss if we need to use encryption not only in +the login part. + +Solutions to keep the server working and avoid unfair players: - DoS attack: * Account activation. @@ -101,16 +155,68 @@ Solutions to keep the server working and avoid unfair players. - Cheating/Botting: * First of all just keep every calculation done by the server. + +Also we need the possibility to warn/kick/ban players/accounts/ip addresses. 7. DATABASE Player data should be stored using databases, probably MySQL. This way player -infos could be easily accessed trough web. +infos could be easily accessed trough web and used to show stats or required +infos on the website/forum. 8. REGISTRATION Still to decide if we want to use a dialog (client registration) or to use a web based interface (web registration). +Registration should ask for less details as possible. This way it will be less +annoying. Required infos will be: + + - username + - password + - email (to limit account number and to be used to activate account) + +More infos could be added later for security problem (such as activation codes +and so on). +In RO you also have to choose the sex of your player. It will be better to let +the user choose the sex when creating the player: this way he can delete is male +player and create a female one. + + +9. SERVER CONTROL + +The server can be controlled in two ways: + + - In game control: server admins or GMs sending particular commands or a + trough a GUI (the way it is used in Ultima Online). + + - A graphical interface which connects to the server trough an open port. + +The prefferred way is the first one. + +10. OPERATING SYSTEM + +We have two choices about this: the former is to follow as for the client the +cross-compatibility philosophy. This means that the server will compile on every +windows, unix, macos based system. The latter is to choose the best performance +system (probably linux) and implement a unique os server. +Just remember that the current game server run on linux. + + +11. ADVANCED DATA TRANSMISSION + +Other ways to reduce bandwidth can be considered such as: + + - Using bitstreams instead of bytestreams: this way if you need to send a + boolean values only 1 bit will be required instead of 1 byte (compression + 8:1), item types (4 different types) can be represented sending 2 bits + instead of 1 byte (compression 8:2), player coordinates can be represented + using 20 bits instead of 4 bytes (compression 24:20) + + - Compressing data following packet id could help reducing bandwidth usage + as well. RLE compression or more advanced statistical techniques can be + used. Compression can be disabled in very slow systems (If using + compression is declared to the server when the client connects to map + server.
\ No newline at end of file diff --git a/docs/items.txt b/docs/items.txt index beaa2ab1..e31f4904 100644 --- a/docs/items.txt +++ b/docs/items.txt @@ -4,34 +4,137 @@ THE MANA WORLD INVENTORY SYSTEM 1. INTRODUCTION 2. DATABASE -3. EQUIPMENT +3. INVENTORY +4. EQUIPMENT +5. IMPLEMENTATION +6. SPECIAL ITEMS +7. PROTOCOL +An item will have the following properties: + +C means info is used only by the client +S means info is used only by the server +C&S means info is used by both -1. INTRODUCTION +- id (C&S) -> unsigned int + + a positive integer uniquely identifying an item. -The inventory system will be based client side on a database realized by an XML -document. The database will contain a list of all the items available ingame. +- image (C) -> unsigned int + + used if same images are used for different items. + Maybe we need more image ids to tell which image (bigger one) to show in + equipment window or when equipping items in weapon slot. +- name (C) -> char[30] -2. DATABASE + to be shown in inventory. + +- description (C) -> char[100] + + a brief description shown in shops, or in the inventory + +- type (S) -> unsigned char + + server uses it to check if is an item or an equipment and send the + appropriate packet. + + * USABLE_ITEM (food, potions, ...) + * EQUIPMENT_ITEM (weapons, armors, ...) + * SLOT_ITEM (cards, materias, summoned beings, ...) + * SLOTTED_ITEM (bags, small chests, ...) + +- identify (S) -> unsigned char + + the server will check this flag if the items can be identified by the + player. + + * IDENTIFIED no need to identify the item + * IDENTIFY_ITEM you can identify it by using a special item + * IDENTIFY_MAGIC you can identify it by using a particular spell + * BLACKSMITH needs a blacksmith to be identified + * WIZARD needs a wizard to be identified (enchanted items) + * ANCIENT_BLACKSMITH + * ANCIENT_WIZARD + * NOT_IDENTIFIABLE reserved for future use + +- weigth (S) -> unsigned short + + used by server to calculate if the being can carry more items. + +- # of slots (C&S) -> unsigned char + + if this field is greater than 0 it means this one is a slotted item. + (Probably we can remove SLOTTED_ITEM from the type enumeration) + For example a bag will have 4 slots, while a chest about 10. + +- script (S) -> probably a file name to reference the script file + + script to be executed when item is used/equipped. + -The XML document (name to be defined, suggested items.xml) will contain a list -of items. An item can have the following properties: +3. INVENTORY -- id (a positive integer uniquely identifying an item) -- image (used if same images are used for different items) -- name -- description (a brief description shown in shops, or in the inventory) -- type (weapon, food, armor, stone, and so on...) -- properties (probably a series of flags) +Inventory will contain any kind of weapons including non equipped items and +slotted items. Every being will have a variable number of slots to store items. +For example a maggot won't have any slot, while players could have a number of +slots depending on his strength. A pet could have one slot used to add a bag and +help the player carrying items. -3. EQUIPMENT +4. EQUIPMENT Every being will have a variable number of slots to equip items. For a player we will have 6 slots: head, upper body, lower body, feet, left hand, right -hand. +hand. We can also add slots to equip rings, whistlet and elbowpad. + + +5. IMPLEMENTATION + +Since both client and server will only need to store item ids, inventory and +equipment can be easily coded as unsigned int arrays. The only problem is +about slotted items. They for sure can't store another slotted item, but it's +hard to represent them as an int. Probably a more complex structure is needed. + +struct ITEM_HOLDER { + int id; + int quantity; + ITEM_HOLDER *item; +} + +ITEM_HOLDER inventory[number_of_slots]; +ITEM_HOLDER equipment[number_of_slots]; + +If item is not NULL it will reference an array of items stored in the slotted +item. + +How to limit the quantity of items? We could have a fixed number of slots in the +inventory. In one slot you can store only items with the same id (except slotted +items which need separate slots). When you pick up/receive a new item, total +weigth you can carry is checked if the item can be stored. + +6. SPECIAL ITEMS + +A special case is represented by arrows holder. Three solutions will apply: + + - equipment will have a special slot where you can equip only arrows + (or stones) + + - item with one slot + + - arrows can be simply stored in inventory + +Weapons can store a limited number of items in their slots. In this kind of +slots you can store materia, demons or arrows. Some examples: + + * arrows holder = max 100 arrows (1 slot) + + * sword = max 1 materia + 1 demon (2 slot) + + * magic sword = max 2 materias (1 slot) + + * sword of cahos = max 1 materia + 2 demons (2 slot) + +7. PROTOCOL -To equip an item you should go to the inventory, select the desired item and -push the "Equip" button. To unequip, push the "Unequip" button in the equipment -window. Unequipped items should automatically go back in the inventory. +To be defined.
\ No newline at end of file diff --git a/docs/progression.txt b/docs/progression.txt index e5527936..ce348170 100644 --- a/docs/progression.txt +++ b/docs/progression.txt @@ -1,10 +1,13 @@ --------------------- -Player's Progression --------------------- +----------------------------------- +THE MANA WORLD PLAYER'S PROGRESSION +----------------------------------- +1. PLAYER'S STATS +2. PLAYER'S STATUS +3. AN ATTACK PROCESS +4. LEVELS -Player's stats : ----------------- +1. PLAYER'S STATS Strength : The Strength determines how much a player will physically damage an enemy. @@ -30,8 +33,7 @@ level 1. A Stat must have at least 1 point given to it. The Player earns 1 point for each level he reaches. -Player's Status : ------------------ +2. PLAYER'S STATUS HP : Hit Points. How much a player can be hit before dying. HP = (3 * Vitality) + Strength + Level @@ -62,8 +64,7 @@ Evade (%) : Indicate the chance a player has to evade an opponent's hit. Evade = ((3 * Luck + Spirit + Vitality )/5) (Max : 75 %) -An Attack Process : -------------------- +3. AN ATTCK PROCESS An attack process is quite simple : The Hit(%) of the attacker is taken, minus the evade of the opponent. @@ -77,8 +78,7 @@ Then, the attack plus the its modifiers (weapons attack upgrade, items bonus, HP. -Levels : --------- +4. LEVELS The XP-For-The-Next-Level of a player is calculated with his/her class number. Cf. Class Number for more information. Higher is the class, higher is the class @@ -92,8 +92,7 @@ xp for next level. N.B. : A player earns 1 stat point for each level he reaches. -Job Points : ------------- +5. JOB POINTS Job Points are used to get skill points, that can be used to learned and reinforce special skills, which can be acquired by being of certain classes. @@ -105,8 +104,7 @@ Job points are obtained by job leveling. Job level : 20 + 2^Level + Level. -Classes : ---------- +6. CLASSES A player can be one of mutiple classes ; A wizard is different from a archer, and can't held the same weapons, armors, etc... A score is associated with each @@ -123,10 +121,9 @@ Peon 17 Double Hit, Hard Hit(JL:5) Beginner Lvl:10 ... -Notes: ------- +7. NOTES Every of these notes have to be discussed, if you have any feedback, suggestions, updates, commit or tell them at: -address: http://irc.freenode.net channel: #manaworld +address: irc://irc.freenode.net channel: #manaworld |