How G1 Computing Visual Programming and Debugging Work

G1 Computing in the 2027 Secondary Education Certificate, syllabus K127, includes visual programming with variables, conditions, loops, sprites and debugging. Module 7 asks students to plan a sequence of events, create a game-like program, identify why it behaves unexpectedly and correct the first wrong instruction. It is about reasoning with program logic, not simply dragging colourful blocks until something moves.

The examination has a 75-minute e-Examination (40%) and a two-hour lab-based paper (60%). The practical paper covers media, document/spreadsheet and programming tasks; programming is allocated approximately 25 of the 90 raw lab marks, but the precise task allocation can vary. The approved software is installed by the examination centre, and required files must be saved within the two-hour assessment.

2027 SEC quick answer

2027 G1 Computing subject: K127; Module 7 is Visual Programming and Game Programming.
Paper 1 e-Exam: 1h 15m, 60 marks, 40%; it covers all seven syllabus modules.
Paper 2 lab: 2h, 90 marks, 60%; its programming task is approximately 25 raw marks.
Module 7 covers variables, if / if-else (no nested ifs), repeat, forever, repeat-until, logical and relational operators and debugging.
Game programming includes stage x/y coordinates, sprites, costumes, backdrops, input events and sprite or colour contact.
Students must distinguish intended behaviour from observed behaviour and test one hypothesis at a time.
Visual programming may be practised with suitable approved software; do not assume a text-based language is the SEC requirement.

This guide explains sequences, named variables, Boolean conditions, loops, stage coordinates, sprite behaviour, collision events and methodical testing using original examples. The specific K127 scope uses visual programming and includes Scratch blocks; it does not require learners to master advanced Python or nested if-statements as compulsory G1 examination content.

Official evidence: SEAB K127 2027 syllabus (PDF) and SEAB 2027 G1 subject directory. This independent article does not reproduce examination material.

What G1 Computing actually asks students to learn

The 2027 Singapore-Cambridge SEC reports subjects at the actual G1, G2 or G3 level taken. Computing at G1 uses code K127. The level refers to an examination subject, not a permanent judgement of a student’s intelligence or future potential. The school confirms each candidate’s subject registration and exact exam instructions.

An effective study method is to understand the task, choose relevant evidence, apply an idea, inspect the result and then transfer the idea to a new example. This guide focuses on the specific skill named in its title, rather than presenting a duplicate summary of every syllabus topic.

The official 2027 paper scheme

Component	Duration or marks	What candidates do
Paper 1 — e-Examination	1h 15m; 60 marks; 40%	All seven modules; 20 MCQs (20 marks) and short structured questions (40 marks).
Paper 2 — Lab examination	2h; 90 marks; 60%	Tasks involving media (~30 marks), documents/spreadsheets (~35) and programming (~25).
Module 7: Basics	K127 outcomes 7.1.1–7.1.14	Events, storyboards, flowcharts, variables, conditions, loops, operators, random numbers and debugging.
Module 7: Game Programming	K127 outcomes 7.2.1–7.2.23	Sprites, coordinates, event triggers, backdrops, sound, interactions and collisions.
Centre software	Provided for lab examination	Approved installed software; candidate has sole laptop use and saves required softcopies.
Calculator rule	Approved calculator allowed	May be used in Papers 1 and 2 as stated in syllabus.

SEAB’s national assessment scheme does not require every school weighted assessment to use the same format. Practical, digital or authenticated coursework remains governed by the official examination centre and school instructions.

How G1 Computing works in practice

Each section explains one principle, what can go wrong and a useful practice activity. The activity is an original illustration and should not be mistaken for an assessed task or an authorised examination submission.

Plan the program in words before using blocks

Students may rush to drag blocks because the interface feels friendly. Yet an attractive game can be built from incorrect logic. A short plan defines what should happen, in which order and which event should start each behaviour.

Make a storyboard with four panels for a fictional catching game: start screen, move a character, catch a falling object and update a score. Ask the student to explain the sequence without opening an editor. This reveals logical gaps before coding.

A flowchart is a map of decisions

Flowcharts can show a start, an action and a decision point. The student needs to understand what follows when a condition is true and what follows when it is false. Memorising arrow shapes does not establish why the program behaves differently.

Use a paper flowchart: Start → Ask for a number → Is the number greater than 5? → Display one of two messages. Predict the result for 4, 5 and 6. A clear boundary test makes the condition meaningful.

An event is a trigger, not the same as a loop

A key press, mouse click or incoming message can start a script. A loop can then repeat its operations. A student who places all logic under the wrong trigger may create a game that works only when a hidden button is pressed.

In a fictional game, pressing a start key begins movement. Ask which block starts the script and which repeats movement. Change the input trigger in an unassessed example and observe the difference.

Variables store values that can change

