Game development. The path from the idea on the napkin to the Kickstarter campaign
Hello. My name is Andrey Vlasenko. I live in the city of Kharkov, Ukraine. By profession I am a software developer. I work as a CIO at ApexTech. I want to tell you about the creation of our game "Demolition Lander".
First, look at the small trailer, which will give an idea of ​​what happened in the end (shots from the game start from the 50th second).
')
There is nothing worse than the idea of ​​sitting in your head. At first, she just looms in the back of her mind, then after the incubation period she makes you act. And so, having worked in Enterprise for about 7 years, I firmly decided that I wanted to try my hand at game building and create a game.
A lot of time passed from the moment of this decision, and somehow, quite unexpectedly, one day the idea took on concrete shape.
At dinner, my friend Sasha (CEO at ApexTech) and I discussed what games we used to play and what each of us loved to play. Both recalled the classic game from Atari - Lunar Lander. During the discussion, I began to draw a ship with two engines on a napkin and it just so happened that these same engines were not symmetrical and looked in different directions. There was a faint smile on our faces. - Here it is! The mechanics of Lunar Lander with ships equipped with two engines, which in turn are controlled by separate joysticks. "It will be a hit!"
In the future, the concept is overgrown with destructible levels and elements of action, but more on that later.
the very first ship
It’s worth starting with the fact that the company decided to give this project the green light, but only me was selected from the people.
We planned to make the game for mobile devices, so naturally I thought about the original multiplatform. The game engine was chosen from variations of cocos2d and Unity. Unity, after long discussions, we discarded due to the fact that this engine is good for 3D, and for working with 2D it is crooked. Plus, I had a little experience with cocos2d, and the choice was made in his favor.
The first prototype was based on cocos2d Javascript. The advantages of this technology are as follows:
The disadvantages were no less significant:
In other words, for a full-fledged game, you need to natively implement all the heavy and platform-dependent (same Game Center, or In-App Purchases) parts of the code. Pull them through Javascript bindings and use in common Javascript code. The process is not fast and not pleasant.
first prototype
Having hit this rake, the position has been revised. We decided to do a version for iOS only on cocos2d-iphone. Despite the name, the engine works fine on both the iPhone and other Apple devices running iOS.
Physics began to implement using Chipmunk 2D. Some may ask - why not Box2D? The answer is simple, at the time of creating the first prototype, the Javascript bindings in cocos2d were implemented only for Chipmunk. When switching to native cocos2d-iphone, they decided to leave it as it is, which they did not regret.
There have been several weeks of development. The prototype is ready. Game mechanics ready. Everything flies, the engines are spinning, the levels are large. It already seems that a little more and you can lay out in the App Store. But playing this game is boring. And this means one thing - there is no Gameplay in the game.
Here are the elements of game mechanics that were implemented at the time:
After the collective brainstorming, the following elements were planned:
Approving the new functionality, it was decided to expand the team to 4 people.
I was always captured by games in which you had a large space to move without any restrictions or loadings, and I tried to implement this in Demolition Lander. The levels in the game turned out huge. If you draw the whole level, you will get an image of the size of 65 536 by 16 384. And this is not the limit - you can increase them to 65 536 by 65 536 without any special loss of performance, but I still saw the game process as a horizontal flight above the ground with periodic research underground caves.
The level in the game consists of the following elements:
level mask
texture of soil, edge, edge pattern and blending of all textures
sky tile map
as a result level is drawn
The level drawing algorithm consists of two parts - loading the layers of the sky and creating a parallax from them; loading ground textures and initializing a shader that imposes these textures on each other.
One of the most spectacular features of the game required a very responsible approach to implementation. The destruction of the surface should occur quickly, synchronized with the boundaries of the physical body level and graphic display.
To create and update the physical boundaries of the earth, we used the Chipmunk 2D Pro functional, which scans the texture of the mask of the level relief and creates a set of tiles with boundary lines. Later, when the ship moves along the level, nearby tiles with lines are recalculated, and old ones are unloaded from memory.
The deformation itself is executed as a change in the mask texture in the right places and recalculating tiles with physical boundaries. Graphically, the deformation is displayed instantly when the next frame is drawn - this is the result of the fact that both the physics engine and the earth shader use the same mask.
physics debug layer is enabled
Having a fully working game with fascinating game mechanics, it seems that the App Store is as close as ever. But the levels with the names Test1, Test2 and one rectangular ship without any sane design say something else. It's time for design and content.
Creating content themselves. The types of ships, their names, characteristics, the names of the planets, the amount of in-game money at each level - everything was decided during the next brainstorming session.
But with the design decided to hire a freelancer. And not just a freelancer, but a citizen of India with an outstanding portfolio, excellent English and seemingly common sense. People are unexpectedly deceptive. Starting with the fact that a person periodically just did not get in touch, ending with the disgusting quality of drawings and we did not understand the elementary things that we wanted to achieve from him. At the same time, the model of a person's behavior surprised with constancy - “OK, sir. No problem. It will be done. ”
After a deadly week, freelancers parted ways to search for a designer on a permanent basis.
Looking for a designer is easier for someone who himself understands something in design. We were not. Judged by the sent portfolio. Liked - invited, looked at the person. So stumbled upon one unique "creator". His portfolio was amazing, a large number of beautiful high-quality drawings in different styles, freehand sketches, 3D models. Invited, talked, seemingly adequate person. In the evening, a colleague sends everyone a link to one of the candidate’s drawings. The drawing is not his. Like 80% of the rest of the portfolio. The moral is that people are lying, and Google Images is good at looking.
As a result, they still found a designer who quite successfully coped with the assigned tasks and became an indispensable part of our team.
anti-aircraft installation and black hole
Detonation of bomb
It took another couple of months. Design and content are ready. At real levels, the game began to slow down and periodically fly out with prolonged use. Began to search for memory leaks and optimize performance.
Of the memory leaks, the most painful places were blocks and their use in conjunction with ARC. In the second place is the incorrect construction of the object graph, namely, strong references to objects that contain each other (even through several nested objects).
Performance optimization has come down to the same principle - to draw and cheat only objects in the field of view of the ship and the reach of bombs.
Half year development. Almost finished game. The end of the possibility of own financing.
From the rest:
From the planned:
The first is not to dream about the timing of development. Initial expectations were to invest in a couple of months.
Second, immediately look for the designer in the team and start part of it in parallel with the entire development. It would save a lot of time. And no freelancers.
And third, we should have shown the game to everyone it might be interested in, from the very first prototype to the current state. This would have gathered a certain base of people who “know” and “speak” about the Demolition Lander by the time the project was released on Kickstarter.
The Kickstarter campaign deserves a separate article, which if I get a chance I will definitely write.
In short, the fundamental factors for the success of funding are fan base, creator recognition and / or product recognition.
We have now launched the second fundraising campaign for Demolition Lander. The first had to be canceled due to a disastrous PR strategy.
What will happen to the second is not clear, but there is an alarming tendency.
First, look at the small trailer, which will give an idea of ​​what happened in the end (shots from the game start from the 50th second).
')
The birth of an idea
There is nothing worse than the idea of ​​sitting in your head. At first, she just looms in the back of her mind, then after the incubation period she makes you act. And so, having worked in Enterprise for about 7 years, I firmly decided that I wanted to try my hand at game building and create a game.
A lot of time passed from the moment of this decision, and somehow, quite unexpectedly, one day the idea took on concrete shape.
At dinner, my friend Sasha (CEO at ApexTech) and I discussed what games we used to play and what each of us loved to play. Both recalled the classic game from Atari - Lunar Lander. During the discussion, I began to draw a ship with two engines on a napkin and it just so happened that these same engines were not symmetrical and looked in different directions. There was a faint smile on our faces. - Here it is! The mechanics of Lunar Lander with ships equipped with two engines, which in turn are controlled by separate joysticks. "It will be a hit!"
In the future, the concept is overgrown with destructible levels and elements of action, but more on that later.
the very first ship
The first prototype. Multiplatform. The choice of engine. First misconceptions
It’s worth starting with the fact that the company decided to give this project the green light, but only me was selected from the people.
We planned to make the game for mobile devices, so naturally I thought about the original multiplatform. The game engine was chosen from variations of cocos2d and Unity. Unity, after long discussions, we discarded due to the fact that this engine is good for 3D, and for working with 2D it is crooked. Plus, I had a little experience with cocos2d, and the choice was made in his favor.
The first prototype was based on cocos2d Javascript. The advantages of this technology are as follows:
- javascript code
- the same code works on almost all platforms, including browsers with html5 support
The disadvantages were no less significant:
- as if the developers of the engine did not assure - it works slowly compared to the native variants
- implementation of platform-dependent functionality is quite confusing and the curve
In other words, for a full-fledged game, you need to natively implement all the heavy and platform-dependent (same Game Center, or In-App Purchases) parts of the code. Pull them through Javascript bindings and use in common Javascript code. The process is not fast and not pleasant.
first prototype
Having hit this rake, the position has been revised. We decided to do a version for iOS only on cocos2d-iphone. Despite the name, the engine works fine on both the iPhone and other Apple devices running iOS.
Physics began to implement using Chipmunk 2D. Some may ask - why not Box2D? The answer is simple, at the time of creating the first prototype, the Javascript bindings in cocos2d were implemented only for Chipmunk. When switching to native cocos2d-iphone, they decided to leave it as it is, which they did not regret.
Gameplay Is there any?
There have been several weeks of development. The prototype is ready. Game mechanics ready. Everything flies, the engines are spinning, the levels are large. It already seems that a little more and you can lay out in the App Store. But playing this game is boring. And this means one thing - there is no Gameplay in the game.
Here are the elements of game mechanics that were implemented at the time:
- a large level with a bunch of flat ground stations that need to be landed for refueling
- the ship is equipped with two engines that can be controlled, both synchronously with one joystick, and separately with two joysticks
- the goal of the game is to fly without crashing to the end of the level
After the collective brainstorming, the following elements were planned:
- pumping the ship in all respects
- spheres with energy for which you can buy upgrades and fly to new remote planets
- ship repair boxes
- underground caves
- fuel canisters for caves
- destructible level surface
- weapons from ships - bombs
- danger zones - zones in which the ship takes damage over time
- passive and active traps - mines and anti-aircraft installations
- artifacts unique to each level, hidden deep in caves
- the goal of the game remains old
Approving the new functionality, it was decided to expand the team to 4 people.
Level dimensions
I was always captured by games in which you had a large space to move without any restrictions or loadings, and I tried to implement this in Demolition Lander. The levels in the game turned out huge. If you draw the whole level, you will get an image of the size of 65 536 by 16 384. And this is not the limit - you can increase them to 65 536 by 65 536 without any special loss of performance, but I still saw the game process as a horizontal flight above the ground with periodic research underground caves.
The level in the game consists of the following elements:
- level mask - greyscale relief texture of size 2048 by 512 (which, when applied, increases 32 times)
- soil textures, edges, edge patterns and texture for blending all textures along with overlaying the stretched mask
- tile map with sky and stars textures
level mask
texture of soil, edge, edge pattern and blending of all textures
sky tile map
as a result level is drawn
The level drawing algorithm consists of two parts - loading the layers of the sky and creating a parallax from them; loading ground textures and initializing a shader that imposes these textures on each other.
Realization of the earth being destroyed
One of the most spectacular features of the game required a very responsible approach to implementation. The destruction of the surface should occur quickly, synchronized with the boundaries of the physical body level and graphic display.
To create and update the physical boundaries of the earth, we used the Chipmunk 2D Pro functional, which scans the texture of the mask of the level relief and creates a set of tiles with boundary lines. Later, when the ship moves along the level, nearby tiles with lines are recalculated, and old ones are unloaded from memory.
The deformation itself is executed as a change in the mask texture in the right places and recalculating tiles with physical boundaries. Graphically, the deformation is displayed instantly when the next frame is drawn - this is the result of the fact that both the physics engine and the earth shader use the same mask.
physics debug layer is enabled
Is the game ready? - Not
Having a fully working game with fascinating game mechanics, it seems that the App Store is as close as ever. But the levels with the names Test1, Test2 and one rectangular ship without any sane design say something else. It's time for design and content.
Creating content themselves. The types of ships, their names, characteristics, the names of the planets, the amount of in-game money at each level - everything was decided during the next brainstorming session.
But with the design decided to hire a freelancer. And not just a freelancer, but a citizen of India with an outstanding portfolio, excellent English and seemingly common sense. People are unexpectedly deceptive. Starting with the fact that a person periodically just did not get in touch, ending with the disgusting quality of drawings and we did not understand the elementary things that we wanted to achieve from him. At the same time, the model of a person's behavior surprised with constancy - “OK, sir. No problem. It will be done. ”
Work example
one of his "best" works
one of his "best" works
After a deadly week, freelancers parted ways to search for a designer on a permanent basis.
Looking for a designer is easier for someone who himself understands something in design. We were not. Judged by the sent portfolio. Liked - invited, looked at the person. So stumbled upon one unique "creator". His portfolio was amazing, a large number of beautiful high-quality drawings in different styles, freehand sketches, 3D models. Invited, talked, seemingly adequate person. In the evening, a colleague sends everyone a link to one of the candidate’s drawings. The drawing is not his. Like 80% of the rest of the portfolio. The moral is that people are lying, and Google Images is good at looking.
As a result, they still found a designer who quite successfully coped with the assigned tasks and became an indispensable part of our team.
anti-aircraft installation and black hole
Detonation of bomb
Memory Optimization and Leaks
It took another couple of months. Design and content are ready. At real levels, the game began to slow down and periodically fly out with prolonged use. Began to search for memory leaks and optimize performance.
Of the memory leaks, the most painful places were blocks and their use in conjunction with ARC. In the second place is the incorrect construction of the object graph, namely, strong references to objects that contain each other (even through several nested objects).
Performance optimization has come down to the same principle - to draw and cheat only objects in the field of view of the ship and the reach of bombs.
Total. Readiness - 90%
Half year development. Almost finished game. The end of the possibility of own financing.
From the rest:
- art on some planets / levels
- completion of sound and music
- optimization for older Apple devices
- testing and testing again
From the planned:
- multiplayer
- more weapon types
- more planets and levels
- port on mobile platforms, Ouya, PC and MAC
What could be done better
The first is not to dream about the timing of development. Initial expectations were to invest in a couple of months.
Second, immediately look for the designer in the team and start part of it in parallel with the entire development. It would save a lot of time. And no freelancers.
And third, we should have shown the game to everyone it might be interested in, from the very first prototype to the current state. This would have gathered a certain base of people who “know” and “speak” about the Demolition Lander by the time the project was released on Kickstarter.
Campaign on Kickstarter
The Kickstarter campaign deserves a separate article, which if I get a chance I will definitely write.
In short, the fundamental factors for the success of funding are fan base, creator recognition and / or product recognition.
We have now launched the second fundraising campaign for Demolition Lander. The first had to be canceled due to a disastrous PR strategy.
What will happen to the second is not clear, but there is an alarming tendency.
Source: https://habr.com/ru/post/214177/
All Articles