Building an A Level Platform Game Project — Part 1: Planning the Game and Setting Realistic Success Criteria
Every good programming project starts with an exciting idea.
Every successful A Level Computer Science project starts with a controlled idea.
That distinction matters.
When students say they want to write a game, they often imagine the finished product first: animated characters, moving enemies, several levels, sound effects, menus, high scores and perhaps even a storyline. That is a perfectly natural way to think as a player. It is not the best way to think as a programmer.
For this project series, we are going to build a simple retro-style platform game. The aim is not to create the next commercial console game. The aim is to produce a working, expandable, testable game that could be used as a model for an A Level project.
This first article is about planning.
Before we write a single line of code, we need to decide what the game is, what it will do, what it will not do, how success will be measured and how the student can collect evidence along the way.
That planning stage may not feel as exciting as making a character jump across the screen, but it is one of the most important parts of the whole project.
Why Planning Matters Before Programming
Many students are tempted to start coding immediately.
They open Python, Pygame, JavaScript, Unity, Godot or another development environment and begin experimenting. There is nothing wrong with experimentation, but it is not the same as a planned project.
A Level project work needs evidence. It needs to show that the student has thought about the problem, considered the user, designed a solution, tested it and evaluated the final outcome.
A game project is not marked simply because it looks fun. It needs to show computational thinking.
That means the student must be able to explain:
what the game is intended to do
who the game is for
what the main features are
which features are essential
which features are optional
how the game will be tested
what makes the project successful
how the design changed during development
Without planning, the project can quickly become a collection of half-finished features.
With planning, even a simple game can become a strong piece of evidence.
The Basic Game Idea
The project we are going to design is a simple 2D platform game.
The player controls a character who can move left and right, jump onto platforms, avoid hazards, collect items and reach an end point.
The game will be retro in style. That is deliberate.
A retro-style game allows us to focus on programming rather than complex artwork. The graphics can begin as coloured rectangles or simple sprites. The technical challenge will come from the movement, gravity, collision detection, level design, scoring and testing.
A simple project description might be:
The aim of the project is to create a 2D platform game in which the player controls a character, moves through levels, jumps between platforms, avoids hazards, collects points and reaches a finish point. The game will include increasing difficulty, clear win and lose conditions, and a scoring system.
That is clear, achievable and expandable.
It gives us enough to build a good project without becoming impossible.
What the Game Is Not
This is just as important as deciding what the game is.
The game is not:
a 3D game
an online multiplayer game
a realistic console-style game
a huge open-world adventure
a game with dozens of levels
a project mainly about graphics
a project copied from a tutorial without understanding
This matters because students often lose control of projects by adding too much too early.
A successful project is not the one with the longest feature list. It is the one where the features actually work and are properly explained.
A small, complete game is much stronger than an ambitious unfinished one.
Starting With the Minimum Viable Game
A useful project design technique is to begin with the smallest version that can be called a game.
This is sometimes called a minimum viable product, or MVP.
For our platform game, the minimum viable version would include:
a game window
a player character
left and right movement
gravity
jumping
at least one platform
collision detection with the platform
a way to win or finish the level
a way to lose or restart
That is enough to make a playable first version.
It may look basic, but it proves that the core mechanics work.
Once that is working, the student can add features gradually.
Essential, Desirable and Extension Features
A good way to keep the project under control is to divide features into three categories.
Essential Features
These are the features the game must have.
Without these, the project does not really work.
For this platform game, essential features could include:
player movement left and right
jumping
gravity
platforms
collision detection
hazards or obstacles
a scoring system
a start position
an end point
win and lose conditions
basic testing evidence
These should be completed first.
Desirable Features
These are features that would make the game better, but the game can still function without them.
Examples include:
collectable coins or stars
multiple levels
lives
a start menu
a pause screen
a high score table
simple sound effects
improved graphics
moving enemies
moving platforms
These are useful because they provide development opportunities once the main game works.
Extension Features
These are more advanced features that should only be attempted if the core project is already working.
Examples include:
level editor
user-created levels
saved progress
difficulty settings
animated sprites
different player characters
enemy artificial intelligence
timed challenges
file-based level loading
controller support
These could be excellent additions, but they should not be allowed to damage the main project.
A sensible student should not begin with extension features. They should earn the right to add them by first completing the essential game.
Setting Realistic Success Criteria
Success criteria are one of the most important parts of project planning.
They define what the program should do. They also provide a basis for testing and evaluation.
Weak success criteria are vague.
For example:
The game should be fun.
The graphics should be good.
The player should be able to move.
The game should have levels.
These are not useless, but they are not precise enough.
Better success criteria are specific and testable.
For example:
The player can move left and right using keyboard input.
The player falls downwards when not standing on a platform.
The player can jump only when standing on a platform.
The player cannot pass through solid platforms.
The player loses a life when touching a hazard.
The score increases when the player collects an item.
The level ends when the player reaches the finish point.
The game displays a final score at the end of the level.
These can be tested.
That is the key.
If a success criterion cannot be tested, it is probably not clear enough.
Example Success Criteria for the Platform Game
Here is a possible set of success criteria for the first version of the project.
Player Movement
The player can move left when the left arrow key is pressed.
The player can move right when the right arrow key is pressed.
The player stops moving horizontally when no movement key is pressed.
The player cannot move beyond the edge of the game screen.
Jumping and Gravity
The player falls when not standing on a platform.
The player can jump from the ground or a platform.
The player cannot repeatedly jump while already in the air.
The player lands on platforms without falling through them.
Platforms and Collision Detection
The game contains at least three platforms.
The player can stand on the top of each platform.
The player cannot pass through solid platforms from above.
The player respawns or loses when falling below the screen.
Hazards and Collectables
The game includes at least one hazard.
The player loses a life or restarts after touching a hazard.
The game includes at least one collectable item.
The score increases when a collectable is collected.
Level Completion
The level has a clear finish point.
The player wins the level by reaching the finish point.
The game displays a win message when the level is completed.
The game allows the player to restart after winning or losing.
User Interface
The score is visible during the game.
The number of lives or attempts is visible during the game.
The game has a simple start screen or instruction screen.
The controls are explained to the player.
Testing and Evaluation
Each main feature is tested using normal, boundary and error test cases where appropriate.
At least one user tests the game and gives feedback.
The game is improved in response to testing or feedback.
The final evaluation compares the finished game against the original success criteria.
These success criteria give the project structure.
They also give the student a ready-made testing framework.
Turning Success Criteria Into Evidence
A Level projects need evidence of development, not just the final program.
For each success criterion, the student should be able to collect proof.
That proof might include:
screenshots of the game working
code snippets with explanation
test tables
user feedback
before-and-after improvements
notes explaining bugs and fixes
diagrams showing how the game logic works
For example, if the success criterion is:
The player can jump only when standing on a platform.
The evidence might include:
a screenshot of the player standing on a platform
a screenshot of the player jumping
a test showing that pressing jump in mid-air does not create another jump
a code explanation showing how the program checks whether the player is on the ground
a note explaining any bug that occurred during development
This is much stronger than simply saying “jumping works”.
The Main Technical Problems We Expect to Face
It is useful to predict problems before they happen.
This is not being negative. It is good project planning.
A platform game is likely to create problems such as:
the player falling through platforms
the player getting stuck inside platforms
jumping feeling too high or too low
collision detection working from the top but not from the side
the player being able to jump repeatedly in the air
moving platforms causing strange behaviour
the score not resetting properly
levels becoming too easy or too difficult
the game running at different speeds on different computers
sound or graphics taking too much development time
These problems are not reasons to avoid the project.
They are reasons the project is worthwhile.
A project with no problems gives the student very little to discuss. A project with genuine problems and sensible solutions gives the student excellent development evidence.
Deciding the Tools
Students can build this type of game in several ways.
Possible tools include:
Python with Pygame
JavaScript with HTML5 Canvas
Godot
Unity in 2D mode
Java
C# with a simple framework
For an A Level project, the best tool is usually the one the student understands well enough to explain.
That is important.
A student using a powerful game engine without understanding the code may struggle to produce a strong write-up. A student using a simpler environment but explaining the algorithms clearly may produce a better project.
For this series, the ideas will be kept general enough to apply to different languages, but Python with Pygame or JavaScript with Canvas would both be realistic options for many students.
The important point is not the tool. The important point is the thinking.
Designing the First Version of the Game
The first version should be deliberately simple.
A sensible first design might include:
screen size: 800 by 600 pixels
player: simple rectangle or sprite
controls: left arrow, right arrow and space bar
platforms: rectangles stored in a list
gravity: applied each frame
jump: allowed only when standing on a platform
hazard: one red block or spike area
collectable: one coin or star
finish point: one flag or door
score: displayed at the top of the screen
This gives us enough to build a basic level.
A possible first level could be:
the player starts on the ground at the left
there are three platforms at increasing heights
one collectable is placed on a platform
one hazard is placed on the ground
the finish point is placed on the final platform
That is a complete level.
It is small enough to build, but it contains all the core ideas.
A Simple Project Brief
Students often benefit from writing a short project brief.
Here is an example.
I will create a 2D platform game for students aged 11–16 who enjoy simple retro-style games. The player will control a character who must move through a level, jump between platforms, avoid hazards, collect items and reach a finish point. The game will begin with a simple level and may be expanded to include multiple levels, lives, high scores and improved graphics. The project will focus on movement, gravity, collision detection, scoring, testing and user feedback.
This is a good starting brief because it is clear and realistic.
It identifies:
the type of program
the target users
the main features
possible extensions
the programming focus
That is much better than simply saying, “I am going to make a game.”
User Requirements
Even a simple game needs users.
For this project, the likely users might be younger students, friends, classmates or beginner gamers.
Possible user requirements could include:
The game should be easy to understand.
The controls should be simple.
The player should know what the objective is.
The difficulty should increase gradually.
The game should restart easily after losing.
The score should be visible.
The game should not require complicated instructions.
The game should run on a normal school or home computer.
These requirements help shape the design.
For example, if the target user is a younger student, the controls should be simple and the first level should not be too difficult. If the user is another A Level student, the game might include more challenging levels and a high score system.
Avoiding the Common A Level Project Trap
The common trap is trying to make the project impressive too early.
Students sometimes spend days choosing sprites, drawing backgrounds, finding sound effects or planning a storyline before the basic game works.
That is the wrong order.
The first priority is not making the game beautiful.
The first priority is making the game function.
A sensible order is:
Get the window working.
Get the player on the screen.
Add left and right movement.
Add gravity.
Add jumping.
Add platforms.
Add collision detection.
Add a win condition.
Add hazards.
Add scoring.
Add levels.
Improve appearance and sound.
Graphics and sound can come later.
A plain rectangle that moves correctly is better than a beautiful character that falls through the floor.
Planning the First Few Development Stages
The project can be broken into weekly development stages.
Stage 1: Planning and Success Criteria
Define the idea, users, features and success criteria.
Stage 2: Game Window and Player Movement
Create the game window and allow the player to move left and right.
Stage 3: Gravity and Jumping
Add vertical movement, falling and jumping.
Stage 4: Platforms and Collision Detection
Allow the player to land on platforms and prevent falling through them.
Stage 5: Hazards, Collectables and Scoring
Add danger, reward and a visible score.
Stage 6: Level Design
Create a full playable level and possibly a second level.
Stage 7: Menus, Lives and Restarting
Add structure around the game.
Stage 8: Testing and User Feedback
Test features properly and improve the game.
Stage 9: Evaluation and Further Development
Compare the finished game with the success criteria and suggest improvements.
This is a controlled route from idea to working game.
It also gives students a strong structure for their project log.
What Should Be in the Student’s Project Folder From Day One?
A good project folder should not just contain code.
From the beginning, students should collect evidence.
A sensible folder structure might include:
Project Brief
User Requirements
Success Criteria
Design Notes
Algorithms
Development Log
Testing
User Feedback
Screenshots
Final Evaluation
Source Code
This helps avoid the last-minute panic of trying to recreate evidence after the project is finished.
The best evidence is collected while the project is being developed.
Practical Task for Students
Before writing the game, students should complete the following task.
Platform Game Planning Task
Write a one-page plan for your platform game.
Include:
The title of the game.
The target user.
The basic objective.
The controls.
The essential features.
The desirable features.
The extension features.
At least ten clear success criteria.
Three possible technical problems.
How you will collect evidence during development.
This task turns a vague idea into a project.
It also forces students to think realistically before they start coding.
Example Mini Plan
Game Title
Escape the Platforms
Target User
Students aged 11–16 who enjoy simple retro games.
Objective
The player must move across platforms, collect stars, avoid hazards and reach the exit flag.
Controls
Left arrow: move left
Right arrow: move right
Space bar: jump
R key: restart level
Essential Features
player movement
jumping
gravity
platforms
collision detection
hazards
collectables
score
finish point
restart option
Desirable Features
multiple levels
lives
simple sound effects
high score table
moving enemies
Extension Features
level editor
animated sprites
difficulty settings
saved high scores
moving platforms
Example Success Criteria
The player moves left and right using the keyboard.
The player jumps when the space bar is pressed.
The player falls when not supported by a platform.
The player lands on platforms correctly.
The player cannot jump repeatedly while in the air.
The player loses when touching a hazard.
The score increases when a star is collected.
The level ends when the player reaches the flag.
The player can restart the level after losing.
The game displays the score during play.
This is not a complete project, but it is a very good starting point.
Final Thoughts: A Good Game Begins Before the Code
A platform game is an excellent A Level project idea if it is kept under control.
It gives students real programming problems to solve: movement, gravity, jumping, collision detection, level design, scoring and testing.
But it only works as a project if it begins with clear planning.
The student must know what they are building, who it is for, what features are essential and how success will be measured.
The first version does not need polished artwork. It does not need sound effects. It does not need twenty levels.
It needs one thing above all else.
It needs to work.
Once the basic game works, everything else can be improved.
In the next article, we will move from planning to building the first working version: creating the game window, placing the player on the screen and getting simple left and right movement working.
No comments:
Post a Comment