Computer games have always been a great passion of mine and as a child, frustrated with waiting for my next birthday or Santa to provide me with my next game, I decided to try out programming games myself. I would sit for hours copying in pages and pages of code from computer game magazines to play some kind of Pac-Man clone and revel in the satisfaction of knowing that my hours of work have resulted in creating entertainment for myself and friends. I began tinkering with the games I had typed in from magazines and customising them. Eventually I began programming my own games from scratch. Since these early days, I had aspirations of being a games programmer myself one day, so that I could create games for thousands of people to enjoy.
After completing a BSc in Computer Science, I decided I wanted to specialise my knowledge a little more before getting into the games industry and undertook a MSc in Games Programming. Upon finishing the MSc, I was fortunate enough to land a job straight away at Sony in London. I worked there for a year before moving to my current job at Sumo Digital in Sheffield. Over the past two and a half years I have worked on six different titles, two of which have been released, and one of which is my current project, which is an undisclosed title.
Whenever I’m with friends or family sitting down to play a game and they ask how the game is created, I’m always stuck for an answer because it is such a huge process. I usually end up gabbling on about how I’m handed a game design and I have to work with other programmers in creating some code that will tell the computer what to do in order to play like the original design. This is the broadest description possible that I can give to them, whereas all developers know that the job involves a lot of concentration, calculation, evaluation, communication and team spirit. We have development hardware which we can use to slowly build a game – sometimes from scratch and sometimes built upon a previous game.
Essentially, it is our job to communicate with the designers and artists, get art assets rendering on the screen and create an interface for the player to be able to interact with those virtual objects. All of this is done to strict deadlines and variable game design constraints.
I consider myself to be an artificial intelligence (AI) programmer since this is what I specialised in on my MSc, but since coming into the industry I have worked more as a gameplay programmer. The two are quite closely interlinked and both fun to do, although I would like to be able to spend more time in AI since this is still a relatively tame area of games with great opportunity to push the boundaries. Yet as with most jobs, it isn’t always possible to do exactly what you want to do all of the time, but part of being a professional is to be able to accept this fact, be patient and keep working hard until the opportunities show themselves (or you create them).
In summary, my role is to look into features of a game design, evaluate different ways of implementation, discuss ideas with designers, artists and other programmers and to ultimately produce the code to create part of the game. It is important to ensure that whatever I am coding fits together with work produced by other coders, since one person can never code an entire game themselves anymore – they are simply too big and complicated. When designing and implementing the code, I have to decide upon what algorithms and mathematical formulas to use and have an awareness of other code libraries which can be incorporated to facilitate my code.
Feedback is essential and it is up to me to ensure that designers and artists are happy with the end results and be able to adapt to any changes that are required.
Even as a programmer it is great to be able to exchange design ideas and concepts and our opinions are always welcomed. Sometimes I am included in design meetings to evaluate the plausibility of the propositions and offer boundaries to the designers, meaning that there is pressure to realistically come up with such boundaries so as to not over-commit or close the door on a design prospect that could, perhaps, have been a plausible concept.
Every project is exciting, it doesn’t matter too much if I’m not a big fan of the genre of game I’m making (although it helps) because my goal is always the same: to make it as good as possible and contribute to the industry I am so passionate about.
A typical day in the office will depend greatly on the stage of the project. Towards the start of the project you can expect to be involved in scheduling meetings, brainstorming sessions or technical reviews, discussing different approaches to the task at hand. During this time I tend to find myself doing research to help create a list of goals, things to look out for and ways of achieving the goals and so on.
More time will be spent drawing up diagrams and experimenting with different systematic approaches to coding a problem. There may also be opportunities to create prototypes for the designers to try out. Part way through the project, I can expect to be spending the majority of time simply coding away the ideas and designs established at the start of the project and getting resources into the game. Towards the end of the project, more time will be spent collaborating with the designers and artists to ensure they are happy with the look and feel of the final (or near final) product. The quality assurance team will be testing the game and discovering bugs that must be fixed, whilst the lead programmers are busy preparing to create new builds to send off to the testers. Every team will have at least one producer who helps to ensure that this process goes as smoothly as possible.
It is a great honour to be a part of the industry. I have, and still do, spend a lot of time playing games and it’s great to know that you’re contributing to the industry as well. People outside of work generally take a great interest in what you do. They want to know the ins and outs of how a game is made, what sort of personnel and resources are involved, what sort of funny stories you have. For example tiny bugs that have slipped the net or funny bugs that were noticed late in the project.
People will ask you a lot of questions which can be fun to answer, obviously within the boundaries of your confidentiality agreement. It is an exciting industry to be involved in and one that is moving fast so you’re always feeling like you need to try and push the boundaries and move it along further.
Working in the games industry
On the whole, it is a really fun and challenging career to have. I enjoy turning up to work in the mornings and I like working with the other people here. One of the occupational hazards of this industry is that during the early stage of the product, there is always the chance that the final product may never actually hit the shelves. This will be because of marketing and management reasons and luckily, as a programmer, I’m protected from the politics of it all. This has happened to me twice now, and although it is a little frustrating knowing that my efforts will bear no fruit, I am able to take some consolation from the fact that the start of the project is when most of the research is conducted.
This knowledge can then hopefully be used or adapted for future projects. The start stage of a project (in my experience) is the most fun stage, where I get to try new ideas and perhaps test and evaluate different programming/gameplay/AI techniques and so all is not lost if a project gets called off.
As I have become more adapted to the life of a programmer, I have been able to sit back and see the opportunities that exist around me for programmers in the industry. Some prefer to stick to being technical programmers and specialising further in their area and working closer to the hardware, whilst others prefer to go into a more management style role where they are responsible for a particular area (e.g. graphics, gameplay) and help to manage and schedule a group of people.
Some people also seem quite happy to just stick with the job they’re doing without pushing for more responsibility simply because they enjoy the work that they do. I haven’t decided which route I would most like to take as yet and so I simply keep my head down, produce the best work I can and assume that my skills and personality will help direct me down the most suitable route.