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. the first ship

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

Cons were no less weighty:

• 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

In other words, for a full game it is necessary to implement natively all heavy and platform-dependent (like Game Center, or In-App Purchases) parts of the code. Then one should pull them through Javascript bindings and use in the main Javascript code. It is not fast and not a very pleasant process. the first prototype Hitting this rake, the position has been reconsidered. It was decided to do only a version for iOS on cocos2d-iphone so far. Despite the name, the engine works well both as on the iPhone and other Apple devices running iOS. We started to implement physics using Chipmunk 2D. Some might ask - why not Box2D? The answer is simple, at the time of the first prototype, Javascript bindings in cocos2d have been implemented only for Chipmunk. In the transition to native cocos2d-iphone, we decided to leave it as it is, and never regretted the decision.

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

After collective brainstorming the following elements were planned:

• 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

While approving the new features it was decided to expand the team to 4 people.

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

level mask textures of terrain, crust, crust pattern and texture mix tile map of the sky rendered level as a result Rendering algorithm of the level consists of two parts - loading the layers of the sky and creating a parallax; loading land textures and initializing a shader that mixes these textures.

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. physics debug layer is rendered

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] example of his work [/spoiler] After a week of wasted time the freelancer was fired and we were looking for a designer to join the team on a permanent basis. Search of an art designer is easier for those who understand something in artwork. We do not. We were deciding by the portfolios. If we liked it, we invited the person for a meeting. That way we stumbled upon a unique "creator". His portfolio was amazing, a great number of beautiful high-quality graphics in a variety of styles, hand sketches, 3D models. Invited him over, chatted for a bit. He seemed to be an adequate person. In the evening a colleague sends everyone a link to one of the pictures of the candidate. It wasn't his drawing, as with 80% of the rest of the portfolio. Moral - people lie, and Google Images is good for finding pictures. In the end we managed to find an artist who coped quite successfully with the assigned objectives and became an indispensable part of our team. anti-aircraft gun and a black hole explosion of a bomb

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

Scheduled:

• multiplayer
• more types of weapons
• planets and more levels
• port to mobile platforms, Ouya, PC and MAC

What could have been done better

Firstly - do not fantasize about the timing of development. Initial expectations were to spend a couple of months. Secondly, find an art designer for the team and begin his part together with the development. It would have saved a lot of time. And no freelancers. And thirdly - we should have shown the game to everyone whom it might interest, from the first prototype to the current state. That could have collected a certain base of people who already "know" and "talk" about Demolition Lander by the time the project was launched on Kickstarter.

Campaign on Kickstarter

Campaign on Kickstarter deserves a separate article, which, if I get a chance I will definitely write. In short, the fundamental success factors for financing are: a fan base, brand creator and / or product awareness. We have now launched a second campaign to raise funds for Demolition Lander. First had to be canceled due to a failure of PR strategy. What will happen to the second - is not clear, but the worrying is building up.