The total user audience of the company has over 60,000,000 players in 165 countries. Our projects are launched on platforms such as Facebook, IOS, Android, Amazon and Steam. We specialize in spectacular action, addictive gameplay, stunning graphics and a unique gaming experience. Our hallmark is physically accurate animations that allow players to maximize their immersion in the gameplay.

As a rule, the development of IT projects begins with the definition of a range of problems that the product must solve. After that, a specification and a technical building are written on it. That is, what is to be done within the framework of the project can be formalized with a good degree of accuracy. This works even in the case of agile development, with the allowance for the fact that formalization takes place for shorter periods, and usually this is due to the fact that the customer has a poor idea of ​​what he needs.

In games, the situation is radically different. The reason lies in the fact that the game should bring the concept of Fun, which is difficult to formalize. Moreover, it should bring this Fun to a huge (the more, the better) number of people. Compare the wording “Through our application, the user should be able to book a hotel room” and “Through our application, the user should have fun”.

In this, games are akin to cinematography or even theater – before release or on stage (in fact, launch), one cannot be exactly sure what kind of reaction the audience (players) will have. On the other hand, games are a multi-billion dollar business growing every year. In good business, predictability in terms of both results and timing is one of the main components.

The classic production cycle up to the launch of a game project looks like this: Idea Generation, Pre-production, Production, Finaling. These stages differ in team composition, artifacts, and even management approach. If agile development is quite appropriate at the Pre-production stage, then at the Production stage it is better to use classical methodologies.

The main principle is early prototyping. Anything that raises questions should be implemented as early as possible. This significantly reduces the cost of the error. At the same time, the concept of “early prototyping” should be considered rather broadly. For example, let’s make a game like Diablo. There is a risk in the game – to get an uninteresting combat game. In order to appreciate this very interesting, you need to invest a lot in production – you need the character to be ready, so that the enemies are ready (preferably several different ones), so that the feedback is configured – visual and sound effects, so that the HUD is made, so that a system of rewards was made. Moreover, all this should be done at a quality level close to the final one, otherwise the complex cannot be evaluated. Therefore, “early prototyping” is both alpha-beta versions and soft launch.

There may be a hierarchy inside the programming department – architects, leading developers, but this is all within the framework of the structure indicated above. At the same time, the majority of the team are programmers. In game projects, the situation is fundamentally different. Despite the fact that games grew out of purely programming teams (or rather, even from the hobby of single programmers), now, in order to make a game, it is necessary to involve a very diverse range of specialists. Moreover, for different games they will be different specialists.