A variable named score might start at zero and increase when an object is caught. A variable named time might decrease toward the end of the game. Choosing names that match the meaning makes the program easier to explain.

Write a trace table showing score initially 0, then 1 after a catch, then 2 after another. Ask which instruction changes the value and what it should be after three successful catches.

Initialisation prevents stale values

If a game starts with a score left over from the previous run, the program may not have correctly initialised the variable. Students sometimes fix the visible score but ignore the condition that caused the error.

Test an imaginary game twice. If the second round begins with 5 instead of 0, identify where ‘set score to 0’ belongs. Explain why starting state should be established before the gameplay loop begins.

An if statement runs when a condition is satisfied

A conditional instruction does not simply mean ‘something should happen’. It checks a specific true/false relationship such as score greater than five or a sprite touching another object. The question is what value makes the condition true.

Use an original scenario where a ‘well done’ message appears if score ≥ 3. Test scores of 2, 3 and 4 and ask which branch runs. The exact boundary value is often where misunderstanding appears.

An if-else statement chooses between alternatives

If-else provides one action when the condition is true and another when it is false. K127 explicitly excludes nested ifs from the learning outcome, so students can practise clear one-level decisions without inventing more advanced examination requirements.

Imagine a game showing a green message when a target is reached and a neutral message otherwise. Explain both branches and ensure they do not activate simultaneously under the same state.

Repeat and forever loops serve different needs

A fixed repeat loop runs a set number of times, while a forever loop continues until some other stopping or control condition intervenes. Choosing the wrong one can make objects stop too early or keep moving after a round should finish.

For a paper trace, repeat ‘increase steps by 1’ four times starting from zero. The final value is 4. Compare that with a forever loop and ask what additional event would be needed to stop the game.

Repeat-until uses a stopping condition

A conditional loop repeats until its condition becomes true. If the condition can never be reached, a program may run indefinitely or behave unexpectedly. Students should test whether the loop’s state actually changes toward the stopping point.

An original logic exercise says ‘repeat until timer = 0; reduce timer by 1’. Start at timer 3 and trace 3 → 2 → 1 → 0. Then ask what happens if the instruction accidentally increases timer instead.

AND, OR and NOT combine conditions

Logical operators help define more nuanced rules. AND means both conditions; OR means at least one; NOT reverses a condition. Confusing OR with exactly one can cause a game to reject an event when two relevant conditions happen together.

Practice with A = player touches target, B = round is active. A score should increase only if A AND B is true. Evaluate a small truth table and explain what the condition protects against.

Relational operators compare values

The K127 syllabus lists greater than, less than and equals among tested relational comparisons. A learner must know what each says and avoid off-by-one errors at a threshold. The problem can be logical even when no arithmetic is difficult.

If the game ends when score > 10, it should not end at score 10 under that condition. Compare with score = 10 or score ≥ 10, and note which comparisons are actually available in the program’s implementation.

Random numbers introduce variation, not guaranteed fairness

Random values can change an object’s position or another game condition. Students must understand how the chosen range affects possible outcomes. A program that picks only one possible value is not creating useful variation.

Use a fictional game choosing one of three lanes at random. Ask which lanes are possible and how to test whether all are reachable. Avoid claiming an exact distribution from a very small sample.

Stage coordinates locate a sprite

Visual games use a two-dimensional stage with x and y coordinates. A student’s sprite may disappear because it was moved outside the visible stage rather than because a costume is missing. Reading the coordinates is a practical debugging step.

Draw a blank Cartesian stage with an origin and a few labelled positions. Ask where a sprite should be placed to start near the centre versus a corner. The actual coordinate range depends on the authorised program stage.

Sprites and backdrops have different roles

A sprite is an object that can have instructions, positions and costumes; the stage can have backdrops and its own code. The user may confuse changing a backdrop with moving a sprite, but these actions affect different elements.

In an unassessed exercise, describe how the background changes from ‘Menu’ to ‘Play’ while a character remains a sprite. Ask which part should receive the action and why.

Costumes change the sprite’s appearance

A sprite can switch among costumes to show a state or simple animation. That does not automatically change its collision boundaries, size or location in exactly the way a learner imagines. The program’s state must still be tested.

Create a fictional sprite with two drawn expressions. When the score changes, switch to the second costume. Explain what visual feedback it gives and whether the score variable was updated separately.

Messages coordinate separate scripts

Broadcast-style messages can trigger other sprites or the stage to begin their own code. A student may have the correct movement script but never activate it because the message is not sent or received as expected.

Outline a practice event: pressing start broadcasts ‘begin game’; receiving that message starts the falling object’s motion. Trace which object sends and receives. Keep the exercise within the syllabus’s supported event concepts.

Collision or colour contact is a condition, not a whole game design

K127 includes detecting contact between sprites or coloured areas of objects. When a sprite touches an item for several frames, the condition may remain true repeatedly, causing a score to increase many times.

