Game studios hire from portfolios, but a portfolio never reaches a hiring manager on its own. It travels inside a resume, through an applicant tracking system (ATS) that reads text, not builds, and past a recruiter who may not know the difference between a shader and a sprite. Plenty of talented developers lose at that stage: the itch.io page is great, the resume is a wall of project names with no engine keywords, no platforms, and no numbers.

This page gives you a complete game developer resume example, a breakdown of why each section works, and the thing most resume guides skip: how Unity/C# postings and Unreal/C++ postings ask for different things, and how to write a version for each instead of one blurry resume for both.

Your resume has two readers, and they want different things.

The first is a recruiter or an ATS filter. This reader scans for exact terms: the engine, the language, the platform, sometimes a specific system like multiplayer or UI. If the posting says "Unity" and "C#" and your resume says "built games in a popular cross-platform engine," you lose a match you had earned. Matching the posting's vocabulary is not gaming the system, it is translation. Our guide to ATS resume keywords covers the mechanics.

The second reader is an engineering lead or senior developer, and they are skeptical by default. Every applicant lists an engine. What this reader looks for is evidence you shipped: a title that reached players, a frame budget you hit, a memory problem you found with a profiler and fixed. One quantified performance bullet is worth five lines of "passionate about creating immersive experiences."

A strong game developer resume satisfies both readers on one page: exact keywords for the filter, shipped titles and measurable performance work for the human. The example below shows what that looks like in practice.

This example is built for the most common profile in game dev hiring: a Unity developer with a few years of experience, a shipped mobile title, and a PC project. Notice three choices as you read it. The shipped titles are impossible to miss. The bullets lead with results, and the results are performance numbers, not feature lists. And the skills section uses the exact terms postings use, grouped so a recruiter can verify a match in seconds.

The header does one job beyond contact details: it puts your portfolio and GitHub one glance away, written out as visible text rather than hidden behind an icon or the word "portfolio." Some ATS exports strip hyperlinks, and a printed or plain-text version of your resume should still lead to your work. If your GitHub actually contains readable game code, feature it; if it is a graveyard of empty tutorial repos, clean it first. Here is where and how to include a GitHub link so it helps instead of hurts.

Match your header title to the role family you are targeting. "Game Developer (Unity / C#)" tells both readers what you are in half a second. "Software Engineer" makes a game studio recruiter work to figure out whether you fit, and they usually do not.

Three lines, four facts: your engine and language, your years of experience, your strongest shipped credit, and the thing you are best at. "Unity developer with 4 years of experience and 2 shipped titles, specialized in mobile performance optimization" beats any paragraph about passion. If the summary could describe a thousand other applicants, rewrite it until it can only describe you.

Do not bury shipped games inside job descriptions. Give them their own section near the top, one line per title with the platform, year, and your specific role. A hiring lead who sees a Shipped Titles heading relaxes immediately, because shipping is the hardest signal to fake. The full format is covered later on this page.

Every strong bullet in the example follows the same shape: what you did, in which system, with what measurable outcome. "Implemented gameplay features in C#" says nothing. "Cut average load time on mid-tier Android devices from 11s to 4s by moving asset loading to Addressables and async scene loading" says everything: the tool, the platform, the judgment, the result. Not every bullet needs a number, but every job entry needs at least one that has one.

Group skills into Engine, Languages, and Tools so a recruiter can verify the posting's requirements line by line. Use the posting's exact spelling: if it says "Unity3D," include that form. And list only what you can defend in a technical screen, because a game dev interviewer will pick the most obscure item on your list and ask about it.

An Unreal-focused resume is not the Unity resume with the engine name swapped. The vocabulary, the expected specialization, and even the version control system change. If you have real Unreal experience, make these substitutions:

If you genuinely work in both engines, still pick a lead for each application. A resume that gives Unity and Unreal equal billing tends to read as shallow in both to a specialist reviewer. Put the posting's engine first and let the other appear as a supporting credit.

Read enough game developer postings and the split becomes predictable. The two ecosystems ask for different languages, different performance vocabulary, and different team contexts, which is exactly why one generic "game programmer resume" underperforms against both. Here is how the requirements typically diverge:

