Building an A Level Platform Game Project — Final Part: Reviewing the Game, Improving Performance and Turning a Project Into Something Players Want to Play

By Philip M Russell Ltd – GCSE and A-Level Tuition

Over the last few articles, we have built up the idea of an A Level Computer Science platform game step by step.

We started with planning.
Then we created a game window.
Then we added movement.
Then gravity and jumping.
Then platforms and collision detection.
Then levels, routes, collectables and hazards.
Then enemies, moving hazards, lives, scoring, menus and high scores.

At this point, the project is no longer just a square moving on a screen.

It is a structured game.

But this final article asks a different question.

Not just:

“Would this score marks as an A Level project?”

But also:

“Would someone actually want to play it?”

That is a much more interesting question.

Because a good programming project is not only about code. It is about users, experience, performance, challenge, satisfaction and polish.

From Coursework Project to Playable Game

An A Level project needs analysis, design, development, testing and evaluation. A platform game can be an excellent project because it produces lots of evidence.

You can show:

user requirements
success criteria
design sketches
algorithms
code development
testing tables
screenshots
user feedback
debugging notes
evaluation against objectives

But a real game needs something extra.

It needs a reason for the player to care.

A technically working game may still feel dull if there is no atmosphere, progression, story, challenge or reward. The code may be correct, but the game may not yet be engaging.

That is an important lesson for students.

A program can function correctly and still not be a good product.

Reviewing the Whole Project

Before adding more features, students should review what they already have.

A useful review question is:

Does the game do what it was originally designed to do?

For example, the original aim might have been:

To create a 2D platform game where the player moves through levels, jumps between platforms, avoids hazards, collects items and reaches a finish point.

The student should then check whether the finished project includes:

working left and right movement
jumping and gravity
collision detection
platforms
levels
collectables
hazards
enemies or moving obstacles
lives
scoring
menus
restart options
win and lose conditions
testing evidence

This links the final evaluation back to the original plan.

That is exactly what an A Level project needs.

Performance: Does the Game Run Smoothly?

Performance matters.

A game can have good ideas but feel poor if it runs slowly, freezes, stutters or responds badly to input.

Students should test:

Does the game run at a steady frame rate?
Does the player respond immediately to key presses?
Do moving enemies behave consistently?
Are there too many objects on screen?
Does the game slow down when more enemies are added?
Does the high score file load without delaying the game?
Does the game crash if files are missing?

A simple platform game should not need huge processing power. If it performs badly, that may suggest inefficient code.

For example, a student might be checking too many collisions unnecessarily, loading images repeatedly inside the game loop, or drawing objects that do not need to be redrawn.

A useful improvement is to load resources once at the start of the program, not every frame.

Bad approach:


# Not ideal if repeated every frame
player_image = pygame.image.load("player.png")

Better approach:


# Load once near the start
player_image = pygame.image.load("player.png")

Then draw it each frame.

Small choices like this can make the game more reliable.

Code Quality: Can the Project Be Extended?

By the end of the project, students should ask:

Could another programmer understand this?

That is a serious question.

If the code is one huge block with hundreds of lines in the main loop, it may work, but it may be hard to maintain.

Possible improvements include:

using functions
using classes
using meaningful variable names
storing level data separately
removing repeated code
adding comments where helpful
grouping related code together
separating drawing, updating and collision logic

For example, instead of writing all enemy movement inside the main loop, students might create a function:


def update_enemies(enemies):
    for enemy in enemies:
        enemy["rect"].x += enemy["speed"]

        if enemy["rect"].left <= enemy["left_limit"]:
            enemy["speed"] = abs(enemy["speed"])

        if enemy["rect"].right >= enemy["right_limit"]:
            enemy["speed"] = -abs(enemy["speed"])

This makes the program clearer.

For stronger students, a class-based structure may be even better:


class Enemy:
    def __init__(self, x, y, speed, left_limit, right_limit):
        self.rect = pygame.Rect(x, y, 40, 40)
        self.speed = speed
        self.left_limit = left_limit
        self.right_limit = right_limit

    def update(self):
        self.rect.x += self.speed

        if self.rect.left <= self.left_limit:
            self.speed = abs(self.speed)

        if self.rect.right >= self.right_limit:
            self.speed = -abs(self.speed)

This is not essential for every project, but it shows a more advanced understanding of program structure.

Evaluation: What Worked Well?

The final evaluation should not simply say:

The game worked well.

That is too vague.

A stronger evaluation might say:

The movement system worked reliably after testing. The player could move left and right, jump, fall and land on platforms. The use of an on_ground Boolean prevented repeated jumping in mid-air. User testing showed that the first level was playable, although one platform had to be moved closer because the original jump was too difficult.

That is much better.

It refers to:

a feature
a technical solution
testing
user feedback
improvement

