Can I Develop an A-Level Computer Science Project Using Unreal Engine 5?
Yes — But the Computer Science Must Be More Impressive Than the Graphics
One of the questions I increasingly hear from A-level Computer Science students is:
“Can I use Unreal Engine 5 for my programming project?”
The short answer is yes.
The more important answer is:
Yes — provided Unreal Engine is being used as a platform on which you build your own computational solution, rather than as a tool that builds most of the solution for you.
That distinction can make the difference between a visually spectacular project that demonstrates surprisingly little Computer Science and a relatively modest-looking game that provides excellent evidence for the NEA.
There is also some reassuring official guidance here. OCR specifically identifies Unity, Unreal and Defold as acceptable game engines. However, OCR also warns that students should not rely on built-in drag-and-drop scripting functionality for the assessed design and development. Its guidance emphasises a substantial coded solution using a textually derived high-level programming language.
AQA does not need the project to be a traditional business database either. Its guidance explicitly gives computer games, simulations, optimisation problems and artificial intelligence applications as possible project types.
So the problem isn't Unreal Engine.
The question is what the student actually programs inside it.
An Impressive Game Is Not Necessarily an Impressive Computer Science Project
This is probably the most important point for students to understand.
Imagine two projects.
Project A
A student creates a beautiful medieval arena.
There are animated horses, detailed knights, banners moving in the wind, realistic sunlight, spectators, sound effects and cinematic camera movements.
The horse movement comes from an existing controller.
The environment comes from an asset pack.
The animations come from an animation library.
The collision system is Unreal's.
The menus use a tutorial.
Most of the gameplay consists of connecting existing Blueprint nodes.
It might look extraordinary.
But there may actually be very little original Computer Science underneath it.
Now consider another project.
Project B
The graphics are considerably simpler.
However, the student has programmed:
- an opponent decision-making system;
- a tournament structure;
- a scoring algorithm;
- an impact calculation system;
- different armour characteristics;
- lance stability;
- player stamina;
- opponent personalities;
- persistent save data;
- rankings;
- dynamic difficulty;
- collision interpretation;
- data structures containing competitors and results;
- testing tools for examining the behaviour of the algorithms.
Project B might not make such an impressive YouTube trailer.
But as an A-level Computer Science project, it potentially contains far more that can actually be assessed.
That is the mindset I would encourage from the beginning:
Don't ask, “How impressive can I make Unreal look?”
Ask:
“What interesting computational problem can I solve using Unreal?”
Our Jousting Game: A Good Example
We have been developing a jousting game ourselves, and I think it provides an excellent example of how a game can be turned from entertainment into a genuine Computer Science problem.
Part of our teaching approach is to show students some of what we have developed, discuss why particular decisions were made and allow them to question how the systems work.
That can stimulate some very interesting conversations:
Why did the opponent choose that action?
How should a hit be scored?
Should a faster horse always produce a more powerful strike?
How do you represent the accuracy of the lance?
Should armour reduce damage?
What determines whether the rider remains mounted?
How should the computer-controlled opponent adapt to the player's behaviour?
Suddenly we have moved a long way beyond simply creating a knight riding towards another knight.
We have a computational modelling problem.
A tightly focused student project could therefore be something like:
“Design and development of a 3D jousting simulation incorporating player control, computer-controlled opponents, impact modelling, scoring, tournament progression and persistent results.”
That sounds rather different from:
“I made a jousting game.”
And that difference matters.
Start With the Problem, Not Unreal Engine
A common mistake is beginning the project proposal with:
“I want to use Unreal Engine 5.”
But Unreal isn't really the project.
It is the development environment.
A much better starting question is:
What problem am I trying to solve?
For our hypothetical jousting project, the problem could be:
To develop a system capable of simulating a jousting competition in which player skill, speed, aiming, defence and computer-controlled opponent behaviour influence the result of each pass.
Now we can begin identifying computational requirements.
For example:
Player system
The player must control:
- speed;
- lane position;
- lance position;
- aim;
- timing of bracing;
- defensive posture.
Opponent system
The computer might decide:
- how aggressively to attack;
- which target area to aim for;
- when to accelerate;
- whether to prioritise accuracy or power;
- how much defensive stability to maintain.
Impact system
The program might consider:
- relative speed;
- aim accuracy;
- target location;
- lance stability;
- armour;
- rider balance;
- previous damage;
- random variation.
Now there is plenty to program.
Turning Jousting Into Algorithms
Suppose several variables are represented on a scale from 0 to 100.
A simple model might begin with:
impactScore = speedFactor + aimAccuracy + braceTiming - defenderStability
That is probably too simplistic for the finished project, but it provides a starting point.
A more sophisticated version might use weightings:
impactScore = (relativeSpeed * 0.30) + (aimAccuracy * 0.30) + (lanceStability * 0.25) + (braceTiming * 0.15)
Then defence could modify the result:
finalImpact = impactScore - armourProtection - defenderStability
The interesting Computer Science comes from deciding how those values interact.
For example:
IF targetZone = "shield"damageMultiplier = 0.6ELSE IF targetZone = "torso"damageMultiplier = 1.0ELSE IF targetZone = "helmet"damageMultiplier = 1.3ENDIF
The student can then ask whether the algorithm produces believable results.
Perhaps the helmet is difficult to hit, so aiming accuracy must also influence the chance of success.
Perhaps an aggressive opponent sacrifices stability for speed.
Perhaps tired competitors become progressively less accurate.
That gives us another system:
effectiveAccuracy = baseAccuracy - fatiguePenalty
And perhaps:
fatiguePenalty = staminaUsed * 0.25
The particular numbers aren't the important part.
Designing, implementing, testing and improving the model is.
Opponent AI Is Particularly Valuable
A computer-controlled opponent gives the student considerable opportunity to demonstrate computational thinking.
It doesn't need ChatGPT-style artificial intelligence or a neural network.
A perfectly good opponent could use a finite-state machine.
For example:
READY|vACCELERATING|vAIMING|vBRACING|vIMPACT|vRECOVERY
Different opponents could have different characteristics.
One might be highly aggressive:
aggression = 90
accuracy = 55
defence = 40
Another might be cautious:
aggression = 45
accuracy = 80
defence = 85
The AI might then make decisions such as:
IF aggression > 70 AND opponentStamina > 50choose highPowerAttackELSE IF playerDefence > 75choose accuracyAttackELSEchoose standardAttackENDIF
We now have something that can be tested properly.
Does an aggressive opponent actually behave aggressively?
Does the cautious opponent win differently?
Can the player identify the opponent's strategy?
Does increasing aggression make the AI stronger, or simply more reckless?
Those are excellent evaluation questions.
Data Structures Suddenly Become Meaningful
Games are particularly useful because they naturally generate interesting data.
A competitor might be represented as an object or structure containing:
competitorIDnameskillaggressionaccuracystaminaarmourwinslossespointsranking
A tournament could then contain a collection of competitors.
The student may need algorithms for:
- sorting league positions;
- selecting tournament opponents;
- storing results;
- calculating rankings;
- searching competitors;
- loading saved games;
- updating statistics.
This provides natural opportunities to demonstrate arrays, lists, records or structs, classes, objects, functions, procedures and other techniques rather than trying to include them artificially simply because they appear in the specification.
What About Unreal Blueprints?
This requires some care.
Blueprints are tremendously useful. I would certainly not suggest avoiding them altogether.
They can be excellent for:
- connecting game systems;
- prototyping;
- animation events;
- interfaces;
- level behaviour;
- visualising state;
- linking coded systems to Unreal actors.
But for an OCR A-level NEA, I would be cautious about making Blueprints the main evidence of programming ability.
OCR's published advice specifically states that Unreal is acceptable but warns against reliance on built-in drag-and-drop scripting, saying this does not count towards design and development in the way the required coded solution does.
Therefore, for an OCR student using Unreal, a much safer architecture might be:
C++ — computational core
Use C++ for:
- impact algorithms;
- opponent AI;
- scoring;
- tournament management;
- data handling;
- rankings;
- save/load logic;
- stamina calculations;
- difficulty systems.
Blueprints — presentation and engine integration
Use Blueprints where appropriate for:
- triggering animations;
- connecting interface elements;
- cameras;
- sounds;
- visual effects;
- level events.
That also produces a very clean distinction in the report:
Unreal provided the 3D engine. The student programmed the game systems.
For AQA, students should likewise make sure the technical solution clearly demonstrates their programming skill. AQA's published guidance places particularly heavy emphasis on the programmed solution: its guidance allocates 42 of the 75 NEA marks to the technical solution.
Don't Reprogram Unreal Just to Prove You Can Program
There is an opposite mistake.
Students sometimes assume that using an engine means they must recreate everything themselves.
That isn't necessary.
There is little value in spending weeks writing a rendering engine when the interesting problem is opponent behaviour.
There may be no need to develop your own collision detection from first principles simply because Unreal contains one.
Instead, distinguish between:
engine functionality
and
student-developed functionality.
For example:
Unreal may detect that the lance collided with the opponent.
The student's program then decides:
- where the lance hit;
- how accurate the strike was;
- the relative speed;
- the stability of the lance;
- armour protection;
- impact score;
- points awarded;
- effect on balance;
- whether the rider is unhorsed.
That is a perfectly sensible division of responsibility.
Marketplace Assets Aren't Automatically a Problem Either
There is another misconception worth clearing up.
The student does not necessarily have to model every horse, knight, castle, lance and tree.
In fact, doing so could become a serious distraction.
If the project is being assessed as Computer Science rather than 3D art, spending twenty hours modelling a historically accurate saddle may contribute very little to the programming evidence.
Third-party graphical, sound or animation assets can therefore be extremely useful.
But they should be clearly acknowledged.
And students should be able to say:
“This asset isn't my work.”
while also being able to say:
“This algorithm is.”
AQA's assessment requirements similarly expect students to present their technical solution clearly enough for another person to discern the quality and purpose of their coding.
The Tutor's Demonstration Must Remain a Demonstration
There is an important issue for teachers and tutors here too.
If I show students our jousting game, I want them asking questions such as:
Why did you implement the opponent this way?
Could I do it differently?
What happens when you change this variable?
Why did you use a state machine?
What other algorithm could solve the problem?
That is educationally valuable.
But I would not want a student's NEA to become a slightly modified copy of our project.
The awarding bodies require authenticated, independent candidate work. OCR's current guidance reiterates that only independent candidate work should receive credit, while AQA's candidate documentation similarly requires submitted work to be the candidate's own.
So our finished system should be inspiration rather than a solution to copy.
A particularly useful teaching method is to demonstrate a problem, discuss possible solutions and then ask:
“How would you solve it?”
The student's answer may be completely different from ours.
That is exactly what we want.
Keep the Scope Under Control
Unreal encourages ambition.
That is both one of its strengths and one of its dangers.
A student starts planning:
- open-world medieval Britain;
- fifty castles;
- multiplayer;
- historically accurate physics;
- horse breeding;
- character customisation;
- destructible environments;
- weather;
- online tournaments;
- 200 opponents;
- voice acting;
- cinematic story sequences.
Six months later they have a beautiful castle entrance and no functioning tournament.
For an NEA, I would much rather see:
one arena, four opponents and five excellent computational systems
than:
an enormous medieval world containing dozens of unfinished systems.
OCR itself advises candidates to control projects with excessive scope and concentrate on something achievable within the available time.
What Could a Manageable Jousting NEA Contain?
A realistic version might have six major systems:
1. Player control
Speed, positioning, aiming and bracing.
2. Impact simulation
An original algorithm combining speed, accuracy, stability, armour and target zone.
3. Computer opponent
A state-based opponent capable of changing its behaviour.
4. Scoring
Points calculated according to successful strikes and outcomes.
5. Tournament management
Multiple opponents, progression, wins, losses and ranking.
6. Persistent data
Save and reload tournament progress.
That is already a substantial project.
Features such as weather, multiplayer and horse customisation can remain on a future development list.
Testing Becomes Much More Interesting Too
A good project should not simply demonstrate that pressing the Start button launches the game.
The algorithms themselves can be tested.
For example:
| Speed | Accuracy | Stability | Expected outcome |
|---|---|---|---|
| Low | Low | Low | Weak/inaccurate strike |
| High | Low | High | Powerful but likely miss |
| High | High | High | Strong successful strike |
| High | High | Low | Powerful but unstable |
| Medium | High | High | Controlled accurate hit |
Then investigate edge cases.
What happens if:
speed = 0
or:
accuracy = 100
or:
stamina = 0
or:
armour = 100
What if both riders are simultaneously unhorsed?
What if two competitors finish the tournament on identical points?
These aren't inconvenient problems.
They are opportunities to demonstrate good Computer Science.
The Report Should Explain Decisions, Not Just Show Screenshots
This is particularly important with Unreal.
Twenty screenshots of attractive medieval scenery prove very little.
A useful screenshot of a system accompanied by an explanation of:
- what problem it solves;
- what data enters it;
- what algorithm is used;
- why that algorithm was selected;
- what output it produces;
- how it was tested;
- what was changed after testing;
is much more valuable.
The student should effectively be able to defend every important piece of the system by answering:
“Why did you do it this way?”
That is a very good test of whether the project genuinely belongs to them.
Unreal Can Actually Lead to Some Excellent A-Level Projects
Used properly, Unreal Engine opens up some fascinating possibilities beyond the typical game.
A student could develop:
- a traffic simulation;
- an evacuation model;
- an autonomous vehicle simulation;
- a predator-prey environment;
- a crowd behaviour model;
- an airport management simulation;
- a robot navigation system;
- an ecological simulation;
- a projectile simulator;
- a procedural maze;
- an economic trading game;
- a logistics simulation.
The important word here is simulation.
Once students stop thinking of Unreal simply as something that produces beautiful games and start thinking of it as an interactive environment within which algorithms operate, its potential for Computer Science becomes much clearer.
So, Can You Get a Good A-Level Project Using Unreal Engine 5?
Absolutely.
But Unreal won't earn the marks for you.
In some ways, it can actually make the project harder because the student has to demonstrate clearly where Unreal ends and their own computing begins.
A strong project might therefore be described as:
Design and development of a rule-based 3D jousting tournament simulation incorporating player input, computer-controlled opponent behaviour, impact modelling, ranking, progression and persistent data.
The weaker description remains:
I made a jousting game in Unreal.
The distinction isn't just in the wording.
It reflects two completely different approaches to the project.
One concentrates on what the engine can do.
The other concentrates on what the student can program.
Final Thoughts: Let Unreal Provide the World — You Provide the Computer Science
I think Unreal Engine 5 can be an excellent choice for the right A-level student.
It is exciting. It feels relevant to modern software development. It gives students an immediate visual reward when their algorithms work, and it can make quite sophisticated computational ideas tangible.
But I would repeatedly remind students of one principle:
The examiner isn't assessing Unreal Engine 5. They are assessing you.
Let Unreal draw the knights.
Let Unreal render the arena.
Let Unreal handle the camera and lighting.
But make the opponent think because you programmed it to think.
Make the tournament work because you designed its data structures.
Make the impact calculation work because you developed and tested the algorithm.
And make sure you can explain every important decision.
For an A-level Computer Science project, a relatively small game containing substantial original programming, thoughtful algorithms and excellent testing is far more valuable than an enormous, gorgeous, half-finished 3D world.
Use Unreal Engine as the stage.
Make the Computer Science the performance.
