A game developer resume should connect your engine and language experience with the systems you built, tested or maintained. A portfolio adds useful detail, but the resume should still explain your contribution when the reader has not opened the project.

This guide uses a fictional Unity and C# example, explains how to present Unreal experience accurately, and shows how to check a performance claim before adding it to a bullet. It does not assume every studio requires a commercial release or the same toolchain.

For a selected project, identify the engine, platform, system and your own contribution. “Implemented the inventory save/load flow in Unity and added tests for missing save files” is more specific than “worked on gameplay,” even without a performance number.

Name relevant tools accurately and explain unfamiliar project names. The keyword guide can help compare language with a vacancy; it cannot establish hidden screening rules.

Choose evidence for the actual duties. Gameplay, tools, rendering, networking and UI work can require different examples. Do not force every application into a single story about optimization or shipped titles.

Kenji Watanabe, the studios, education, training, award and project titles below are fictional teaching details. The timeline begins in 2019. These are not verified commercial credits or evidence of an applicant’s hiring results.

The example describes gameplay implementation, test builds and profiling work without invented player counts, crash rates or speed improvements. Replace every detail and placeholder link. Skill ratings in the layout are illustrative, not certified proficiency levels.

Match relevant requirements with actual systems and tools used. Training, personal projects and professional work can all be described, with their setting clear.

A keyword comparison may reveal terminology worth clarifying. Do not add an engine, subsystem or language solely because the vacancy names it.

Provide readable portfolio or repository links and test them from the final document. A useful project page explains your contribution, how to view the work and any access requirements. Link only material you are allowed to share.

A target-role headline may clarify your focus; keep employment titles accurate. “Game developer — Unity and C#” is a focus statement, not a reason to rename a previous job.

A short summary can connect your actual engine experience with the systems relevant to the vacancy. The sample mentions gameplay, UI, build tools and profiling. It does not need a commercial title, a fixed number of lines or an unsupported claim of specialization.

Use a separate project or title section when it helps the reader. Label a prototype, jam entry, student project or released product accurately. A commercial release is useful context when true, but it is not required for every applicant or every section.

Explain what you changed and how you checked it. In the fictional sample, a save/load component includes missing-file and invalid-data checks. That is more informative than adding a made-up load-time improvement.

Include measured results when available and relevant. No rule requires at least one numerical performance result in every job entry.

Group tools if that improves readability, and name the actual products or languages. Do not relabel C# as C; they are different languages. Separate course exposure, prototype use and production experience where the distinction matters.

An Unreal-focused application should draw on real Unreal work. Epic’s Blueprint and C++ guidance says a project can use either or both, with the choice depending on context. Blueprint experience is not automatically irrelevant to a development role, and it does not establish C++ fluency.

If you work with both engines, select examples relevant to the vacancy. There is no evidence here that giving both engines space makes you appear shallow. Depth comes from the contribution you can explain, not hiding useful experience.

This table is a planning aid for your own experience, not a survey of current job postings. It avoids treating engine choice as a reliable proxy for studio size or specialization.

Maintain a source record of projects, then choose the relevant evidence for each application. Roleframe can help compare a posting with a draft, but a fit report does not reveal the studio’s private screening rules. Review every suggested change for technical accuracy.

A portfolio entry should make the work reviewable without expecting someone to install an unexplained build. Include a short description, your contribution, status and an appropriate demonstration or code link. Provide prerequisites and controls if sharing a playable build.

Use the project name, platform, dates and status, followed by your contribution. Add team context when useful, but team size alone does not establish your responsibility. Distinguish your code, teammates’ work and licensed or third-party assets.

Fictional example: “Ridge exploration prototype — PC, personal project. Implemented scene-loading failure handling and tested repeated transitions.” It makes no claim to a store release or player adoption.

For a real released title, link an authorized public page and keep any commercial figures sourced and dated. Do not share private source code, unreleased features or internal platform requirements.

Use projects, coursework or jam work with the setting labelled accurately. Explain what you built and tested, rather than assuming a release count is necessary. A technical demo may be relevant for a specialized vacancy even when it has no public players.

If work began from a tutorial, identify the starting point and your additions. Do not present tutorial code or purchased assets as wholly original work. An unfinished project can still demonstrate a completed subsystem when its limitations are clear.

Performance work can be useful evidence when it matches the role. Record the device, build, scene, settings and measurement method before comparing results. Unity documents profiling on a target platform to collect realistic application measurements.

Describe the measured quantity precisely. Frame time, average frame rate, peak memory, allocation rate and crash-free sessions are different measures. A tool name alone does not validate a causal claim or show that the result holds across all devices.

Hypothetical calculation: reducing the same measured frame-time statistic from 20 ms to 16 ms is a 20% reduction: (20 − 16) ÷ 20. It does not by itself prove stable 60 FPS across a game, and a percentage change in frame time is not the same percentage change in FPS.

A faithful bullet needs the actual test conditions and your change. If you investigated a problem without a reliable before-and-after result, say what you diagnosed, tested or documented instead of inventing a percentage.

Large and small teams can hire specialists or people with broader responsibilities. Read the role’s tasks before deciding which experience to emphasize. A tools vacancy may benefit from editor utilities and build workflows; a gameplay opening may call for feature implementation and testing.

Show collaboration, code review, delivery or independent work when relevant and true. Do not assume solo projects disqualify someone from a large studio or that every indie role requires full-cycle publishing.

Keep technical claims consistent across versions. You can change emphasis without changing what you built, the language used or the release status.

If using Roleframe, start with your own project record or replace the fictional sample. Check imported text, dates, language names and links. Reject AI suggestions that invent shipped titles, metrics, certification or ownership.

Use a format the studio accepts, inspect the exported document and test its links. A PDF does not guarantee correct layout or parsing in every system; check uploaded fields and previews when available.