A good evaluation should be honest. It should mention strengths and weaknesses.

What Could Be Improved?

Every real project has limitations.

That is not a problem. In fact, recognising limitations is a strength.

Possible limitations might include:

collision detection works well from above but not perfectly from the side
graphics are basic
there are only two or three levels
enemies have simple movement patterns
sound effects are limited
there is no save system
the high score system only stores one score
there is no level editor
the game does not scale well to different screen sizes
there is no controller support
difficulty could be better balanced

Students should not pretend the project is perfect.

A strong evaluation explains what could be improved and how.

For example:

Side collision detection was not fully developed. In a future version, I would separate horizontal and vertical collision checks so that the player could not partially enter platforms when moving sideways.

That is thoughtful and specific.

The Player Experience: Is It Fun?

This is where we move beyond marks.

A game can be technically correct but not enjoyable.

Students should ask:

Is the objective clear?
Does the player understand the controls?
Is the first level too easy or too difficult?
Is there a reason to collect items?
Do hazards feel fair?
Does the player want to try again after losing?
Is the score motivating?
Does the game have a sense of progression?
Is there any personality or story?

This is where user feedback becomes very important.

It is not enough for the programmer to like the game. Other people need to play it.

A useful user testing question is:

“What made you want to continue playing?”

Another useful question is:

“At what point did you feel frustrated or confused?”

Those answers can tell the student far more than a simple pass/fail test.

Fancy Graphics Help — But Story Helps Even More

Students often think better graphics will automatically make a better game.

Graphics do help. A polished game looks more professional. Sprites, backgrounds, animations and effects can make the game feel more complete.

But graphics alone do not make a game engaging.

A simple storyline can make a huge difference.

For example, instead of:

Collect coins and reach the flag.

The game could become:

A small robot has lost power cells across an abandoned space station. The player must collect enough energy to reopen the escape hatch before the security drones catch them.

That is still the same basic platform game.

But now the player has a reason to care.

Collectables become power cells.
Enemies become security drones.
Hazards become broken electrical circuits.
The finish point becomes an escape hatch.
Levels become parts of the space station.

The code may hardly change, but the experience feels more complete.

Possible Story Ideas for a Simple Platform Game

Students do not need a huge novel-length plot. A simple theme is enough.

Possible ideas include:

1. The Lost Robot

A robot must collect missing circuit boards and escape a factory.

Collectables: circuit boards
Enemies: security drones
Hazards: electric sparks
Finish point: repair station

2. The Castle Escape

A character must escape a castle by collecting keys and avoiding guards.

Collectables: keys or gems
Enemies: guards
Hazards: spikes
Finish point: castle gate

3. The Science Lab Rescue

A student must collect experiment notes from a chaotic laboratory.

Collectables: notebooks
Enemies: runaway robots
Hazards: acid spills
Finish point: exit door

4. The Space Platform

An astronaut must repair a space station before oxygen runs out.

Collectables: oxygen canisters
Enemies: alien drones
Hazards: radiation zones
Finish point: escape pod

5. The Environmental Mission

A character collects recycling tokens and avoids pollution hazards.

Collectables: recycling symbols
Enemies: smoke clouds
Hazards: toxic waste
Finish point: clean-energy station

A theme helps connect the game elements together.

That is what makes the level feel less random.

What Might Sell a Game Like This?

A simple retro platform game could still appeal to players if it has a clear identity.

It would not compete with huge commercial 3D games on graphics. It would need to compete on charm, clarity and gameplay.

What might sell it?

simple controls
short levels
a clear theme
gradually increasing difficulty
satisfying jumping
fair hazards
replay value through scoring
a memorable character
a simple story
attractive retro graphics
good music or sound effects
level progression
challenge without frustration

Retro games can work because they are immediate. The player understands them quickly.

But they still need polish.

A player should not feel that the game is unfinished. They should feel that it is deliberately simple.

That is a big difference.

What More Coding Would Be Needed?

To move from an A Level project model to a more complete game, several areas could be developed.

1. Better Collision Detection

The current system may handle landing well, but a more polished game would need better side and ceiling collisions.

The program should separately handle:

landing on platforms
hitting walls
hitting the underside of platforms
moving with platforms
falling through one-way platforms
avoiding getting stuck in corners

This is one of the most important technical upgrades.

2. Better Level Management

A real game needs more than one level.

The project could be extended with:

multiple level dictionaries
external level files
level selection
automatic progression
locked levels
difficulty ratings
level completion tracking

A level editor would be an excellent advanced extension.

3. Improved Enemy Behaviour

Enemies could be developed beyond simple patrols.

Possible improvements include:

enemies that chase the player
enemies that jump
enemies that shoot projectiles
enemies that sleep until the player gets close
enemies with different movement patterns
enemies that can be defeated
boss-style challenges

