Creating a space browser game. First experience
This article will discuss the first experience of creating a space browser game. About the initial steps, the first results, about the mistakes made and the most interesting development difficulties that one had to face. We will be happy if Habr's readers find interesting information in this article.
Earlier, during the last 2 years, there have been attempts to launch some small-scale browser games that collected less than 1000 players, but in this article we will not touch them. The story will be about the first experience of creating a browser-based online game, which in the future will seek to go to the masses.
The idea of ​​creating a space game was born a long time ago. Why space? Partly because the space theme has always aroused my personal interest, and partly because of nostalgic memories from a pleasant pastime behind Space Rangers, sometime in the distant past ...
')
Since my main activity is web development, the choice fell on HTML + JavaScript in the client, and PHP + MySQL in the server. Perhaps this question is a topic of endless discussions, but then the story will be about developing it in these languages. Of course, Flash in terms of animation is much more productive than JavaScript, but Flash was not chosen purely due to lack of knowledge in ActionScript.
The server part was written from scratch - probably not the wisest solution, but I wanted to go all the way from the clean index.php page, writing my own game engine.
So, a start. A brief history of the game world is invented and written, telling about the distant future of mankind, the Federation as the dominant authority, the corporate wars for planetary resources and the wages of extremely hostile advanced civilization from the depths of space. Developed the idea of ​​gameplay, basic functionality and principles of the game.
All conceived ideas fit well into the creation of an epic online game with elements of RPG, strategy, text quest and arcade. Issues of implementation of the main game interface were solved for about two weeks. During this time: 7 layouts, 4 design options.
As planned, I wanted to create a game that requires certain mental expenditures from the players (by the way, this goal is still not considered achieved, and we are working on it). That is why the main task was to create an interface that was as clear and as least as possible.
During the work on the design, a lot of browser-based space games were viewed. It became obvious that the most successful of them are games, with a carefully thought-out interface. And so, the main points that were taken as a rule:
As a result, this option was born:
The main information is located at the top of the screen (player level, rank, money, fuel, cargo hold), as well as the main navigation buttons (profile info, events, diplomacy, etc.). Game settings and reference information - in the lower right corner.
However, since the action of the game takes place not only in space, it was required to make a convenient transition between locations. That is why the central button was invented. Through it, a return “to a higher level” is carried out according to the logic of a spacecraft taking off from the planet upwards - into space (if we are in the colony - by pressing the central button, we return to the planet’s surface, from the planet to the star system, from the star system to open space). The action logic of the top-down central button is shown in the figure below:
In certain locations additional units appear, from above or to the right, depending on which part of the screen is used for the main gameplay:
Looking ahead, it is worth noting that after launching the alpha test of the game, there were no complaints about the interface convenience from the players, and the logs said that the players are well oriented in the basics of management.
So, even though we do not have a staff of professional game designers and artists, we managed to create an acceptable interface with minimal forces, which later turned out to be quite understandable to the players.
The first version of the game was written about 4 months. Knowing that the game will evolve over time, the functionality will expand, and, accordingly, the amount of code will increase, it was necessary to determine its architecture at the initial stage. It turned out that it is not so easy due to the fact that:
The above is applicable, in fact, to any project, however, as practice has shown, this problem manifests itself most acutely in the development of the game .
Based on this, the solution was quite simple:
All client requests are processed through a single req.php file, which, depending on the received GET request, includes and executes the necessary scripts. The scripts themselves are in the conditional data / folder and are named for their intended purpose: planets.dat, solars.dat, colonies.dat, ships.dat, users.dat, etc. Inside these files are described classes and functions, divided into three main purposes:
This approach allowed us to minimize the complexity in processing the code structure due to the expansion of gaming capabilities: ships' capabilities expand - the ships.dat file opens, we add new types of planets - we open planets.dat. All changes are usually performed within one or two files, which allows you to not forget anything.
I will be happy to tell you more about the technical aspects of the development in the following articles. Now let's move on ...
So, the pilot version of the game is ready. The next question is where to start the project? This question, of course, became relevant even at the stage of the beginning of development. In fact, there are no special options here - either this is an independent browser game, or this application is in one of the social networks.
Understanding that the budget tends to zero, and a lot of investment is needed for advertising the game, it was decided to use the platform where you can get a good starting audience of players, and, preferably, for free.
The choice fell on VKontakte . “Contact” with placement in the Applications offers the games a good start, and a fairly loyal audience, ready to take part in testing and developing the game, as well as ready to turn a blind eye to certain shortcomings and bugs.
To get to the application directory, it took:
And now, two days after the application was submitted, the moderator approved the application, and it appeared in the catalog.
In itself, the placement in the directory does not particularly lead players, but after a week in the application have already played a few people.
The situation radically changed when the application got into the “New” block.
During the first day about 6,000 people came to the application. In the following - less, but the flow was quite large. During the weekly deployment, the application installed about 15,000 people (meaning those who did not uninstall the application after installation).
First of all, due to the load on the database . In principle, this was expected, which is why we had to double the capacity of the server (up to Intel Xeon 4 CPU and 4 GB of RAM). And of course, optimization, optimization and optimization again ...
Since It was necessary to carry out optimization in record time in order not to lose the audience, decisions were made very quickly. Many lines of code have been rewritten, in particular, regarding database queries. The CPU took over the load partially. Data output from the database was simplified: in certain places where comparison and sampling from several tables were required, simple SELECTs were put from each table separately, and then the necessary data were derived by comparing arrays in PHP. And all because JOINs require quite a lot of resources (as it turned out later, this is not true, since the speed of work of JOINs directly depends on how well they are optimized, but there was no time for this, and we decided to shift some of the load to PHP).
It helped! The application was able to stabilize. And although the issue of optimization is still far from the last, this problem no longer arose so acutely.
Participants in the game during the gameplay found a variety of bugs - from lying on the surface, to the most unthinkable. It was obvious: since the experience in creating such a game is actually the first, there will be a lot of bugs. So it was. Someone wrote about the bugs in the group of the game, someone, understanding the seriousness of the situation, wrote personally, and someone quietly used these bugs, spinning his money, or other characteristics. With the latter it was the hardest because they were not easy to track, it was even harder to roll back up to adequate values.
During the work, the bugs were eliminated, the gameplay was “undermined” and became more understandable and convenient. Most of the vulnerabilities, of course, did not significantly affect the gameplay, no one broke the base, did not demolish the records, however, minor flaws in the code and in the rules of the game themselves, revealed another serious problem.
This is perhaps one of the most significant problems that new game developers can face.
Balance is needed in everything. Otherwise, users will not be interested to play, either immediately or in the near future. It is necessary to think over the balance in advance, at the stage of preparation for the introduction of a particular feature into the game.
Our first mistake was that we did not take into account one obvious fact: the players spend a different amount of time in the game. And so, one of our players spent in the game about 5 hours a day. A week later, his finances rose to a nine-digit number. What did he do? Engaged in trade. I found a planet where one resource was sold cheaper than it was bought on another. Of course, experienced game developers will take this into account in the first place. For us, it was a discovery.
After that, we read a lot of literature about the game balance (good, plenty of information about it), and we realized that he needed to pay much more attention.
As a result of this article, I would like to mention a few of the most significant conclusions that were made from the moment of the birth of the idea, to its implementation:
The project has been working for more than a year (with some interruptions, since it requires personal financial investments). There has been a long journey, but there is still a lot of work ahead. Rejoicing little achievements, making mistakes, we move on, what we wish to everyone who read this article! In the end, I wonder what all this will turn out ... :)
I will be glad to tell you in the following articles about the technical details of the development, about our approach to the implementation of various aspects of the game.
Thanks for attention!
As an introduction
Earlier, during the last 2 years, there have been attempts to launch some small-scale browser games that collected less than 1000 players, but in this article we will not touch them. The story will be about the first experience of creating a browser-based online game, which in the future will seek to go to the masses.
The idea of ​​creating a space game was born a long time ago. Why space? Partly because the space theme has always aroused my personal interest, and partly because of nostalgic memories from a pleasant pastime behind Space Rangers, sometime in the distant past ...
')
What to write?
Since my main activity is web development, the choice fell on HTML + JavaScript in the client, and PHP + MySQL in the server. Perhaps this question is a topic of endless discussions, but then the story will be about developing it in these languages. Of course, Flash in terms of animation is much more productive than JavaScript, but Flash was not chosen purely due to lack of knowledge in ActionScript.
The server part was written from scratch - probably not the wisest solution, but I wanted to go all the way from the clean index.php page, writing my own game engine.
Development process
So, a start. A brief history of the game world is invented and written, telling about the distant future of mankind, the Federation as the dominant authority, the corporate wars for planetary resources and the wages of extremely hostile advanced civilization from the depths of space. Developed the idea of ​​gameplay, basic functionality and principles of the game.
Genre
All conceived ideas fit well into the creation of an epic online game with elements of RPG, strategy, text quest and arcade. Issues of implementation of the main game interface were solved for about two weeks. During this time: 7 layouts, 4 design options.
Interface
As planned, I wanted to create a game that requires certain mental expenditures from the players (by the way, this goal is still not considered achieved, and we are working on it). That is why the main task was to create an interface that was as clear and as least as possible.
During the work on the design, a lot of browser-based space games were viewed. It became obvious that the most successful of them are games, with a carefully thought-out interface. And so, the main points that were taken as a rule:
- Wherever possible, texts need to be replaced with icons. Visual characters are always perceived as simpler;
- Refuse to display various kinds of information over locations outside the blocks allocated for this purpose (remove chat, notifications, explanations, tasks, and output only when absolutely necessary) —in general, unload the working window as much as possible, but at the same time leave the possibility of going to the right information with one or two clicks;
- Trite, but not least: a readable font and adequate color gamut;
As a result, this option was born:
The main information is located at the top of the screen (player level, rank, money, fuel, cargo hold), as well as the main navigation buttons (profile info, events, diplomacy, etc.). Game settings and reference information - in the lower right corner.
However, since the action of the game takes place not only in space, it was required to make a convenient transition between locations. That is why the central button was invented. Through it, a return “to a higher level” is carried out according to the logic of a spacecraft taking off from the planet upwards - into space (if we are in the colony - by pressing the central button, we return to the planet’s surface, from the planet to the star system, from the star system to open space). The action logic of the top-down central button is shown in the figure below:
In certain locations additional units appear, from above or to the right, depending on which part of the screen is used for the main gameplay:
Looking ahead, it is worth noting that after launching the alpha test of the game, there were no complaints about the interface convenience from the players, and the logs said that the players are well oriented in the basics of management.
So, even though we do not have a staff of professional game designers and artists, we managed to create an acceptable interface with minimal forces, which later turned out to be quite understandable to the players.
Code writing
The first version of the game was written about 4 months. Knowing that the game will evolve over time, the functionality will expand, and, accordingly, the amount of code will increase, it was necessary to determine its architecture at the initial stage. It turned out that it is not so easy due to the fact that:
- new ideas are constantly being born, and therefore new, more rational methods for implementing these ideas;
- the current code is optimized and added, which often entails processing and restructuring of the entire file, or even several (just to have a single logic everywhere, and not to get confused in the future);
The above is applicable, in fact, to any project, however, as practice has shown, this problem manifests itself most acutely in the development of the game .
Based on this, the solution was quite simple:
All client requests are processed through a single req.php file, which, depending on the received GET request, includes and executes the necessary scripts. The scripts themselves are in the conditional data / folder and are named for their intended purpose: planets.dat, solars.dat, colonies.dat, ships.dat, users.dat, etc. Inside these files are described classes and functions, divided into three main purposes:
- Output data to the player
- Create / Modify / Delete Data
- Other common engine functions (data checking, caching, etc.)
This approach allowed us to minimize the complexity in processing the code structure due to the expansion of gaming capabilities: ships' capabilities expand - the ships.dat file opens, we add new types of planets - we open planets.dat. All changes are usually performed within one or two files, which allows you to not forget anything.
I will be happy to tell you more about the technical aspects of the development in the following articles. Now let's move on ...
Launch of the project
So, the pilot version of the game is ready. The next question is where to start the project? This question, of course, became relevant even at the stage of the beginning of development. In fact, there are no special options here - either this is an independent browser game, or this application is in one of the social networks.
Understanding that the budget tends to zero, and a lot of investment is needed for advertising the game, it was decided to use the platform where you can get a good starting audience of players, and, preferably, for free.
The choice fell on VKontakte . “Contact” with placement in the Applications offers the games a good start, and a fairly loyal audience, ready to take part in testing and developing the game, as well as ready to turn a blind eye to certain shortcomings and bugs.
To get to the application directory, it took:
- explore the VK API, implement some social functions (authorization, inviting friends, ratings);
- rent a server. Initially, an average KVM VPS was leased on an Intel Xeon processor (4 CPUs) with 4 GB of RAM and an SSD disk;
- purchase and connect an SSL certificate (can be purchased free of charge at startssll.com);
- apply for moderation;
And now, two days after the application was submitted, the moderator approved the application, and it appeared in the catalog.
In itself, the placement in the directory does not particularly lead players, but after a week in the application have already played a few people.
The situation radically changed when the application got into the “New” block.
During the first day about 6,000 people came to the application. In the following - less, but the flow was quite large. During the weekly deployment, the application installed about 15,000 people (meaning those who did not uninstall the application after installation).
First serious problems
Server fell
First of all, due to the load on the database . In principle, this was expected, which is why we had to double the capacity of the server (up to Intel Xeon 4 CPU and 4 GB of RAM). And of course, optimization, optimization and optimization again ...
Since It was necessary to carry out optimization in record time in order not to lose the audience, decisions were made very quickly. Many lines of code have been rewritten, in particular, regarding database queries. The CPU took over the load partially. Data output from the database was simplified: in certain places where comparison and sampling from several tables were required, simple SELECTs were put from each table separately, and then the necessary data were derived by comparing arrays in PHP. And all because JOINs require quite a lot of resources (as it turned out later, this is not true, since the speed of work of JOINs directly depends on how well they are optimized, but there was no time for this, and we decided to shift some of the load to PHP).
It helped! The application was able to stabilize. And although the issue of optimization is still far from the last, this problem no longer arose so acutely.
Bugs, many bugs ...
Participants in the game during the gameplay found a variety of bugs - from lying on the surface, to the most unthinkable. It was obvious: since the experience in creating such a game is actually the first, there will be a lot of bugs. So it was. Someone wrote about the bugs in the group of the game, someone, understanding the seriousness of the situation, wrote personally, and someone quietly used these bugs, spinning his money, or other characteristics. With the latter it was the hardest because they were not easy to track, it was even harder to roll back up to adequate values.
During the work, the bugs were eliminated, the gameplay was “undermined” and became more understandable and convenient. Most of the vulnerabilities, of course, did not significantly affect the gameplay, no one broke the base, did not demolish the records, however, minor flaws in the code and in the rules of the game themselves, revealed another serious problem.
Imbalance
This is perhaps one of the most significant problems that new game developers can face.
Balance is needed in everything. Otherwise, users will not be interested to play, either immediately or in the near future. It is necessary to think over the balance in advance, at the stage of preparation for the introduction of a particular feature into the game.
Our first mistake was that we did not take into account one obvious fact: the players spend a different amount of time in the game. And so, one of our players spent in the game about 5 hours a day. A week later, his finances rose to a nine-digit number. What did he do? Engaged in trade. I found a planet where one resource was sold cheaper than it was bought on another. Of course, experienced game developers will take this into account in the first place. For us, it was a discovery.
After that, we read a lot of literature about the game balance (good, plenty of information about it), and we realized that he needed to pay much more attention.
What's next?
As a result of this article, I would like to mention a few of the most significant conclusions that were made from the moment of the birth of the idea, to its implementation:
- Game development is an incredibly exciting experience;
- Test, test and test again ... In any project, testing and eliminating bugs take a significant amount of time. In the game - three times more;
- Elaboration of the game balance is one of the main tasks in creating the game, which should be laid at the stage of the formation of the basic gaming capabilities;
- The idea that “I myself know how the game I want to create should look like” is only partly correct. Active players and testers can make a significant contribution to the development of the game. Do not neglect to communicate with them, preferably from the very early stages of development;
- You have to be fully embraced by your idea. Development will take a lot of your time. And the fewer people working on it, the more time it will require from you;
The project has been working for more than a year (with some interruptions, since it requires personal financial investments). There has been a long journey, but there is still a lot of work ahead. Rejoicing little achievements, making mistakes, we move on, what we wish to everyone who read this article! In the end, I wonder what all this will turn out ... :)
I will be glad to tell you in the following articles about the technical details of the development, about our approach to the implementation of various aspects of the game.
Thanks for attention!
Source: https://habr.com/ru/post/268973/
All Articles