16 August 2026

How Do We Measure Intelligence — and Where Does “Common Sense” Fit In?

A Level Psychology: How Do We Measure Intelligence — and Where Does “Common Sense” Fit In?

Intelligence is one of those psychological ideas that sounds straightforward until we try to define it.

We all think we recognise intelligence when we see it. Someone solves difficult mathematical problems, learns languages quickly, remembers enormous amounts of information or performs exceptionally well in examinations, and we describe them as intelligent.

But then something puzzling happens.

A person who can solve an advanced equation may make a remarkably poor everyday decision. Someone with outstanding academic qualifications may struggle to organise a journey, recognise when another person is becoming annoyed, or realise that putting a metal container into a microwave is probably a bad idea.

At the same time, someone who was never particularly successful at school might be exceptionally good at diagnosing a mechanical problem, running a business, judging character or finding a practical solution when something goes wrong.

This raises an excellent A Level Psychology question:

What exactly is intelligence — and is “common sense” part of it?

Intelligence Is Much Harder to Define Than It Looks

Before psychologists can measure something, they need to decide what they are measuring.

That is the first problem with intelligence.

Does intelligence mean:

reasoning ability?
memory?
vocabulary?
mathematical ability?
solving unfamiliar problems?
creativity?
understanding other people?
making sensible decisions?
learning from experience?
adapting successfully to new situations?

Different definitions produce different ways of measuring intelligence.

That is important because an intelligence test does not simply discover some mysterious quantity called "intelligence". It measures performance on a particular collection of tasks that psychologists believe tells us something about intellectual ability.

IQ: The Traditional Attempt to Measure Intelligence

Probably the best-known measure is the Intelligence Quotient, or IQ.

Modern IQ tests generally contain several different types of task. These might assess areas such as:

verbal comprehension;
working memory;
processing speed;
spatial reasoning;
pattern recognition;
quantitative reasoning.

Rather than asking someone hundreds of general-knowledge questions, psychologists are trying to sample several different cognitive abilities.

A typical task might present:

2, 4, 8, 16, ?

The answer is 32.

But another task might involve identifying how shapes should be rotated, remembering a sequence of numbers or explaining the relationship between two words.

The resulting scores are compared with those obtained by other people of approximately the same age.

Traditionally, IQ scores are standardised so that the population average is around 100.

That does not mean somebody scoring 120 is "20% more intelligent" than somebody scoring 100. IQ is a statistical score indicating performance relative to the comparison population.

The Idea of General Intelligence — Spearman's "g"

One influential psychologist, Charles Spearman, noticed something interesting.

People who performed well on one type of mental ability test tended, on average, to perform reasonably well on others.

Someone good at verbal reasoning might also be relatively good at mathematical or spatial reasoning.

Spearman proposed that there was an underlying general intelligence factor, usually called:

Alongside this general ability, he proposed more specific abilities associated with individual tasks.

It helps explain why academic abilities often correlate.

But it immediately raises another question.

If there really is a general intellectual ability, why can someone be brilliant in one area and surprisingly ordinary in another?

Being Brilliant at One Thing Does Not Mean Being Brilliant at Everything

This is something I have repeatedly noticed in education.

A student can be exceptional at mathematics and struggle to express an argument in an essay.

Another may produce wonderfully creative writing but find algebra extremely difficult.

Someone else might have an extraordinary musical ability, recognising pitch, rhythm and musical structure almost instinctively, while being comparatively average in conventional academic subjects.

Even within a subject the differences can be considerable.

A Physics student might understand mechanics very quickly but struggle with electricity.

A Mathematics student might be excellent at algebra but find three-dimensional geometry difficult.

So intelligence cannot simply mean:

"How clever is this person?"

There are different cognitive abilities, and people have different profiles of strengths and weaknesses.

Fluid and Crystallised Intelligence

Another useful distinction is between fluid intelligence and crystallised intelligence.

Fluid intelligence

Fluid intelligence concerns solving unfamiliar problems without relying heavily upon previously learned knowledge.

Imagine being shown:

▲ ● ▲ ● ▲ ?

You have never seen the question before, but you can identify the pattern and predict what comes next.

That requires reasoning.

Crystallised intelligence

