Building an A Level Platform Game Project — Part 5: Turning Platforms Into Proper Levels
In Part 1, we planned the platform game and set realistic success criteria.
In Part 2, we created the game window and added player movement.
In Part 3, we added gravity and jumping.
In Part 4, we added platforms and collision detection, allowing the player to land on raised surfaces rather than simply jumping on a flat ground line.
Now we are ready for the next important stage.
We need to turn a collection of platforms into an actual level.
This is where the project begins to feel much more like a real game. A level is not just a random arrangement of rectangles. A good level has a start point, a route, a challenge, a finish point, rewards, risks and a sense of progression.
For an A Level Computer Science project, this is also a very useful stage because it introduces data structures, design decisions, user testing, difficulty control and evidence of iteration.
A platform game becomes much stronger when the student can explain not only how the code works, but why the level has been designed in a particular way.
Why Level Design Matters
At the end of Part 4, we had platforms.
The player could jump, fall and land. That was a major step.
But platforms alone do not make a level.
A proper level needs purpose.
The player should know:
where they start
where they are trying to go
what they must avoid
what they can collect
how they can win
what happens if they fail
A level gives structure to the game.
Without levels, the player is simply moving around a test screen. With levels, the player is trying to complete a challenge.
This is also where students begin to see the difference between a technical prototype and a finished project.
The Aim for Part 5
The aim of this stage is:
Develop the platform layout into a complete playable level with a start position, route, finish point, collectables and hazards.
By the end of this stage, the game should include:
a defined player start point
a planned route through the platforms
a finish point
collectable items
hazards or danger areas
a score
win and lose conditions
testing evidence for the level design
a structure that can later support multiple levels
This moves the project beyond movement mechanics and into game design.
From Platforms to Level Data
In Part 4, platforms were stored in a list like this:
platforms = [
pygame.Rect(0, 580, 800, 20),
pygame.Rect(150, 480, 200, 20),
pygame.Rect(450, 380, 200, 20),
pygame.Rect(250, 280, 180, 20)
]
This is a good start.
But now we need more than platforms.
A complete level may need:
platforms
player start position
finish point
collectables
hazards
background colour
time limit
difficulty rating
level name
Instead of treating platforms separately, we can begin to think of the level as a data structure.
For example:
level_1 = {
"player_start": (100, 500),
"platforms": [
pygame.Rect(0, 580, 800, 20),
pygame.Rect(150, 480, 200, 20),
pygame.Rect(450, 400, 200, 20),
pygame.Rect(250, 300, 180, 20)
],
"collectables": [
pygame.Rect(220, 440, 20, 20),
pygame.Rect(520, 360, 20, 20)
],
"hazards": [
pygame.Rect(380, 560, 60, 20)
],
"finish": pygame.Rect(650, 340, 40, 60)
}
This is a very important development.
The level is now stored as data.
That means the program can load, draw, test and change levels more easily.
This is exactly the kind of design decision that can strengthen an A Level project.
Why Data Structures Are Important
Students sometimes think a game is mainly about drawing graphics and moving characters.
But a game also depends heavily on data.
In this project, data controls:
where the platforms are
where the player begins
where hazards are placed
where collectables appear
where the finish point is
how the level is completed
Once students understand this, the project becomes more flexible.
Instead of rewriting large sections of code for each new level, they can change the data.
That is good programming practice.
A student might write in their project documentation:
I used a dictionary to store the level data, including platforms, collectables, hazards, the player start position and the finish point. This made the program easier to extend because new levels could be created by changing the data rather than rewriting the main game logic.
That is a strong explanation.
Designing a Start Point
The player start position should be chosen carefully.
It should be:
safe
visible
close to the first platform or route
not inside a platform
not touching a hazard
easy for the player to understand
A sensible first start point might be:
"player_start": (100, 500)
This places the player near the left side of the screen, standing on the ground.
That makes sense for a first level because most players expect to move from left to right.
A more advanced level might start higher up, in the middle, or even near danger, but the first level should be clear and forgiving.
Good level design begins by helping the player understand what to do.
Designing a Route
A level should have a route.
That does not mean there must be only one path, but the player should be guided through the challenge.
For a simple first level, the route might be:
Start on the ground.
Jump onto a low platform.
Collect a star.
Jump to a higher platform.
Avoid a hazard on the ground.
Reach a finish flag.
This creates a basic journey.
It gives the player a goal and allows the student to test whether the jump height and platform spacing are suitable.
A poor level might have platforms placed randomly with no clear path. That makes the game feel confusing.
A good level has intention.
Difficulty: Not Too Easy, Not Impossible
Difficulty is one of the hardest parts of level design.
Students often make levels too difficult because they already know how the game works. They know where to jump. They know how the controls feel. They know where the hazards are.
A new user does not.
This is why user testing matters.
A first level should usually be:
easy to understand
forgiving
short
clear
achievable after one or two attempts
Later levels can become more difficult.
Difficulty can be increased by:
making platforms smaller
increasing gaps between platforms
adding hazards
adding moving enemies
placing collectables in risky positions
adding time pressure
making the route less direct
adding moving platforms
However, difficulty should increase gradually.
A game that becomes impossible too quickly is not challenging. It is frustrating.
Adding a Finish Point
A platform game needs a way to win.
The simplest finish point could be a rectangle representing a flag, door or portal.
For example:
finish_rect = level_1["finish"]
The finish point can be drawn like this:
pygame.draw.rect(screen, (0, 200, 0), finish_rect)
Then the program can check whether the player reaches it:
if player_rect.colliderect(finish_rect):
game_won = True
This gives us a win condition.
Once the player touches the finish point, the program can display a message such as:
Level Complete!
This may seem simple, but it is a major design step.
The game now has an objective.
Adding Collectables
Collectables give the player something optional or rewarding to do.
They might be:
coins
stars
gems
keys
energy cells
books
science symbols
computer chips
For this project, collectables can begin as small rectangles or circles.
Example data:
collectables = [
pygame.Rect(220, 440, 20, 20),
pygame.Rect(520, 360, 20, 20)
]
They can be drawn using a loop:
for item in collectables:
pygame.draw.rect(screen, (255, 215, 0), item)
If the player touches a collectable, the score increases:
for item in collectables[:]:
if player_rect.colliderect(item):
collectables.remove(item)
score += 10
The use of collectables[:] creates a copy of the list while looping. This helps avoid problems caused by removing items from a list while processing it.
That is another useful programming point for students to explain.
Why Collectables Improve the Project
Collectables are useful because they introduce:
collision detection with non-platform objects
score calculation
list processing
object removal
optional challenge
user feedback
testing opportunities
A collectable is not just decoration.
It creates data and logic.
For A Level project evidence, students can test:
whether the collectable appears
whether the player can collect it
whether the score increases
whether the item disappears after collection
whether the same item cannot be collected twice
That gives excellent evidence for testing and evaluation.
Adding Hazards
Hazards give the game risk.
A hazard might be:
spikes
lava
water
a moving enemy
a falling object
a red danger block
an electric barrier
For the first version, a simple red rectangle is enough.
Example data:
hazards = [
pygame.Rect(380, 560, 60, 20)
]
Drawing hazards:
for hazard in hazards:
pygame.draw.rect(screen, (255, 0, 0), hazard)
Collision with hazards:
for hazard in hazards:
if player_rect.colliderect(hazard):
player_rect.x, player_rect.y = level_1["player_start"]
player_y_velocity = 0
lives -= 1
This gives the game a lose condition.
If lives reach zero, the game can display:
Game Over
Again, this is more than just a visual feature. It introduces consequences.
Lives, Restarts and Failure
A game should handle failure clearly.
If the player touches a hazard, what should happen?
Possible options include:
restart the level
lose one life
return to the last checkpoint
reduce the score
end the game immediately
For a first version, losing a life and returning to the start is sensible.
Example variables:
lives = 3
score = 0
game_over = False
game_won = False
Then:
if lives <= 0:
game_over = True
This allows the student to create clear success criteria:
The player loses a life when touching a hazard.
The player returns to the start position after touching a hazard.
The game ends when the player has no lives remaining.
The game displays a game over message.
These are all testable.
Displaying Score and Lives
A game should give feedback to the player.
At minimum, the player should be able to see:
score
lives
game status
In Pygame, text can be displayed using a font:
font = pygame.font.SysFont(None, 36)
score_text = font.render("Score: " + str(score), True, (0, 0, 0))
screen.blit(score_text, (10, 10))
Lives can be displayed in the same way:
lives_text = font.render("Lives: " + str(lives), True, (0, 0, 0))
screen.blit(lives_text, (10, 40))
This makes the game feel more complete.
It also improves usability because the player knows what is happening.
Example Level Structure
Here is an example of how a first complete level might be organised:
level_1 = {
"name": "First Steps",
"player_start": (100, 520),
"platforms": [
pygame.Rect(0, 580, 800, 20),
pygame.Rect(140, 500, 180, 20),
pygame.Rect(390, 430, 180, 20),
pygame.Rect(610, 350, 140, 20)
],
"collectables": [
pygame.Rect(200, 460, 20, 20),
pygame.Rect(460, 390, 20, 20),
pygame.Rect(660, 310, 20, 20)
],
"hazards": [
pygame.Rect(340, 560, 80, 20),
pygame.Rect(570, 560, 60, 20)
],
"finish": pygame.Rect(710, 290, 40, 60)
}
This level has a clear structure.
The player starts near the left.
The route moves upwards and to the right.
Collectables reward progress.
Hazards punish mistakes.
The finish point gives the player a clear goal.
That is now a proper level.
Planning the Level on Paper First
Before coding a level, students should sketch it.
This does not need to be artistic.
A simple diagram is enough:
draw the screen rectangle
mark the start position
sketch the platforms
mark the finish point
add collectables
add hazards
draw the likely route
This is useful because it helps students think before coding.
It also creates evidence for the design section of the project.
A student can include:
original level sketch
explanation of the route
screenshot of the coded level
notes about changes after testing
That shows a clear design process.
Testing the Route
A level must be playable.
That means the route must actually work.
Students should test:
Can the player reach the first platform?
Can the player reach the second platform?
Is any gap too wide?
Is any platform too high?
Can the player reach the finish?
Can the player avoid the hazards?
Can collectables be reached?
Does the game become too difficult too quickly?
This is where students may need to adjust jump strength, platform positions or hazard placement.
That is not a failure. That is development.
A good project should show these adjustments.
Example Test Table for Level Design
| Test Number | Test | Expected Result | Actual Result | Change Needed |
|---|---|---|---|---|
| 1 | Start the level | Player appears at start position | Player appears correctly | None |
| 2 | Jump to first platform | Player can reach and land on platform | Player lands correctly | None |
| 3 | Jump to second platform | Player can reach platform | Jump is slightly too difficult | Move platform 20 pixels closer |
| 4 | Touch collectable | Score increases by 10 | Score increases correctly | None |
| 5 | Touch same collectable again | Score should not increase again | Item disappears after collection | None |
| 6 | Touch hazard | Player loses one life and restarts | Player restarts correctly | None |
| 7 | Reach finish point | Level complete message appears | Message appears | None |
| 8 | Lose all lives | Game over message appears | Game over appears | None |
| 9 | New user plays level | User understands route | User missed first platform | Add visual clue or move platform |
| 10 | Complete level without collecting items | Player can still finish | Player can finish | None |
Notice that some tests lead to changes.
That is excellent evidence.
A project is stronger when the student can show that testing caused improvements.
User Testing and Feedback
At this stage, user testing becomes very useful.
The student can ask another person to play the level and watch what happens.
Useful questions include:
Was the objective clear?
Were the controls easy to understand?
Was the first jump too easy, too hard or about right?
Did you notice the collectables?
Were the hazards clear?
Did the level feel fair?
What would improve the level?
Students should not just collect compliments.
They need useful feedback.
For example:
The user did not realise the green rectangle was the finish point, so I changed it to a flag shape and added a label.
That is excellent evidence of evaluation and improvement.
Increasing Difficulty Across Levels
Once one level works, the next step is to create more levels.
Each level should increase difficulty gradually.
Level 1 might teach the controls:
wide platforms
small gaps
few hazards
obvious finish point
Level 2 might increase challenge:
narrower platforms
more hazards
collectables placed in riskier positions
longer route
Level 3 might add new mechanics:
moving platforms
enemies
timed sections
keys and locked doors
This creates progression.
It also gives the student a clear way to justify the design.
The game becomes structured rather than random.
Using Several Level Dictionaries
A simple way to manage multiple levels is to store them in a list:
levels = [level_1, level_2, level_3]
current_level_number = 0
current_level = levels[current_level_number]
When the player reaches the finish point, the game can load the next level:
current_level_number += 1
if current_level_number < len(levels):
current_level = levels[current_level_number]
player_rect.x, player_rect.y = current_level["player_start"]
else:
game_won = True
This gives students a clear extension route.
They do not need to build all levels at once. They can begin with one level and then add more once the structure works.
Why This Is Strong for A Level Projects
This stage is especially valuable for A Level Computer Science because it combines several important ideas:
data structures
lists
dictionaries
collision detection
scoring
state management
user testing
iterative improvement
evaluation against success criteria
It also gives students something visual and engaging.
A project does not need to be technically enormous to be strong.
It needs to be understandable, testable and well developed.
A platform game with three well-designed levels, clear documentation, thoughtful testing and user feedback could be much stronger than an overambitious game that is unfinished and poorly explained.
Personal Reflection: Students Learn That Design Is Not Decoration
One of the things I like about this stage is that it changes how students think about games.
At first, they often see level design as decoration.
They think it is about where to put platforms so the screen looks interesting.
But good level design is not decoration.
It is problem design.
The level asks the player questions:
Can you make this jump?
Can you avoid this hazard?
Can you choose the safer route?
Can you collect the item without taking a risk?
Can you reach the finish?
The programmer has to design those questions carefully.
Too easy, and the game is boring.
Too hard, and the game is frustrating.
Too unclear, and the user gives up.
That is why this is such a good teaching stage. It brings together programming, testing and user experience.
Practical Task for Students
Part 5 Student Task
Turn your platform layout into a complete first level.
Your level should include:
A named level.
A clear player start position.
At least four platforms.
A route from start to finish.
At least two collectables.
At least one hazard.
A finish point.
A score system.
A lives or restart system.
A test table showing that the level can be completed.
Extension Task
Improve the level system by adding one of the following:
a second level
a level list
difficulty progression
moving hazards
collectables placed in optional harder routes
a timer
a checkpoint
a key and locked door
level data stored in an external file
Students should only attempt the extension once the first level is complete and playable.
Development Log Example
A good development log entry for this stage might look like this:
Development Stage
Creating the first complete level.
Aim
To turn the platform prototype into a playable level with a start point, finish point, collectables, hazards, score and lives.
What Was Added
level dictionary
player start position
finish point
collectables
hazards
score display
lives display
win condition
lose condition
Problems Found
The second jump was too difficult for a new user.
One collectable could be collected more than once before it was removed from the list.
The finish point was not obvious enough.
A hazard was placed too close to the start position.
Changes Made
Moved one platform closer to make the jump fairer.
Removed collectables from the list after collection.
Changed the finish point to a clearer flag shape.
Moved the first hazard further away from the start.
Evidence Collected
original level sketch
screenshot of first coded level
screenshot of improved level
test table
user feedback
code showing level data
code showing scoring and hazards
This sort of evidence shows the full development process.
It is not just coding. It is analysis, design, implementation, testing and evaluation.
Final Thoughts: A Level Is More Than a Screen of Platforms
At the beginning of this series, the platform game was only an idea.
Then it became a window.
Then a moving player.
Then a jumping player.
Then a player who could land on platforms.
Now it is becoming a game.
Adding levels, routes, collectables and hazards gives the project purpose.
The player now has something to do, something to avoid and something to achieve.
For A Level Computer Science, this is where the project can become very strong. The student can show design decisions, data structures, testing, user feedback and improvement.
A good level is not random. It is planned.
It teaches the player.
It challenges the player.
It rewards the player.
It gives the game structure.
In the next article, we can develop this further by looking at enemies, moving hazards and more advanced interactions — the features that make a level feel alive.
