Introduction
Hello, my name is Andrey Vlasenko. I live in Kharkiv, Ukraine. I am a software developer and work as a CIO in ApexTech company. I want to tell you about the creation of our game "Demolition Lander". To start with watch a small trailer that will give you an idea of how the result looks (shots of the game begin with the 50th second). [media][/media]
Birth of the idea
There is nothing worse than an idea stuck in your head. At first it's just looming at the back of your mind, then after an incubation period it makes you act. And so having worked in Enterprise software for about 7 years I have firmly decided that I want to try game development and create a game. A lot of time has passed since this decision was made and one day all of a sudden the idea has gained a concrete shape. Over lunch, my friend Sasha (CEO of ApexTech) and I discussed what kinds of games there used to be and what each of us liked to play. Both remembered 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 happened that these engines were not symmetrical and aligned in different directions. We both smiled. That's it! Mechanics of Lunar Lander where ships are equipped with two engines, which in turn are controlled by separate joysticks. "It will be a hit!" In the future, the concept was extended by destructible levels and elements of action, but later about this.![2a6a55f195b58b5ee1a461ce585ba156.jpg](http://habrastorage.org/getpro/habr/post_images/2a6/a55/f19/2a6a55f195b58b5ee1a461ce585ba156.jpg)
The first prototype. Multiplatform support. Selection of game engine. First mistakes
I should start with the fact that the company decided to give a green light to this project, but only I was assigned to do it. We had planned the game for mobile devices, so naturally I thought about the multiplatform realization from the start. There were two variants of the game engine: cocos2d variations and Unity. After long discussions Unity was discarded due to the fact that this engine is good for 3D, and not so good for working with 2D. In addition to this I had some experience with cocos2d, and the choice was made in its favour. The first prototype was built on the cocos2d Javascript. The advantages of this technology are:- code in Javascript
- the same code runs on virtually all platforms, including web browsers with support of HTML5
- no matter how the developers of the engine may assure you - it runs slow compared to native implementations
- the implementation of a platform-dependent functional is pretty messy and curved
![2712953f1d74150c8528e6081746d161.jpg](http://habrastorage.org/getpro/habr/post_images/271/295/3f1/2712953f1d74150c8528e6081746d161.jpg)
Gameplay. Is there one?
A few weeks of development passed. Prototype was ready. Game mechanics were ready. Everything is flying, engines are spinning, levels are large. It seemed that just a bit more and it can be put in the App Store. But playing this game was boring. And that means one thing - gameplay is missing. Here are the elements of the game mechanics that have been implemented at the time:- big level with a bunch of flat ground stations on which it is necessary to land for refuelling
- ship equipped with two engines, which can be operated synchronously by one joystick, and separately by two joysticks
- the purpose of the game - finish the level without breaking the ship
- tuning the ship in all specifications
- spheres with energy, which helps you to buy upgrades and fly to new distant planets
- boxes for ship repair
- underground caves
- fuel cans for caves
- destructible surface of the level
- weapons for ships - bombs
- danger zones - a zone which damages a ship over some time period
- active and passive traps - mines and anti-aircraft guns
- unique to each level artifacts hidden away deep in the caves
- the aim of the game remains the same
Dimensions of a level
I always felt excited playing games which offered a large space to move about without any restrictions or additional loading lags and I was keen to implement a similar experience in Demolition Lander. Levels in the game are huge. If you draw the entire level, you get an image of 65,536 by 16,384 in size. And this is not the limit - you can enlarge them to 65,536 by 65,536 without any loss of performance, yet I have imagined the playing process as horizontal flight above ground with periodic exploration of underground caves. Levels of the game consists of the following elements:- level mask - greyscale relief texture 2048 by 512 (which scales by 32 when overlayed)
- texture of soil, crust, crust pattern and the texture for mixing all textures together imposed on a stretched mask
- tile map with textures of the sky and stars
![06a184746091db1a398776d73a964714.jpg](http://habrastorage.org/getpro/habr/post_images/06a/184/746/06a184746091db1a398776d73a964714.jpg)
![5d20ebd926ca590487bd821f956309a0.jpg](http://habrastorage.org/getpro/habr/post_images/5d2/0eb/d92/5d20ebd926ca590487bd821f956309a0.jpg)
![ba337a0f35ef929d438e2bf805f76131.jpg](http://habrastorage.org/getpro/habr/post_images/ba3/37a/0f3/ba337a0f35ef929d438e2bf805f76131.jpg)
![c71429225e09c7aba0cfff403cd94169.jpg](http://habrastorage.org/getpro/habr/post_images/c71/429/225/c71429225e09c7aba0cfff403cd94169.jpg)
Creating the destructible land surface
One of the most spectacular features of the game demanded a very responsible approach to implementation. Destruction of the surface must be fast, synchronized with the boundaries of the physical body of the level and graphical display. To create and update the physical boundaries of the land we used a feature of Chipmunk 2D Pro, which scans the terrain texture mask of the level and creates a set of tiles with the boundary lines. In the future, when traveling on the ship through the level the surrounding tiles with lines are reprocessed, and the old ones are unloaded from memory. Deformation itself is done as a change in texture of the mask in the corresponding places and reprocessing of tiles with physical boundaries. Graphically it is displayed instantly when drawing the next frame - it is a result of physics engine and terrain shader using the same mask.![154c9ba276914fb39da1102155492c4f.jpg](http://habrastorage.org/getpro/habr/post_images/154/c9b/a27/154c9ba276914fb39da1102155492c4f.jpg)
Is the game ready? - No
When you have a fully working game with exciting game mechanics, it seems that App Store is close as ever. But the levels with names like Test1, Test2 and one rectangular ship without any sane design suggests otherwise. It's time for design and content. We engaged in creating the content ourselves. Types of ships, their names, characteristics, names of the planets, the number of in-game money at every level - this all was decided at the following brainstorming sessions. For the art design we decided to hire a freelancer. And not just a freelancer, a citizen of India with an outstanding portfolio, excellent English and what seemed to be common sense. People are surprisingly deceptive. Starting with the fact that he just did not get in touch periodically, ending with disgusting quality drawings and misunderstanding of the basic things that we wanted him to do. At the same time model of behavior of the person was surprisingly consistent - "OK, sir. No problem. It will be done". [spoiler]![1a6041c85be2ef0a4c6bfb1fb1362650.jpg](http://habrastorage.org/getpro/habr/post_images/1a6/041/c85/1a6041c85be2ef0a4c6bfb1fb1362650.jpg)
![6c72902ca12329adb5cb9e4a734b8e7b.jpg](http://habrastorage.org/getpro/habr/post_images/6c7/290/2ca/6c72902ca12329adb5cb9e4a734b8e7b.jpg)
![d3f677125856cd7d8381b40c5af20cfd.jpg](http://habrastorage.org/getpro/habr/post_images/d3f/677/125/d3f677125856cd7d8381b40c5af20cfd.jpg)
Optimization and memory leaks
Another couple of months have passed. Design and content were ready. On actual levels the game was performing too slow and crashing periodically after a certain time. We began to search for memory leaks and ways to optimize performance. Of memory leaks the blocks and their common use with the ARC were the weakest spot. In second place - wrong construction of the object graph, namely strong references to objects that contain each other (even through multiple nested objects). The optimization of performance came down to one principle - to draw and process only objects in sight of the ship and within the reach of bombs.Summary. Readiness - 90%
Half a year of development. Almost finished game. End of capability for its funding. Remaining:- art on some planets / levels
- refinement of sound and music
- optimization for older Apple devices
- testing and once again testing
- multiplayer
- more types of weapons
- planets and more levels
- port to mobile platforms, Ouya, PC and MAC
just want it known that I added the link to the Kickstarter campaign