Crystallised intelligence involves the knowledge and skills accumulated through education and experience.

Vocabulary is a good example.

Knowing what the word "photosynthesis" means depends partly on previous learning.

An experienced scientist, teacher, engineer or doctor may therefore solve problems partly because decades of accumulated knowledge allow them to recognise patterns that a novice cannot see.

This becomes particularly interesting when discussing common sense.

Perhaps some apparent common sense is actually crystallised experience.

So What Is Common Sense?

We use the phrase constantly.

"It's just common sense."

Psychologically, however, common sense is surprisingly difficult to define.

There is no universally accepted psychological variable called Common Sense Quotient.

What we casually describe as common sense probably contains several different abilities, including:

practical reasoning;
judgement;
recognising consequences;
understanding social situations;
applying previous experience;
risk assessment;
self-control;
problem solving;
adapting behaviour when circumstances change.

So common sense may not be a single ability at all.

It may be the everyday outcome of several psychological processes working together.

A Simple Example: The Overflowing Sink

Imagine that someone notices that a sink is filling rapidly and is about to overflow.

What should they do?

Most people might immediately:

turn off the tap;
remove the plug;
grab something to contain or mop up the water.

It seems like common sense.

But notice how many psychological processes are involved.

The person must:

notice the problem;
identify its cause;
predict what is about to happen;
select an appropriate response;
ignore irrelevant alternatives;
act quickly.

That involves perception, attention, memory, reasoning, executive functioning and previous experience.

What looks like one thing — "common sense" — may actually be the combination of many things.

Practical Intelligence

Psychologist Robert Sternberg proposed that traditional intelligence tests capture only part of what allows people to function successfully.

His broader approach distinguished between abilities such as:

analytical intelligence;
creative intelligence;
practical intelligence.

Practical intelligence is particularly relevant to common sense.

It involves knowing how to deal effectively with real-world situations.

Consider two people trying to assemble a piece of equipment.

Person A has read extensively about mechanics and can explain the underlying physics perfectly.

Person B has spent twenty years repairing machinery.

When the equipment jams, Person B immediately says:

"That part isn't sitting correctly. Loosen this first, align that, and then tighten it."

Person B might not be able to explain the theoretical mechanics as elegantly.

But they possess an enormous amount of practical knowledge.

Tacit Knowledge — Knowing Things Nobody Explicitly Taught You

An especially interesting idea is tacit knowledge.

Tacit knowledge consists of knowledge acquired through experience that may never have been formally taught.

A teacher develops it.

After years in classrooms, an experienced teacher may notice almost immediately that a student does not really understand something.

Perhaps the student says:

"Yes, I understand."

But their hesitation, explanation or choice of words suggests otherwise.

That judgement may be difficult to reduce to one simple rule.

Nobody necessarily taught the teacher:

"When a student pauses for precisely 1.8 seconds and looks slightly to the left, they don't understand."

It develops through experience.

The same happens in countless occupations.

A mechanic hears that an engine sounds wrong.

A doctor notices that a patient's presentation does not quite fit the expected pattern.

A sailor feels that the boat is behaving differently.

A musician hears that something is slightly out of tune.

That accumulated practical judgement can look very much like common sense.

Why Very Intelligent People Can Sometimes Lack Common Sense

This is perhaps the most fascinating part.

A high level of reasoning ability does not guarantee excellent judgement in every situation.

Someone could possess outstanding analytical intelligence but have relatively limited:

life experience;
social awareness;
emotional regulation;
practical experience;
impulse control;
knowledge of a particular situation.

Imagine an extremely capable mathematician entering a sailing boat for the first time.

They might understand forces, moments, fluid mechanics and vectors considerably better than an experienced recreational sailor.

But that does not mean you would automatically want them controlling the boat in a sudden squall.

The experienced sailor possesses something else:

experience applied to context.

Knowing the physics and knowing what to do in the next five seconds are related — but they are not identical.

Executive Functions May Matter Too

What we describe as poor common sense may sometimes involve executive functioning.

Executive functions help us regulate and organise behaviour.

They include processes such as:

planning;
inhibition;
switching attention;
monitoring our actions;
working memory;
resisting impulsive behaviour.

