Unity3D game development

After we have finished creating the game in Unity and releasing it on Google Play and AppStore, there was a desire to share experiences and impressions and to receive constructive comments and suggestions

Teamwork

So, the project was done in Unity 4.5 Free efforts of 5 people in free from work and household chores. For teamwork we used the Bitbucket service — there is just up to 5 people can be added to the project for free. The version control system - Git. We understand Unity PRO has its own version control system, but we decided not to buy the PRO and not hack it.

The first problem we faced was quite difficult merging changes made by multiple developers. The Unity project files (scenes, prefabs and so on) have their own peculiar formats, and do not merge as text files. In the end, we just divide up the responsibility: more than one person simultaneously is not ruled by one scene or one prefab. This is easy to achieve if the right to distribute the tasks. With the script files in C#, of course, we have no problems, they ruled at the same time.

Efficiency

We decided to develop project in 2D. The final image was formed from 3 layers: the substrate, the shadow from the element and the element

image

Then testing the game on the devices, we found that we have very low FPS about 20, and an big battery consumption. The problem was in the display of semi-transparent layers of shadow. There are not so many elements on the level, but in Unity it completely kills the performance.

We started the optimization, have reduced the sizes of texture elements, gathered textures in atlases. FPS has become higher, but the battery still discharged very quickly. Then we made the mechanism of decrease FPS in those moments when the user does not move the elements, and there is no animation.

It looks approximately so: there is a dictionary, where the keys are the different animations and user actions. Each key is assigned an integer counter. Animation or action increments the counter when it is completeddecrements. When all keys counters==0, we made lower FPS:

Application.targetFrameRate = Constants.CountFPS_Min; // == 10, in our case

As soon as something happens, we similarly remove the limitation. After this simple trick, we forgot about the problems with the battery.

In-app purchases. Testing.

For the organization of purchases, we used the Soomla plugin version 1.5.3. Very good decision in that moment with intuitive codes and support for AppStore and GooglePlay.

Once we have added a new product — opening of 6 chapters. We setup on test phones, checked - everything works. Flooded on Google Play. And got a lot of angry reviews! Why? — because, as it turns out, when you first install our game, all purchases work as they should. But when you update the game, Soomla did not recognized a new product, and users faced an interesting bug with 6 chapter. Perhaps the fact that Soomla caches on your phone shopping list and when you update does not find new...

It turns out that any modification to the shopping list you need to modify (increment) the version of this list in simple Soomla function

int GetVersion() {return 1;} // we had 0 unfortunately

We solved this problem in the next update. But the global conclusion is clear: when you update the game be sure to test how the game behaves when you "clean install", and how the update runs correctly. It would be nice to test it on multiple devices.

Agree, not good if you spend development time and money for advertising, and half of the users will not be able to use basic functions (e.g. a purchase) in the new app.

The problem with testing we decided:

1) the document was created, describing a methodology for validating of new app. This document lists all the OS versions and devices on which to test (from our arsenal of course), all the functionality to test (sounds, animations, scene changing, work with social networks, game settings, promocodes, AboutUs with updated versions and more)

2) before creating a release in Unity, you should verify the ID-keys for the correct operation of the Soomla plugin and other plugins (such as GoogleAnalytics, Google Games)

3) after installing the app to the target platform test purchases were required. For tests of purchases that can be made only once with one account, we used fake accounts for testing.

4) of course we fully use for the testing instruments, provided Apple or Google

5) pay attention to user complaints. We understand that there are no trifles.

***

A separate topic can be, as we worked with fonts and GUI in Unity. It was not a very easy job. But, fortunately, in Unity 5.0 all significantly improved.

 

Contact us

Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Skype: south-media.com
Phone: +7 903 4057009, +7 928 1260550
Top
Локальный сервер Денвер.
Установка Joomla на локальный сервер.