Explosive GameDev. The history of my game
Here, finally, got around to join the army of developers for mobile platforms and write here an article about how I got into this topic. Immediately I will write that the Unity3d engine was chosen for writing the game, so that people understand what I was going to describe.
The most interesting part of the story is that the original idea absolutely did not coincide with the final implementation. Why? Yes, everything is simple. At first I had an idea to create a puzzle using a Turing machine.
To make it clearer, I will write an example. Imagine that we have a little bit of all annoyed Angry birds. The mechanics of the game is simple, we take the bird, aim it at the pig and launch it. And now we attach the Turing machine here. For example, at the bottom of the screen there is a menu that reflects the order of actions. We do not just launch the bird, but write to the action queue, at what speed and at what angle we launch it. In this case, the level will be completed when all actions are performed correctly.
')
Of course, in my project there were no evil birds, the point was to set fire boxes in the correct order, but now there is no difference. In the end, I decided that the project was too complicated for both the game and the implementation. By that time I had been working with the engine for only a month and had managed to make a fire that was distributed specifically to specific boxes, but I had problems with the Turing machine itself.
After that, at one point, I beat the fruit slice, then I went into the unity and made sure that the boxes I had just flew out from all sides. In general, 10 minutes I watched this picture ...
So the final idea was formed.
However, we all know that writing a clean clone of a game is not enough to be able to promote it. The idea to add fruit to the game was sent by an urgent flight with all its suitcases as soon as it appeared. The idea to cut the boxes in half was sent to the same. I needed explosions! Bright pictures should attract users. But the idea of simply blowing up the boxes and getting points for it was considered at least unfinished to its ideal. To make the game really interesting to play, something must happen after the explosion of the box. In addition, it would be interesting if from time to time there were some events, the wind was blowing or gravity disappeared.
With all these thoughts, I decided that it was time to take into my hands a notebook and try to sketch the concept of the game.
Now is the time to consider options for the implementation of all that I wrote above.
The very first concept developed looked like this:
Just departing boxes that could blow up, there is nothing easier! However, it would be foolish to dwell on this!
The next version of the game looked like this:
The boxes became multi-colored. It was already interesting. Moreover, they became multi-colored for a reason, the color was determined by the effect that occurred after the explosion of a particular box.
For example, after the explosion of the yellow box, a fixed sphere appeared (it can be seen on the screen above). When breaking other objects about it, the player received a bonus. After the explosion of the blue box, a sphere also appeared, but now homing, if it hits something, the player receives a penalty (the total number of points won decreased).
Adding such chips made the game more interesting, which is best, the user stopped smashing the boxes mindlessly and he had a choice which of the boxes was better to be smashed first.
So I began to gradually develop a mature idea. Later events appeared that occurred depending on time. For example, the wind started to blow and blew all the boxes, or the cold wind started blowing, which also blew all the boxes, plus freezing them, which caused the texture to change to a crust of ice, and it was more difficult to identify which box was flying now.
Skill tree
Later a skill tree was added. Here is the screen:
The skill tree screen was taken in one of the latest builds of the game, before it looked different.
In my humble opinion - games with the tree of skills live longer games without him.
In general, the gameplay turned out pretty original. The name of the game was all the easier. For example: there is a game fruit slice. What needs to be done there? Cut the fruit, of course! There is my game in which you need to blow up everything that is on the screen. hence the name - Explode It!
With the idea finished, let's proceed to interesting points that have arisen as they are implemented.
Before proceeding to the description of technical issues, I will say that this is my first game, there are a lot of jambs in it, so constructive criticism, you understand, is welcome.
The game was created on Unity. In my opinion, this choice is one of the best, if not just the best. The engine has a lot of advantages. It is easy to learn, it is cross-platform, the engine has a huge working ecosystem, which includes a forum, an assetstore and many other things.
And most importantly - it is free. Now, as far as I know, there are such things as unreal engine 4 and source 2, which were also made free, but when I started to get familiar with the topic, these engines were not released yet, so the choice was obvious.
Here I do not like the standard UI in Unity. Slow, there are few opportunities, there is no binding to the sides of the screen (now, as far as I know, there are). Its main problem is the OnGUI function, which can be triggered several times per frame, which is unacceptable for mobile devices.
There is one thing here, I wrote my project on unity version 4.5.4, this version did not have an interface tied to different sides of the screen (and when switching to the new version there were crazy bugs, it was in beta testing), so without hesitation, I began to look for a replacement for the standard UI. So I found NGUI.
The principle of operation of NGUI is as follows: all GUI elements are simple objects that have their own material and are easily drawn even by mobile phones without sacrificing performance. There is one thing here: You have to display separate functions for handling events, such as pressing a button and similar ones.
NGUI paid. When purchased in the assetstore, the latest version costs $ 95 and requires Unity version 4.5.5 and higher. However, he who seeks will always find. NGUI is distributed free of charge, moreover, it is distributed free of charge on the official website, link here: www.tasharen.com/forum/index.php?topic=526.0 It can also be found on the official Unity forum: forum.unity3d.com/threads/ngui -free-edition.124032
At the end of the post, one important detail was written: “What is the catch? NGUI 2 is outdated in September 2013 at the time of NGUI 3. This is the previous version, which does not have the latest features that are present in the third version. Moreover, it lacks support. There is another limitation that is imposed on the commercial use of this version. It falls under the terms of commercial use of Unity Free. The free version of Unity cannot be licensed for commercial use if your organization’s total income does not exceed $ 100,000 (for the previous fiscal year). ”
English original read under the spoiler:
FAQ link (LICENSING & ACTIVATION) Unity: unity3d.com/unity/faq
In general, I can still use this version.
The main advantage of this UI system is that we can bind to different sides of the screen, which allows us to create functional interfaces. Moreover, all interface objects are contained in one atlas. Atlas is such a huge texture that contains all interface elements. For example, the texture of the font, buttons, icons and everything else. On mobile devices, it is desirable to limit the size of such a texture to 2048/2048 for the purpose of optimization.
In general, I will not describe all the features of NGUI right now, there is a wonderful article on Habré (especially for beginners), in which some of its features are already described, link: habrahabr.ru/post/211536
An example of an interface written in NGUI:
Another question that arose as the project progressed was how time could be efficiently calculated. I used to do this in the Update function, but there is one problem. This function is triggered by each frame. If the game has 60 fps, it will work 60 times per second. For phones, having several of these functions on stage will be a terrible hit on performance. It is desirable to reduce the number of calls to this function, or replace the function with another option.
A good example of solving such a problem is coroutines.
For example, we have a scene with the gameplay and we need some kind of action to take place every second until the moment we quit the game or load a new scene (a timer, for example).
This can be done in two ways.
Using the Update function, we need to increment a variable that counts time by the value of Time.deltatime.
The second example. We can do it differently using the coroutine and the WaitForSeconds function. In the second case, we don’t even have to write a conditional block to constantly check the current time.
Example:
It's no secret that Android is still a zoo of devices. This implies a lot of fun moments and not so much. One of these moments is the screen resolution.
If everything is more or less clear with IOs, then questions arise with Android.
Initially, the entire visual part of the game was adjusted to the resolution of 16:10.
As for the available permissions in general: here you can see an approximate (!) Table of the used screen resolutions on the Android platform: geektimes.ru/post/169141
Here is a table of screen resolutions for tablets:
Also table with permissions screens for phones:
After all the tests, the only problem was the adjustment for 4: 3 resolution.
There were a couple of ways to fix the whole situation:
In general, I will immediately say that I used the first option, I got something like this.
4: 3
3: 2
5: 3
16: 9
4:10
As can be seen from the pictures above, at a 4: 3 resolution, the menu takes up almost the entire screen, but at a resolution, for example, 16: 9, unused areas are visible on the sides.
In the skill tree, the second option did not badly help, the initially scrolling menu went under the buttons, and later began to edit it at the time of loading the level.
Nevertheless, I consider that I have coped with the problem at my level.
They are needed ... moreover, they are needed simply MANDATORY. About many problems that the programmer doesn’t even know about, he is informed by testers.
For example, I initially did not know that the game turns out to be difficult, the animation is too long, that button works several times until you just hold your finger on it, skills do not work under certain conditions, and so on.
In short, I will give a couple of examples of how the game has changed after testing it.
The design of the tree of skills has changed almost completely (under the cut). Incidentally, the game has completely changed the font.
Old version:
New option:
The same type of multi-colored boxes exchanged for various geometric objects. By the way, here is an interesting point; a person better understands the situation when, in addition to the color in objects, something else changes, for example, the geometric shape. It turned out to be interesting, because I originally had enough pure color.
Old version:
New option:
On this with interesting technical points all. Of course, you can also write about the optimization process, but I’m going to write about the optimization process for a very long time, this article will become simply enormous. If you, gentlemen, have a desire to read, I will write an article on this subject later.
If everything goes as I planned, later I will share information about the progress of the project and tell you about the features of publishing and analytics, I think this will be interesting to many.
That's all, thank you all for reading the article.
About the idea
The most interesting part of the story is that the original idea absolutely did not coincide with the final implementation. Why? Yes, everything is simple. At first I had an idea to create a puzzle using a Turing machine.
To make it clearer, I will write an example. Imagine that we have a little bit of all annoyed Angry birds. The mechanics of the game is simple, we take the bird, aim it at the pig and launch it. And now we attach the Turing machine here. For example, at the bottom of the screen there is a menu that reflects the order of actions. We do not just launch the bird, but write to the action queue, at what speed and at what angle we launch it. In this case, the level will be completed when all actions are performed correctly.
')
Of course, in my project there were no evil birds, the point was to set fire boxes in the correct order, but now there is no difference. In the end, I decided that the project was too complicated for both the game and the implementation. By that time I had been working with the engine for only a month and had managed to make a fire that was distributed specifically to specific boxes, but I had problems with the Turing machine itself.
After that, at one point, I beat the fruit slice, then I went into the unity and made sure that the boxes I had just flew out from all sides. In general, 10 minutes I watched this picture ...
So the final idea was formed.
However, we all know that writing a clean clone of a game is not enough to be able to promote it. The idea to add fruit to the game was sent by an urgent flight with all its suitcases as soon as it appeared. The idea to cut the boxes in half was sent to the same. I needed explosions! Bright pictures should attract users. But the idea of simply blowing up the boxes and getting points for it was considered at least unfinished to its ideal. To make the game really interesting to play, something must happen after the explosion of the box. In addition, it would be interesting if from time to time there were some events, the wind was blowing or gravity disappeared.
With all these thoughts, I decided that it was time to take into my hands a notebook and try to sketch the concept of the game.
Now is the time to consider options for the implementation of all that I wrote above.
About the game
The very first concept developed looked like this:
Just departing boxes that could blow up, there is nothing easier! However, it would be foolish to dwell on this!
The next version of the game looked like this:
The boxes became multi-colored. It was already interesting. Moreover, they became multi-colored for a reason, the color was determined by the effect that occurred after the explosion of a particular box.
For example, after the explosion of the yellow box, a fixed sphere appeared (it can be seen on the screen above). When breaking other objects about it, the player received a bonus. After the explosion of the blue box, a sphere also appeared, but now homing, if it hits something, the player receives a penalty (the total number of points won decreased).
Adding such chips made the game more interesting, which is best, the user stopped smashing the boxes mindlessly and he had a choice which of the boxes was better to be smashed first.
So I began to gradually develop a mature idea. Later events appeared that occurred depending on time. For example, the wind started to blow and blew all the boxes, or the cold wind started blowing, which also blew all the boxes, plus freezing them, which caused the texture to change to a crust of ice, and it was more difficult to identify which box was flying now.
Skill tree
Later a skill tree was added. Here is the screen:
The skill tree screen was taken in one of the latest builds of the game, before it looked different.
In my humble opinion - games with the tree of skills live longer games without him.
In general, the gameplay turned out pretty original. The name of the game was all the easier. For example: there is a game fruit slice. What needs to be done there? Cut the fruit, of course! There is my game in which you need to blow up everything that is on the screen. hence the name - Explode It!
With the idea finished, let's proceed to interesting points that have arisen as they are implemented.
Technical part of the project
Before proceeding to the description of technical issues, I will say that this is my first game, there are a lot of jambs in it, so constructive criticism, you understand, is welcome.
The game was created on Unity. In my opinion, this choice is one of the best, if not just the best. The engine has a lot of advantages. It is easy to learn, it is cross-platform, the engine has a huge working ecosystem, which includes a forum, an assetstore and many other things.
And most importantly - it is free. Now, as far as I know, there are such things as unreal engine 4 and source 2, which were also made free, but when I started to get familiar with the topic, these engines were not released yet, so the choice was obvious.
Ui
Here I do not like the standard UI in Unity. Slow, there are few opportunities, there is no binding to the sides of the screen (now, as far as I know, there are). Its main problem is the OnGUI function, which can be triggered several times per frame, which is unacceptable for mobile devices.
There is one thing here, I wrote my project on unity version 4.5.4, this version did not have an interface tied to different sides of the screen (and when switching to the new version there were crazy bugs, it was in beta testing), so without hesitation, I began to look for a replacement for the standard UI. So I found NGUI.
Ngui
The principle of operation of NGUI is as follows: all GUI elements are simple objects that have their own material and are easily drawn even by mobile phones without sacrificing performance. There is one thing here: You have to display separate functions for handling events, such as pressing a button and similar ones.
NGUI paid. When purchased in the assetstore, the latest version costs $ 95 and requires Unity version 4.5.5 and higher. However, he who seeks will always find. NGUI is distributed free of charge, moreover, it is distributed free of charge on the official website, link here: www.tasharen.com/forum/index.php?topic=526.0 It can also be found on the official Unity forum: forum.unity3d.com/threads/ngui -free-edition.124032
At the end of the post, one important detail was written: “What is the catch? NGUI 2 is outdated in September 2013 at the time of NGUI 3. This is the previous version, which does not have the latest features that are present in the third version. Moreover, it lacks support. There is another limitation that is imposed on the commercial use of this version. It falls under the terms of commercial use of Unity Free. The free version of Unity cannot be licensed for commercial use if your organization’s total income does not exceed $ 100,000 (for the previous fiscal year). ”
English original read under the spoiler:
Original
“What's the catch? NGUI 2 has been deprecated in September 2013. It also does not come with support. Unity Free: “If you’ve been using them for commercial purposes, it’s not limited to US $ 100,000.
FAQ link (LICENSING & ACTIVATION) Unity: unity3d.com/unity/faq
In general, I can still use this version.
The main advantage of this UI system is that we can bind to different sides of the screen, which allows us to create functional interfaces. Moreover, all interface objects are contained in one atlas. Atlas is such a huge texture that contains all interface elements. For example, the texture of the font, buttons, icons and everything else. On mobile devices, it is desirable to limit the size of such a texture to 2048/2048 for the purpose of optimization.
In general, I will not describe all the features of NGUI right now, there is a wonderful article on Habré (especially for beginners), in which some of its features are already described, link: habrahabr.ru/post/211536
An example of an interface written in NGUI:
Update vs coroutines
Another question that arose as the project progressed was how time could be efficiently calculated. I used to do this in the Update function, but there is one problem. This function is triggered by each frame. If the game has 60 fps, it will work 60 times per second. For phones, having several of these functions on stage will be a terrible hit on performance. It is desirable to reduce the number of calls to this function, or replace the function with another option.
A good example of solving such a problem is coroutines.
For example, we have a scene with the gameplay and we need some kind of action to take place every second until the moment we quit the game or load a new scene (a timer, for example).
This can be done in two ways.
Using the Update function, we need to increment a variable that counts time by the value of Time.deltatime.
float currentTimer = 0; void Update() { currentTimer += Time.deltaTime; if (currentTimer >= 1){ // currentTimer = 0; } } The second example. We can do it differently using the coroutine and the WaitForSeconds function. In the second case, we don’t even have to write a conditional block to constantly check the current time.
Example:
IEnumerator Example() { while(true){ yield return new WaitForSeconds(1); // } } Screen resolution
It's no secret that Android is still a zoo of devices. This implies a lot of fun moments and not so much. One of these moments is the screen resolution.
If everything is more or less clear with IOs, then questions arise with Android.
Initially, the entire visual part of the game was adjusted to the resolution of 16:10.
As for the available permissions in general: here you can see an approximate (!) Table of the used screen resolutions on the Android platform: geektimes.ru/post/169141
Here is a table of screen resolutions for tablets:
Also table with permissions screens for phones:
After all the tests, the only problem was the adjustment for 4: 3 resolution.
There were a couple of ways to fix the whole situation:
- Leave the picture as it is for all screen ratios. In the code, the pictures do not change, just tune in the editor. The normal solution is if there is no time to do a separate assembly for each ratio and write a bunch of scripts in which you have to change the initial size of the pictures.
Advantages of the method: no need to write any scripts and do several assemblies under different ratios. Net time savings.
There is one drawback. Suppose that we made it so that the whole picture is placed on the screen at a 4: 3 ratio (usually on screens with this ratio in landscape orientation, the picture creeps out of the edges of the screen), but we assume that we succeeded. At the same time, the game on the 16:10 aspect ratio will still look normal, at 16: 9 unused areas on the sides will be pronounced. - Change the size of pictures depending on the ratio. I did this in the scene responsible for the skill tree. But in general, if you have a shortage of time - the method may not seem the best. Too much to change. Not only separate textures, but also the text itself (which also got out of the screen) and many other things.
- Change the size of the camera. The way of a man who clearly set his sights on catching a freebie. It almost never helps, because not only the width of the camera changes (I was interested in unused areas on the right), but also the height of the camera, which is logical. It also does not help if you use NGUI, and you have an IUDraggablePanel script on the scene that is responsible for the scrollable menu.
In general, I will immediately say that I used the first option, I got something like this.
4: 3
3: 2
5: 3
16: 9
4:10
As can be seen from the pictures above, at a 4: 3 resolution, the menu takes up almost the entire screen, but at a resolution, for example, 16: 9, unused areas are visible on the sides.
In the skill tree, the second option did not badly help, the initially scrolling menu went under the buttons, and later began to edit it at the time of loading the level.
Nevertheless, I consider that I have coped with the problem at my level.
Testers
They are needed ... moreover, they are needed simply MANDATORY. About many problems that the programmer doesn’t even know about, he is informed by testers.
For example, I initially did not know that the game turns out to be difficult, the animation is too long, that button works several times until you just hold your finger on it, skills do not work under certain conditions, and so on.
In short, I will give a couple of examples of how the game has changed after testing it.
The design of the tree of skills has changed almost completely (under the cut). Incidentally, the game has completely changed the font.
Old version:
New option:
The same type of multi-colored boxes exchanged for various geometric objects. By the way, here is an interesting point; a person better understands the situation when, in addition to the color in objects, something else changes, for example, the geometric shape. It turned out to be interesting, because I originally had enough pure color.
Old version:
New option:
On this with interesting technical points all. Of course, you can also write about the optimization process, but I’m going to write about the optimization process for a very long time, this article will become simply enormous. If you, gentlemen, have a desire to read, I will write an article on this subject later.
If everything goes as I planned, later I will share information about the progress of the project and tell you about the features of publishing and analytics, I think this will be interesting to many.
That's all, thank you all for reading the article.
Source: https://habr.com/ru/post/260467/
All Articles