Suppose somebody knows that checking their phone while driving is dangerous.

They understand the information perfectly.

Yet they still reach for the phone when it rings.

Their problem is not necessarily intelligence.

It might involve judgement, inhibition or risk-taking.

This illustrates an important psychological principle:

Knowing something is not the same as acting upon it.

Social Intelligence Also Matters

Common sense frequently involves other people.

Should I make this joke now?

Is this person being serious?

Should I interrupt?

Is somebody becoming uncomfortable?

Should I argue this point or leave it alone?

These questions are not usually found on conventional IQ tests.

Yet being able to interpret other people's behaviour can be enormously important in everyday life.

Abilities involving social understanding, empathy and emotional processing therefore contribute to what people sometimes casually call common sense.

Can Common Sense Be Measured?

This is where psychology becomes particularly interesting.

You could construct a test containing everyday scenarios.

For example:

You smell burning while using an electrical appliance. What should you do first?

Or:

A colleague who normally talks to you enthusiastically suddenly gives very short answers and avoids conversation. What might you reasonably conclude?

Or:

You have an important interview at 9.00 am. The journey normally takes 45 minutes but heavy traffic is forecast. When should you leave?

These could test practical judgement.

However, there is an enormous methodological problem.

Who decides what the common-sense answer is?

Common Sense Is Not Always Common

The phrase itself is misleading.

What seems obvious to one person may be completely unfamiliar to another.

Consider changing a car tyre.

An experienced driver might describe the correct procedure as common sense.

Someone who has never been shown a jack or wheel brace may have absolutely no idea where to begin.

Likewise, someone brought up around boats may instinctively recognise danger around water that another person completely misses.

Therefore:

common sense often depends upon experience and culture.

That makes it much harder to measure objectively than something such as reaction time.

Cultural Bias and Intelligence Testing

This problem also appears in intelligence testing.

Suppose a test uses vocabulary, objects, customs or knowledge familiar to one cultural group but unfamiliar to another.

Are differences in scores really measuring intelligence?

Or are they partly measuring familiarity?

Psychologists therefore have to consider cultural bias very carefully.

Non-verbal reasoning tests can reduce some forms of cultural dependence, but completely culture-free testing is extremely difficult.

Education itself also matters.

Someone who has spent years practising examination questions has learned how tests work.

That experience can affect performance.

Intelligence: Nature or Nurture?

Another major psychological issue is where intelligence comes from.

Genetic differences contribute to individual differences in cognitive ability.

But environmental influences are also extremely important.

These can include:

nutrition;
education;
stimulation during childhood;
health;
family environment;
opportunities for learning;
socioeconomic conditions;
expectations;
practice.

This is why simplistic arguments such as:

"Intelligence is genetic"

"Intelligence is entirely produced by education"

are inadequate.

Psychological characteristics usually emerge through complex interactions between biology and environment.

Intelligence Tests Must Be Reliable

Psychologists also have to ask whether a test is reliable.

Suppose I take an intelligence test today and score 125.

Next week I take the same type of test and score 83.

The following week I score 142.

That would make the test rather questionable.

A useful psychological measure should produce reasonably consistent results when the underlying characteristic being measured has not changed substantially.

This is known as reliability.

But Reliability Is Not Enough — We Also Need Validity

Imagine I invent the Russell Intelligence Test.

It contains one task:

"How quickly can you sort 100 buttons into different colours?"

The test could be extremely reliable.

Perhaps people repeatedly obtain almost identical scores.

But does that make it a good intelligence test?

No.

The more important question is:

Does the test actually measure intelligence?

That is a question of validity.

This distinction is enormously important throughout A Level Psychology.

A measurement can be highly reliable while measuring the wrong thing.

What About Musical Intelligence?

This leads into another controversial area.

We clearly observe people with extraordinary abilities in specialised domains.

A brilliant musician might possess exceptional:

auditory discrimination;
musical memory;
timing;
pattern recognition;
motor coordination;
creativity.

Howard Gardner famously proposed a theory of multiple intelligences, including areas such as musical, linguistic and spatial intelligence.

The idea has been extremely influential in education.

However, students need to be cautious.

It is tempting to conclude:

"Everybody simply has a different intelligence."

