Introduction to MMORPG game development

Original: Radu Privantu

Translator Preface: This is an introductory article on how to develop a MMORPG, the author himself is a game developer, the text of the content from the practice, there is a high reference value. A lot of people want to have their own games, this article for those who want to develop their own game may be a paper gospel, may be a bowl of cold water. In any case, developing a game is not a simple thing. Here is the text of the translation:
　　

The center of the article is how to start developing your own massively multiplayer online role-playing game (original: Massive multiplayer online role Playing games) (MMORPG) (commonly known as: Online game, online gaming). The target audience is the developer with limited experience and resources. After reading the article, you should know how to get started, as well as some advice on what to do and what not to do. The first step is to assess your abilities and resources. You have to be honest with yourself, because doing what you can't do will waste your time and make you feel discouraged.
　　
The first step: Evaluate your ability
　　
Required Skills:
　　
1, understand at least one programming language. To date, C + + has become the first choice for game developers because of its performance and efficiency advantages. Visual Basic, Java, or C # may also be a good choice;

2, familiar with a graphics library. The usual choices are SDL, OpenGL, or DX/D3D. (Translator Note: There are also many free/paid engines to download and sell online);

3, select a network communication library. You can choose from Winsock, Sdl_net, or DirectPlay. (Translator Note: Many people like to develop their own unique network library, which is not complicated, it seems that ACE is also a choice);

4, the game development has the general experience. For example, event loops, multi-threading, GUI design, and so on.
　　
Highly recommended skills:
　　
1. c/s structure communication;
　　
2, multi-platform development. You might want to design a MMORPG, especially a server that can run on multiple operating systems. For this, I recommend using SDL, OpenGL and sdl_net;

3, website development. This is necessary if you want users to view player stats, server information, and other information through the website. (Translator Note: In fact, the site can be handed over to others to develop, if necessary);

4, security management. You certainly don't want to waste time because someone attacked your server!

6, team organization ability. You need a team that you can successfully lead and manage;

　　
Step Two: Preliminary planning
　　
I noticed a lot of people posting in different forums looking for teams to develop MMORPG. Most of them are: "We set up a company/game studio that requires 3 artists, two programs, 1 music productions, and so on." To innovate, don't look at the past MMORPG, you have all the freedom to create the world you want, and so on. We'll pay you when the project is finished and money is earned, and so on. " Unfortunately, with the existing technology and bandwidth, you can't have a dynamic world. Moving toward an unreachable target can only lead to failure. The right approach is to come up with some small-scale, functional, extensible design and architecture. ,
　　
Basic software Architecture
　　
First, try to create a simple C/S model with the following function:
　　
1, create a new role;
2, Save the Role (server side);
3, with the role of landing;
4, can talk with others;
5, can tour in 3D space;
　　
Saving a character looks simple. For example, there are two ways to save a role: Using the database service or using a file. Both have their own pros and cons:

	Database	File
Advantages	Adding new fields or modifying existing ones is simple. Updating player stats is simple (out of the game). You can get different kinds of statistical results conveniently through SQL queries. The database is ready for you without having to do the I/O yourself. Easy to update/restore.	High-speed operation (read/write). Simple to implement. No additional libraries are required. Do not rely on the database server. So you don't have to worry about database upgrades or security issues.
disadvantages	error prone. For example, the "where" clause was omitted when making an update query. Can lead to painful losses, especially when you don't have a backup. If for some reason the database file is corrupted, you are unlucky and you may lose all player data (especially when there is no backup in the short term).	updates and restores are more complex.

Now that you've decided on how to store the role, you have to choose the network protocol for the C/s communication: TCP or UDP? , we all know that TCP is slow, but more accurate, and requires additional bandwidth. I'm actually using TCP and I'm not experiencing any problems. If you have enough bandwidth, TCP is a good choice, at least for beginners. UDP can be a hassle, especially for newbies. Remember, the initial test of the game or engine will be done on your LAN, and all packages will arrive sequentially. This is not guaranteed on the Internet. Although the packages arrive in order, they sometimes drop packets, which is usually a hassle. Of course, you can design your protocol so that C/s can recover from the packet loss. But this is very painful for beginners, it is not recommended.

