The development of an MMO RPG is a practical guide. Episode 1
 |
|
In the series of articles “Development of MMO RPG - a practical guide” you will receive answers to these and many other questions. All numbers are real. All schemes, tables, source code, database diagrams, etc., are taken from a real-life and successfully working project.
The text will contain many references to the gameplay and appearance of our Star Ghosts game . I will try to present the material so that you do not need to delve into (and play) our product, but for a better understanding of the material, it is advisable to spend a couple of minutes and see how it all looks.
Ready? Then go!
Labor costs
We will start, perhaps, with the most interesting - with the cost of development. The diagram (see Fig. 1) shows the costs as a percentage of the total project budget. When calculating the cost of the office, depreciation of equipment and taxes were not taken into account.
As you can see, creating a client was the most expensive. And this is not surprising, given that the game is in real time and using 3D. In second place is the server, and this is also expected. What is unexpected is high management costs and low costs for 2D and 3D graphics. “Maybe it's just plain graphics?” You say. Just not: the players like the graphics. The secret is to actively use outsourcing to create graphics. We managed to significantly reduce the cost of graphics production, but at the same time, of course, increased management costs. Thanks to this, the total budget of the project was reduced by almost 10%. But the high costs of game design is our mistake. Initially, we did not correctly assess the strength and cost of development, so we swung at what we were unable to do. As a result, we had to redo the plot 3 times, change the combat system several times, process interface circuits, and so on. With a more sober initial assessment, I think it would be possible to reduce the cost of game design by half (or 5% of the total project budget).
We outsourced concept art and the creation of 3D models, and the first pieces of equipment in the line (for example, a 1st and 20th level turret) were necessarily created in the office. But the rest (turrets of the 40th, 60th and 80th) - both concepts and 3D modeling were outsourced. Why is that? In 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 outsourced.
Also, outsourcing was fully given to the creation of videos, voice acting, musical design, the creation of sounds and layout of the site. There wasn’t so much content for this type of game for our game, so there wasn’t any sense in hiring people. And our attempts to outsource part of the program code (in the form of final tasks) were unsuccessful, therefore, the entire software part was completely written by our forces.
Another value in the diagram may seem strange - only 1% of the cost of testing. The main contribution to the testing was made by the players themselves at the stages from alpha to the open beta test, and we paid them in the apsidium (premium gaming currency). Therefore, it was possible to significantly reduce costs in real money.
Command structure
In the office on an ongoing basis, five people worked on the project. About 2 months before alpha, we took two more testers to the office part-time, but they did not work for us for long - about three months each (or 1.5 person-months each). Starting with the closed beta, we were able to completely shift the testing to remote testers: some for real money, and 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 work (preparation of the first documents and creation of a demo) until the release of the product.
Table 1.
| Role | Costs, person-months |
| Director, manager, architect, server, client and admin programmer | 26 |
| Client programmer | 12 |
| Art Director, Concept Artist, 2D Artist | 16 |
| 3D modeler, texture planner | 16 |
| Game designer | 16 |
| Tester-1 (part-time) | 1,5 |
| Tester-2 (part-time) | 1,5 |
conclusions
- As realistic as possible, evaluate your strengths and project budget. Otherwise, you will spend extra money and ultimately create a less successful product than you could.
- Make the most of outsourcing to produce content. For workers in the office, leave only interesting research work, as well as critical in time or quality.
- Try to minimize the size of the team, but take only talented and highly qualified specialists.
System diagram and development plan
Formally , Star Ghosts is a 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 downloads transparently to the user. What are the components of the game? It would seem that everything should be simple - from the client and server. But in reality (see Fig. 2), everything is somewhat more complicated.
We followed the following development order:
- Main customer
- "Test tube" for 3Dshnikov.
- Primary server
- Db
- Admin (partially: creating items, locations, bots)
- Auto Scripts
- Chat server
- Admin (everything else)
- Drivers for the payment system
- Drivers for Traffic Providers
- Web site
- Reg. server and reg. client
- Social network drivers (authorization).
This order allowed us to get an existing system in the early stages of development 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 dwell on each of them in detail.
Stage 1.First of all, a prototype of the game was developed without any server, but it included almost all the technologies supposed for use in the client, namely: Adobe Flash, Adobe Away3D, Adobe Starling. We had a space in which the user controlled a lone ship. On this prototype, we tested the basic system for calculating the curve of the ship’s movement, space movement (parallax), and tested the possibilities of rendering models on the texture. In general, we tested all the bottlenecks that we saw at the beginning of development and roughly understood how everything would look like here. This made it possible to draw a conclusion about the possibility of technical implementation of the plan, and also gave a demo with which it was possible to go to investors.
Stage 2.After the approval of the terms of reference, we developed technical requirements for 3D models: at this stage we already had an idea about the appearance of the game, the platform and the engine. In addition, we created a “test tube” for 3D wizards - a separate tool into which you could load a 3D model and see how it would look after rendering in Away3D. The fact is that after exporting directly to the engine, the model looks a bit different than in the modeling tool. Therefore, it was extremely important for our artillery department, and especially the art director, to see how everything would actually look in order to “pull up the textures,” as he said. Here I will make a reservation right away: during the work we switched to the 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 be re-created. From here there are two very important conclusions:
Step 3. Then we proceeded to create the server and network part in the client. C ++ was chosen as a programming language, as we already had achievements and our libraries in this language. At this stage, the server worked without a database, it loaded the data from an XML file. The objective of this stage is to test the selected server technologies, as well as to enable the game designer and the whole team to play online. The most important thing here is to test - with what 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 twitching so that it is impossible to play. At this stage, our ships couldn’t even shoot, we just flew one after another and tested different synchronization algorithms.
Stage 4.Then iterative development of the client and server went on for some time. The first thing that appeared was XML equipment configs so that the game designer could 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 combat mechanism.
Stage 5.When the mechanics of the game more or less settled, it was possible to connect the database to the server. MySQL was chosen as the DBMS. The connection implied, first of all, transferring the loading of equipment data 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 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 advance much faster.
Stage 6.As the project became more complicated, we were faced with the fact that the creation of each new package by hands took a lot of time and was fraught with errors. Therefore, again, a script was written on PHP that accepts an XML file and generates source code files for the client and server (and, subsequently, for the chat server). A similar problem arose for a game designer: as the range of items grew, it became extremely difficult to manage and modify them. Therefore, a number of scripts were written for him that facilitated the generation of the entire line of objects at once.
Stage 7.Initially, we were going to use an IRC chat server. It seemed that everything was simple and the chat question was postponed. But when it was the turn to create a chat, it turned out that integrating an IRC server with our system was not so simple. After all, we need not just authorization, but also a moderation system, as well as the display of specific data in the chat - level, clan, etc. We appreciated that it’s easier to write a chat server than to modify an IRC server. In fact, on the client we spent less time integrating with our server than with IRC, so this solution was correct.
Step 8. We were approaching a closed beta test (PTA). It became apparent that statistics would be needed. Improvements affected the server and the database, plus the display in the admin panel. There was a lot of work, but mostly a routine, with the exception of database design.
Stage 9. After the CBT, 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 accepting payments. Such improvements affected the client, server, database, and also had to create a special script. Here, again, no particular magic - everything is on PHP.
Step 10. It's time to deal with traffic providers. We work with them according to two schemes: 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. The improvements affected the client, server, database, website and admin panel (filters in statistics).
Stage 11.Immediately before MBT, we created the game’s website (during the PTA, players switched to the page with Flash, and registration and login were implemented in flash). The integration of the game with the forum base took the most time to provide a pass-through forum / game login.
Stage 12.After MBT and load testing, we realized that pouring traffic to the main game server is a bad idea. The fact is that the number of traffic very much depends on the time of day. And at peak times, up to a hundred requests per second could come. The players we rushed right into the game, a separate instance was created for each new player. 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 only downloads registration locations) and a separate client in which the player plays only before registration (after which he redirects to the main server). In addition, we reduced the amount of downloaded data in the registration client, as we knew exactly what was necessary for the player.
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 series “Development of MMO RPGs - a practical guide” we will take a closer look at the server part, its components, touch upon working with the database and much more.