The psychological evidence is more complicated than that. Some proposed "intelligences" may overlap with talents, personality characteristics or learned abilities rather than representing completely independent forms of intelligence.

It is a useful debate precisely because it forces us to ask:

What should qualify as intelligence?

Intelligence Is Not the Same as Achievement

This distinction is also important for students.

Getting an A* does not simply measure intelligence.

Examination success depends upon many things:

Ability + knowledge + revision + motivation + examination technique + concentration + health + confidence + opportunity.

Two students with similar cognitive abilities could therefore obtain very different grades.

Likewise, two people achieving the same grade may have reached it through very different combinations of ability and effort.

This is one reason I am wary of casually labelling students as either "clever" or "not clever".

Human ability is far more complicated.

A Useful Classroom Investigation

This topic could make an excellent A Level Psychology discussion.

Ask students to rank these individuals from "most intelligent" to "least intelligent":

a theoretical physicist;
a concert pianist;
an experienced carpenter;
a successful entrepreneur;
a chess grandmaster;
an emergency nurse;
a farmer;
a novelist;
a computer programmer.

Very quickly a problem appears.

What criteria are we using?

Academic knowledge?

Problem solving?

Creativity?

Memory?

Practical judgement?

Social skills?

Ability to learn?

Now ask a more interesting question:

Could we design one test that fairly measures the intelligence of all nine people?

The difficulty of doing so reveals the fundamental problem.

An Even Better Question: Intelligent at What?

Perhaps instead of asking:

"How intelligent is this person?"

we should sometimes ask:

"What cognitive abilities does this person possess, and under what circumstances are they able to use them?"

That produces a much richer psychological picture.

Someone might have:

excellent verbal reasoning;
moderate working memory;
exceptional spatial ability;
weak processing speed;
excellent practical judgement;
strong interpersonal skills.

Reducing that whole person to one number inevitably loses information.

That does not make IQ meaningless.

It means we should understand what the number can — and cannot — tell us.

Where Does Common Sense Finally Fit?

Common sense probably does not sit neatly inside a single box labelled intelligence.

Instead, it seems to involve an interaction between several things:

reasoning + experience + memory + executive control + social understanding + contextual knowledge + judgement

This explains why intelligence and common sense can sometimes appear disconnected.

A person may possess extraordinary analytical ability but limited practical experience.

Another may have average performance on traditional cognitive tests yet possess exceptional practical judgement developed over decades.

Neither observation requires us to conclude that intelligence tests are useless.

It means human cognition is complicated.

And psychology becomes much more interesting when we stop pretending otherwise.

The Bigger A Level Psychology Lesson

The real value of studying intelligence is not simply learning what an IQ score means.

It introduces some of the biggest questions in psychology.

How do we define an invisible psychological characteristic?

How do we turn that definition into something measurable?

How do we know our measurement is reliable?

How do we establish validity?

How do biology, environment and culture interact?

Can complicated human characteristics really be reduced to numbers?

These questions stretch far beyond intelligence testing.

They lie at the heart of psychological research.

Conclusion: Perhaps Being Clever Isn't Enough

We often talk about intelligence as though everyone possesses a certain quantity of it.

Reality appears much more complicated.

Traditional intelligence tests can provide valuable information about cognitive ability, and general intelligence remains an important concept in psychology. But intelligence does not automatically produce wisdom, good judgement, social awareness or practical competence.

And that is where our everyday idea of common sense becomes interesting.

Common sense may not be a separate form of intelligence at all. It may emerge when reasoning, knowledge, experience and judgement come together in the right situation.

Perhaps that explains one of life's familiar puzzles:

How can somebody be extraordinarily clever and still occasionally do something remarkably foolish?

Psychology's answer may simply be that being able to think brilliantly is not quite the same thing as knowing what to do.

And understanding that difference gives us a far more interesting picture of human intelligence.

15 August 2026

Building an A Level Platform Game Project — Part 7: Menus, Lives, Scoring, High Scores and Game Structure

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.

In Part 5, we turned platforms into proper levels with routes, collectables, hazards and finish points.

In Part 6, we added enemies, moving hazards and more advanced interactions to make the level feel alive.