Step three: Select data Transfer Protocol
　　
It looks very simple again, not really. You can't just send a string that ends with '/'. Because you need a generic protocol that can be used for both string and binary data. It is unwise to make a terminator with 0 (or any other character), because that Terminator may be part of the data you are sending. Also, if you send 20 bytes and then 20 bytes, the server will most likely receive less than two 20-byte packages. Instead, it will receive 40 bytes at a time, in order to avoid wasting bandwidth on unnecessary heads. And, you can send a 1KB package, but the server will receive it in two small packets. So you have to know where is the beginning of a package and where is the end. In the "Eternal Continent" (Translator Note: Original: Eternal Lands, the author of this article is developing a MMORPG), we use the following methods:
　　
· Offset 0:1 bytes represents the transmitted command;
· Offset 1:2 Bytes, the transmitted data length;
· Offset 3: Variable length, message content;

This approach has the same advantages: all data transmission has a uniform standard. The disadvantage is that some commands have a fixed known length, wasting some bandwidth. In the future we will change to a mixed method.
　　
The next thing to decide is the server model: "Non-blocking soket, no threads", or "blocking soket, using threads". There are pros and cons to both methods (using thread vs not using threads).
　　
Thread:
　　
1, the server response will be smoother, because if a player needs a lot of time (such as reading data from the database), this will be done in its own thread, will not affect other people. (Translator Note: Perhaps the author means that each player has a separate thread, but this is not realistic for MMORPG);

2, difficult to properly implement and debug: You may need a lot of synchronization, and a small negligence will lead to catastrophic consequences (server paralysis, object duplication, etc.);

3, can use multi-processor;

Wireless range:
　　
1, the implementation and debugging easier;

2, the response speed is slow;

In my company, we use the method of wireless, because I do not have enough resources and manpower to handle threading mode.
　　
Fourth Step: Client
　　
Are you going to do 2D or 3D games? Some people think 2D games are easy to do. I've done both, and I tend to be easier on 3D games. Allow me to explain.

You usually have a frame buffer, which is a huge array of pixel points. The format of pixel points will vary depending on the graphics card. Some are RGB mode, others are BGR mode, and so on. The number of bits per color will also be different. This problem only exists in 16BPP mode. The 8-bit and 24-bit modes are simpler, but have their own problems (8-bit is too few (256) and 24-bit slower). At the same time, you need to make your Sprite animation program and have to sort all the objects yourself so that they are drawn in the correct order. Of course, you can make 2D games with OpenGL or D3D, but it's usually not worth it. Not everyone has a turbo card, so using a 3D library to develop 2D games will generally give you the disadvantage of both: not everyone can play, you can not rotate the camera, have beautiful shadows, and the 3D game dazzling effect.

(translator note, most of the current graphics card support 565 16BPP format, this also become the current 16-bit color industry common format, a lot of articles and code is to describe this format as processing, especially the use of MMX technology)

The 3D approach, as I said, is simpler. But some knowledge of mathematics (especially trigonometry) is needed. The modern graphics library is powerful and provides free basic operations (you do not need to arrange objects from the back to front, changing the color and/or the image of the object is very simple, the light is calculated according to the light source and its location (as long as you calculate the normal vector for them), and more). And. 3D gives you more freedom of creation and movement, and the downside is that not everyone can play your game (the number of people without 3D cards may surprise you), and pre-rendered images are always more beautiful than real-time rendering.

(Translator Note: It is difficult to buy a video card that does not support 3D, but the price of high-performance 3D card is not low)