The practical takeaway: maintain two resume versions, one per engine lane, each using its lane's vocabulary top to bottom. This is exactly the base resume and tailored versions pattern: a master resume per target, and a tailored copy per application. Roleframe's role workspaces exist for this case, and its per-job fit report will show you which engine keywords a specific posting filters on and which ones your resume is missing, before you apply rather than after the rejection.

This is where game developers struggle most, because the real work lives in builds and videos and an ATS reads neither. The fix is to translate the portfolio into structured text the resume can carry.

One line per title, then one line of your contribution. Include the platform and year because they answer the reviewer's first two questions, and include team size because "solo" and "team of 40" mean opposite things about your role. A clean entry looks like: game name, studio, platform, year on the first line; your role and a single concrete contribution with a result on the second. If a title has public traction you can verify, such as a store rating or a download milestone the publisher has announced, include it. Never guess at a number you cannot back in an interview.

Rename the section Projects and apply the same discipline. Game jam entries are legitimate credits: a finished Ludum Dare or GMTK Jam game proves you can scope and ship under a deadline, which is the exact skill studios worry juniors lack. An itch.io release with real players beats a polished tech demo nobody ran. A vertical slice is fine if you describe the systems you built rather than the game you imagined. The rules in our guide to listing coding projects on a resume apply directly: fewer projects, described deeper, each with a link and a result.

What to cut: tutorial follow-alongs, unfinished "dream game" projects with nothing playable, and asset flips. A reviewer who clicks one weak link stops clicking.

Here is the quiet truth about game programmer hiring: everyone lists the engine, almost nobody proves they can ship inside a frame budget. Performance and memory work is the strongest differentiator available to you, because it is measurable, it is hard to fake, and it maps directly to what senior engineers spend interview time probing.

Name your tools: Unity Profiler, Frame Debugger, Memory Profiler, RenderDoc on the Unity side; Unreal Insights, stat commands, and platform profilers like PIX on the Unreal side. Then attach each tool to an outcome. Sample bullet shapes worth adapting to your own numbers:

These are templates, not claims to copy. Use your own numbers, and only numbers you measured, because a performance bullet is the first thing a game dev interviewer will drill into. That drill-down is good news: it moves the interview onto ground you prepared.

The same experience should be framed differently depending on who is reading. AAA studios hire specialists into large codebases; indie teams hire generalists who can ship a whole game. Reorder and reweight accordingly.

For a AAA application, lead with your deepest specialization and name it in your title line: gameplay programmer, tools programmer, graphics programmer. Emphasize C++ where you have it, work inside existing large codebases, code review culture, Perforce, and any console platform experience including certification requirements. Compress your solo projects to a line or two; a AAA lead reads a long solo-project section as a signal you have not worked at scale.

For an indie application, invert it. Lead with full-cycle shipping: you scoped it, built it, put it on a store, and supported it after launch. Breadth is the asset here, so bullets covering gameplay plus UI plus build pipeline plus store submission tell an indie founder you can carry weight across the whole project. Live-ops and player-facing results, like retention improvements after an update you shipped, land harder than architecture talk.

Same career, two resumes. Keep both as maintained versions rather than rewriting from scratch each time, and check each against the specific posting before you send it. If you are running many applications in parallel, our guide on managing multiple resumes for different career paths shows a system that does not collapse at application twenty.

Game developers have strong opinions about tools, so here is the straight version. Most "free" resume builders let you build the whole document and then gate the download behind a signup wall, a watermark, or a trial. If you have been burned by that pattern, the export paywall trap is well documented.

Roleframe's free resume builder skips it: the full drag-and-drop editor, every template, and an unwatermarked PDF download with no account and no card. The PDF matches the editor exactly, which matters when your header carries portfolio URLs that must survive export intact. Build the Unity version, duplicate it, rework it into the Unreal version, and submit both as PDF. Always PDF, unless a specific studio's system explicitly demands otherwise; it is the format that preserves your layout everywhere.