Now we need to step back and look at the wider game.

So far, we have been building the mechanics of a platform game. The player can move, jump, collect items, avoid hazards and complete a level. That is excellent progress.

But a complete game needs more than a playable level.

It needs structure.

It needs a start screen.
It needs instructions.
It needs a score.
It needs lives.
It needs win and lose screens.
It may need high scores.
It needs a way to restart.
It needs clear feedback for the player.

This is the stage where a prototype starts to feel like a finished project.

For A Level Computer Science, this is also a valuable stage because it introduces state management, file handling, user interface design, validation, testing and evaluation.

Why Game Structure Matters

A game is not just what happens during play.

The player needs to move through different stages:

Start the game.
Read or understand the instructions.
Play the level.
Collect points.
Lose lives when making mistakes.
Complete the level or lose the game.
See the result.
Restart or exit.

Without this structure, the game may technically work, but it can feel unfinished.

A student might have a good level, but if the program immediately launches into the game with no explanation and no proper ending, the user experience is weak.

Good structure helps the player understand what is happening.

It also gives the student more opportunities to demonstrate good programming.

The Aim for Part 7

The aim of this stage is:

Add menus, lives, scoring, high scores and game states so the platform game feels like a complete playable game rather than a single test level.

By the end of this stage, the game could include:

a start menu
an instruction screen
a playing state
a game over screen
a level complete screen
a lives system
a score system
a high score system
restart and quit options
testing evidence for each game state

Students do not need to add every possible feature at once. The key is to add structure carefully and test each part.

From One Loop to Game States

Most simple games run inside one main loop.

In the early stages, that loop handled everything:

checking input
moving the player
applying gravity
checking collisions
drawing the screen

As the game grows, this can become messy.

One way to organise the program is to use game states.

A game state records what part of the game is currently active.

For example:

game_state = "menu"

The possible states might be:

"menu"
"instructions"
"playing"
"level_complete"
"game_over"
"high_scores"

Then the main loop can decide what to do depending on the current state.

For example:

if game_state == "menu":
    draw_menu()

elif game_state == "instructions":
    draw_instructions()

elif game_state == "playing":
    update_game()
    draw_game()

elif game_state == "level_complete":
    draw_level_complete()

elif game_state == "game_over":
    draw_game_over()

This is a very important design improvement.

Instead of one large, confusing block of code, the program is divided into sections.

That makes it easier to understand, test and extend.

Why Game States Are Useful for A Level Projects

Game states give students something strong to explain in their documentation.

They can say:

I used a game state variable to control which part of the game was active. This made the program easier to organise because the menu, instructions, gameplay and game over screen could be handled separately.

This shows design thinking.

It also helps with testing.

The student can test:

whether the menu appears first
whether pressing a key starts the game
whether the instructions screen displays correctly
whether the game over screen appears when lives reach zero
whether the level complete screen appears when the finish point is reached
whether the player can restart the game

Each state has clear expected behaviour.

Creating a Start Menu

A simple start menu does not need to be complicated.

It might show:

game title
short instruction
start option
quit option

For example:

ESCAPE THE PLATFORMS

Press SPACE to start
Press I for instructions
Press Q to quit

In Pygame-style code, the menu could be drawn using text:

def draw_text(text, x, y, size=36):
    font = pygame.font.SysFont(None, size)
    image = font.render(text, True, (0, 0, 0))
    screen.blit(image, (x, y))

Then:

def draw_menu():
    screen.fill((255, 255, 255))
    draw_text("ESCAPE THE PLATFORMS", 230, 180, 48)
    draw_text("Press SPACE to start", 280, 260, 32)
    draw_text("Press I for instructions", 270, 310, 32)
    draw_text("Press Q to quit", 320, 360, 32)

The input handling might include:

if game_state == "menu":
    if event.type == pygame.KEYDOWN:
        if event.key == pygame.K_SPACE:
            game_state = "playing"
        elif event.key == pygame.K_i:
            game_state = "instructions"
        elif event.key == pygame.K_q:
            running = False

This gives the game a proper beginning.

It also improves usability because the player is not suddenly thrown into the level without explanation.

Adding an Instruction Screen

An instruction screen is especially useful if someone else will test the game.