Imagine a character overlaps a target for half a second. If the code increments score in a forever loop during contact, the score may rise repeatedly. Consider a game rule that prevents repeated scoring until the target resets, and verify it within an authorised visual-programming environment.

One bug can have several plausible causes

A character fails to move. The cause could be a missing start event, incorrect direction, conflicting scripts, a hidden sprite or a coordinate outside the stage. Guessing the answer from the symptom alone can waste time.

Write the observed symptom, list two possible causes, and check one by one. For instance, confirm whether the script starts before altering the movement number. A controlled test reveals more than randomly replacing several blocks.

Change one thing, then test again

Debugging is a method for learning why the program differs from intended behaviour. Changing five blocks and seeing a correct screen does not establish which change fixed the issue, or whether a hidden new error was introduced.

After reproducing a bug, alter one relevant instruction and run the same test. Record the result. If the problem remains, restore the old state or test the next hypothesis. This habit becomes useful in many technical fields.

Test boundary and repeated-run conditions

A program may pass one demonstration but fail when the player scores at the exact threshold or restarts the game. Good testing includes values just below, at and above a condition; and whether variables reset after stopping.

For a winning score of 5, test 4, 5 and 6 where appropriate. Then run a second game and check that the score begins as intended. Repeated tests expose errors that a successful first run can hide.

Sound and media should support the event

Module 7 includes playing sounds, voice recording and simple audio editing within the game. Extra audio may improve user feedback, but unnecessary clips can make the game confusing or create copyright and privacy issues.

Use the game’s original or properly permitted sound for a target catch and a different sound for a game end. Ask whether the audible events help the player understand what happened. Never assume commercial recordings may be copied freely.

Saved files are part of the examined result

The two-hour lab exam includes time to save the required softcopies. A correct program that has not been saved to the specified location may not be available for marking. File naming and verification belong in every practical rehearsal.

During a school-approved practice, save the project, reopen it where possible, test its core interaction, and confirm the required filename and location. Do not trust that seeing the project open on screen means the correct file was submitted.

The software is a tool for thinking, not a measure of intelligence

Some students take longer to find a block in an editor while being strong at the underlying logic. Others build attractive games from tutorials but cannot explain why the code works. The learning goal is an independent logical solution using the prescribed environment.

Ask a learner to explain one program script in plain language before clicking anything. Then change one requirement and invite them to adapt the logic. That reveals whether understanding transfers beyond a memorised tutorial.

Keep lab practice balanced across all tasks

Programming is approximately 25 raw marks of a 90-mark Paper 2. Media and document/spreadsheet tasks remain important. Families should avoid making the student spend the entire practical revision period perfecting a game while ignoring the other two required tasks.

Make a weekly checklist of one media output, one document/spreadsheet task and one visual-programming task. Finish each with a save-and-verify routine and name the most common error in that software category.

Original worked examples and explanations

The examples here were created for teaching. They are not official specimen questions, leaked visual stimuli or model answers that SEAB has approved.

Worked example — a score that rises twice

An original sprite game should increase score by one when a character catches a falling item. A learner observes that one catch occasionally adds three points instead.

Possible cause: the contact test remains true during several iterations of a forever loop, so the increment runs repeatedly. Reproduce the case, inspect the repeated condition and test an appropriate one-catch rule. Do not assume it is merely an arithmetic mistake.

Worked example — a game that never ends

A paper program starts a timer at 10 and repeats until timer = 0. Inside the loop the developer accidentally increases the timer by one instead of decreasing it.

Because the timer moves away from zero, the stopping condition is not reached. Test with initial values 2 and 1 and trace the state changes. Correct the variable update and verify that the loop can reach its intended end.

Worked example — wrong coordinate

An imaginary game uses a visible stage with a centre origin. The sprite is placed far outside the expected visible region and appears missing when the game starts.

The program may have created the sprite correctly but assigned an unsuitable initial position. Inspect the coordinates before deleting artwork or redrawing the sprite. A hidden-object symptom can have a position cause.

Worked example — if-else threshold

A fictional program displays ‘Ready for bonus’ when score is greater than 5, and ‘Keep playing’ otherwise. At score 5 it still shows ‘Keep playing’. The student claims the program is faulty.

The observed behaviour follows the stated ‘greater than 5’ condition. If the intention was to trigger at 5 or above, the logical rule needs revision; the difference is at the boundary rather than in the display block.

Worked example — the second run starts with a stale score

At the end of the first practice game, score is 8. The student presses start again and immediately sees score 8 even though the new round should begin at zero.

The start event has not correctly initialised score. Add or repair the appropriate reset within the authorised visual-programming editor, then test two complete runs. A single successful run was not enough evidence of correct design.

Common mistakes and how to fix them

