Cyto: our trial and error method

A year ago, we, the Ukrainian studio Room 8, began to make our first game called Cyto. No one in the team had practically any experience in game development and application development for iOS, but everyone had ambitions to do something really awesome. We had to learn everything literally on the move and sometimes we felt like elephants in a china shop :)

In this article, we would like to help fellow developers, if possible, to learn from our experience.
Before we begin the story, let us show you what we did:
')


We will share our collection of rakes through which our team paved the way for a year. So, who are interested in technical details of the development - read on.

When we started to develop Cyto, none of the team had any experience with iOS, and even more so in game dev. During the year we learned a lot. Unfortunately, we had to learn from our own mistakes. Eh, if at the beginning of our journey someone had told us at least half of what we had learned when creating the game ...

We sincerely hope that this article will be useful to developers of games on iOS and those who are only going to try their hand in this area.

Engine selection

This may sound like a common truth, but the choice of the engine should be approached very carefully. It is necessary to clearly understand the needs of the project and its future "chips", so as not to be in the middle of development without the ability to embody the original but late idea. As for our game, we did not particularly bother. Since the cross-platform issue did not arise at that time, we settled on cocos2d-iphone version 1.0 (there was no other then).

If the project started now, we would definitely immediately choose a cross-platform solution. By the way, a lot of things in the coconut had to be changed or completely redone. Also a lot of rakes arose due to some “ingenious” architectural solutions of cocos2d-developers. Free engine, what can I say ... At the same time, not every paid engine can boast of such a large community and so many examples.

It was much more difficult to choose a physics engine. We chose from 2 options: Chipmunk or Box2d. Complicated by the fact that we were going to use them outside the box, because we needed an imitation of a deforming elastic body, and both engines are designed to work only with rigid bodies and the connections between them. We looked at the examples and made several test cases for both, and in the end we chose Chipmunk. The main reason for this was a more flexible link setting (constraints & joints), and a wider choice of links themselves. The damped spring turned out to be especially useful - here they are used almost everywhere. Thanks to them, the whole game world turns out more lively and dynamic. By the way, for iOS developers there is a Pro version written in Objective-C. It is, in fact, just a wrapper over the C-shny code, but it is made really convenient and taking into account all the features of the engine.

Starting work on the game, we mastered the chipmunk on the move and tried to adjust it to our needs. Working with constraints in this engine is quite convenient and you can effortlessly get a sane soft body. But we needed something more. Our being should have had a soft deformable shell, which it stretches from the inside. Due to limitations in the physical engine (it is still not designed for the simulation of soft bodies) and our requirements for the final result, many problems arose. Often, solving one of them, we got a few more new ones. Having tried a bunch of options, we did something similar to what we wanted.

Cyto Shell

Cyto shell is our pride and the basis of the gameplay. Players can stretch it with their fingers and cling to other objects. We wanted to make shell management simple and fun, but this was not so easy to achieve.

Of course, I had to draw the shell with handles on OpenGL. Especially useful [here is this article = habrahabr.ru/post/110998 ] (Max, thank you!), The rendering of the shell was made entirely on the basis of the approach described in it. The plans were to hang more dynamically changing highlights on its surface, but this time was not enough. However, the result and so it turned out quite beautiful.



We approached the modeling of the shell in the forehead - we decided to create a set of interconnected springs of rectangular bodies surrounding one circular body (core). Like a caterpillar in a tank or tractor.

But there was a problem with physics. When stretching the shell, the bodies would move away from each other so far that they could not keep the core inside. As a result, we created a complex model in which the outer segments were added upon stretching and removed when the shell returned to its original state.



So we were able to achieve a uniform density of the external bodies and avoid falling out of the core from the shell. Nearly. The fact is that connections in Chipmunk, as in most other engines, have one problem - no matter how you limit their length, the moment will come when they stretch so much that a model like ours will break. When interacting with the character, too often the central ball with the character's sprite attached to it fell out of the shell. Cyto "undressed" and it looked very funny, but then we had no time for fun. The model chosen by us was not justified. In addition to technical problems, the appearance and behavior of the shell also left much to be desired. The shell was more like a bag than an elastic jelly mass. It was necessary to urgently do something, and we began to look for other options for implementation.

The obvious solution was to simplify the physical model. In the new version, the shell consists of two components:
1. A nucleus with a shell of round bodies fixedly attached to it. Nothing is added or removed.
2. Skeleton of several round bodies of larger diameter, connected by springs. The core with the shell is fixed to one of the ends of the skeleton or can move along it.



With this approach, we were able to convey the softness of the shell, when the character hits some object, and, at the same time, preserve its integrity and elasticity when stretching. Against the background of the result, all the problems that arose with the new model did not look so scary.

The only difficulty that has arisen with the new model, which has brought us a lot of trouble, is connected with the drawing, or rather with the fact that we had to work with two polygons and subsequently merge them into one. But with this in the end coped.

And finally, the interesting conclusions of Part 1 , to which we came during the development:

• No need to become a hostage to technology and put yourself in the framework dictated by the architecture - you can always find another way. Moreover, do not use technology for the sake of technology. You will spend a lot of time realizing some kind of “cool” chip that no one really appreciates and may not even notice.
• Choose the right platform for your game. Or vice versa, choose the right genre of the game if you want to do something for a specific platform. Max Payne and GTA on the iPod is, of course, cool, but casual players, the majority of users of mobile devices, need not this at all.
• Use the strengths of the platform under which you write - touch screens are good for direct interaction with objects in the game, for tactile sensations.
• Do not complicate and do not dwell on one thing for too long. You can overdo it and spoil what was good. Or you can get stuck on unnecessary trifles and stop moving forward. There must be a limit to perfection, and the best is the enemy of the good.

On it we will finish yet. Rate the result of our work here on this link - [ click ]
The first 50 havers, who wrote in a personal, we will provide a promotional code. Gameplay can also be viewed in a game trailer.

We will continue our story in the next article - we can tell a lot more interesting things, for example:

• How to cut the weight of the project 5 times a month before the release;
• How to adapt the project for the iPhone, if it was developed only for the iPad;
• The nuances of creating levels and much more;