Students often forget that they know their own game better than a new user does.

A new user needs to know:

which keys to press
what the objective is
what collectables do
what hazards do
how to win
how to restart

Example instruction screen:

HOW TO PLAY

Move left: Left arrow
Move right: Right arrow
Jump: Space

Collect stars to increase your score.
Avoid enemies and red hazards.
Reach the flag to complete the level.

Press B to return to the menu.

This is a small feature, but it can improve user testing significantly.

It also gives the student evidence of user interface design.

Adding Lives

Lives give the player a limited number of attempts.

A simple lives system might start with:

lives = 3

When the player touches a hazard or enemy:

lives -= 1
reset_player()

If lives reach zero:

if lives <= 0:
    game_state = "game_over"

This creates a clear lose condition.

The player should also be able to see how many lives remain:

draw_text("Lives: " + str(lives), 10, 40, 30)

This makes the game feel fairer because the player understands the consequence of mistakes.

Avoiding the Multiple-Life-Loss Bug

One common problem is that the player loses several lives from one collision.

This happens because the game loop runs many times per second. If the player remains touching an enemy for several frames, the collision may be detected repeatedly.

There are several possible solutions.

One simple solution is to reset the player position immediately.

Another solution is to add a short invulnerability timer:

invulnerable_timer = 0

Each frame:

if invulnerable_timer > 0:
    invulnerable_timer -= 1

When the player touches danger:

if invulnerable_timer == 0:
    lives -= 1
    reset_player()
    invulnerable_timer = 60

At 60 frames per second, this gives about one second before another life can be lost.

This is a useful advanced feature because it introduces timed state management.

It also gives students a good debugging example for their project write-up.

Adding a Score System

A score system gives the player feedback and reward.

The simplest score might increase when the player collects an item:

score += 10

It might also increase when:

collecting a coin
completing a level
defeating an enemy
finishing quickly
collecting all items

For a first version, collectables are enough.

Example:

for item in collectables[:]:
    if player_rect.colliderect(item):
        collectables.remove(item)
        score += 10

Then the score can be displayed:

draw_text("Score: " + str(score), 10, 10, 30)

This supports several success criteria:

The score is displayed during play.
The score increases when a collectable is collected.
A collectable disappears after being collected.
The same collectable cannot be scored more than once.

These are all testable.

Making Scoring More Interesting

Once the basic score works, students can think about better scoring rules.

For example:

coin collected: +10
enemy defeated: +25
level completed: +100
all collectables collected: bonus +50
losing a life: no score penalty
optional hard-to-reach item: +30

This creates design decisions.

Should the game reward risk?
Should difficult collectables be worth more?
Should speed matter?
Should players be encouraged to explore?

A thoughtful student can justify these choices in their project documentation.

For example:

I gave optional collectables a higher score because they were placed near hazards and required more skill to collect. This encouraged players to take risks without making the level impossible to complete.

That is a good design explanation.

Adding a Level Complete Screen

When the player reaches the finish point, the game should respond clearly.

Instead of just stopping or closing, it should show a level complete screen.

Example:

LEVEL COMPLETE!

Score: 120
Lives remaining: 2

Press SPACE for next level
Press M for menu

The state change might be:

if player_rect.colliderect(finish_rect):
    game_state = "level_complete"

This creates a more polished game experience.

It also prepares the project for multiple levels.

Adding a Game Over Screen

If the player loses all lives, the game should show a game over screen.

Example:

GAME OVER

Final Score: 80

Press R to restart
Press M for menu

Input handling might include:

if game_state == "game_over":
    if event.type == pygame.KEYDOWN:
        if event.key == pygame.K_r:
            restart_game()
            game_state = "playing"
        elif event.key == pygame.K_m:
            game_state = "menu"

This gives the player control.

It also makes the game feel complete rather than unfinished.

Restarting the Game Properly

Restarting is not just moving the player back to the start.

Several things may need to be reset:

player position
vertical velocity
lives
score
collected items
enemy positions
moving hazard positions
current level
game state

A restart function can help:

def restart_game():
    global score, lives, player_y_velocity, game_state

    score = 0
    lives = 3
    player_y_velocity = 0
    player_rect.x, player_rect.y = current_level["player_start"]
    reset_level_items()
    game_state = "playing"

