Development of MMO RPG - a practical guide. Episode 1

Wondering how much online game development costs? Do you want to know how to organize the development of MMOs from idea to release? Have you ever thought about the technical difficulties of creating online games?

In the series of articles "Development of MMO RPG - a practical guide" you will get answers to these and many other questions. All numbers are real. All schemas, tables, source code, database diagrams, etc. are taken from a real-life and successfully working project.
The text will be a lot of references to the gameplay and appearance of our game "Star Ghosts . " I will try to present the material so that you do not need to delve into (and play) our product, but to better understand the material it is advisable to spend a couple of minutes and see how it all looks.
Ready? Then go!

Labor costs

We begin, perhaps, with the most interesting - with the cost of development. The diagram (see Figure 1) shows the costs as a percentage of the total project budget. The calculation did not take into account the cost of the office, depreciation of equipment and taxes.
')


As you can see, the creation of the client cost the most. And this is not surprising, given that the game - in real time and using 3D. In second place is the server, and this is also expected. What is unexpected is the high management costs and low costs for 2D and 3D graphics. "Maybe just plain nondescript?" - You say. Just no: the graphics players like it. The secret is in the active use of outsourcing to create graphics. We managed to significantly reduce the cost of production graphics, but at the same time, of course, increased management costs. Due to this, the total budget of the project was reduced by almost 10%. But the high cost of game design is our mistake. Initially, we did not correctly estimate the strength and cost of development, so we threatened that we were unable to do so. As a result, we had to redo the plot 3 times, change the combat system several times, rework the interface circuitry and so on. With a more sober initial assessment, I think it would be possible to reduce the cost of game design by a factor of two (or 5% of the total project budget).

At outsourcing, we gave concept art and the creation of 3D-models, and the first units of equipment in the line (for example, the turret of the 1st and 20th level) were created in the office. But the rest (the turrets of the 40th, 60th, and 80th) - both the concepts and the 3D modeling were outsourced. Why is that? At the office, first of all, the concept is searched and displayed in 3D. And, like any research work, it required highly qualified (and, therefore, expensive) specialists. And when the form is found, production can be safely given to outsourcing.
The creation of videos, voice acting, musical accompaniment, sound creation and site layout were also completely outsourced. This type of content didn’t need much for our game, so there wasn’t any point in taking people to the state. And our attempts to outsource a part of the program code (in the form of finite tasks) were not successful, therefore the whole program part was completely written by our forces.

Another value in the chart may seem strange - only 1% of the cost of testing. The main contribution to the testing was made by the players themselves at stages from alpha to open beta test, and we paid them in the apsidium (premium game currency). Therefore, it was possible to significantly reduce costs in real money.

Line-up

In the office, five people worked on the project on a permanent basis. About 2 months before the alpha, we took two more testers to the office part-time, but they worked for us for a short time — about three months each (or 1.5 man-months each). Starting from the closed beta, we were able to completely pass the testing on to remote testers: some for real money, some for gaming.

The table (see Table 1) shows the composition of the team, their roles and total labor costs. Each row of the table is one person who could combine several functions at the same time. Labor costs are indicated from the beginning of the work (preparation of the first documents and the creation of a demo) until the release of the product.

Table 1.

Role	Costs man-months
Director, Manager, Architect, Server Programmer, Client and Admin Panel	26
Client programmer	12
Art director, concept artist, 2D artist	sixteen
3D modeler, text level	sixteen
Game designer	sixteen
Tester-1 (part-time)	1.5
Tester-2 (part-time)	1.5

findings

1. The most realistic estimate of your strength and budget of the project. Otherwise, you will spend extra money and eventually create a less successful product than they could.
2. Make the most of outsourcing to produce content. For employees in the office, leave only interesting research work, as well as critical in time or quality.
3. Strive to minimize the size of the team, but take only talented and highly qualified specialists.

System diagram and development plan

Formally, "Star Ghosts" - browser game. But the web part is running Adobe Flash and uses a socket connection. Therefore, in fact, this is a client-server game, only the client download is transparent to the user. What are the components of the game? It would seem that everything should be simple - from the client and the server. But in fact (see Fig. 2) everything is somewhat more complicated.



We followed the following order of development:

1. Main customer
2. "Tube" for 3Dshnikov.
3. Main server
4. DB
5. Admin (partially: creation of items, locations, bots)
6. Auto Scripts
7. Chat server
8. Admin (everything else)
9. Drivers for the payment system
10. Drivers for traffic providers
11. Web site
12. Reg. server and reg. customer
13. Drivers of social networks (authorization).

At the early stages of development, this procedure allowed us to obtain an operating system and test certain concepts on it.

Below I will give a brief description of each of the components, for a general understanding of the system, after which we will focus on each of them in detail.

Stage 1. First of all, a prototype game was developed without any server, but which included almost all technologies intended for use in the client, namely, Adobe Flash, Adobe Away3D, Adobe Starling. We had a space in which the user flew a lone ship. On this prototype we tested the basic system for calculating the curve of the ship's movement, the movement of space (parallax), checked the possibility of drawing models on the texture. In general, we tested all the bottlenecks that we saw at the beginning of development and understood in a nutshell how things look like. This led to the conclusion about the possibility of technical implementation of the conceived, as well as gave a demo with which it was possible to go to investors.

