Game programming is not one job but a family of specialisms, from gameplay and graphics to networking and build systems. This guide explains what each one involves, which languages and engines UK studios use, what technical tests look like and how to build a code portfolio that gets you to interview.
The specialisms
At a small studio, one programmer may cover gameplay, UI, tools and the build pipeline. At a large one, each of these is a team. Knowing the specialisms helps you read job adverts accurately and decide where to focus your learning.
Gameplay programming
Gameplay programmers turn design into something the player can feel: character movement, cameras, combat, abilities, inventory, quests, interaction. The role sits closest to designers and animators, and the best gameplay programmers care about game feel as much as clean code. It is the most common entry point for juniors.
Engine programming
Engine programmers work on the core systems everything else depends on: memory management, threading and job systems, file streaming, platform layers and core architecture. The work demands strong C++, an understanding of hardware and a habit of measuring performance rather than guessing.
Graphics and rendering
Rendering programmers build the systems that draw the frame: lighting, shadows, materials, post-processing and the interface with graphics APIs such as DirectX 12, Vulkan and the console equivalents. Expect heavy use of linear algebra, shader languages such as HLSL, and GPU profiling tools.
AI programming
AI programmers build the behaviour of non-player characters: decision making through behaviour trees, state machines or utility systems, plus navigation, perception and group tactics. The job is as much about making characters readable and fun as about technical sophistication.
Network programming
Network programmers make multiplayer work: replication, client prediction, lag compensation, matchmaking integration and bandwidth optimisation. Bugs here are notoriously hard to reproduce, so rigour and good debugging habits matter.
Tools programming
Tools programmers build the editors, importers, pipelines and plugins that the rest of the studio uses every day. Their users are colleagues, so communication and an eye for usability are as important as code. C# is common for tools alongside C++ and Python.
Build, release and DevOps
Build engineers keep large codebases compiling and shipping: continuous integration, build farms, automated testing, version control (Perforce is widespread in games, alongside Git) and platform packaging. A good build team saves the whole studio hours every day.
Online and backend
Live-service games need servers: accounts, inventories, leaderboards, matchmaking, telemetry and in-game stores. Backend engineers in games often use languages and stacks familiar from wider software development, such as Go, Java, C#, Node.js and cloud platforms. This is a good route in for web and backend developers moving into games.
Audio programming
Audio programmers integrate middleware such as Wwise or FMOD, build systems for dynamic music and spatial sound, and work closely with sound designers. It is a small specialism, and people who combine programming with audio knowledge are rare.
UI programming
UI programmers implement menus, HUDs and front-end flows, often in engine UI frameworks or third-party solutions. It is frequently underrated and always needed.
Languages and engines
C++
C++ remains the core language of console and PC game development and of Unreal Engine. For engine, graphics, gameplay and networking roles at most large UK studios, solid modern C++ is the baseline. That means understanding memory and object lifetimes, pointers and references, the cost of allocations and virtual calls, templates, move semantics and how data layout affects cache performance.
C#
C# is the language of Unity, which is widely used for mobile, indie and mid-sized projects, and is common for tools work in studios using other engines.
Scripting and others
Python appears constantly in pipelines and build tools. Lua is embedded in some engines for gameplay scripting. Shader languages (HLSL, GLSL) are essential for rendering roles. Unreal's Blueprints visual scripting is used heavily by designers, and gameplay programmers are expected to understand how C++ and Blueprints work together.
Engines
- Unreal Engine is used by a large share of UK studios on console and PC projects. Experience shipping something, even small, in Unreal with C++ is very marketable.
- Unity is common on mobile, at indie studios and for co-development work.
- Proprietary engines power many of the UK's biggest games. Frontier in Cambridge builds on its Cobra engine, Rockstar's studios use RAGE, Rebellion in Oxford has its Asura engine, and Playground Games works with Microsoft's ForzaTech. You cannot learn these before joining, so studios using them hire for fundamentals: C++, maths, problem solving and the ability to learn a large unfamiliar codebase.
Maths
Game programming uses maths every day. As a minimum, be comfortable with vectors (dot and cross products and what they tell you), matrices and transforms between coordinate spaces, quaternions for rotation, interpolation and easing, basic trigonometry, and simple collision tests such as ray against sphere or box. Rendering and physics roles go much further. You do not need to derive everything from first principles, but you should know which tool to reach for and why.
What a technical test looks like
Most studios test programmers before or during the interview process. Formats vary, and many studios use more than one.
| Format | What it involves | What they are looking for |
|---|---|---|
| Timed online test | C++ questions, debugging snippets, short algorithm problems | Language knowledge and fundamentals under time pressure |
| Take-home task | A small feature or system built in a few days, sometimes in a supplied project | Code quality, structure, judgement and communication |
| Maths questions | Vector and matrix problems, often game-flavoured ("is the enemy in front of the player?") | Practical spatial reasoning |
| Live coding or whiteboard | Solving a problem while talking through your approach | How you think, how you handle hints and mistakes |
| Code review | Reading a deliberately flawed piece of code and critiquing it | Spotting bugs, performance issues and unclear design |
How to approach a take-home test
- Read the brief twice and do exactly what it asks before adding extras.
- Write readable code. Consistent naming, small functions and clear structure matter more than clever tricks.
- Include a short README explaining your approach, trade-offs, anything you left out and what you would do with more time.
- Test edge cases and say which ones you considered.
- Respect the time guidance. Spending far longer than suggested rarely helps and can raise questions about how you work to deadlines.
Expect to discuss your submission in a later interview. Being able to explain your decisions, and to accept a better suggestion gracefully, often counts for as much as the code itself. Our guide to studio interviews covers this stage.
Building a code portfolio
Programmers are often told they do not need a portfolio. At junior level that is wrong: with no professional history, your own projects are the only evidence a lead has of what you can do.
What to include
- Two to four focused projects rather than many half-finished ones.
- At least one C++ project if you are applying to studios that use C++. A small engine-level system (a memory allocator, an entity component system, a simple software rasteriser, a physics integrator) shows depth.
- At least one playable game or feature showing you can make something that feels good, ideally in Unreal or Unity.
- Something matching your target specialism: a shader collection for graphics, a behaviour tree for AI, a client-server prototype for networking, an editor tool for tools roles.
- Team projects such as jam games or university group work, with your contribution clearly stated.
How to present it
- Host code on GitHub or a similar service, with a clean README for each repository: what it is, how to build it, a screenshot or GIF, and the most interesting part of the code to look at.
- Pin your best repositories and remove or archive old coursework that does not represent you.
- Add a short video for anything visual. Most reviewers will not clone and build your project.
- Write a one-page summary on a personal site linking everything together, with a sentence on what each project demonstrates.
- Point reviewers at specific files ("the pathfinding is in NavGrid.cpp"). It saves them time and shows you know what is worth reading.
Do and don't
- Do profile and optimise one thing and write up the before and after numbers from your own measurements.
- Do show tests, even simple ones.
- Don't list every language you have touched. Name the ones you could pass a test in.
- Don't submit tutorial projects unchanged; extend them with something original and say what you added.
Seniority and progression
Titles differ between studios, but the ladder for programmers usually looks something like this.
- Junior or graduate programmer. Works on well-defined tasks with review and guidance. The focus is learning the codebase and becoming reliable.
- Programmer. Owns features end to end, estimates their own work and needs less supervision.
- Senior programmer. Owns systems, makes technical decisions within an area, reviews others' code and mentors juniors. Judgement about what not to build becomes as important as building.
- Lead programmer. Leads a team or discipline on a project: planning, technical direction, hiring and people management alongside some hands-on coding.
- Principal or technical director. Two branches tend to appear at this level. Principal or expert roles stay deeply technical; technical director roles own the technology strategy for a project or studio.
Moving up depends less on time served than on scope: the size of the problems you can be trusted with and how much you raise the output of the people around you. If you want to compare how studios title and pay these levels, see games job titles explained and our salaries guide.
Moving in from other software work
Experienced developers from finance, web, embedded or defence often move into games. Backend, tools, build and online roles are the most natural fit, since the skills transfer directly. For gameplay or engine roles, build a small game or system in C++ to show you understand real-time constraints, and be ready for maths questions you may not have met in years.
Next steps
- Browse live programming jobs at UK studios.
- Starting out? See graduate and junior roles and our guide to graduate schemes.
- Many programming roles are open to remote or hybrid working: see remote games jobs and our remote work guide.
- Find out who is hiring on the studios page and where they are in our guide to UK games hubs.
- Get your application in shape with games CVs and cover letters.
- Search every live vacancy on the job board.