This is another useful programming idea.

A function can collect repeated reset behaviour in one place.

Students should be careful here. If collectables have already been removed from a list, they need to be restored when the game restarts. That may mean keeping an original copy of the level data.

Adding High Scores

High scores are a good extension because they introduce file handling.

A simple high score system might store the best score in a text file.

When the game ends, the program compares the current score with the saved high score.

Example:

def load_high_score():
    try:
        with open("highscore.txt", "r") as file:
            return int(file.read())
    except:
        return 0

Saving a high score:

def save_high_score(score):
    with open("highscore.txt", "w") as file:
        file.write(str(score))

Then:

if score > high_score:
    high_score = score
    save_high_score(high_score)

This gives the project a valuable file handling feature.

However, it must be handled carefully.

The student should test:

what happens if the file exists
what happens if the file does not exist
whether the high score loads correctly
whether the high score updates when beaten
whether a lower score does not replace the high score

This is excellent A Level evidence.

Validating High Score Data

A more careful version checks whether the file contains valid data.

For example, if the file is empty or contains text instead of a number, the program should not crash.

The loading function could be improved:

def load_high_score():
    try:
        with open("highscore.txt", "r") as file:
            data = file.read()

            if data.isdigit():
                return int(data)
            else:
                return 0

    except FileNotFoundError:
        return 0

This is a strong extension because it shows defensive programming.

It also gives the student something useful to discuss in testing.

A Simple Game Structure

By this stage, the game structure might look like this:

Start program

Load high score

Set game state to menu

Main loop:
    Check events

    If state is menu:
        handle menu input
        draw menu

    If state is instructions:
        handle instruction input
        draw instructions

    If state is playing:
        update player
        update enemies
        check collisions
        update score and lives
        draw level

    If state is level_complete:
        handle next level or menu input
        draw level complete screen

    If state is game_over:
        check high score
        handle restart or menu input
        draw game over screen

Quit program

This kind of structure can be shown as a flowchart in the project documentation.

That would be excellent evidence of design.

Testing the Wider Game Structure

Testing now needs to cover more than movement and collisions.

Students should test the whole user journey.

Example test table:

Test Number	Test	Expected Result	Actual Result	Pass/Fail
1	Start program	Menu screen appears	Menu appears	Pass
2	Press I on menu	Instructions appear	Instructions appear	Pass
3	Press B on instructions	Returns to menu	Returns to menu	Pass
4	Press SPACE on menu	Game starts	Game starts	Pass
5	Collect item	Score increases by 10	Score increases	Pass
6	Touch hazard	Lives decrease by 1	Lives decrease	Pass
7	Lose all lives	Game over screen appears	Game over appears	Pass
8	Press R on game over	Game restarts	Game restarts	Pass
9	Reach finish point	Level complete screen appears	Level complete appears	Pass
10	Beat high score	High score updates	High score updates	Pass
11	Score below high score	High score unchanged	High score unchanged	Pass
12	Delete high score file and run game	Program creates or assumes score of 0	No crash	Pass

This is much more complete than simply testing the player movement.

It shows that the program works as a whole game.

User Testing: Does the Game Make Sense?

At this stage, user testing should focus on clarity.

Ask a user to play without explaining everything verbally.

Watch what they do.

Useful questions include:

Did the menu make sense?
Were the instructions clear?
Did you understand how to start?
Did you understand the score?
Did you notice how many lives you had?
Did the game over screen tell you what to do next?
Did you want to try again?
Was the high score motivating?

This is where students may discover that something obvious to them is not obvious to a new player.

For example:

A user did not realise that pressing R restarted the game, so I added the instruction “Press R to restart” to the game over screen.

That is useful evidence of user-centred improvement.

Personal Reflection: This Is Where the Project Becomes a Product

I often find this stage changes the way students view their projects.

Before this point, they are mainly thinking as programmers.

Can I make the player move?
Can I make the jump work?
Can I detect the collision?
Can I add an enemy?

Those are important questions.

But menus, scoring, lives and high scores push the student to think more like a designer.

What does the user see first?
How do they know what to do?
What happens when they lose?
Why would they play again?
How does the game communicate success and failure?