Stage 2. After the approval of the technical specifications, we have developed technical requirements for 3D models: at this stage we already had an idea of ​​the appearance of the game, the platform and the engine. In addition, we created a “test tube” for 3D-shakers - a separate tool into which you could upload a 3D model and see how it will look after the render in Away3D. The fact is that after exporting directly to the engine, the model looks a bit different from the modeling tool. Therefore, it was extremely important for our art department, and especially the art director, to see how everything would look like in order to “pull up the textures,” as he said. I will immediately make a reservation: during the work we switched to a new version of Away3D, in which the shaders were different, and this led to a change in the visual display of the models. "Tighten the texture" had to again. From here there are two very important conclusions: first, demand that the texture makers have an order in the texture files, layouts all over the layers with human names, so that in six months another person can open the file and find the desired layer, and, second, all the “pull-ups” Schedules do not immediately on its readiness, but closer to the end of the project.

Step 3. Then we started creating the server and the network part in the client. C ++ was chosen as the programming language, since we already had some groundwork and our own libraries in this language. At this stage, the server worked without a database, it loaded data from an XML file. The task of this stage is to test selected server technologies, as well as to enable the game designer and the whole team to play "online." The most important thing is to test here - with which maximum ping the game can still be played. That is, you need to find out whether it is possible to play on the network at all, or if everything is so twitching that it is impossible to play. At this stage, the ships could not even shoot, we just flew one after another and tested different synchronization algorithms.

Stage 4. Then for some time there was an iterative development of the client and server. The first thing that appeared is the XML configuration of the equipment, so that the game designer can test the parameters of guns and ships. Also at this stage there were many experiments, the creation of various types of weapons and the search for a mechanism of battle.

Stage 5. When the game mechanics more or less settled, it was possible to connect the database to the server. MySQL was chosen as the DBMS. The connection meant, first of all, the transfer of data loading equipment from XML files to the database, as well as loading and saving the state of users. Naturally, it was necessary to create an admin panel that would allow the game designer to create / edit objects and locations. The admin panel was written in PHP. When there was no need to edit XML files, the game designer was very happy, and the process of filling the game with objects and locations began to move much faster.

Stage 6. As the project became more complex, we were faced with the fact that the creation by hands of each new package took a lot of time and was fraught with errors. Therefore, again, a script was written on PHP that receives the XML file and generates source code files for the client and server (and, later, for the chat server). A similar problem arose in a game designer: as the range of items grew, it became extremely difficult to control and modify them. Therefore, a number of scripts were written for it, which facilitated the generation of the entire line of objects at once.

Step 7. Initially, we were going to use an IRC chat server. It seemed that everything was simple there and the question of the chat was postponed. But when it came the turn to create a chat, it turned out that integrating the IRC server with our system is not so easy. After all, we need not just authorization, but also a system of moderation, as well as the display of specific data in the chat - level, clan, etc. We appreciated that it is easier to write your chat server than to modify the IRC server. In fact, on the client, we spent less time integrating with our server than with IRC, so this solution was right.

Stage 8. We were approaching a closed beta test (CBT). It became obvious that statistics would be required. Improvements have affected the server and database, plus the display in the admin. There was a lot of work, but mostly routine, except for the design of the database.

Step 9. After the PTA, we fixed bugs and performed some modifications, after which we began to prepare for the open beta test (MBT). Of course, it was necessary to realize the possibility of receiving payments. Such improvements have affected the client, server, database, and also had to create a special script. Here, again, no particular magic - all on PHP.

Stage 10. It's time to deal with traffic providers. We work with them in two ways: a fixed cost per month regardless of the number of transitions / registrations or payment for registration (CPA). To work on the CPA model, it was necessary to integrate with the API of these traffic providers. Improvements have affected the client, server, database, website and admin panel (filters in the statistics).

Stage 11. Immediately before the OBT, we created a game site (during the PTA, the players moved to the Flash page, and the registration and login were implemented in a flash). Most of the time it took the integration of the game with the base of the forum to provide a pass-through login forum / game.

Step 12. After OBT and load testing, we realized that pouring traffic to the main game server is a bad idea. The fact that the number of traffic is very dependent on the time of day. And at peak times, up to one hundred requests per second could arrive. The players we threw straight into the game, for each new player a separate instance was created. This very heavily loaded the game server and caused lags on it. Therefore, a special registration server was created (in fact, another instance of the main server, but launched with a special key, so it loads only the registration locations) and a separate client in which the player plays only before registration (after that, he redirects to the main server). In addition, we reduced the amount of data loaded in the registration client, because we knew exactly what was needed for the player. This reduced the client download time and solved the problem with lags on the main server, and also made the system scalable - if necessary, we can deploy at least one hundred separate registration servers.

Stage 13. Immediately before the release, integration with social networks was added, namely the possibility of authorization through social networks. This increased conversion conversions in registrations by about 10%.

Conclusion

In the next article of the “MMO RPG Development - Practical Guide” cycle we will take a detailed look at the server part, its components, touch on working with the database and much more.