December 12, 2011 at 20:31The evolution of gameplay on the example of one game
At the end of November this year, on the Android platform and, a week later, on iOS, our game called Voltage ( Android, iOS , Gameplay Video ) came out . I want to share a small history of its creation with the community. It should be immediately warned that this is not a “success story”, not an instruction for dealing 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 for Corona SDK, as well as about our experience of promotion and promotion.
The task was as follows: to develop a game that would be:
a. easy to manufacture
b. simple in terms of gameplay.
To this, for purely aesthetic reasons, another point was added: do not distort the game mechanics one to one. Frankly, I did not want to follow the motto “who has time before, you or him”, already established in casual game development.
Technically, this last point can be solved in two ways - fantastic and pragmatic. Fantastic implies the composition of something completely new, which has not yet appeared in any form among the thousands and thousands of “time killers”. In an ideal world where all the ideas that come to mind are fresh and original, we would use this option.
A pragmatic approach involves achieving a novelty effect with a scalpel and surgical thread. As a result, two classic games fell on the vivisector table: Tetris and Plumber. Next, it remains to cut off the excess and apply voltage to the resulting monster:
Initially, it was assumed that the blocks would fall in groups of four and that they could be operated on according to the Tetris rules. This idea had to be abandoned after the very first prototype.
The next prototype already contained the main features of the final version: the blocks began to fall out one by one, the block controlled by the player was in the upper row for an arbitrarily long time, until the player decided to drop it down and, finally, several different types of blocks 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 left or right, such a block rotated a quarter of a turn. Nobody bothered to come up with an adequate Russian name for him - until now he goes under the conspiratorial pseudonym “green”.
3. Fixed block - does not rotate when moving.
4. "Bomb" - being in a shorted circuit, destroys directly contacting blocks.
5. Insulator - a block without conductors with a characteristic striped coloring.
Testing of the prototype revealed a number of disadvantages. The most obvious was the size of the "glass." It seemed almost impossible to fill an 11 × 16 field at least until the middle. They started from this, cutting the sides to 7 × 8 cells. At the same time, it became possible to make the blocks themselves much larger. The second prototype looked something like this:
The following identified problems with control and balance: the ability to rotate and move the universal block ate away all four “swipe” directions, as a result of which the block had to be dropped by directly pressing it with a finger. In addition, against the background of the rest of the blocks, the universal too simplified the game.
For these two reasons, changes have occurred in the ranks of the blocks. Insulators, bombs and the green block remained with them. The universal block ceased to be universal - it was taken away from it the ability to move in the horizontal direction. Now, instead of five possible finger movements, it was possible to leave three: “left / right” move and / or rotate the block depending on type, “down” - drop the block steeply.
Almost from the very beginning, we decided to stylize the game as a “diesel punk”. That is, retro-futurism of the 30s, with all the corresponding fonts, color and sound design. And in this short chapter, one could simply show a picture and move on, if not for one “but”: the
project was not lucky for the artists from the very beginning. That is, they themselves were good specialists and just good people, but circumstances from force majeure to frankly comical washed them out of the development with intrusiveness leading to suspicions of malicious intent.
Therefore, if the idea of styling a game under the 30s did not undergo any changes from the very beginning of development, the graphics themselves changed several times as entropy mowed down our ranks. Here, for example, is one of the intermediate options:
It should be noted right away that the picture looked much nicer on the phone screen, but in general the styling was done in full accordance with the principle described in the composition “Just glue some gears on it and call it steampunk” . In particular, discharge indicators with the era of the diesel engine intersected with a huge stretch, not to mention brass tubes.
Finally, we met a designer who was much less prone to Chaos emanations and safely got the final version:
Instead of gas-discharge indicators, cylindrical meters with numbers, instead of a slurred creeping strip, incandescent lamps were connected in series. The blocks retained recognizable colors, and the conductors became clearly distinguishable.
With this, almost ready-made version, we drove to Casual Connect Kyiv 2011 , where, in addition to the usual entertainment for such events, we started field testing on live people. We release the game immediately upon return, it could be provided with something like this annotation:
- I suck at this game.
Some drunk guy from “Rovio”
- Why are there any light bulbs?
Sober developer from the next table
And then in the same vein. What we took for granted turned out to be much 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 or block restrictions, or had no restrictions at all. Gaining points, the player “charged” the indicator - those same bulbs-on-a-shelf - until they all lit up. At this point, the player added resources and prize points.
It seems so obvious. In reality, no. Firstly, the problem was created by the fact that the indicator was filled in proportion to the points earned: the longer the player collected the chain, the faster he received prize resources. The seemingly logical scheme did not contain enough clues to deduce it empirically. Secondly, it contained a curious pitfall: what if a player, having 75% of a fully charged indicator, added another 50%?
You can give him a 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 inseparably, in fact, he will see that his readings have decreased.
You can reset the indicator. This is a much more obvious and understandable mechanics, but it conceals an even more unpleasant catch: a 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 encourage.
Finally, the game itself, despite all efforts, stubbornly fell into one of two stable states: “offensively easy” and “mockingly difficult”. The gameplay was configured from a JSON file in which the probabilities of falling out of each block and conductor were described - during the game the probabilities remained unchanged.
We started to rebuild all this.
First, we changed the principle by which the charge indicator increases - now the fact that the player has closed the chain, and not the length of this chain, matters.
Then, we added the concept of "level." The charge indicator has become an analogue of the “experience” counter. For each new levellap, the number of closures is gradually growing.
Each time a player receives bonus points and resources, he is informed of their quantity and the reason for receiving it, whether it is circuit closure or achievement of a new level.
The system has become much more transparent and understandable.
But the gameplay itself still represented a choice between unpleasant and inevitable - the complexity curve had to be made more gentle. In the initial version, the game began with hardcore and further, as the playing field was filled with “garbage” blocks, it became only more difficult.
The first change made did not change the difficulty at all: we just multiplied all the bonuses by ten and for each dropped block we began to give another five points. The psychological effect turned out to be much more significant than could be expected at first glance. At the same level of difficulty, the very perception of gaming achievements has changed.
Further, instead of fixed probabilities, we introduced the dependence of the probability of the appearance of a block and conductor on it from the current level. Along the way, especially unpleasant combinations were completely removed from the first levels.
As a result, immersion in the game at early levels was simplified. In addition, the gameplay itself has become more controlled.
We made the prototype purely on Android, using native tools, and used Canvas to display graphics. Then, when it came to the full-fledged 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, almost no effort was required and, secondly, in its class, developer licenses were very expensive very cheap.
The source code for the Corona SDK is written in Lua - to me, with my experience in developing for LAMP it turned out to be very easy to get comfortable with this language, but a colleague who is more specialized in compiled languages suffered a little.
In general, the Crown API has a quick start, but, as is often the case with similar systems, the low entry threshold has a downside. So, if you are not puzzled by the development of your own layer between the API and the game logic in time, in a month you will have a heavy pile of hard to read code. Fortunately, this cup passed us, unlike our colleagues, on the bitter experience of which this statement of ours is based.
The performance problem in the Corona SDK is solved simply: by cutting off the segment of budget phones 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 fast nor slow - no way.
Is it worth it to deliberately exclude potential players in exchange for simple development and cross-platform - an open question and, in general, it remains outside the scope of this specific article. This is already a choice for us and in the very near future we will find out whether it was true or false.
The version of the game released by us is free, with built-in advertising. By Christmas, we are switching to the Freemium model - advertising will be disabled in the paid version, and new and tasty chips will be added to it.
Also, we include in-game currency in the new version, with the possibility for players to further simplify their lives by purchasing bonuses.
And yet - a new game mode.
Download Voltage here:
Voltage Gameplay Video
PS While this article was being written, Voltage accumulated small statistics, 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 Sino-Korean markets) - 12k. Every day, the game is uploaded by about 100-200 users more than on the previous day.
iOS: about 2500 downloads, the growth rate of which is the same as on Android.
PPS In a recent competition, ITJump Voltage ranked second in the gaming 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 for Corona SDK, as well as about our experience of promotion and promotion.
1. The island of Dr. Pajitnov
The task was as follows: to develop a game that would be:
a. easy to manufacture
b. simple in terms of gameplay.
To this, for purely aesthetic reasons, another point was added: do not distort the game mechanics one to one. Frankly, I did not want to follow the motto “who has time before, you or him”, already established in casual game development.
Technically, this last point can be solved in two ways - fantastic and pragmatic. Fantastic implies the composition of something completely new, which has not yet appeared in any form among the thousands and thousands of “time killers”. In an ideal world where all the ideas that come to mind are fresh and original, we would use this option.
A pragmatic approach involves achieving a novelty effect with a scalpel and surgical thread. As a result, two classic games fell on the vivisector table: Tetris and Plumber. Next, it remains to cut off the excess and apply voltage to the resulting monster:
- There is a “glass” of a certain size with a certain number of “cells”.
- There are game elements-blocks, vertically descending into the "glass".
- Blocks carry "conductors" of various configurations.
- If the player closes the opposite sides of the “glass” with a chain of conductors, the elements containing this chain burn out.
Initially, it was assumed that the blocks would fall in groups of four and that they could be operated on according to the Tetris rules. This idea had to be abandoned after the very first prototype.
The next prototype already contained the main features of the final version: the blocks began to fall out one by one, the block controlled by the player was in the upper row for an arbitrarily long time, until the player decided to drop it down and, finally, several different types of blocks 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 left or right, such a block rotated a quarter of a turn. Nobody bothered to come up with an adequate Russian name for him - until now he goes under the conspiratorial pseudonym “green”.
3. Fixed block - does not rotate when moving.
4. "Bomb" - being in a shorted circuit, destroys directly contacting blocks.
5. Insulator - a block without conductors with a characteristic striped coloring.
Testing of the prototype revealed a number of disadvantages. The most obvious was the size of the "glass." It seemed almost impossible to fill an 11 × 16 field at least until the middle. They started from this, cutting the sides to 7 × 8 cells. At the same time, it became possible to make the blocks themselves much larger. The second prototype looked something like this:
The following identified problems with control and balance: the ability to rotate and move the universal block ate away all four “swipe” directions, as a result of which the block had to be dropped by directly pressing it with a finger. In addition, against the background of the rest of the blocks, the universal too simplified the game.
For these two reasons, changes have occurred in the ranks of the blocks. Insulators, bombs and the green block remained with them. The universal block ceased to be universal - it was taken away from it the ability to move in the horizontal direction. Now, instead of five possible finger movements, it was possible to leave three: “left / right” move and / or rotate the block depending on type, “down” - drop the block steeply.
2. Stylization and stylists
Almost from the very beginning, we decided to stylize the game as a “diesel punk”. That is, retro-futurism of the 30s, with all the corresponding fonts, color and sound design. And in this short chapter, one could simply show a picture and move on, if not for one “but”: the
project was not lucky for the artists from the very beginning. That is, they themselves were good specialists and just good people, but circumstances from force majeure to frankly comical washed them out of the development with intrusiveness leading to suspicions of malicious intent.
Therefore, if the idea of styling a game under the 30s did not undergo any changes from the very beginning of development, the graphics themselves changed several times as entropy mowed down our ranks. Here, for example, is one of the intermediate options:
It should be noted right away that the picture looked much nicer on the phone screen, but in general the styling was done in full accordance with the principle described in the composition “Just glue some gears on it and call it steampunk” . In particular, discharge indicators with the era of the diesel engine intersected with a huge stretch, not to mention brass tubes.
Finally, we met a designer who was much less prone to Chaos emanations and safely got the final version:
Instead of gas-discharge indicators, cylindrical meters with numbers, instead of a slurred creeping strip, incandescent lamps were connected in series. The blocks retained recognizable colors, and the conductors became clearly distinguishable.
3. Between the unpleasant and the inevitable
With this, almost ready-made version, we drove to Casual Connect Kyiv 2011 , where, in addition to the usual entertainment for such events, we started field testing on live people. We release the game immediately upon return, it could be provided with something like this annotation:
- I suck at this game.
Some drunk guy from “Rovio”
- Why are there any light bulbs?
Sober developer from the next table
And then in the same vein. What we took for granted turned out to be much 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 or block restrictions, or had no restrictions at all. Gaining points, the player “charged” the indicator - those same bulbs-on-a-shelf - until they all lit up. At this point, the player added resources and prize points.
It seems so obvious. In reality, no. Firstly, the problem was created by the fact that the indicator was filled in proportion to the points earned: the longer the player collected the chain, the faster he received prize resources. The seemingly logical scheme did not contain enough clues to deduce it empirically. Secondly, it contained a curious pitfall: what if a player, having 75% of a fully charged indicator, added another 50%?
You can give him a 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 inseparably, in fact, he will see that his readings have decreased.
You can reset the indicator. This is a much more obvious and understandable mechanics, but it conceals an even more unpleasant catch: a 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 encourage.
Finally, the game itself, despite all efforts, stubbornly fell into one of two stable states: “offensively easy” and “mockingly difficult”. The gameplay was configured from a JSON file in which the probabilities of falling out of each block and conductor were described - during the game the probabilities remained unchanged.
We started to rebuild all this.
First, we changed the principle by which the charge indicator increases - now the fact that the player has closed the chain, and not the length of this chain, matters.
Then, we added the concept of "level." The charge indicator has become an analogue of the “experience” counter. For each new levellap, the number of closures is gradually growing.
Each time a player receives bonus points and resources, he is informed of their quantity and the reason for receiving it, whether it is circuit closure or achievement of a new level.
The system has become much more transparent and understandable.
But the gameplay itself still represented a choice between unpleasant and inevitable - the complexity curve had to be made more gentle. In the initial version, the game began with hardcore and further, as the playing field was filled with “garbage” blocks, it became only more difficult.
The first change made did not change the difficulty at all: we just multiplied all the bonuses by ten and for each dropped block we began to give another five points. The psychological effect turned out to be much more significant than could be expected at first glance. At the same level of difficulty, the very perception of gaming achievements has changed.
Further, instead of fixed probabilities, we introduced the dependence of the probability of the appearance of a block and conductor on it from the current level. Along the way, especially unpleasant combinations were completely removed from the first levels.
As a result, immersion in the game at early levels was simplified. In addition, the gameplay itself has become more controlled.
4. The crown that does not press
We made the prototype purely on Android, using native tools, and used Canvas to display graphics. Then, when it came to the full-fledged 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, almost no effort was required and, secondly, in its class, developer licenses were very expensive very cheap.
The source code for the Corona SDK is written in Lua - to me, with my experience in developing for LAMP it turned out to be very easy to get comfortable with this language, but a colleague who is more specialized in compiled languages suffered a little.
In general, the Crown API has a quick start, but, as is often the case with similar systems, the low entry threshold has a downside. So, if you are not puzzled by the development of your own layer between the API and the game logic in time, in a month you will have a heavy pile of hard to read code. Fortunately, this cup passed us, unlike our colleagues, on the bitter experience of which this statement of ours is based.
The performance problem in the Corona SDK is solved simply: by cutting off the segment of budget phones 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 fast nor slow - no way.
Is it worth it to deliberately exclude potential players in exchange for simple development and cross-platform - an open question and, in general, it remains outside the scope of this specific article. This is already a choice for us and in the very near future we will find out whether it was true or false.
5. Instead of a conclusion
The version of the game released by us is free, with built-in advertising. By Christmas, we are switching to the Freemium model - advertising will be disabled in the paid version, and new and tasty chips will be added to it.
Also, we include in-game currency in the new version, with the possibility for players to further simplify their lives by purchasing bonuses.
And yet - a new game mode.
Download Voltage here:
Voltage Android
Voltage iOS
Voltage Gameplay Video
PS While this article was being written, Voltage accumulated small statistics, 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 Sino-Korean markets) - 12k. Every day, the game is uploaded by about 100-200 users more than on the previous day.
iOS: about 2500 downloads, the growth rate of which is the same as on Android.
PPS In a recent competition, ITJump Voltage ranked second in the gaming category.