By Evan Harris – Programmer

On my first day at Kwalee, after being given the grand tour, awkwardly shaking people’s hands and being harassed by Didi the dog, I was given my first assignment: Make an online multiplayer turn based game.

Wow, okay, first days are normally spent sitting through endless health and safety lectures, HR inductions and arranging your pens into alphabetical order. Nobody does any real work until at least two weeks in. Right?

As I’d had prior experience writing client-server applications in my previous jobs, I volunteered to tackle the networking side of the project and to approach some of the higher level design for how our game would operate. This post covers the stages of work I undertook to go from an empty project to working networking code.

Phase 1

My first task was research. I needed to get up to speed quickly and gather knowledge so I could put together some high level requirements for the task.

I had some key questions at this stage relating to how the messaging architecture would work. What is the basic lifecycle of a request? What do some example messages look like? Following some reading and conversations with the rest of the Kwalee development team, I had a fair grasp of the operation of networking servers and how they had approached this whilst working on Gobang Social.

From this information I was able to to put together a set of skeleton requirements. At a very broad level these included:

• To ensure that the user experience was not adversely affected it needed to transmit messages asynchronously.

• It needed to be resilient to network outages, the code needed to detect and to handle transmission failures.

• It needed to be simple for other programmers to work with; the interface had to be straightforward enough that other programmers didn’t need to know the internal workings of the code in order to work with it.

• It needed to be easy to make changes to the messages format without needing to re-write huge pieces of functionality. At the same time the messages needed to be objects in their own right.

The other critical requirement for the work I was about to undertake was that it needed to be usable in future games. It couldn’t be tied just to the this project. We needed to ensure that we laid strong foundations so that we and other teams, could build upon them later. Therefore the design had to be coherent and modular enough that we could re-use the majority of the components in another project with minimal rework.

Phase 2

Because I was still very new to iOS programming and wanted to get a feel for our capabilities I extended my research and spent the next few days getting a prototype client working that could talk to the Kwalee game servers.

I started by examining the networking functionality and put together a simple test application which would communicate messages to and from the server. Putting together a prototype freed me from some of the pressures of working with the final project. I could quickly see which methods and structures would be useful and capable of working within the final design.

Putting together a prototype also allowed me to interact with the server directly. This helped to cement some of the core concepts in my mind and helped to clear up some of the assumptions I had made about the operation of the Kwalee game servers.

Phase 3

Armed with requirements, a working prototype and a rough idea about the approach I was going to take, I started work on designing the core architecture. This took the form of sketching out how different systems would talk to each other on paper and then to create files, class definitions and major method signatures in code to fill in this representation.

I’ve found this to be a more preferable method of system design than producing UML diagrams and up-front formal documentation. This is partially because I’ve found there to be a mental disconnect between thinking how to communicate a design outside of an IDE and how it would actually work in practice. By performing the design directly in code I’ve found that it’s easier to express ideas and concepts and to figure out which solutions would have the cleanest implementation.

At this stage I wanted to keep the design conceptual so I resisted implementing concrete functionality as much as possible. All of the core functionality was stubbed out and commented to make it clear where different pieces of functionality would live. I found that by considering how the classes would ultimately be wired up, it forced me to think about the design in terms of how it would actually be implemented. This helped to improve the overall design as I could catch problems early and think about alternative solutions and alternative representations.

At this stage I knew that the design would roughly follow the Pareto Principle, namely that I could account for 80% of the required functionality with only 20% of the classes I would need.

Phase 4

With a design in place I started bringing together the working prototype and the conceptual hierarchy I’d produced during phase 3. Because I’d been careful to keep notes in each classes about what the responsibilities would actually be and some of the core method names I would need this was a straightforward process of solidifying the ideas into implementation.

At the end of the second week authentication could be carried out between the game and the Kwalee servers. At the end of the third week we had our first major success when we were able to actually simulate a networked game between two users within the Kwalee office.

From this point my work has been on implementing some of the large pieces of functionality that we need to have a reliable, extensible and coherently design platform on which to develop awesome games.

I’m looking forward to sharing more insights into our development process with you in the future. In the meantime, keep playing Gobang social!