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

good!


Got around to writing the article, I'd like to tell you about another month of life indusny Studio.



Early publications can be found here:

Part 1
Part 2

It was a very hard and productive month, a month getting your buds and adjustments to the original plan.

This month we have brought the level of the game on a playable level. There were tested more than a hundred builds. And here's the brutal truth that we know: not all in the physical devices is the same as in the development environment.

This has involved major problems. To offset them, we derived some basic rules (many of them covered more than once, but maybe for someone they will be the news):

1) Commit to the repository is done after each plus or minus significant changes;
2) Testing on real devices is carried out at least three times a day, so that you can safely rollback the changes.
3) the Development is small iterations and continues only after the full test a small piece;
4) Optimization – our all;
5) Build to external testers is not filled before interior full test and clean of the "hard bugs";
6) Global update in any case should not go before the holidays and weekend.
7) the more external testers the better;

Let's go point by point:

the

Commits


I think, for anybody not news that without version control develop is absolutely contraindicated. If the development is more than one person is dangerous. After each change, which affects the mechanics or the algorithm of the game it is necessary to make collaboration between developers. I think everyone who led the development in such circumstances, faced with a situation, when all at once filled changes, something has stopped working, and the reason is unclear. Even worse – if it is clear that the reason for the unhealthy version were the fruit of an entire working day of a developer and need to roll back all the changes back. Less offensive if the reason was the conflict of work and just need a few alterations. Ideally, if everyone can see the changes in real time and know in which case the maximum setback will be 10-15 minutes.

the

Physical device


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

Some items will need to calibrate "by eye", some to optimize and even do a downgrade (this is also no reason to be afraid).

the

One task


Tasks associated with adding new functionality or content should be as short as possible. For example:

Make a level with new mechanics and elements. Collected passage, for example, for a minute. Next is to test the playability, performance, visualization, etc. has to be Tested in the development environment and the devices. Just need to spend hotfix in a small area and only after that to finalize everything on, adjusted everything and securing the basic rules.

If you have enough persistence in the same breath for half a day to construct something, and then you see that everything is OK (at best), but is bad only a small detail, you have great chances to redo because of minor flaws is very large and quite efficient piece of level.

This can be attributed to everything: interface, tutorial, stores, scripts, balance, physics, etc.
Don't be lazy, it will save you a lot of time and effort.

the

Optimization


I think to explain why it needs to be done. I want to say that to optimize everything at once is also wrong. In this case, it is the 20/80 rule where 20% of efforts bring 80% of the benefit. Approach the issue wisely.
the

in-house testing and output


You can't send an untested build to external testers. People often test your product out of curiosity. Sometimes it happens that the build falls off a very important detail.

the

Case:


After the UI fix, we didn't replace the script on the button to start the level.

Standard series of poor choices (excuse): it was late, many of which were amended and added, ahead of the weekend, and Friday night had an impact on care. In General, as it always happens – someone did not finish, someone checked, we have what we have.

Fact: no One could see innovation as the build was unplayable, start passage impossible.

Our audience signed up for the closed alpha, downloaded the update and saw the non-working version. It would seem that people who test alpha must be ready and wait for the fixes. Perhaps it was, but we were able to release only on Monday evening and all weekend and Monday the market was just curve version. During this time, the game has removed 20% of the audience and not waiting for the updates.

In the case where you have an audience of 100 people, you're just upset and trying to compensate for the loss and it is more than real. If you are already in open access, these figures may be in the thousands and return such a number of testers back will be difficult.

the

Audience


For Analytics, while we use only a Firebase and a feedback from the testers. This allowed us to optimize the game for older graphics chips and to reduce the lag to a minimum, compared to the first versions. The more devices – the full picture. Sometimes we communicate directly with the person and optimized the game it was under his device. The output is so that together with this device was a significant increase and on the other to this problematic devices.

Also it was very useful feedbacks in General. We learned that it was like the audience in the game, what's not to like (this is the most valuable feedback). Because we make the product not for themselves but for the wider audience and I want my game like and fun that she wanted to tell friends and acquaintances. Working closely with the community in the early stages of development – the most valuable resource that can be and will make your game something really worthwhile and the more your audience the easier it will be to do.

the

PS


Now we have a playable build where we have tried to convey the essence, basic mechanics and atmosphere of the game.

Now we solve the already known problems, optimized chamber physics and performance, reconcile the balance for leveling. Also actively working on level design to enhance gameplay and make it more dynamic.

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

Soon the game will be endless levels, new campaign levels and more content for leveling.

Thank you all! To be continued.
Article based on information from habrahabr.ru

Комментарии

Популярные сообщения из этого блога

When the basin is small, or it's time to choose VPS server

Performance comparison of hierarchical models, Django and PostgreSQL

From Tomsk to Silicon Valley and Back