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_groundBoolean 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.
