What this subject family covers
Games and interactive media sits within film, animation and games, but its defining feature is that the audience acts and the work responds. That separates it from film and television production, where the maker controls the order and pace of what is seen, and from film studies, which analyses finished works. Animation and visual effects shares tools and skills with games art, but animation is usually rendered for playback rather than built to run in real time under a player’s control.
Courses in this family vary a great deal. Before writing, read the module descriptions of the courses you are applying to and work out where they sit. These are some common emphases, though course titles do not always match their content:
- Games design: rules, systems, levels, player motivation, difficulty, feedback and playtesting.
- Games development: building working games, often across design and production, and often in teams.
- Games programming: code, engines, mathematics, performance, gameplay systems and tools.
- Games art: characters, environments, props, concept art, 3D modelling, texturing and visual style made to work in real-time constraints.
- Interactive media: interactive work beyond games, such as installations, web experiences, interactive storytelling, apps and interfaces.
- Creative computing and creative technologies: code used as a creative medium, including generative art, sound and music technology, physical computing, sensors and hybrid physical-digital work.
You do not need evidence for every branch. A statement that tries to show strength in art, code, design and installation work at once usually ends up thin on all of them. Lead with the branch your courses emphasise. Mention others only where they connect to it.
Turning playing games into evidence
Enjoying games is the starting point for most applicants, so on its own it says very little. The difference lies in how you describe a game. A player says what they liked. A designer, artist or programmer explains how the game produced that effect.
Choose one or two specific moments and analyse their mechanics, not their plot. For example:
- How a game teaches a mechanic without a tutorial, and what that means for level layout.
- Why a difficulty spike felt fair or unfair, and which feedback (sound, animation, checkpoint placement) changed that.
- How a limited colour palette or silhouette design makes enemies readable at speed.
- What an economy or progression system rewards, and what behaviour it encourages in players.
- Why a particular control scheme feels responsive, if you can describe input timing or animation cancelling.
- For interactive media, how a museum touchscreen or web piece signals what can be touched or clicked.
Narrative is a legitimate interest, but write about it in interactive terms: how choice, environmental storytelling or player agency carry the story, not only what happens in it. Analysis that could equally describe a film suits film studies better.
Avoid lists of favourite titles, hours played, competitive rankings or claims that you have played games all your life. High-level play can show careful attention to systems. If you mention it, explain what it taught you about design, such as how balance changes altered strategies, rather than presenting skill as a player as a qualification.
Evidence by branch
Design
The strongest design evidence is something you made, tested and changed. Paper prototypes count. A board game or card game you built and played with friends can show design thinking as clearly as a digital one, because rules, balance and player behaviour are the same concerns. Useful reflection names a specific problem, what players actually did, and what you changed. For example, testers might have ignored an optional rule, or one strategy might have dominated. Free tools such as Twine for interactive fiction, or the level editors built into many games, are accessible starting points. Design documents with no playtesting behind them demonstrate much less.
Programming
Describe what you built and the specific technical problem you solved: collision behaving oddly, an enemy pathfinding badly, frame rate dropping. Say how you worked out the cause. Naming an engine or language matters less than showing you understand what your code was doing. Following a tutorial is a reasonable start. Say honestly what you added or changed beyond it, because a finished tutorial project mainly shows you can follow instructions. If you study maths or physics, connect it to concrete uses such as vectors for movement, trigonometry for aiming or rotation, and matrices in 3D transformation, but only where you have actually met these.
Art
Show awareness that game art has to function as well as look good. Silhouettes must read during play, environments guide the player, and assets have limits on polygon count and texture size. Traditional drawing, life drawing and observational study are relevant foundations. Say what you learned about form, anatomy, lighting or colour, and how it applies to game assets. If you model in 3D, describe a decision you made for the asset’s in-game use, not just the software you used. Fan art can show technique, but original designs show more about your own visual thinking. Your portfolio will carry much of the visual evidence, so use the statement to explain the thinking behind your work.
Interactive media, creative computing and creative technologies
These courses usually value interest in interaction beyond entertainment games. Evidence might include a website or interactive piece you built, generative visuals made with Processing or p5.js, a microcontroller project using sensors, an interactive audio piece, or close attention to interfaces and installations you have encountered. Reflect on the relationship between the person and the system: what they understood, where they got confused, and what the work did in response. If your interest is mainly in game titles, check that these courses fit you rather than a games-specific degree.
Game jams, mods and team projects
Game jams are short events, often online and free, where people make a game to a theme within a time limit. They suit this subject well because they force you to cut scope, finish work and often collaborate. Do not just say you took part. Explain what you cut to finish on time, what your role was, and what went wrong. Mods and custom levels for existing games show you can work within someone else’s systems, and player feedback on shared work gives you real reflection material. Be accurate about your role in team projects. Claiming credit for a whole game when you made the music or the menus undermines otherwise good evidence.
If you have no directly relevant experience
Many applicants have not made a game. Ordinary experience can still be relevant if you connect it precisely and do not overstate it.
- Computing, maths or physics at school: these support programming and creative computing. Name a specific topic or project and how it relates to interactive systems. They show readiness for the technical side, not design ability.
- Art, design and technology, or graphics coursework: these support art and design branches. Describe your process of iteration and response to critique. They show visual and making skills, but not real-time constraints unless you address those.
- Drama, music or creative writing: these can support narrative design, interactive storytelling and audio, through timing, pacing and audience response. Their limit is that the audience does not change the outcome, so say how interactivity would alter the work.
- Running tabletop games for friends: this is genuine evidence of adapting a system to players in real time, and close to design work. It shows design thinking, not digital production skills.
- Retail, hospitality or customer-facing jobs: these can give you observations about how people misread signs, instructions or self-service machines, which matter in interface and interactive media design. Use one precise observation. A job does not show game skills in itself.
- Teaching or helping younger siblings, or caring responsibilities: watching someone else learn a game, app or device can show you how people learn controls and where they get stuck. This is relevant to onboarding and accessibility, provided you describe what you noticed rather than presenting it as user research.
- Volunteering with clubs or libraries: helping at a coding club or a games session can give you specific observations about how beginners learn. The value is in what you observed, not in your attendance.
If you have time before applying, one small finished piece is worth more than plans for a large one. That might be a one-room Twine story, a single playable level, one modelled prop, or a sketch in p5.js. These are suggestions, not requirements. A small, honest, well-reflected project is better than an ambitious project you describe only vaguely.
What useful reflection looks like
Strong reflection in this subject tends to follow a cycle: what you intended, what players or users actually did, why the gap existed, and what you changed. Weak versions of the same material look like this:
- Saying a project taught you a lot without naming one specific thing.
- Listing software (Unity, Unreal, Blender, Photoshop) with no account of what you made in it.
- Describing a game you plan to make as if it already shows ability.
- Saying people loved your game, rather than describing how they played it.
Consider including one failure in detail. A mechanic that testers found boring, an asset that looked wrong in the engine, or a bug you could not fix all show you understand that this work is iterative.
Pitfalls specific to this subject
- Confusing the degree with a job title. Saying you want to become a lead designer at a named studio says little about what you want to study. Focus on the problems and techniques that interest you.
- Defending games as a medium. Defensive arguments that games are art, or that they are not a waste of time, take up space that could hold evidence.
- Ignoring the collaborative and constrained nature of the work. Writing as though you will realise a personal vision unchanged can read as unaware of how games are made, through scope limits, team roles and iteration.
- Drifting into a neighbouring subject. Long passages about cinematography, plot or film suggest film studies or production. Pure rendering or showreel ambitions suggest animation and visual effects. Keep the focus on interactivity.
- Mismatching branch and evidence. An art-focused statement for a programming-heavy course, or the reverse, can suggest you have not checked the course content.
- Overstating informal work. A published hobby project does not make you an indie developer, and modding does not equal industry experience. Describe what you actually did.
For general advice on planning, structure and editing, read our personal statement writing guide.