How to start young mobile game developers from Russia [Part 3]

All good!

We got our hands on writing an article in which I would like to tell you about another month of the life of the turkey studio.



Early publications can be read here:
')
→ Part 1
→ Part 2

It was a very tough and productive month, a month of stuffing cones and adjustments to the original plan.

For this month we have brought the level of the game to the playable level. In total, more than one hundred builds were tested. And here is the most cruel truth that we managed to find out: far from everything on physical devices works as in the development environment.

There were major problems with this. In order to level them, we derived several basic rules (many of them were covered more than once, but maybe for some they will become news):

1) A commit in the repository is done after each plus or minus significant change;
2) Testing on “live” devices is carried out at least three times a day, so that if anything happens, you can safely roll back the changes;
3) Development is carried out in small iterations and continues only after a full test of a small piece;
4) Optimization is our everything;
5) The build for external testers is not filled before the internal full test is performed and the “hard bugs” are not removed;
6) The global update should never be released before holidays and weekends.
7) The more external testers - the better;

Let's go point by point:

Commits

I think it’s not news for anyone that it’s categorically contraindicated to lead development without a version control. If the development is conducted by more than one person - it is deadly. After each change that affects the mechanics or algorithm of the game, it is necessary to make a collaboration between all the developers. I think everyone who has developed in such conditions has come across a situation where everyone poured changes at once, something stopped working, and the reason is unclear. Even worse - if it is clear that the reason for the non-working version was the fruits of the whole working day of the developer and you need to roll back all changes back. It is less annoying if the cause was a work conflict and you just need to redo it a bit. Ideally, if everyone sees changes in real time and knows that in case of anything, the maximum rollback will be 10-15 minutes.

Physical devices

What we see in the development environment is far from what we see on devices. If with the PC version all have plus or minus the same, then with mobile devices everything is different.

Some items will need to be calibrated "by eye", some optimized, and even downgrade (you don’t need to be afraid of this either).

Short tasks

Tasks that are associated with the addition of new functionality or content should be as short as possible. For example:

Making a level with new mechanics and elements. Collected the passage, for example, for a minute. Next, a test is performed on playability, performance, visualization, etc. You need to test both in the development environment and on devices. Immediately you need to carry out hardfix on a small area and only after that refine further and further by checking out everything and fixing the basic rules.

If you had enough perseverance in one breath for half a day to construct something, and then you saw that everything is OK (at best), but only a small part does not work well, you have great chances to rework because of a minor flaw very large and workable level piece.

This can be attributed to everything: the interface, tutorial, shops, scripts, balance, physics, etc.
Do not be lazy, it will save you a lot of time and effort.

Optimization

I think that there is no need to explain why. From myself I want to say that optimizing everything at once is also wrong. In this case, the rule of 20/80 works, when 20% of the efforts bring 80% of the benefits. Approach the issue wisely.

Internal Testing and Weekend

You can not send an unchecked build to external testers. These people often test your product out of curiosity. Sometimes it happens that a very important trifle falls off in a build.

Case from life:

After fixing the UI, we did not replace the script on the level trigger button.

The standard series of wrong actions (excuse): The time was later, a lot of things were corrected and added, the weekend was ahead, and Friday evening affected attentiveness. In general, as it always happens - someone did not finish, someone did not check, we have what we have.

Fact: No one could see the innovations since the build was not playable, it is impossible to launch the passage.

Our audience, subscribing to the closed alpha, downloaded the update and saw the non-working version. It would seem that people who test alpha should be ready for this and wait for the fixes. Maybe it was, but we could only release it on Monday evening and all weekend and Monday there was a curved version in the market. During this time, the game has removed 20% of the audience without waiting for the update.

In the case when you have an audience of 100 people, you just get upset and try to make up for the loss and this is more than real. If you are already in open access, then these numbers can amount to thousands and it will be difficult to get back so many testers.

Lecture hall

To collect analytics, for the time being, we use only Firebase and feedback from testers. This allowed us to optimize the game under the old graphics chips and reduce lags to a minimum, compared with the first versions. The more devices - the fuller the picture. Sometimes we contacted directly with the person and optimized the game precisely for his device. At the exit, it turned out that, together with this device, there was a tangible increase on other problem devices as well.

Feedbacks in general also proved to be very useful for us. We learned what exactly the audience likes in the game, what does not like (this is the most valuable reviews). After all, we make the product not for ourselves, but for a wide audience and we really want our game to be liked and bring pleasure, so that we would like to tell our friends and friends about it. Dense work with the community in the early stages of development is the most valuable resource that you can have and will allow you to make something really worthwhile out of your game and the bigger your audience is, the easier it will be to do.

PS

Now we have a playable build in which we tried to convey the essence, main mechanics and atmosphere of the game.

Now we are solving the problems we already know, we are optimizing the camera, physics and performance, we verify the balance for leveling up the character. We are also actively working on level design to diversify the gameplay and make it more dynamic.

In the study of the full tutorial, at the moment it is limited to only the main points related to the gameplay.

In the near future, the game will have endless levels, new campaign levels and more content for leveling.

Thanks to all! To be continued.