Evolution of the gameplay on the example of one game
At the end of November of this year on the Android platform and, a week later, our game called Voltage ( Android, iOS , Gameplay Video ) came out on iOS. I want to share a small story of its creation with the community. It should be immediately warned that this is not an “success story”, not an instruction on how to deal with publishers, and certainly not a theoretical introduction to the development of gaming applications.
Most of the attention we paid to the evolution of gameplay - from the prototype, to the final version and development plans. Just because for us it was the most interesting part of the development. It is possible that there will be the following articles, in which we will talk more about the technical side of the issue, in particular, about the development practice under the Corona SDK, as well as about our experience in promotion and promotion.
')
The task was the following: to develop a game that would be:
but. easy to make
b. simple in terms of gameplay.
To this, for purely aesthetic reasons, one more point was added: do not overdo the game mechanics one to one. To follow the motto already established in casual game devs, “who has time before, you or he” frankly did not want to.
Technically, this last point can be solved in two ways - fantastic and pragmatic. Fantastic implies composing something absolutely new, which has not yet appeared in any form among thousands and thousands of "timekillers". In an ideal world, where all the ideas that come to mind are fresh and original, we would use this option.
A pragmatic approach implies the achievement of a novelty effect with the help of a scalpel and surgical thread. As a result, two classic games went to the Vivisector's table: Tetris and Plumber. Next, it remains to cut off the excess and apply to the resulting monster voltage:
Initially it was assumed that the blocks would fall in groups of four, and they could be operated according to the Tetris rules. From this idea had to be abandoned after the first prototype.
The following prototype already contained the main features of the final version: the blocks began falling out one by one, the block controlled by the player remained in the top row for as long as the player decided to drop it down, and finally several different types of block appeared.
The blocks in the prototype were of five types:
1. A universal block that could be rotated and moved horizontally.
2. "Semirotary" - when moving to the cell to the left or to the right, such a block was rotated by a quarter of a turn. Nobody bothered to come up with an adequate Russian name for him - until now he walks under the conspiracy pseudonym “green”.
3. Fixed block - does not rotate when moving.
4. “Bomb” - being in a short circuit, destroys directly touching blocks.
5. Insulator - a block without conductors with a characteristic striped coloring.
Testing the prototype revealed a number of flaws. The most obvious was the size of the "glass." Filling a field of 11 Ă— 16 at least up to the middle seemed almost impossible to do. From this point we started, cutting sides to 7 Ă— 8 cells. At the same time, the opportunity to make the blocks themselves is much larger. The second prototype looked like this:
The following problems with management and balance came to light: the ability to both rotate and move the universal block ate away all four “swipe” directions, as a result of which it was necessary to “drop” the block by pressing it directly with your finger. In addition, against the background of the other blocks, the universal simplified the game too much.
For these two reasons, changes have occurred in the ranks of the blocks. Insulators, bombs and the "green" block remained with him. The universal block has ceased to be universal - they have taken away the opportunity to move in the horizontal direction. Now, instead of five possible movements with a finger, three could be left: “left / right” move and / or rotate the block depending on the type, “down” - drops the block vertically.
Practically from the very beginning, we decided to stylize the game under “dieselpunk”. That is, retro-futurism of the 30s, with all the relevant fonts, color and sound design. And in this short chapter one could just show the picture and move on, if not for one “but”:
On the artists project was not lucky from the start. That is, they themselves were not bad experts and just good people, but the circumstances from force majeure to frankly comical, washed them out of the design with intrusiveness suggestive of evil intent.
Therefore, if the idea to stylize a game under the 30s from the very beginning of development did not undergo any changes, the graphics themselves changed several times as the entropy mowed down our ranks. Here, for example, one of the intermediate options:
It should be immediately noted that the picture on the screen of the phone looked much prettier, but on the whole the stylization was performed in full accordance with the principle described in the composition “Just glue some gears” . In particular, gas-discharge indicators with the era of diesel intersected with a huge stretch, not to mention the brass tubes.
Finally, we met a designer, much less prone to the emanations of Chaos, and successfully got the final version:
Instead of gas-discharge indicators there are cylindrical counters with numbers, instead of a slurred creeping strip there are consecutively incandescent lamps. The blocks retained recognizable colors, and the conductors became well distinguishable.
With this, almost finished version, we drove to Casual Connect Kyiv 2011 , where, in addition to the usual entertainment for such events, we took up field testing for living people. If we had released the game right after returning, it could be provided with approximately such annotation:
- I suck at this game.
Some drunk guy from “Rovio”
- Why is there a light bulb?
Sober developer from the next table
And further in the same vein. What we took for granted turned out to be far less obvious to a third-party user. The game had to be simplified.
Initially, the system was as follows: depending on the mode, the player had time limits or blocks, or no limits at all. Gaining points, the player "charged" the indicator - the very light-on-the-shelf - until they lit up all. At this point, the player added resources and prize points.
It seems so obvious. Not really. First, the problem was created by the fact that the indicator was filled in proportion to the points scored: the longer the chain was collected by the player, the faster he received bonus resources. The seemingly logical scheme did not contain enough clues to derive it empirically. Secondly, it contained a curious underwater stone: what to do if a player having 75% of a fully charged indicator, added another 50%?
You can give him the bonus due and set the indicator to 75 + 50-100 = 25%. But then the player, who is not obliged, in general, to observe the indicator incessantly, will in fact see that his testimony has decreased.
You can reset the indicator. This is much more obvious and understandable mechanics, but it conceals an even more unpleasant trick: the player can spend a lot of resources on a long chain, but with a 90% charged indicator, most of them will be wasted. As a result, the game punishes for what, in theory, should be encouraged.
Finally, the game itself, despite all efforts, stubbornly collapsed into one of two stable states: “to the insulting easy” and “mockingly complicated”. The gameplay was configured from a JSON file, in which the probabilities of each block and explorer were described - during the game, the probabilities remained unchanged.
All this we began to rebuild.
First, we changed the principle by which the charge indicator grows - now the fact that the player has closed the circuit, and not the length of this circuit, is important.
Then, we added the concept of "level." The charge indicator has become an analogue of the “experience” counter. For each new level, the number of closures is gradually increasing.
Every time a player receives bonus points and resources, he is informed about their quantity and the reason for their receipt - whether it is a circuit closure or reaching a new level.
The system has become much more transparent and understandable.
But the gameplay itself was still a choice between the unpleasant and the inevitable - the complexity curve had to be made flatter. In the original version, the game began with hardcore and further, as the playing field was filled with “garbage” blocks, it only became more difficult.
The first change made did not change the difficulty at all: we simply multiplied all the bonuses by ten and began to give five more points for each block dropped. The psychological effect was much more significant than it might have been supposed at first glance. With the same level of complexity, the perception of game achievements has changed.
Further, instead of fixed probabilities, we have introduced the dependence of the probability of the occurrence of a block and a conductor on it from the current level. Along the way, especially unpleasant combinations were completely removed from the first levels.
As a result, the immersion into the game was simplified at early levels. In addition, the gameplay itself has become more controlled.
We did the prototype exclusively on Android, using quite native means and using Canvas to display the graphics. Then, when it came to full development, we thought about a slightly more productive and, if possible, cross-platform engine.
In the end, we settled on the Corona SDK - which, with certain disadvantages, had two undoubted advantages: firstly, to achieve compatibility with Android and iOS practically no effort was required and, secondly, in its class, developers were very expensive and very cheap.
The source code for the Corona SDK is written in Lua — I, with my development experience under LAMP, found it very easy to get comfortable with this language, but a colleague who is more specialized in compiled languages ​​suffered a bit.
In general, the Crown API has a quick start, but, as is often the case with similar systems, the low threshold of entry has a downside. So, if you don’t take time to develop your own layer between the API and the game logic, in a month you will have a very heavy pile of hard-to-read code. Fortunately, this cup has passed us, unlike our colleagues, on the bitter experience of which this statement is based.
The performance problem in the Corona SDK is solved simply: by cutting the budget phone segment at the level of system requirements. That is, on an operating system earlier than Android 2.2 and with processors lower than ARM7, the game will not start. Neither quickly nor slowly - no way.
Is it worth knowingly excluding potential players in exchange for simple development and cross-platform - the question is open and, in general, it remains outside the framework of this particular article. For us, this is a choice already made and in the very near future we will find out whether it was correct or erroneous.
The released version of the game is free with built-in ads. For Christmas, we are switching to the Freemium model - advertising will be disabled in the paid version, and all new tasty chips will be added to it.
Also, we include the in-game currency in the new version, with the possibility for players to further simplify their lives due to the acquired bonuses.
And yet - the new game mode.
Download Voltage here:
Voltage Gameplay Video
PS While this article was being written, Voltage has accumulated a small statistic, which I will share:
Android: in 2 weeks the number of downloads on the Android Market: ~ 4700, the total number of downloads (android market + countless Chinese-Korean markets) - 12k. Every day, the game is downloaded about 100-200 users more than the previous day.
iOS: about 2500 downloads, the growth rate of which is the same as on Android.
PPS In the recent ITJump competition , Voltage ranked second in the games category.
Most of the attention we paid to the evolution of gameplay - from the prototype, to the final version and development plans. Just because for us it was the most interesting part of the development. It is possible that there will be the following articles, in which we will talk more about the technical side of the issue, in particular, about the development practice under the Corona SDK, as well as about our experience in promotion and promotion.
')
1. The Island of Dr. Pazhitnov
The task was the following: to develop a game that would be:
but. easy to make
b. simple in terms of gameplay.
To this, for purely aesthetic reasons, one more point was added: do not overdo the game mechanics one to one. To follow the motto already established in casual game devs, “who has time before, you or he” frankly did not want to.
Technically, this last point can be solved in two ways - fantastic and pragmatic. Fantastic implies composing something absolutely new, which has not yet appeared in any form among thousands and thousands of "timekillers". In an ideal world, where all the ideas that come to mind are fresh and original, we would use this option.
A pragmatic approach implies the achievement of a novelty effect with the help of a scalpel and surgical thread. As a result, two classic games went to the Vivisector's table: Tetris and Plumber. Next, it remains to cut off the excess and apply to the resulting monster voltage:
- There is a “glass” of a certain size with a certain number of “cells”.
- There are game elements-blocks, vertically falling into the "glass".
- The blocks carry on themselves the "conductors" of various configurations.
- If a player closes the opposite sides of the "glass" with a chain of conductors, the elements containing this chain are burned.
Initially it was assumed that the blocks would fall in groups of four, and they could be operated according to the Tetris rules. From this idea had to be abandoned after the first prototype.
The following prototype already contained the main features of the final version: the blocks began falling out one by one, the block controlled by the player remained in the top row for as long as the player decided to drop it down, and finally several different types of block appeared.
The blocks in the prototype were of five types:
1. A universal block that could be rotated and moved horizontally.
2. "Semirotary" - when moving to the cell to the left or to the right, such a block was rotated by a quarter of a turn. Nobody bothered to come up with an adequate Russian name for him - until now he walks under the conspiracy pseudonym “green”.
3. Fixed block - does not rotate when moving.
4. “Bomb” - being in a short circuit, destroys directly touching blocks.
5. Insulator - a block without conductors with a characteristic striped coloring.
Testing the prototype revealed a number of flaws. The most obvious was the size of the "glass." Filling a field of 11 Ă— 16 at least up to the middle seemed almost impossible to do. From this point we started, cutting sides to 7 Ă— 8 cells. At the same time, the opportunity to make the blocks themselves is much larger. The second prototype looked like this:
The following problems with management and balance came to light: the ability to both rotate and move the universal block ate away all four “swipe” directions, as a result of which it was necessary to “drop” the block by pressing it directly with your finger. In addition, against the background of the other blocks, the universal simplified the game too much.
For these two reasons, changes have occurred in the ranks of the blocks. Insulators, bombs and the "green" block remained with him. The universal block has ceased to be universal - they have taken away the opportunity to move in the horizontal direction. Now, instead of five possible movements with a finger, three could be left: “left / right” move and / or rotate the block depending on the type, “down” - drops the block vertically.
2. Styling and stylists
Practically from the very beginning, we decided to stylize the game under “dieselpunk”. That is, retro-futurism of the 30s, with all the relevant fonts, color and sound design. And in this short chapter one could just show the picture and move on, if not for one “but”:
On the artists project was not lucky from the start. That is, they themselves were not bad experts and just good people, but the circumstances from force majeure to frankly comical, washed them out of the design with intrusiveness suggestive of evil intent.
Therefore, if the idea to stylize a game under the 30s from the very beginning of development did not undergo any changes, the graphics themselves changed several times as the entropy mowed down our ranks. Here, for example, one of the intermediate options:
It should be immediately noted that the picture on the screen of the phone looked much prettier, but on the whole the stylization was performed in full accordance with the principle described in the composition “Just glue some gears” . In particular, gas-discharge indicators with the era of diesel intersected with a huge stretch, not to mention the brass tubes.
Finally, we met a designer, much less prone to the emanations of Chaos, and successfully got the final version:
Instead of gas-discharge indicators there are cylindrical counters with numbers, instead of a slurred creeping strip there are consecutively incandescent lamps. The blocks retained recognizable colors, and the conductors became well distinguishable.
3. Between unpleasant and inevitable
With this, almost finished version, we drove to Casual Connect Kyiv 2011 , where, in addition to the usual entertainment for such events, we took up field testing for living people. If we had released the game right after returning, it could be provided with approximately such annotation:
- I suck at this game.
Some drunk guy from “Rovio”
- Why is there a light bulb?
Sober developer from the next table
And further in the same vein. What we took for granted turned out to be far less obvious to a third-party user. The game had to be simplified.
Initially, the system was as follows: depending on the mode, the player had time limits or blocks, or no limits at all. Gaining points, the player "charged" the indicator - the very light-on-the-shelf - until they lit up all. At this point, the player added resources and prize points.
It seems so obvious. Not really. First, the problem was created by the fact that the indicator was filled in proportion to the points scored: the longer the chain was collected by the player, the faster he received bonus resources. The seemingly logical scheme did not contain enough clues to derive it empirically. Secondly, it contained a curious underwater stone: what to do if a player having 75% of a fully charged indicator, added another 50%?
You can give him the bonus due and set the indicator to 75 + 50-100 = 25%. But then the player, who is not obliged, in general, to observe the indicator incessantly, will in fact see that his testimony has decreased.
You can reset the indicator. This is much more obvious and understandable mechanics, but it conceals an even more unpleasant trick: the player can spend a lot of resources on a long chain, but with a 90% charged indicator, most of them will be wasted. As a result, the game punishes for what, in theory, should be encouraged.
Finally, the game itself, despite all efforts, stubbornly collapsed into one of two stable states: “to the insulting easy” and “mockingly complicated”. The gameplay was configured from a JSON file, in which the probabilities of each block and explorer were described - during the game, the probabilities remained unchanged.
All this we began to rebuild.
First, we changed the principle by which the charge indicator grows - now the fact that the player has closed the circuit, and not the length of this circuit, is important.
Then, we added the concept of "level." The charge indicator has become an analogue of the “experience” counter. For each new level, the number of closures is gradually increasing.
Every time a player receives bonus points and resources, he is informed about their quantity and the reason for their receipt - whether it is a circuit closure or reaching a new level.
The system has become much more transparent and understandable.
But the gameplay itself was still a choice between the unpleasant and the inevitable - the complexity curve had to be made flatter. In the original version, the game began with hardcore and further, as the playing field was filled with “garbage” blocks, it only became more difficult.
The first change made did not change the difficulty at all: we simply multiplied all the bonuses by ten and began to give five more points for each block dropped. The psychological effect was much more significant than it might have been supposed at first glance. With the same level of complexity, the perception of game achievements has changed.
Further, instead of fixed probabilities, we have introduced the dependence of the probability of the occurrence of a block and a conductor on it from the current level. Along the way, especially unpleasant combinations were completely removed from the first levels.
As a result, the immersion into the game was simplified at early levels. In addition, the gameplay itself has become more controlled.
4. A crown that does not shake
We did the prototype exclusively on Android, using quite native means and using Canvas to display the graphics. Then, when it came to full development, we thought about a slightly more productive and, if possible, cross-platform engine.
In the end, we settled on the Corona SDK - which, with certain disadvantages, had two undoubted advantages: firstly, to achieve compatibility with Android and iOS practically no effort was required and, secondly, in its class, developers were very expensive and very cheap.
The source code for the Corona SDK is written in Lua — I, with my development experience under LAMP, found it very easy to get comfortable with this language, but a colleague who is more specialized in compiled languages ​​suffered a bit.
In general, the Crown API has a quick start, but, as is often the case with similar systems, the low threshold of entry has a downside. So, if you don’t take time to develop your own layer between the API and the game logic, in a month you will have a very heavy pile of hard-to-read code. Fortunately, this cup has passed us, unlike our colleagues, on the bitter experience of which this statement is based.
The performance problem in the Corona SDK is solved simply: by cutting the budget phone segment at the level of system requirements. That is, on an operating system earlier than Android 2.2 and with processors lower than ARM7, the game will not start. Neither quickly nor slowly - no way.
Is it worth knowingly excluding potential players in exchange for simple development and cross-platform - the question is open and, in general, it remains outside the framework of this particular article. For us, this is a choice already made and in the very near future we will find out whether it was correct or erroneous.
5. Instead of conclusion
The released version of the game is free with built-in ads. For Christmas, we are switching to the Freemium model - advertising will be disabled in the paid version, and all new tasty chips will be added to it.
Also, we include the in-game currency in the new version, with the possibility for players to further simplify their lives due to the acquired bonuses.
And yet - the new game mode.
Download Voltage here:
Android Voltage
Voltage iOS
Voltage Gameplay Video
PS While this article was being written, Voltage has accumulated a small statistic, which I will share:
Android: in 2 weeks the number of downloads on the Android Market: ~ 4700, the total number of downloads (android market + countless Chinese-Korean markets) - 12k. Every day, the game is downloaded about 100-200 users more than the previous day.
iOS: about 2500 downloads, the growth rate of which is the same as on Android.
PPS In the recent ITJump competition , Voltage ranked second in the games category.
Source: https://habr.com/ru/post/134470/
All Articles