This article will focus on the first steps in building your own Massive Multiplayer Online Role Playing Games (MMORPG). It's target is the indie game developer, with limited resources and experience. After reading this article, you should know what it takes to get started, and some advises regarding what to do and what not to do. The very first step is to assess your skills, and your resources. You need to be honest with yourself, because it can be frustrating to waste your time trying to build something you just can't.
Step one: Assessing your skills
Required Skills:
-
Know at least one programming language. So far, C++ is the most popular choice among game developers due to efficiency and performance advantages. Visual Basic, Java or C# might do the job as well.
- Become familiar with a graphic library. Popular choices are SDL, OpenGL, or DX/D3D.
-
Choose the network library to utilize. You can chose between WinSock, SDL_net, or DirectPlay.
- Have general experience in game programming. For example, the events loop, multithreading, GUI design, etc.
Highly Recommended Skills:
- Client/Server communication and architecture.
-
Multiplatform programming. You might want to design your MMORPG, and especially the server such that it can run on multiple OSs. For this purpose, I recommend using SDL, OpenGL and SDL_net.
- Web development. This will be needed if you want to enable people to view player statistics, server information, and other information on a website.
- Security & Administration. You don't want someone to hack your server, and mess around!
-
Team skills. You will need a team that you can successfully lead and manage.
Step Two: Making a preliminary design
I have noticed many people posting in various forums looking for teams to make MMORPGs. Most of them start with something like this: "We are a starting company/game studio and we need 3 artists, 2 programmers, 1 musician, etc. for an innovative, never seen before MMORPG where you will have total freedom to do whatever you want and reshape the world, etc. We will pay you when it's done and we make some money." Unfortunately, with the current technology and limited bandwidth, you cannot have a dynamic world. Aiming at something impossible leads to failure. Rather, try to come up with a small, functional, expandable design and architecture.
Basic software architecture
First, try to focus on making a simple client/server model, where you will be able to:
- Create a new character
- Save that character (server side)
- Log in with the character
- Be able to chat with others
- Be able to navigate around in 3D
Saving characters might seem simple, but in fact, it isn't. For example, there are two ways of saving the characters: using a database server or using files. There are advantages and disadvantages for both:
| Databases | Files |
| Advantages | | |
| Disadvantages | - Easy to make mistakes. For example, doing an update query where you omit the 'where' clause. It can have disastrous effects, especially if you have old (or no) backups.
- Databases may be slower than actually opening/writing a player file. You might lose a few milliseconds when retrieving some data, especially if a lot of players log in/out at the same time.
- Additional code is required to convert your data to/from the database.
- Database and SQL experience is required. In addition, you will need a library to interface between your program and the database.
- If for some reason the database file becomes corrupt, you are out of luck; you can lose all the players (especially if no recent backups).
| |
Now that you decided which way to go about saving your characters, you'll need to chose what network protocol to use for the client/server communication: TCP or UDP? TCP is known to be slower but more accurate, and require additional bandwidth. In practice, I didn't notice any problem using TCP. Provided that you have enough bandwidth available, TCP is a good choice, at least for the beginning. UDP can be really annoying, especially for beginners. Keep in mind that the preliminary tests of the engine or game will be done in your local network, so all the packets will arrive to the destination in the same order. This can't be guaranteed over the Internet. While the packets will usually arrive in the same order, some packets can be lost, and this is usually a problem. Of course, you can design your protocols in way so that the client/server will be able to recover from lost packets. But this is a painful process which is not recommended for beginner.
Step Three: Choosing an internal protocol for data transmission
It might seem simple, but, again, it isn't. You can't just send strings, '\0' terminated. This is because you will need a consistent protocol, which will be able to send both strings and binary data. It is unwise to use 0 (or any other sequence) as a terminator, because that terminator can be part of the data stream you want to send. Furthermore, if you send 20 bytes, and then another 20 bytes, most likely the server will not receive a 20 bytes packet, then another 20 bytes packet. Instead, it will receive 40 bytes at once, to avoid wasting the bandwidth with unnecessary headers. Alternatively, you can send a 1KB packet, but the server will receive it in 2 smaller packets. So you will need to be able to know where a packet starts, and where it ends. In Eternal Lands, we use the following method:
- Offset 0: 1 byte denoting the command transmitted.
- Offset 1: 2 bytes, the length of the data transmitted.
- Offset 3: variable length, the body of the message.
This method has the advantage of consistency: all the data transmitted follows the same standard. The disadvantage is that some commands have a fixed, known length, so some bandwidth is wasted. We will eventually switch to a hybrid approach, at a later date.
The next thing to decide is the server model: "Non-blocking sockets, non threaded", or "blocking sockets, threaded". Both methods (threaded vs. unthreaded) have their advantages and disadvantages.
Threaded:
- Somewhat smoother response from the server, since if a player needs a lot of time (such as reading data from the database) this is done on it's own threaded, not affecting others.
- Very hard to debug, and implement properly: You will need a lot of synchronization, and small oversights can have disastrous effects (server crashing, item duplication, etc.)
- Makes use of multiprocessors systems.
Non-threaded: - Much easier to implement and debug.
- Slower response time.
In my company, we went for the non threaded way, because I just don't have the resources and disposition to cope with the threaded.
Step Four: The Client
Do you plan to make a 2D or 3D game? Some would argue that it's easier to make a 2D game. I've done both, and I tend to believe that 3D is easier. Allow me to explain.
In 2D, you usually have a frame buffer, which is a big array of pixels. The format of those pixels can differ, from video card to video card. Some have RGB modes, other have BGR modes, etc. The number of bits for each color can differ as well. This happens only for 16bpp video modes. 8-bit and 24-bit video modes are easier, but with their problems (8-bits gives you few colors (256), while 24-bit modes are slower). Also, you will need to make your sprite routines, and you have to sort your objects yourself, so they will be drawn in the right order. Of course, you can use OpenGL or D3D for 2D games, but it's usually not worth it. Not everyone has a 3D accelerated video card, so using a 3D library for a 2D game usually gives you the disadvantages of both worlds: Not everyone will be able to play it, and you won't be able to rotate the camera, have nice shadows, and various other eye candies specific to the 3D applications.
The 3D way is, like I said, easier, but requires some basic math (especially trigonometry) knowledge. Today's graphic libraries are very powerful, and will offer you the basic operations for free (you won't need to sort your objects back to front, changing the colors and/or texture of an object is very easy, the objects will be lit according to the light and their position (as long as you calculate the normal vectors for them), and more. Furthermore, 3D gives you much more freedom of creation and movement. The disadvantages are that not everyone will be able to play your game (you might be surprised how many people don't have 3D capable cards), and pre-rendered graphics will always look better than the real-time rendered equivalent.
Step Five: Security
Obviously, the users cannot be trusted. Under no circumstances can you assume that the users will not be able to defeat your cleverly-designed encryption scheme (if you use one), or your protocols. Everything the user sends to the server has to be validated. Most likely, on your server, you will have fixed buffers. For example, it is common to have a small (maybe 4K) buffer for the incoming data (from the sockets). A malicious user can send a really long data sequence. If not checked, this will overflow the buffer, resulting in a server crash, or, worse, the user being able to hack your server, executing arbitrary code. Every single message has to be checked: whether buffer overflow occurred, whether invalid data was sent (such as users sending "enter this door" even though the door is at the other end of the map, or "use the healing potion" although the user has no such potions, etc.). I will say it again: It is extremely important to validate all the data. Whenever there is a violation, log it along with the username, IP, time and date, and the nature of the violation. Every once in a while, check that log. If you find few violations from many users, this is usually a bug in the client, or a network problem. However, if you find a lot of violations from the same user or IP, this is a good indication that someone is toying with the server, trying either to hack it, or running a macro/script. Also, never store data on the client. The client should receive it's data from the server. In other words, It should not send things such as: "Ok, this is my list of items" or "my strength is 10, my mana is 200, and my life is 2000 out of 2000". Also, the client should not receive more data than it needs. For example, the client should not know where other players are, except if they are nearby. This is common sense, since sending all the players to everyone will consume a lot of bandwidth, and some players might hack the client to give themselves unfair advantages (like having the position of certain player displayed on a map). All this seems common sense, but, again, you'd be surprised to find out how many people do not possess what we call common sense.
Other things to consider, when it comes to security: The player walk speed should be enforced on the server, not on the client. The server should keep track of the time (in milliseconds) when a client last moved, and if a move request comes faster than the normal threshold, this request should be discarded. Do not log such bogus requests, because they can result in network latency (i.e. the player lags, and all the data he sent in the last 10 seconds comes at once).
Check the Distance. If a player attempts to trade with another player that is 10 billion kilometres away (or even on another map) log that. If a player attempts to look at, or use a map object that is far away, log that. Be careful for bogus IDs. For example, it's normal to assign an ID to every player (the ID can be assigned when they log in, or it can be permanent (unique ID). If the ID is given when the player logs in (or when a monster is created), it makes sense to use the position (index) in the players array (where that player is) as the ID.
So the first player that logs in has ID 0, the second has ID 1, and so on. Now, most likely you will have a limit of, say, 2000 indexes in that player list. So if a client sends a command such as: "look at actor with ID 200000" this will crash the server if unguarded since the server will attempt to access an invalid memory. So do a check such as: "if actor id<0> max players then log the violation and disconnect the player". If you program in C or C++, take care to either define the index as 'unsigned int' and check for the upper range, or if for some reason you define the index as int (int, by default is signed), remember to check against <0>max actor. Failure to do so will result in a lot of frustration both for you and the other users. Similarly, check for out-of-map coordinates. If you have some form of path finding on your server, and the clients move by clicking on a position on the ground, make sure they do not click outside of the map.
Step Six: Getting a team
Making a game is a lot of work (except for Pong and Tetris). This is especially true for MMORPG. You simply can't do it all by yourself. Ideally, an indie team should be comprised of:
- At least 3 Programmers: 1 for the server, and 2 for the client (or 1 for the client, one for the tools, such as plug-ins for the artists, a world editor, etc.). Having up to 6 programmers is good, more than 6 might be too much. It really depends on your leadership abilities. At the very least 1 artist, but preferably 2 or 3. If it's a 3D game you will need a 3D artist, a 2D artist (textures, interface, etc.), an animator, and an art department leader. Unless you are a good artist, the art department needs to be kept together and coordinated by an experienced artist.
- A few world builders: Building all your maps is a very long process, and it's critical to the game's success. Again, you will need a leader for the world building department. You can't just have anyone making whatever the hell they want since your world design should be consistent.
- A webmaster is a must, unless you are really good at web design, and are willing to spend your time making a website. Having a sound and musician is not required, but a game with sound and music can be more enjoyable than a game without it.
-
A designer of the game's economy. You might think that this is easy, and you can do it all yourself, but in fact it is one of the most complicated things. If your economy is poorly designed (i.e. items not properly balanced, resources put randomly on the maps, etc.) the players will get bored/frustrated and will quit. We had a big problem in one of our early stages, especially because the economy was mainly made by me (a programmer), and it wasn't properly planned. So it took us about 2 months to rethink and re-implement an entire new economy system. This also required a total elimination of the items. Let me tell you, players are usually unhappy when you delete all their items. Fortunately, most of our players agreed with the idea, but it was still frustrating to spend so many hours arguing, compromising, explaining, and, in general, wasting time. But more on the economy later.
As mentioned previously, you will need a 10-15 people for a team, not including the moderators and admins. Those 10-15 people should also have previous experience in their field. If they are all beginners it's usually not worth it, since you will need to spend too much time explaining to them what to do, how to do something, why the way they are doing it is bad, etc.
Getting 10-15 people from the beginning is pretty close to impossible. No matter how much you will post on various forums, you will not get quality team members. After all, if someone is pretty skilled in his/her field, why would s/he join your team, when you have nothing to show? Many people have great ideas, but implementing them takes a lot of time and effort, so they would rather work at their own projects than join yours. So if you need 10-15 people, but you can't get them join your team, how can you ever make a MMORPG? Well, in reality, you won't need all of them from the start. What you really need is 1 programmer and 1 artist. If you are a programmer, just get an artist. Beg a friend with art skills, pay a colleague/friend of yours for some art or whatever works for you.
Now that you have an artist, and hopefully an idea on how the game should look like, it's time to start implementing the idea. Once you will have a semi working client/server engine, and some screenshots to show (or even better, the ability for players to actually log in to your world, walk around, and chat with each other), more people will be willing to join your team. Preferably, unless you brave some technology that no one has, you should make your client open source. Many programmers would join (as volunteers) an open source project, rather than a closed source project. The server, on the other hand, should be closed source (unless you plan from the beginning to make a totally open source MMORPG).
Some other advice: Do not brag about your game until you have something to show. One of the most annoying things ever is when a newbie posts a "help wanted" request, asking for a huge team to join his game, explaining how cool the game is. Once you go to the website advertised (usually on a free hosting service) you will see an impressive navigation menu, containing sections such as: "Download", "Screenshots", "Concept art", "Forums". You click on the Download link, and you get a nice "under construction" page (or, worse, a 404 error). Then you click on the Screenshots page, and you get the same result. If you don't have anything for download, then do not put a download link. If you have no screenshots to show, do not put a screenshots link. Better yet, do not even waste your time with a website until you are at least 10% into the project (programming and art wise).
Step Seven: Dispelling some myths
- You can't make an MMORPG, it takes a big company to build one.
I disagree with that. While producing a game such as World of Warcraft, Ever Quest 2, Asheron's Call 2, Lineage 2, and others is impossible for a small, independent development team, making a decent game is possible, provided that you have the experience, motivation and time. You will need at least 1000 hours of programming to have a simple tech demo going, and perhaps up to 10-15K hours of programming to have an almost complete client/server. But as the team leader you'll have to do much more than just programming. Keeping the team together, solving conflicts, doing public relations (PR), tech support, setting up servers, banning troublemakers, brainstorming, etc. will be your attributions. So you will be swamped with non-programming tasks as well. Then you will most likely need to go to work/school, which shortens the time you can dedicate to your project. We are very lucky that no team member left the team, but if this happens it can really be a problem. Just imagine your artist leaves halfway through the project. And even worse, s/he doesn't give you permission to use his/her art anymore. Of course, this can be solved by having them sign a contract, but it would still tiresome to have to get another artist. Having two different art styles in the same project can be a problem. -
Large amounts of money (usually 4-6 digits) is required to maintain an MMORPG server.
Well, this is simply not true. I've seen dedicated servers, with 1000 GB/month for ~100 USD/month (and a 2-300 USD setup fee). Unless your data transfer protocol is very poorly designed, 1000 GB/month should be enough for a server with a 1000 players online (on average). Of course, you will need another server to keep your website and the client download (the client download can get a lot of traffic, once the game becomes popular). Our client is about 22MB, and sometimes we have a 400 GB/month transfer. And we are not even that popular (yet). Another thing is, you won't need a dedicated server to start this project. A DSL/cable server can do it's job pretty well, until you get 20-30 people online at the same time. Then either find a friendly hosting company to host it for free, in exchange for some advertising, or just pay from your own pocket.
-
Making an MMORPG is very fun.
This is not true. You might think that everyone will appreciate you, that the players will be supportive, that you can make very innovative quests, and, of course, have a lot of players playing your game. Players could be annoying. Even if it is a totally free game, they will find reasons to complain. What's worse is people will often complain about contradictory things. The fighters will not like the fact that it's too hard to gain levels, while the merchants will be very disappointed that the fighters make too much money from loots. If you decrease the monster drops, some people will threaten to quit the game. If you increase it, the same people will not like the fact that now even beginners can make money easily. Letting it as is, isn't good either. There has to be some innovation and improvements. If you decide to change something, for instance adding some new challenges to those who manufacture items, some will say it's too hard. If you don't, they will say it's too easy or plain boring. You might notice that the content players will usually not say anything and be satisfied, while the disrupting people will complain the most.
The economy is an MMORPG is far harder to balance than the single player equivalent. In a single player game, you can have gradually improved weapons, so as the player advances s/he can afford better equipment, abandoning (or selling) the old. In a multiplayer game, on the other hand, this is concept fails since everyone will attempt to get the best weapon, skipping the low-level weapons. Most of the players would rather use no weapon and just save until they can afford the best possible weapon in the game. Economy design deserves it's own article.
All the things I enumerated so far, coupled with the extra work and challenges should make you think at least twice before deciding to engage in such an impressive project. You must understand the implications of your decision.
Conclusion
Hopefully this article gave you the insight you needed. My next article will be on how to set up an economy (more specifically, what mistakes to avoid), and some information about debugging a server and a client.
About the Author
This article was written by Radu Privantu, lead programmer and project leader for Eternal Lands www.eternal-lands.com, a free, open source client MMORPG. I can be contacted at chaos_rift at yahoo dot com