This is where the project starts to become a product.

It is no longer just a collection of mechanics. It becomes a complete experience.

That is valuable for A Level Computer Science because it links technical implementation with user needs.

Common Bugs at This Stage

This stage can introduce new bugs.

Bug 1: The Game Restarts but the Score Does Not Reset

This happens when the restart function resets the player but not the score.

The solution is to make sure all necessary variables are reset.

Bug 2: Collected Items Do Not Return After Restart

If collectables are removed from the list during play, they need to be recreated when the level restarts.

Students may need to store original level data and create a fresh copy.

Bug 3: The Game Continues Behind the Menu

Sometimes the player, enemies or hazards continue updating even when the menu or game over screen is displayed.

The solution is to update gameplay only when:

game_state == "playing"

Bug 4: High Score File Causes a Crash

If the file is missing or contains invalid data, the program may crash.

The solution is to use error handling and validation.

Bug 5: Pressing One Key Triggers Too Many Actions

If key input is checked continuously instead of through key-down events, a single key press may skip screens or restart too quickly.

Students should think carefully about event handling.

Each of these bugs can become useful evidence if recorded properly.

Linking Back to Success Criteria

This stage supports success criteria such as:

The game displays a start menu.
The game provides instructions.
The score is visible during play.
The lives remaining are visible during play.
The game displays a game over screen when lives reach zero.
The game displays a level complete screen when the finish point is reached.
The player can restart the game.
The program stores and displays a high score.
The program handles missing high score files without crashing.
User testing is used to improve the interface.

These criteria are specific, measurable and useful for evaluation.

Practical Task for Students

Part 7 Student Task

Add wider game structure to your platform game.

Your program should include:

A start menu.
An instruction screen.
A playing state.
A level complete screen.
A game over screen.
A visible score.
A visible lives display.
A restart option.
A test table covering menu, score, lives and game states.
User feedback on whether the game is easy to understand.

Extension Task

Add one or more of the following:

high score saved to a file
high score validation
multiple player names
level selection menu
pause screen
settings menu
sound on/off option
different difficulty modes
animated menu screen
improved visual design

Students should only attempt these extensions once the basic game structure works reliably.

Development Log Example

A good development log entry might look like this:

Development Stage

Adding menus, lives, scoring and game states.

Aim

To make the game feel more complete by adding a start menu, instructions, game over screen, scoring system, lives system and restart option.

What Was Added

game state variable
start menu
instruction screen
score display
lives display
game over screen
level complete screen
restart function
high score file handling as an extension

Problems Found

The game continued updating while the menu was displayed.
The score did not reset properly after restarting.
Collectables did not reappear after restarting the level.
The high score file caused an error when it was missing.
A user did not know which key restarted the game.

Changes Made

Updated gameplay only when the game state was set to “playing”.
Added score and lives reset to the restart function.
Recreated collectables when restarting the level.
Added error handling for the high score file.
Added restart instructions to the game over screen.

Evidence Collected

screenshots of the menu and instruction screen
screenshot of score and lives display
screenshot of game over screen
screenshot of level complete screen
test table
user feedback
code showing game states
code showing high score file handling

This is strong evidence because it shows planning, implementation, testing, debugging and improvement.

Final Thoughts: A Complete Game Needs More Than a Good Level

At the beginning of this series, the project was only an idea.

Then it became a moving player.
Then a jumping player.
Then a player who could land on platforms.
Then a level with collectables and hazards.
Then a more dynamic game with enemies and moving hazards.

Now it is becoming a complete game.

Menus, lives, scoring, high scores and game states may not sound as exciting as enemies or jumping, but they are essential.

They turn a playable level into a structured user experience.

They give the player instructions, feedback, consequences and reasons to try again.

For A Level Computer Science, this stage is particularly valuable because it shows that programming is not just about making features work in isolation. It is about organising a whole system.

A strong project is not judged only by the most impressive feature. It is judged by whether the program works reliably, whether the user understands it, whether the code is organised, whether testing is thorough and whether the student can explain the decisions they made.

A good platform game is not just a character jumping across platforms.

It is a complete system.

And by this stage, students are starting to build exactly that.