A Level Computing Projects: Why a Retro Platform Game Might Be the Perfect Place to Start

Every year, when A Level Computer Science project season begins, students arrive with big ideas.

Very big ideas.

A fully 3D open-world game.
A multiplayer online battle system.
A PlayStation-style adventure.
A physics-based driving game.
A first-person shooter with realistic graphics, enemies, weapons, levels, menus, sound effects, online scoring and perhaps a little bit of artificial intelligence thrown in for good measure.

The ambition is wonderful. It is also usually completely unrealistic.

That is not because the students are not capable. It is because many students have played modern games for years without ever seeing how much work sits underneath them. A game that feels simple to play may involve teams of artists, programmers, sound designers, testers, level designers, animators and project managers.

An A Level project is not about building the next commercial games franchise. It is about producing a well-planned, well-documented, achievable piece of software that solves a defined problem and allows the student to show evidence of analysis, design, development, testing and evaluation.

Last year, I wrote a series of blog articles on building a text adventure game. Several of my students used the ideas, adapted them, and created their own versions. It worked well because a text adventure has structure, logic, data, choices, files, testing and plenty of scope for extension without needing complex graphics.

This year, we are going to move one step further.

We are going to look at building a simple retro-style platform game.

Not the latest console blockbuster. Not a 3D world with cinematic cut-scenes. A simple 2D platform game: a player, platforms, gravity, jumping, hazards, scoring, levels and a clear objective.

Retro, yes. Simple, no.

A platform game is a brilliant A Level project idea because it looks achievable, but it quickly introduces some very serious programming problems.

And that is exactly why it is worth doing.

Why Students Often Start With the Wrong Game Idea

When students first suggest writing a game, they often describe the game from the player’s point of view.

They talk about the world, the characters, the powers, the enemies, the graphics and the story. They describe what they want it to feel like.

That is natural. It is how players think.

But programmers have to think differently.

A programmer has to ask:

How will the character move?
How will the program know when the character lands on a platform?
How will gravity work?
What happens when the player hits the side of a wall?
How are levels stored?
How is the score calculated?
How will the program know when the game is over?
How will testing be recorded?
How will the project be extended without becoming impossible?

This is where many students begin to see the difference between an idea and a project.

A Level project work needs more than enthusiasm. It needs structure.

Why a Platform Game Is a Good Compromise

A retro platform game sits in a useful middle ground.

It is more visual and exciting than a text-only program, but it does not require the impossible workload of a modern 3D game.

A good simple platform game can include:

• a player character
• left and right movement
• jumping
• gravity
• platforms
• hazards
• collectable items
• a score system
• multiple levels
• enemies or moving obstacles
• a menu screen
• saved high scores
• difficulty settings
• user testing and feedback

That gives the student plenty to write about in the project documentation.

It also gives the student real programming challenges. The project is not just about drawing something on the screen. It involves logic, problem-solving, data handling, algorithms and testing.

That is what makes it useful.

Start With the Simplest Possible Version

The biggest mistake is trying to build the finished game first.

A better approach is to build the smallest possible version of the game and then improve it gradually.

The first version might have:

• a square representing the player
• one flat platform
• basic left and right movement
• a simple jump
• gravity pulling the player down

That is enough for the first prototype.

No enemies.
No music.
No story.
No menu.
No beautiful graphics.
No complicated level design.

Just movement, gravity and landing.

It may look unimpressive, but it contains the foundation of the entire game.

Once the player can move, jump and land properly, the project can grow.

The First Real Problem: Movement

Movement sounds easy.

Press the right arrow, move right.
Press the left arrow, move left.

But even this raises questions.

Should the player move at a constant speed?
Should movement feel instant or gradual?
Can the player change direction in mid-air?
Should there be acceleration?
Should the player stop immediately when the key is released?

For a simple first version, the player might move a fixed number of pixels each frame. That is enough to get started.

Later, the student can improve this with velocity, acceleration and friction.

This creates an excellent development trail for the project write-up. The student can show how the first version worked, what its limitations were, and how later versions improved the behaviour.

That is exactly the kind of evidence A Level projects need.

The Second Problem: Gravity

Gravity is where the game starts to feel like a platform game.

Without gravity, the character simply moves around the screen. With gravity, the player falls, lands and jumps.

A simple gravity system might work like this:

• the player has a vertical velocity
• gravity increases the downward velocity each frame
• when the player jumps, the vertical velocity is set upwards
• as gravity continues to act, the player slows, stops, then falls
• when the player touches the ground, the vertical velocity returns to zero

This gives students a chance to use physics-style thinking in programming.

It also teaches an important lesson: games are often built from approximations. We do not need a perfect model of real-world gravity. We need a model that feels right and works reliably.

The Third Problem: Collision Detection

Collision detection is one of the most important parts of a platform game.

The program must know when the player touches a platform, hits a wall, falls off the screen, collects an item or collides with an enemy.

At first, students often think this will be simple.

Then they discover the awkward cases.

What happens if the player lands on the top of a platform?
What happens if the player hits the underside of a platform while jumping?
What happens if the player hits the side of a wall?
What happens if the player moves so quickly that they pass through a thin platform between frames?
What happens at corners?

