Launching and managing a project to create a game in Ukraine – iTizzi, Kyiv, Odesa, Ukraine


For some people, this is an integral part of life, but only a few know what the day of computer game developers looks like. We would like to introduce this process to the readers of the iTizzi blog with examples that point to certain techniques used during the production of gaming software. We invite you to read.

What is the working day for a game developer? Of course, from time to time, as part of his work, he will test his own project, but first of all, he must first create it, so: modeling 3D models, programming the behavior of objects, adding interaction capabilities in the game, checking if everything is working correctly … And that’s just the tip of the iceberg. Either way, there is too much work to do in one day. The average day for a game software developer comes down to creating one small element of the game – for example, creating a model of a firearm used by a hero, or programming the possibility of using such a toy in a game.

The question remains: what happens to a given game item after it is created?

If the added element works for us, it does not mean that it will work for the players automatically. In the case of teamwork, our results must be shared with other people. In theory, this seems clear and logical, but in reality it is not so trivial.

Why share your part of the work with other employees working on it?

In the end, after all, you can work on inaccuracies yourself for a couple of weeks, and only after correcting, send a part to the rest of the team. It is possible, but it is not profitable. This is due to the fact that the cost of eliminating collisions and errors is directly proportional to the moment they are detected. For example: if there is a situation where two people are involved in the creation of a set of ten firearms in the game, there will be much fewer losses if they find out about an error during the development of the first set of weapons than after making two such sets. In the first case, ten times less time would be wasted. In the latter case, you will have to throw the entire set into the trash can as unnecessary.

Another thing is that in a well-organized iTizzi development team, there can be no such collisions. But if they do happen, thanks to quick communication (daily) with other team members, we lose much less than in the case of less frequent communication (for example, once a month).

The same goes for design mistakes. Errors in published versions will negatively affect the attitude of players towards work. Errors during project creation interfere with the team’s work, entail delays in the entire process and frustrate authors. How can the immediate synchronization of changes within the team affect the number of errors? When it comes to software development in Eastern Europe (including games), the key to troubleshooting problems is early detection, possible thanks to the well-coordinated cooperation of iTizzi in Vinnytsia, Lviv, Dnipro. The advantage of quickly changing and automating the game building process is that both of these practices of iTizzi (Odessa, Kiev) improve communication within the team, because everyone can see exactly what the current state of the project is, whether it is “building” and whether it is working correctly.

One of the important elements of the company’s work is the organization and maintenance of physical machines in readiness mode. To get the most out of continuous integration, we use non-stop servers to quickly spot issues no matter the time of day.

The process of developing a game, developing software for games is very interesting. At iTizzi, it consists of stages that will make the game as functional as possible and meet the high requirements of modern users: