Howard Price is a graphics programmer at Codemasters. He has worked on some the worlds most well-known racing titles including the hugely popular Dirt games.

Explain your role like I'm five

I tell the computer what to draw on the screen when you are playing a game. We draw shapes like triangles and squares and colour them in to make a pretty picture that covers the whole screen. I make racing games, so the first thing we have to draw is the car you are driving, which is usually a really fast sports car. Then we will draw the other cars you are racing against. Next, we will draw the road, and everything around the road like trees, and houses and hills. Then we draw the sky, with the sun and clouds and colour all of it in nicely. We might finish by adding things like rain falling from the sky, smoke coming off the tyres when you drive around a corner really fast, or sparks when a car hits something! At the very end, we draw things like a little map of where you are, a number to show if you are winning and a speedo like on the dashboard of a car so you can see how fast you are going. The cars certainly aren't sitting still, so we have to get the computer to draw a different picture many times every second so it all moves like in real life!

Take us through your average day of work

I usually work on one main graphics feature at a time, but I have to be prepared to fix any bugs that are found during the day. A feature might be something like: "Make the game look more cinematic by adding lens flare" or "Improve the particle editor so the artists can make better special effects". A bug might be something like: "Work out why the headlights look too bright at night" or "Work out why the tyre smoke keeps disappearing". If a bug actually makes the game crash, and it turns out the problem is in code that I wrote, then I have to stop what I'm doing immediately and fix it. When I think I have finished a task or fixed a bug I ask another programmer to "review" my work. They look at the changes I have made to make sure that it does what it is supposed to do. If they spot any problems they might suggest some further changes. Then I test that the game works properly and then publish my changes for the rest of the studio to see. Every afternoon, the graphics team huddle round along with our producer for the daily scrum. We each have a few minutes to talk about what we have done today, what are going to do tomorrow and any problems we are having. Scrums are a very good way to ask for help and receive good advice without realising you are doing so!

What was your journey into your current role?

I loved computers as a teenager, but unfortunately, computer science wasn't an option in my high school in the 90s. I enjoyed maths and science in the classroom and had to try to learn about computers in my spare time. This was difficult because at that time the internet was not widely available! Good A-levels in maths and physics got me a place at university studying physics. The physics degree was fascinating, but in the end I realised that the part of the course that I had enjoyed the most was writing computer simulations. With this in the back of my mind, I decided to go back to university to study for a masters degree in High-Performance Computing. It was a great course and at the end of it, I felt like I had finally become a competent programmer. After graduating I gained valuable experience working in the University department as a programmer, and in the evenings I started trying to write games for fun. Suddenly it dawned on me that there was a possibility that I could get paid for programming games. As a job! I contacted some recruitment agencies and was amazed to be invited for an interview at Sony in which I was offered a job working on the next WipEout game for the newly released PlayStation® 3. When I started at Sony, I was working mainly on physics programming but I also did some gameplay and AI programming. After a few years, I was given an opportunity to work with the graphics team for a PlayStation® 4 title. I didn't know much about graphics programming at that point but I was able to learn everything I needed to know on-the-job from my more experienced colleagues, books and the internet. For the past 4 years, I have worked as a graphics programmer for Codemasters developing game engine technology for the racing games we make for XBOX, PlayStation® and PC.

What is the most rewarding thing about your role?

When the code you have written works for the first time and you see the results on screen it is extremely satisfying. It's great when a system you have talked about for a long time and designed and implemented is actually in the game for everybody to see. It's even better when the game is released and reviewers appreciate the end-result and give it a good writeup.

In your day to day, which other staff roles do you interact with the most?

I am lucky that I am not the only graphics programmer in our studio. I work in a team of dedicated specialist graphics programmers, so most of my time is spent talking to them about the problems we are all trying to solve. Outside of my team when I was a gameplay programmer, I spent a lot of time talking to designers, who decide how the game should play. But as a graphics programmer, I mainly interact with artists, who decide how the game should *look*. The artists model and draw the objects to use in the game, such as vehicles and environments. The graphics programmer's job is to take that data, and get it into the game engine and onto the screen to realise their vision, so we have to work closely together. The other person I talk to a lot is our producer. The producer's responsibility is to ensure the game gets finished on time and to a high standard. They will bend over backwards to make sure that everyone has everything they need to do a good job.

What is the most challenging thing about your role?

Graphics programming is an extremely broad and technical role. We have to have a good working knowledge of things like game engine architecture, 3D maths, physics, real-time rendering algorithms, performance programming, and different computer/console hardware. Nobody can possibly know everything, and often it can be hard work starting a new task in an area that you know very little about. But this is also one of the best things about the job - we are constantly learning new things. We are constantly inspired and challenged by the graphics we see in other games.

What software, digital tools or working practises do you use the most?

I spend most of my day coding using Visual Studio. As well as allowing me to write code, it also has a great built-in debugger - programmers probably spend more time debugging existing code than writing new code. Amazingly Visual Studio is now free to use and supports many languages including C, C++, C# and Python. Game codebases can be extremely large with many thousands of files, so I use a very handy Visual Studio plugin called Visual Assist which helps me to find what I'm looking for very quickly and easily. We also use special graphics debugging tools (such as PIX for Windows) that allow us to "capture" a frame of the game and inspect it to make sure that everything is working as expected on the graphics chip. We use version control and make very good use of "branch-per-task". This allows us to work on multiple features/bugs at once and quickly switch between them with no fear of losing any code.

What are the key skills needed for you to work on to do your role?

• C and C++ programming * Shader programming
• Vector maths (Think points, vectors, dot products, cross products and 4x4 matrices)
• Good clear communication

What advice would you give your younger self just starting in the industry?

Just to sit down at a computer and start actually making games. I would recommend starting out by cloning classic games. You will be amazed by how much you learn writing a complete game from start to finish. Start with really simple games and work up: Space Invaders, Flappy Bird, Pong, Snake, Asteroids, Tetris, Sokoban, Pacman, Gradius, Super Mario Bros, Doom and onward. Focus clearly on the thing you are trying to achieve at any one time. For example, if you are trying to learn the basics of 2D vector maths by cloning Asteroids, then don't get bogged down in low-level platform-specific stuff like creating a Window and reading input. Learn how to take advantage of libraries like SDL2 which can open a Window and give you input and basic drawing functionality out-of-the-box. Write games using engines like Pico-8, Game Maker or Unity. This will expose you to industry-standard ways of doing things and terminology. Watch experienced coders streaming themselves writing games online. It's a great way to pick up little tricks and techniques. Don't be afraid to ask questions you think are dumb - everyone will have had to ask that same question at some point

Could you give us some links to things a young person should read, watch or listen too that will aid them?

• The One Lone Coder (javid9x) YouTube channel has a great "Code-it-Yourself!" playlist which explains clearly how to write simple games in C++.
• Inigo Quilez (IQ) YouTube channel "Tutorials" playlist explains how to "paint with maths" using shaders.
• For more experienced programmers there are three books that I would recommend: "Game Engine Architecture" by Jason Gregory is a very good overview of what goes into making a game engine. "Real Time Collision Detection" by Christer Ericsson has lots of very clear examples of using vector maths. Essential reading for physics, graphics and 3D AI programmers. "Real Time Rendering" by Tomas Akenine-Moller is very good reference for graphics programming. The chapter on "The Graphics Rendering Pipeline" is essential reading. (Older editions may be more affordable)

You can look at the educational pathways for this role here. Or why not go ahead and start building your first game. If you are a bit further on, apply for mentorship or search the opportunities section for events and competitions to help boost your skills and network.