Making a video game is undoubtedly a labour of love. From its sticky beginnings with a small crop of people discussing ideas to the greater expansion of design, construction and rendering of images, games development is an ethereal bastion of creativity. Or so we’re made to believe. Not knowing the inner machinations of how a game is made certainly perpetuates the aura it seemingly possesses. The likelihood is that men and women toil away day and night, sweating profusely trying to use their often modest means to create the technological artistry that contributes to the array of high quality games that entertain us so.

The question of how a video game is made is therefore an incredibly interesting one. I was fortunate enough to get a chance to chat with Ollie Powell, a Computer Gameplay Design and Production student at the University of Staffordshire, UK. We discussed the prospects of making a game, as well as how the production and creation differs dependent on an academic setting. We all follow independent studios developing games but how do any potential future John Carmacks and Sid Meiers begin their journeys from a technical setting with solid taught backgrounds?

On top of how games are developed under specific environments we discussed Ollie’s recent game, Collision Course (currently in Beta), what it’s like working under stresses in a team-based environment like games development and his personal future plans.




We began the interview by discussing the recent project that Ollie and his fellow team of students had been working on. “Collision Course is a competitive 1 on 1 game where both players take on very different roles. One is racing to the end of the level, and the other is trying their best to stop them by placing traps in their path.” Like all games, it starts with a basic algorithm and as such needing a blanket sentence for a premise is incredibly important. “It’s a difficult one to describe in all honesty,” Ollie says, noting that when making anything ambitious it’s notoriously difficult to lay out every nuance and intricacy.

All games live and die by the direction that the developers want to take. Knowing what you want to achieve and making sure players are invested in doing so is vital. “We’ve been saying if you and your opponent aren’t on the verge of a fight, we’re doing something wrong.” Having a vision is the mark of any good team, but equally accepting natural evolutions along the way is the sign of a progressive group of individuals. For example, Ollie and his team, “were originally looking at making something similar to the mine cart levels in Donkey Kong Country. We wanted to include multiplayer in some aspect though, and it gradually evolved into what it is today.”

They had a vision but allowed natural adaptations to happen to create the best game in their eyes. Quite an admirable trait.




We quickly moved onto the very delicate steps of how Collision Course came to be. Like almost every piece of technology the team started off by making a brief tech demo just to see whether their mechanics were sound and whether or not they had the capabilities for creating what they had in mind. In quite humorous, analogical terms, Ollie says the need for recognising the core components based off a demo are, “like the guy who built his house on sand. If you don’t have that solid base of fun, core mechanics at the beginning, it’s going to be difficult going forward.”

Once you have the core down though, it becomes a matter of mechanics and making sure that everything is working at the level needed to complete a project like Collision Course. “After that, we worked on getting the rest of the mechanics in engine, before designing and building the levels with the created art assets,” Ollie says before reassuringly pointing out that he’s confident they have everything down and that touching up the levels is just standard fare for any games developer.

As with everything though, the propensity for any challenging task to face adversities is something everybody has to deal with at some point or another. Ollie says that the most obvious difficulty faced was on the engine side. “Working with UE4 [Unreal Engine 4], with it still being a relatively new engine, has meant we’ve encountered a lot of bugs.” Development of any game can be particularly slow due to these types of issues and when the, “deadline is always in the back of your mind, and everyday lost to dealing with game breaking problems,” then it’s presumably a frustrating time for any developer, big or small.




Another aspect Ollie says he has found improving at a rate of knots is his ability to communicate ideas to a team. As lead designer he says he initially found it difficult to demonstrate the authoritative tendencies needed for such a role and particularly given the fact that everyone involved is working in an academic environment. We can all appreciate that people may not necessarily understand the ways of their fellow peers at first.

Working in this academic environment naturally presents different perspectives in terms of direction of a project and how to go about making it. Asking about the differences between an academic and work environment, Ollie says working in the setting he does is halfway between the two and definitely not entirely disassociated from how a large games developer would work. “We’re set up in our roles like a developer because we’re trying to recreate what it would be like working for a company, you know? But obviously, some of the problems with still being in education rear their head, especially in terms of group work.” It seems that as per any educational course the curse of the missing or absent student still exists! Fortunately, says Ollie, he works with a good bunch that pull their weight.

Before concluding our interview, I wanted to quickly gauge the problems that people might not immediately think of when making a video game and whether any stereotypes held true. Many are naturally industry-wide, i.e. those belonging to time and man-power as well as immediate technological constraints but it’s true that “some of the public don’t realize the damage a single bug can do. It can bring development to a halt for days, or even weeks.”