This is where a “simple” platform game becomes a proper programming project.

A good starting point is rectangle collision detection. The player can be represented as a rectangle. Platforms can also be rectangles. The program then checks whether the rectangles overlap.

That is not perfect, but it is a very good place to begin.

The Fourth Problem: Level Design

Once movement and collision detection work, the next question is how to create levels.

The simplest version might hard-code a few platforms into the program.

For example:

Platform 1: x = 0, y = 500, width = 800, height = 40
Platform 2: x = 200, y = 400, width = 150, height = 20
Platform 3: x = 450, y = 320, width = 150, height = 20

That works for a prototype.

But for a stronger project, students can think about better ways to store level data.

Could levels be stored in a list?
Could they be loaded from a file?
Could a level editor be created?
Could different levels have different themes, hazards or difficulty?

This is where the project becomes much more interesting from an A Level point of view.

The student is no longer just writing a game. They are designing a system.

The Fifth Problem: Keeping the Scope Under Control

A platform game can grow very quickly.

Once the basic game works, students often want to add everything.

Enemies.
Power-ups.
Moving platforms.
Ladders.
Water.
Doors.
Keys.
Boss fights.
Multiple characters.
Sound effects.
Animation.
Menus.
Saving.
Online leaderboards.

Some of these are good extensions. Too many of them become a problem.

A successful A Level project needs a clear scope. The student should decide what is essential, what is desirable and what is only an extension if time allows.

A sensible feature plan might look like this:

Essential Features

• player movement
• jumping and gravity
• platforms
• hazards
• score
• win and lose conditions
• at least two playable levels

Desirable Features

• collectable items
• moving enemies
• start menu
• high score table
• basic sound effects

Extension Features

• level editor
• multiple characters
• animated sprites
• difficulty settings
• saved progress
• user-created levels

This helps the project stay achievable.

It also gives the student something valuable to discuss in the evaluation: what was completed, what changed, what worked and what could be improved.

Why Documentation Matters as Much as the Code

Many students think the project is mainly about programming.

It is not.

The programming matters, of course, but the marks also depend heavily on the evidence around the programming.

Students need to show:

• what problem they are solving
• who the users are
• what success criteria they set
• how the program was designed
• how the program was developed
• how problems were solved
• how testing was carried out
• how feedback was used
• how the final project was evaluated

A simple but well-documented project can often be stronger than an overambitious project that is unfinished and poorly explained.

This is why a platform game can work well. It gives the student visible progress, clear testing opportunities and plenty of technical problems to discuss.

Practical Example: A First Week Target

For the first week, the target should not be “make the game”.

That is too vague.

A better first-week target could be:

Create a basic game window with a player block that can move left and right, fall under gravity, jump from the floor, and land without falling through it.

That is a proper target.

It can be tested.

The student can record:

• what keys control the player
• whether movement works
• whether gravity works
• whether the player lands correctly
• whether jumping feels too high or too low
• what happens at the edges of the screen
• what bugs were found
• what changes were made

This is how the project evidence begins.

The Hidden Teaching Value of a Platform Game

A platform game teaches much more than game design.

It teaches students how to break a problem down.

It teaches iteration.
It teaches testing.
It teaches debugging.
It teaches planning.
It teaches the danger of overcomplicating a project too early.
It teaches students to separate what they want from what they can realistically build.

That last lesson is one of the most important.

A Level Computer Science projects are often the first time students have to manage a large piece of independent software development. They need to make decisions, justify those decisions and cope when the first version does not work.

A platform game will certainly produce bugs.

The player will fall through the floor.
The jump will feel wrong.
The character will get stuck in platforms.
The score will not reset properly.
The collision detection will behave strangely at the edges.
The levels will be too easy or impossible.

That is not failure.

That is the project.

What We Will Cover in This Series

This blog is the starting point.

Over the next few weeks, we can develop the idea step by step, looking at how a simple platform game can be designed, built, tested and improved.

Possible articles in the series include:

1. Planning the platform game and setting realistic success criteria
2. Creating the game window and player movement
3. Adding gravity and jumping
4. Building platforms and collision detection
5. Designing levels and storing level data
6. Adding hazards, enemies and collectables
7. Creating scoring, lives and win conditions
8. Testing the game properly
9. Improving graphics, sound and user experience
10. Writing up the project for A Level evidence

Each article can focus on one manageable part of the project.

That is exactly how students should approach the work itself: one problem at a time.

Final Thoughts: Retro Does Not Mean Easy

A retro platform game may look simple, but it contains many of the same ideas found in much larger software projects.

There is user input.
There is data.
There is logic.
There are rules.
There are errors to find.
There are design decisions to justify.
There is testing to record.
There is evaluation to write.

That makes it a very useful A Level project idea.

The aim is not to build the next PlayStation or Xbox game. The aim is to build something achievable, expandable and well understood.

A simple platform game can start with one square jumping on one platform.

From there, it can become a proper project.

And that is where good Computer Science begins: not with the biggest idea, but with the first working version.