Fifth Step: Security
　　
Obviously, you can't trust users. It is not always possible to assume that the user will not be able to decipher your ingenious encryption algorithm (if you use it) or the protocol, and that any information sent by the user will be verified. Most likely, on your server, you have a fixed buffer. For example, there is usually a small (possibly 4k) buffer used to receive data (from Soket). Malicious users send extra-long data. If not checked, this can cause a buffer overflow, cause the server to crash, or worse, the user can hack your server and execute illegal code. Each individual message must check whether the buffer overflows and whether the data is legitimate (for example, the user sends "access to the door", even if the door is at the other end of the map, or "uses a potion of healing" even though the user does not have that potion, etc.). Again, it is important to validate all the data. Once there is illegal data, record it and username, IP, time and date, and illegal reasons. Check that record occasionally. If you find a small amount of illegal data and come from a large number of users, this is usually a client-side bug or network problem. However, if you find a large amount of illegal data found from a user or IP, this is a clear indication that someone is tricking the server, trying to hack the server, or running a macro/script. At the same time, never store data on the client. The client should receive data from the server. In other words, you cannot send a message like "OK, this is my list of items" or "My strength is 10, magic is 200, health is 2000/2000". Also, the client should not receive data that it does not need. For example: Clients should not know the location of other players unless they are nearby. It's common sense that sending all players to everyone will take up a lot of bandwidth, and some players will hack the client to get unfair benefits (like showing a particular player's location on a map)
　　
(Translator note: Like the legendary candle-free plug-in). All of these seem to be common sense, but, again, you will be amazed at how many people don't know what we think of common sense.
　　　　
Another issue to consider when it comes to security: the speed at which a player moves around must be calculated on the server, not the client.
　　
(Translator Note: This is an important principle, but it consumes a lot of server resources.) World of Warcraft does not do this, it uses the form similar to other players to cover up the fact, causing the acceleration plug can be used, but will be exposed when other players.
　　
The server should track the time (in MS) when the customer is last moved, and the request should be discarded if the moving request arrives faster than the usual limit. Do not record this kind of false request, because this may be due to network latency (that is, the player is delayed, the last 10 seconds to send the data arrived at the same time).
　　　　
Check the distance. If a player tries to trade with a player 10 billion miles away (or even on another map), record it. If a player tries to view, or uses a distant map object, record it. Beware of false IDs. For example, under normal circumstances each player assigns an ID (the ID is assigned at the time of login and can be persistent (unique ID). If the ID is given to 9 when the player logs on, or when the monster is created, it is obvious that the player array (the player) 's position (index) can be used as the ID.
　　　　
So the first login player ID is 0, the second one is 1, and so on. Now, you usually have a limit, say, 2000 indexes in the player list. So if a client sends a command similar to: "View ID200000 's role", this will cause the server to become a machine, if not guarded, because the server will access the illegal memory area. So, be sure to check, just like this: "If actor id<0 or if actor id> Max players then log the illegal operation and disconnect the player." If you use C or C + +, note or define the index as ' unsigned int ' and check the upper limit, or because some reason is defined as int (int, which is signed by default), remember to check <0 and >max. Not doing these will severely bruise you and other users. Similarly, to check for out-of-map coordinates. If your server has some sort of pathfinding algorithm, and the client moves by clicking on the ground, make sure they don't click outside the map.
　　
Sixth step: Get a team
　　
Making a game requires a lot of work (unless it's a pong and Tetris game). especially MMORPG. You can't rely on yourself alone. In theory, a complete team consists of:
　　
• At least 3 programmers: one server, two client (or one client, one for tools such as Art plugin, World editor, etc.). There are 6 programmers who are the best and more are not necessary. It depends on your ability to lead. At least one artwork, 2 to 3 more suitable. If this is a 3D game, you need a 3D art, a 2D art (make a map, interface, etc.), an animator, and a head of the art department. The art department should be organized and arranged by experienced people, unless you are an artist.
　　
• A handful of world builders: Creating all maps is a lengthy process and is directly related to the success or failure of the game. Again, you need a head of the world Building department. Your world needs to be coordinated, so you can't have only one person who is impulsive.
　　
• A webmaster is a must, unless you are proficient in website design and are willing to take the time to do the website. Sound and music are not required, but games with sound and music are more appealing than none.

• A game economy system designer. You might think it's easy to do it yourself, but it's actually one of the most complicated jobs. If the economic system is poorly designed (for example, items are not balanced, resources are placed randomly on the map, etc.). Players will feel bored and exit the game. There is a big problem with our early progress, especially since the economic system was designed primarily by me (a programmer) and it was not properly planned. So it took us two months to rethink and build a whole new economic system. This requires a complete removal of the item. I tell you that players will be very reluctant to delete their items. Fortunately, most of the players agree with the idea, but so many hours of arguing, compromising, explaining and wasting time is frustrating. There will be more later.
　　
As I said before, you need a team of 10~15, not coordinators and managers. This 10~15 person must be experienced. It's not worth it if you're a novice, because you need to spend a lot of time explaining what to do, how to do it, why he's not doing it right now, and so on.
　　
It is almost impossible to 10~15 people from the beginning. No matter how many posts you post on different forums, you won't be able to find the right team members. After all, if a person is skilled in his or her field, why should he/she join your team when you can't come up with anything? Many people have big ideas, but it takes a lot of time and effort to achieve them, so they would rather do their jobs than join you. So if you need to 10~15 people but can't get them to join your team, how can you make a MMORPG? Well, in fact, you don't need everyone in the first place. What you really need is a programmer and an artist. If you are a programmer, just look for a graphic artist to do it. Ask a friend who knows art to help, pay for college/friend to do some art or other work.
　　
Now that you have an artwork, the look of the game you are looking for, can now begin to come true. Once you have a C/s engine that you can run, something to show (or better, the player can log into your world, walk around, chat), and more people will be willing to join your team. More appropriately, unless you use proprietary technology, your client can open source. Many programmers will join (as volunteers) an open source project rather than a non-open source. The server should not be open source (unless you plan to do a fully open-source MMORPG).
　　　　
Some other advice: don't exaggerate your game until you have something to show. One of the most annoying things is that a novice sends a "need-to-help" request, asking a huge team to join his game maker to explain how cool the game is. Once you have a website ad (usually in a free host), you will see an appealing navigation bar that contains "download", "" "," Original picture "(Translator note, Original: Concept art, Concept art, in the game should refer to the original design of the artwork)," forum ". You click on the download link and then see the wonderful "Build in" page (or worse, a 404 error). Then you click and get the same result. If you don't have anything to download, don't drop the link. If there is no display, do not put the link. But better yet, don't waste time on the site until the project progresses 10% (program and artwork).

Seventh step: Breaking Some myths
　　
1. You can't make MMORPG, only big companies can.
　　
I don't agree. While making a game like World of Warcraft (World of Warcraft), The endless Task 2 (ever Quest 2), King Arthur's Call 2 (Asheron ' s calls 2), Lineage 2 (Lineage 2), and some other games on a small spontaneous team is impossible, But it's still possible to do a decent game, as long as you have experience, motivation, and time. , you need 1000 hours of programming to make a running beta, about 10~15k hours to complete the almost complete client and server. But as a team leader, you can't just program. It's your job to keep the team together, resolve disputes, maintain public relations (PR), technical support, set up servers, punish troublemakers, free discussion, and so on. You may be overwhelmed by non-programming tasks. You probably need to go to work/school, which reduces the amount of time you spend on projects. We are fortunate that no member has left the team, but if this happens, it is a big problem. Let's say your artwork is halfway away. Or worse, he/she does not give you permission to use his/her work. Of course this can be solved by signing a contract with them, but it is still troublesome to find another artist. There are two different kinds of art styles in a project that are also problematic.
　　
2. A large amount of money (usually 4-6 digits) is needed to set up a MMORPG server.
　　
Of course, this is not true. I have seen professional servers, 1000gb/months, less than 100 USD/month (2~300 dollar initial charge). Unless your data transfer protocol design is very unreasonable, 1000gb/month is enough for a 1000-player online (average) server. Of course, you also need another server to do Web site and client downloads (client downloads can consume a lot of traffic when the game becomes popular). Our client has 22MB, sometimes 400gb/months of transmission. And we are not very popular (still). Another thing, we don't need another dedicated server to open this project. The adsl/cable server can do the job until you reach 20~30 at the same time as the online number. Then either find a friendly hosting company, Exchange free hosting with ads, or you can only pay for your own pocket.
　　
3, making a MMORPG is very interesting.
　　
It's not true. You may think that everyone appreciates you, the player will support you, you are unconventional, and, of course, many players play your game. Players can be annoying. Even for completely free games, they can find reasons to complain. What's worse is that people often complain about contradictions. The warrior will complain that the escalation is too difficult, and the merchant will be disappointed that the soldiers rob a lot of money. If you reduce monster drops, some players will threaten to quit the game. If you increase, the same group of people will be dissatisfied with the fact that novices can make money more easily. It's a dilemma. Reform and improvement are essential. If you decide to change something, such as adding a challenge to a processed item, some people will say it is too difficult. If you don't do it, they'll say it's too simple and tasteless. You will find that satisfied players usually don't say anything and feel satisfied, while the attackers will complain.
　　　　
The economy of MMORPG is more difficult to balance than the standalone version. In a stand-alone game, you can gradually improve the weapon, as long as the player progresses, he/she can use better equipment, discard (or sell) the old. On the other hand, in multiplayer, this view is not tenable, as everyone tries to get the best weapons while jumping low-level weapons. Most players would rather save money with their bare hands until they can buy the best weapons in the game. The economic system design should refer to relevant articles.
　　　　
All the things I've enumerated so far, plus the extra work and challenges, are enough to make you think twice before you decide to get involved in the project. You have to know what your decision means.
　　
Summary
　　
I hope this article will give you enough knowledge. My next article will show you how to build an economic system (more specifically, which errors to avoid), and some information about debugging servers and clients.

Introduction to MMORPG game development (GO)