Bites and code behind our games
Hello managers! How are you doing? Excited about your races? While March is silently moving toward the end of winter, we at Interactive Project are back with another story about your favourite games. Today we set down with our CTO Augusto Pace to talk about the process behind the development, the coding and the bytes that mash up to create the great games of Interactive Project portfolio!
Interactive Project team member (to know more about your team click here):
Half a man, half a legend from the middle age, 100% a developer and an obscure past as a wandering minstrel (click here for evidence about it), our CTO is the passionate leader of our development team, generating the main lines on which our developers work to transform our projects in amazing games.
We saw, in the last weeks, the work for a fireball to find life into a 3D model and the study behind MyGPTeam Turbo’s circuits. Today we are examining the development of game’s code. Prerequisite, before any work on coding, is a section of group discussion to define the concept behind the game, as was did with OverVolt. Then our developers move on studying game’s requisites: What the gamer should see? How should she/he play? Why should she/he do certain tasks? Brainstorm phase is the initial step before any other process; the game cannot be developed if requisites and basic implementable needs are not defined.
In order to write our games our developers use agile development logics, which are flexible and highly repetitive, continuously looping the task that has to perform certain actions. This is done in order to have an immediate feedback pattern using TDD (Test Driven Development) techniques. Our designers define a series of error and success situations and then write the code in order to satisfy those situations. To have feedback and be sure about the efficient implementation of any step an SDK Unit Testing is used, which verifies that a certain action is performed correctly on every single function (if I make x and I expect y, does it really happen?).
Before writing any code, it is important to present a Project Document to be sure about what to implement. Once agreed upon it, our developers move on studying macrotasks for system’s stakeholders: the user, the device, the system, and so on. At the same time, they start defining and structuring the requisites to develop. Again, (see previous paragraph) our developers do use an agile approach to coding, since the more “classical approach” of having everything defined before moving into writing is a too slow and rigid approach for a start-up. Our developer goes for a rapid, iterated and incremental design in order to study each and every task and to move on to have a module completely autonomous and functional in itself. At this point, a functional test is performed on the whole module. The level of errors in this specific analysis phase is relatively low, since 80% of testing has already been carried out at tasks level.
Working appears smooth until now, isn’t it? Well, big issues begins when we take in consideration that a game is rarely written and designed by a single developer. Many developers are usually working simultaneously on interconnected tasks. And here to you the case for misunderstanding and potentially chaotic situations which might impair all the work.
“The single biggest problem in communication is the illusion that it has taken place”, said George Bernard Shaw. Communicate and communicate a lot; communication is the basic need of a well-designed game. Our CTO stressed the importance of the communication process, among developers first and among any other level of the company after. Often two developers end up writing on the same document and that is why is important to trace modifications and their authors. This work is carried out through systems of code versioning as, for example, “git”. Taking care of modifications is not a problem concerning only start-ups, but all the companies at all levels. When someone writes a change in the code lines has to make a commit and explain what has been modified and why, in order to manage the various versions and, in case of need, go back and retrieve an old, more functional, version. Systems of code versioning are, however, not able to define which is the best code version. They just refer the issue to our developers, which, in the end, have to discuss and fight over it to come up with a solution to generate the lines and solutions that will end up being the base for your favourite games marked Interactive Project!