The development process in Gaming is long and detailed. From game design to art creation, the turn has come to the complex task of coding which is our calendar topic of the day.
The process of game development is an iterative one where our team works very closely together. They have phone meetings every day to go over the tasks at hand and work with design documents, shared routines and task “tickets” in a program called Jira. The glue which ties it all together to form the game is the coding, or technical development, in our case done by Gaming Corps’ Lead Unity Specialist and Game Developer, Michail Moiropoulos. Today we take a page from Michail’s book and again use the genre of adventure puzzles and Oh Frog as an example, to learn more about how the process of game development unfolds from start to finish.
In the development of Oh Frog, as with similar types of games, the team works segment by segment. For Oh Frog this means producing one stage of the game at a time. As described in the first calendar entry of the series, it is not so that the game designer designs everything and once a finished document is done convey it to the team. The design process for a stage has several iterative steps before the design document is completed. Michail is first engaged early on when the game designer is testing out ideas for the stage. The designer will explain the basic idea and functionality of the stage, provide documentation but most importantly present it in a meeting and include the underlying reasons for choosing one thing over another. He will explain how it is meant to work and then it is Michail’s task to feedback on this by doing a first reality check – analysing how to incorporate the idea into code and what potential issues could arise. Here there are two kinds of issues – the ones that can be easily solved, and then Michail will give the green light, and the ones where what is planned will block the gameplay somehow and potentially mess with the logic of the code. If the case is the latter then Michail will suggest options for how to change the design in order to move forward, or work on breaking down these issues and analyse them further in order to avoid pitfalls.
These initial conversations, which are frequent as they come up every time a new idea is introduced, are something Michail handles for the most part without turning on his computer. The code and the inherent logic of the game, all of the interconnecting sequences and mechanics, and the game itself is something he inherently knows. Part of the game developer’s job is taking responsibility for, coding and understanding exactly how everything works exactly in which order. Done right this means that to a large degree, the entire game in minute detail is actually in Michail’s head, ready to be accessed at any time. Overwhelming as that may seem for us outsiders, it is the norm for an accomplished developer. So when the team has a meeting to go over a new idea for a new segment, Michail will be able to deliver his first feedback on what is technically possible and not directly in the meeting without checking the code.
When the design document evolves and more variables in the stage are set, Michail starts coding by first mapping out the work. He prefers to get visuals from the designer in combination with text, to see clearly what the designer is going for. At this point there often are no or few art assets in place yet, but as long as Michail can get a very rough sketch with any program it simplifies converting the game design into code and logic.
Once the full design is in place, how long does it take to code a stage from start to finish? Michail points out that this varies a lot based on the content of the stage, how many assets that need animating and so forth, the work is very much volume driven. Oh Frog is also a game where little is reused, meaning that part of the game concept is that every stage has new graphics and even an individual music score. This means that development time can vary a lot depending on how “heavy” the new stage is. But, there are key mechanisms where it is a matter of reskinning something. For instance – important elements in World 1 are the flowers or plants which Lif swings from, using his tongue. For the not yet published World 2, these have been reskinned to portray something very different, but the underlying mechanic is the same and thus Lif’s basic movement is also the same.
Michail points out that although the type of work carried out by a developer requires specific competencies, or perhaps a specific personality, most importantly it requires is a structured work process. A game developer must be extremely structured in his work in order to code perfectly, and it is in Michail’s opinion not enough just to be structured in the individual tasks themselves, you have to have a structured approach to your life in general. You have to keep your workplace neat, your tasks organized, your planning on point. If you have that basic level of structure in your life and brain, it helps enormously in carrying out the complex task of coding a game.
The way that the game development team works is linear in the sense of taking one stage at a time, despite the work being iterative within the confines of that stage. There is no value from a creative or technical standpoint to do more than one stage in parallel or to stagger them. So despite the playfulness, imagination and complexity of the work of developing a game, the process as a whole benefits from being repetitive and predictable. The only person working somewhat staggered has to be the designer as he needs to stay one step ahead to not hold up the production. Despite this, and no matter how well organized and efficient the team, there will be waiting involved for the developer. It is inevitable that at some point, he will wait for updated assets or changed design. His work is the last outpost before a stage is completely finished, and thus it may be so that before the point of final coding can be reached, there is lag time involved. For Michail, he deals with this by having side projects as it is imperative for him to keep his creativity continuously flowing, staying busy. Currently he is working on assisting the iGaming team from time to time, and in previous employment he worked on more than one game at a time. In those cases, there is no problem in going from one project to the other because for him these are like two completely separate boxes. Sometimes having two projects at once can be beneficial as solutions can be transferred from one to the other,
The work of the game developer is also linear in terms of inherent logic. The basic functionality of coding is the scheduling of sequences which need to be in a logical order. If before A comes B and before B comes C, then C has to also come before A, and so forth. So when adding something new the first rule of coding is “Don’t break the game!” What this means is that whatever is being added should optimally be treated as another module to add to the existing build, expanding the game one building block at the time. If you already have A, B, C and D scheduled in a set order, throwing in E in the middle of the sequence will mess up the logic, as opposed to adding E to the end of the sequence. If you do your job right from the beginning, if the entire team is extremely stringent in their work and think things through ahead of time, there will be few problems along the way. Naturally this is difficult to always live up to, so there will be times where a new addition is imperative to keep the game flowing, and despite “breaking” something, it has to be included. In that case the game developer needs to go back and rework the code to make a new, perfectly logic string of actions or events where one follows the other. You can of course also “break” the logic by accident and in that case need to analyse where the bug has occurred. One tiny line of code in the wrong place can throw a wrench in an entire game play. Once found it may make perfect sense, but it can be very difficult to find. Here is where Michail is thankful for his team members and for the efficiency of their work, having a good process together which means they normally are not taken by surprise when something occurs. And a key ingredient at all times is testing. The game development process goes through continuous and frequent testing.
Michail does all his programming in Unity which produces the final format of the game that eventually finds its way to the players.
We hope you have enjoyed this voyage into the magic realm of game development! Even if we have only scratched the surface. If this was the first segment you read, do go back and read about game design and art creation to get a fuller picture of the process.