Students should still be careful. Enemy behaviour can quickly become complicated.

4. Animation

Animation makes the game feel more professional.

The player could have:

standing frame
walking frames
jumping frame
falling frame
damage frame

Enemies could also be animated.

This does not necessarily change the game logic, but it greatly improves presentation.

5. Sound and Music

Sound gives feedback.

Useful sounds include:

jump
collect item
lose life
enemy collision
level complete
game over
menu selection

Music can add atmosphere, but it should not distract.

Students should also include a mute option if sound is used.

6. Save System

A more complete game might save:

high score
player name
unlocked levels
settings
progress

This introduces file handling and data validation.

It could make the project stronger if implemented carefully.

7. Accessibility and Usability

A real game should consider different users.

Possible improvements include:

adjustable difficulty
clear instructions
readable fonts
colour choices that are not confusing
keyboard remapping
pause screen
simple controls
restart option
sound on/off setting

This is often overlooked, but it is important.

8. Packaging and Distribution

If the game were to become a real product, it would need to be packaged.

Questions include:

Can it run without the development environment?
Are all image and sound files included?
Does it work on another computer?
Is there an installer or executable?
Are there instructions for running it?
Is there a version number?
Is there a bug list?

This takes the project beyond classroom development.

Turning Testing Into Real Playtesting

Project testing often checks whether features work.

Real playtesting asks whether the game feels good.

Both are needed.

Feature testing asks:

Does the player lose a life when touching a hazard?
Does the score increase when collecting an item?
Does the game over screen appear?

Playtesting asks:

Was the hazard fair?
Was the score motivating?
Did the jump feel responsive?
Did you want to play another level?
Was the story interesting enough?
Did the level feel too empty?

This is a useful distinction for students.

A feature can pass a test and still need improvement.

How Students Can Present the Final Project Well

For an A Level project, presentation matters.

Students should not simply submit code and hope the examiner understands it.

A strong project should include:

clear original aim
target user
success criteria
design sketches
level diagrams
algorithms
screenshots of development stages
testing tables
user feedback
evidence of changes
final evaluation
possible extensions

The best projects tell a story of development.

Not a fictional story — a project story.

It should show how the student moved from idea to prototype, from prototype to working mechanics, from mechanics to levels, and from levels to a more complete game.

Personal Reflection: The Best Projects Grow Carefully

When students first say they want to write a game, I usually feel both pleased and cautious.

Pleased, because games can motivate students.
Cautious, because games can easily become too ambitious.

A simple platform game is a good compromise.

It is visual, interesting and expandable, but it can still be controlled.

The key lesson is that good projects grow carefully.

One working feature at a time.

First movement.
Then jumping.
Then platforms.
Then collision detection.
Then levels.
Then hazards.
Then enemies.
Then menus.
Then scoring.
Then polish.

That is how real software grows.

Not by magic.
Not by one huge coding session.
But by planning, testing, fixing and improving.

Practical Final Evaluation Task for Students

Students should finish the project by writing a final evaluation.

They could answer these questions:

What was the original aim of the project?
Which success criteria were fully met?
Which success criteria were partly met?
Which features were not completed?
What were the main technical problems?
How were those problems solved?
What did user feedback show?
What changes were made after testing?
How well does the final game perform?
What would be improved in a future version?
What would be needed to turn this into a real game?
What did you learn from the project?

This creates a strong ending to the project.

It also helps students reflect properly rather than simply describe what they made.

Possible Final Extensions

If time allows, students might choose one or two final extensions.

Good extensions include:

a second or third level
saved high scores
animated sprites
a level editor
moving platforms
better enemy behaviour
sound effects
story screens
pause menu
difficulty settings
improved collision detection
external level files
player name entry
controller support

The key is not to add everything.

The key is to choose extensions that make sense for the project and can be tested properly.

Final Thoughts: From Marks to Meaning

This platform game series began as a model for an A Level Computer Science project.

That is still its main purpose.

A project like this can produce strong evidence for analysis, design, development, testing and evaluation. It gives students real programming problems to solve and plenty of opportunities to explain their thinking.

But the final lesson is bigger than coursework.

A game is not just a mark scheme.

A game is something a person experiences.

The player does not see the success criteria.
The player does not see the testing table.
The player does not see the development log.

The player sees the character, the level, the challenge, the story, the reward and the frustration when a jump is just slightly too hard.

That is why the best student projects think about both sides.

They work technically.
They are documented properly.
They also try to engage the player.

Fancy graphics help, but they are not enough. A good story, clear goals, fair challenge, smooth controls and a reason to try again can make even a simple retro platform game feel worthwhile.

That is the real achievement.

Not just building a program that runs.

Building a game that someone wants to play.

22 August 2026