What goes wrong	What may be missing	Focused repair
The game score increases multiple times for one catch	Contact condition stays active during a loop	Trace repeated triggers and test a controlled reset.
A program never stops	Stopping condition is unreachable	Trace variable updates and condition truth over iterations.
A sprite is invisible after the game starts	Wrong location, size, visibility or stage	Check state and coordinates before recreating media.
An if statement activates at the wrong threshold	Comparison operator or boundary confused	Test just below, at and above the limit.
A second playthrough retains old values	Initialisation step missing	Reset variables at the intended starting event.
Only the background changes but character should move	Stage and sprite roles mixed	Identify the object that owns each script.
Several changes are made at once during debugging	Root cause cannot be identified	Change one instruction per test and record the result.
The saved file does not contain the last fix	Save/verification step omitted	Reopen or verify the submitted file after final testing.
Programming practice excludes media and spreadsheets	Paper 2 is misunderstood as only coding	Practise all three lab tasks according to their indicative marks.

Keep a short error log. Name the earliest misunderstanding, make one targeted correction and practise a different example after several days. A student may reproduce yesterday’s correct answer while still lacking the underlying skill.

Four weeks of targeted learning

This is a manageable revision plan, not the national exam calendar and not a grade guarantee. It should be adapted to school feedback and actual candidate requirements.

Week 1 — storyboard and logic

Plan a small fictional game using a flowchart, variables and one conditional. Explain inputs, actions and expected outcomes before using software.

Week 2 — loops and events

Create a simple unassessed visual-programming exercise with repeat, forever and repeat-until, start events, coordinates and a score. Test boundary behaviour.

Week 3 — sprites and debugging

Add a second sprite and a contact event in a school-approved setting. Reproduce one deliberate bug, state a hypothesis, change one instruction and retest.

Week 4 — examination-shaped practice

Complete an unfamiliar small visual-programming task, save and reopen it. Integrate brief practice for media and spreadsheet/document tasks, and check that the learner can explain independent changes.

A simple weekly learning cycle

Recall one important concept without copying notes.
Try one unfamiliar problem that requires the same principle.
Explain the answer and the evidence for it.
Correct one specific error and test the change.
Return after several days to check the learning is stable.

How parents, teachers and tutors can help

A child may need a missing foundation repaired, a previously learned idea made reliable, or an unfamiliar application after mastering the basics. These are different teaching situations. Ask where the learner first becomes uncertain instead of immediately assigning more tasks.

The immutable eduKateSG Clementi Mathematics tutorial reference informs this series’ reader-first structure: immediate useful information, first-principles explanations, original examples, precise error diagnosis and achievable next actions. The actual assessment details here are independently checked against the K127 syllabus; reproducing a structure is not a guarantee of Google ranking.

eduKateSG’s three-student small-group tutorials can offer close feedback when needed. Not every child requires additional tuition, and no responsible tutor can promise a specific SEC grade. For supervised portfolio or laboratory examinations, the learner must remain the authentic creator and follow the school’s instructions.

Frequently asked questions

What is the 2027 G1 Computing syllabus code?

K127, introduced as a new G1 Computing syllabus for SEC 2027.

Is Scratch or visual programming included?

Yes. The syllabus includes visual programming and a list of examinable Scratch blocks.

Is advanced Python compulsory for G1 K127?

No. The stated programming learning outcomes are framed around visual programming; do not substitute advanced text-based programming as a compulsory requirement.

Are nested if-statements examined?

The K127 outcome explicitly says no nested ifs for the if and if-else instructions.

What loops are in the syllabus?

Repeat, forever and repeat-until.

Why can one sprite collision score several times?

A contact condition can remain true during multiple iterations of a loop, repeatedly activating its instructions.

How many marks is the practical programming task worth?

Approximately 25 raw marks within the 90-mark, two-hour Paper 2 lab examination.

Can students use their own software in the actual exam?

The centre provides the approved installed software and computer facilities; follow its actual instructions.

Does finishing the program mean the work is submitted?

No. SEAB requires saved softcopies and includes saving time in the allotted two hours.

How can a parent help without programming skills?

Ask what the program should do, which state changed, why an error appeared and whether the corrected version still works on a new test.

How can parents tell that learning transferred?

Give the learner a changed problem after several days. A secure student can identify the task, apply the relevant principle and explain why a tempting wrong answer fails without being shown the previous worked example.

Official documents and related eduKateSG guides

Beyond the examination: Visual programming is a way to make thinking testable. The lasting skill is noticing why a system behaves differently from its intended rule, then changing it deliberately and checking again.

Editorial fact-check: 13 November 2026 using the published 2027 SEAB syllabus and the school’s responsibility for candidate work. Worked scenarios are independent teaching examples; official instructions take precedence.

How G1 Computing Visual Programming and Debugging Work | SEC Guide