The most basic way to explain a programmer’s role in the games industry is that they are the people responsible for writing the code that brings a game to life.

They map controller inputs to actions, ensure that night and day cycles function properly and, you know that NPC who keeps on asking you to join them on their side quest? Well, programmers created the code that enabled the AI to be quite so annoying.

However, if you were to think that a programmer’s job in the games industry is 100% writing code 24/7, you’d be sorely mistaken.

In this blog, we will outline and explore the many facets of the role with the help of two members of Dambuster’s Engineering Department: Gameplay Programmer, Robin McFarland and Gameplay Programmer, Bradley Redfern.

Writing Code is About More than Just Writing Code

Okay, stay with us here… but before we dive into the other aspects of a Gameplay Programmer’s job, we first need to talk about the entire code writing process.

It’s not as simple as sitting down, writing a block and moving onto the next section without a second thought spared.

Ernest Hemmingway once famously said, ‘The only kind of writing is rewriting’.

Although we can’t attest to the author’s C++ Skills, we can confirm that the same principle applies to writing code.

As a programmer, you will be expected to revisit your own work and that of your peers to look for ways to improve and optimise it during code reviews.

It is also your responsibility to ensure the code you put into the codebase is legible (by this, we mean it can be read and understood by other team members) and meets the organisation’s coding standards.

The reason being, at some point, other members of the department may need to work on code you’ve written, so it’s important they can read and understand it easily.

After all, nobody wants to spend half of their day deciphering code that would have taken you considerably less time to tidy up.

What are the Other Aspects of the Role?

Now we are going to delve into the other aspects of a game programmer’s role. For reference, when we spoke to Robin and Bradley to gather information for this piece, it was 2:20 pm.

During the meeting, Bradley told us about what a busy day he’d had, and by that point, he was yet to write a single line of code as he was preoccupied with a combination of these duties and responsibilities:

- Explaining technical information to non-technical staff

One of the most important aspects of the role is explaining technical concepts, ideas and information to people with varying levels of technical knowledge.

As a programmer, you will interface with several departments such as Art, Design, Production, Animation, Audio and QA. It’s important you can relay information to people within these departments clearly, without jargon and in a way that doesn’t come across as patronising.

‘My work on the Mission System has meant I need to be very good at communicating with non-technical co-workers, as Level Designers use it to build their Missions. Some of the configuration options can get quite complicated and technical, and I’ve found that it can be useful to have a set analogy that we refer to when discussing what options will work for them. For example, to explain how the system handles checkpoints that might be loaded when a player dies, I always compare them to bookmarks attached to pages in a book.

‘When the player dies during a later Objective, Mission rolls back to the last checkpoint, like someone flicking back through a book to the most recent bookmark. This mental image makes it clear how the system works, and why it has to work that way, even when initially it might seem unintuitive’.– Robin McFarland, Gameplay Programmer at Deep Silver Dambuster Studios

This can even help you solve your own problems!

While it’s an important skill to have to help your non-technical co-workers, coincidentally, it can also help you fix a problem, as Bradley explains here…

‘I remember getting stuck on a linked list problem whilst at university and I ended up talking to mum about it (who is not technical at all). I explained the problem to her as train stations across the country and after five minutes of explaining where all the trains were heading, she said to me, “Shouldn’t the blue train have gone through Sheffield Station by now?”.

‘It was exactly the right question, and it turned out she’d found the problem in my code without ever looking at it. If you can explain a technical problem to your mum in a way that she can understand, then you’re on your way to explaining technical problems to less-technical team members’. – Bradley Redfern, Game Programmer at Deep Silver Dambuster Studios

- Planning and project management

Although we have very talented folks in the Production Department responsible for creating development roadmaps, there is still an aspect of project management and planning for gameplay programmers.

Everyone is in charge of managing their own tasks within our project management tool, Hansoft. This means opening, closing and updating tickets so that your peers can understand where your tasks are up to, any blockers in your way and estimated dates for completion.

As a junior, you may find yourself helping a senior or lead plan your weekly sprint to ensure you make the most of your time and work efficiently. As you progress, however, you will become more autonomous and even help with the planning of more junior staff members’ time.

- Personal development

As well as building on and sharpening their existing programming toolset, our Engineering Department is actively encouraged to learn new skills in the hope that their newfound talents can one day benefit the projects we are working on.

Every other Wednesday afternoon, the Engineering team is given an allocated Learning and Development spot, during which they can explore an area of programming they are interested in.

‘For L&D some time last year, I decided to experiment with and learn more about C++ templates, a notoriously difficult feature to understand and use effectively. I spent the time making a small demonstration program that did something cool, using all the knowledge learnt. I decided to push the project even further and found that what I knew wasn’t enough to make it work! I did some more digging and eventually came to SFINAE, another (even more infamous!) concept within templates.

‘I had heard about it before but had never been able to understand it. L&D gave me the time to really get my head around it by applying it to this specific mini project. I gathered my findings, gave a talk about what I had done, and thought, “well I hope I never need that again!” Well, wouldn’t you know it, last week, I was having a hard time working out how to make something work and realised that SFINAE was exactly what I needed! Having taken the time to understand it before, now I could crack the problem with relative ease’. – Robin McFarland, Gameplay Programmer at Deep Silver Dambuster Studios

Join Us Next Time

That’s all for part one, be sure to join us next time when we will continue to look at the role of a gameplay programmer at Deep Silver Dambuster Studios in more detail as we cover sharing technical knowledge, documentation. fixing and debugging code, and much more.