Welcome back to Gameplay is More Than Just Writing Code with Robin and Bradley from the Engineering Team at Deep Silver Dambuster Studios. If you missed part one, you can catch up here.

If you're all up to date, lets jump back into the responsibilities, tasks and objectives of a Gameplay Programmer:

-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

-Sharing technical knowledge

So, you’ve learnt something cool and would like to use it in your work. You now need to bring the rest of the team up to speed because, as we said before, they could one day end up working on your code.

You need to share the information and thus reduce the *Bus Factor

A way that we share knowledge at Dambuster is through ‘Dev Talks’, during which a member of the Engineering team gives a presentation about something they’ve learnt or an area they’ve explored.

‘After I accepted my offer, but before I started, my new lead had me read up on the SOLID principles. These are some guidelines to follow to make OOP code, like the code we write in C++, easier to develop and maintain. At the time I didn’t really understand them, and it was only after starting here and using them in some new systems that I appreciated what makes them so useful!

‘Having seen how difficult they were to grasp without the context of a real-world example, I decided to try and show my colleagues the new systems I had made, explaining how I had applied the SOLID principles and the specific ways in which they made the code easier to work with. This was the topic of two Dev Talks I gave, each on a different system. Now some of the newer hires have come to me, after watching the videos of those talks, asking for clarifications of how they might apply the principles to their own systems!’. – Robin McFarland, Gameplay Programmer at Deep Silver Dambuster Studios.

*Bus Factor: Taken from the term ‘if I was to get hit by a bus’, this factor calculates the risk to a project if certain skills and information have not been shared amongst your team members in the hypothetical (and very unfortunate) event that you are hit by a bus.

-Technical support

As a programmer, you will be the first port of call if someone from within your team or another department has an issue with a piece of code, asset or function you are responsible for.

You will need to provide technical support; this could mean talking the person through how to resolve the issue or by rolling up your sleeves and implementing a fix yourself.

People with varying levels of technical ability require different levels of support, so it’s important to be adaptable and open-minded.

‘Recently, I was helping a technical teammate resolve why a certain type of Actor wasn’t getting Anim Notifies in cutscenes. All the information we had was that it had worked before the 8th December and nothing in the commit history was anywhere near the area.

‘The teammate in question was more familiar with blueprint than code, so when I stepped in to help, I guided him through Unreal Engine code and found where the Anim Notifies were processed. From here, we put some breakpoints in and moved through callstacks until we found the issue. It turned out that it had nothing to do with Anim Notifies themselves and instead came from an unrelated feature that had been added to a specific Actor.’ – Bradley Redfern, Game Programmer at Deep Silver Dambuster Studios

-Fixing, debugging and improving code

In game development, things can and do go wrong. The introduction of a new asset may bring with it a completely game-breaking bug, or it could be something as simple as a good old bit of lag.

When issues like this do occur, you’ll be expected to dive into the code and isolate the problem and come up with a suitable solution. Depending on the issue, it could take minutes, days or even weeks to resolve.

But just because something hasn’t gone haywire, doesn’t mean code can’t be improved. During code reviews – which everyone in the Engineering Department participates in – you will examine code you and your peers have written to try and highlight areas that could be optimised or need to be more legible.

-Documentation

Unlike the life of a spy, being a programmer means always leaving a paper trail documenting your work.

As we illustrated with the Bus Factor, there can be a real impact on the project you are working on if you do not share this important information with your colleagues.

If you are not present and cannot be contacted – say you’ve been taken ill or moved on to other pastures – documentation relating to your work will help bring other development staff up to speed in your absence.

‘A good form of documentation is a working feature committed to the build. For example, if we have a door and there are four different ways of opening it, then committing a test map with all methods showcased is a good form of documentation.

‘This means that Level Designers can find the documentation without leaving the Editor. Currently, the way we document things is to talk to our Production Engineer.

‘We talk him through a feature (getting a less technical team member’s opinion on the interface and usability before going wide), he makes notes and documents it for us on our internal wiki system.’ – Bradley Redfern, Game Programmer at Deep Silver Dambuster Studios

Extra Information: What Type of Person do you Need to be?

We thought it was worth mentioning some of the soft skills required to be a successful programmer at Deep Silver Dambuster Studios:

• Being able to take and give constructive criticism
• A desire to learn and grow professionally and as a person
• Written and verbal communication skills
• The ability to ask others for help and not go it alone
• A team player attitude, always ready to help others

Bonus: Public speaking skills can come in handy but aren’t a necessity.

We Hope this Helped!

This is by no means an exhaustive list of a gameplay programmer's duties and responsibilities, but we hope it gave you some insight into what the Engineering team at Dambuster gets up to day-to-day.

If you are looking for an opportunity in game programming, be sure to check out our vacancies.