G2 Computing Scratch Programming is one of three compulsory practical task areas in Singapore’s 2027 Singapore-Cambridge Secondary Education Certificate (SEC), syllabus K237. Paper 2 is a 2-hour-15-minute laboratory examination worth 80 marks, or 50% of the Computing result, and Programming accounts for approximately 25 marks alongside Media Software (about 30) and Spreadsheets (about 25). The official Module 6 includes block-based programs, flowcharts, variables, conditions, loops, logical operators, random numbers, lists, custom blocks and Scratch game actions. Candidates must create functioning digital work, test it and save the requested files within the examination period. Microcontroller content is explicitly assessed in Paper 1 only, not the practical Paper 2.

For Punggol parents, a teenager may enjoy playing Scratch games and even drag blocks fluently but still struggle to write a reliable program from an unfamiliar specification. A score counter that increases on every animation frame, a character that cannot stop moving, a collision detector that fires twice or a broadcast that nobody receives can all result from small logical mistakes. The strongest preparation uses an original brief, a short plan of expected behaviour, small independent tests and deliberate debugging. Confirm the child’s K237 registration and the examination centre’s approved software. This guide explains what students must understand about the programming task without presenting any sample game as a guaranteed national examination question.

• 2027 SEC G2 Computing K237, Module 6 Programming; Paper 2 is a practical lab examination.
• Paper 2 lasts 135 minutes, carries 80 marks and contributes 50% of the Computing subject.
• Programming accounts for approximately 25 marks, with three practical task areas compulsory.
• Block programming uses graphical instructions; in the 2027 scheme Scratch is used for game programming.
• Fundamentals include sequencing, flowcharts, variables, initialisation and updating values.
• Selection includes IF and IF-ELSE, with up to one level of nested IF in the syllabus.
• Loops include basic and conditional repetition; conditions use AND, OR, NOT and comparisons.
• Lists can store and retrieve elements by index, insert/delete items, test membership and join lists.
• Custom blocks group instructions; events and broadcasts coordinate multiple sprites.
• Games may require stage coordinates, sprite movement, costumes, backdrops, sounds and inputs.
• Contact between sprites or coloured areas can trigger rules, but collision tests must be precise.
• Microcontrollers and MakeCode content are marked Paper 1 only in the official syllabus.
• Students should test expected behaviour, debug one cause at a time, save and reopen the actual project.

Definition lock: Scratch is programming, not just animation

A Scratch project contains blocks that define what happens when events occur, how values change and how objects respond. Making a character move visually is only part of the skill. A functioning game may need correct scoring, time limits, responses to player input, scene changes and a coherent ending. The examination measures the ability to implement specified behaviour rather than decorate a stage with interesting sprites.

G2 refers to the level of this one subject under Full Subject-Based Banding, not a child’s Secondary 1 Posting Group. K237 is the official Computing code from 2027, and the practical environment depends on the authorised centre. A student who recognises blocks from a tutorial still needs to solve fresh problems independently and explain how the program’s logic works.

Where Programming fits inside the 80-mark practical

Paper 2 contains three required task areas: Media Software approximately thirty marks, Spreadsheets approximately twenty-five and Programming approximately twenty-five. The allocations are approximate, so candidates should follow actual task instructions and not assume every subskill receives a predetermined number of marks. All three practical tasks must be completed and submitted within the one 135-minute lab sitting.

Parents should observe whether the student spends so long polishing one game that their other practical outputs are unfinished. In a mock, allocate sensible working time to each requested artefact and protect time for testing and saving. A beautiful game cannot compensate for a missing spreadsheet if all tasks are compulsory.

Scratch versus microcontrollers: the important boundary

Module 6 contains microcontroller outcomes using sensors, LEDs and related components, but the official syllabus marks that section for Paper 1 only. Scratch blocks in basic and game programming are assessed in Papers 1 and 2. Students should not build a physical electronics project at home believing it is an additional national lab task. Computing and Design & Technology also have different assessment requirements.

Ask the teacher which syllabus outcomes are examinable in the practical and which belong to the electronic theory paper. A simple subject map can prevent wasted revision. Exploring microcontrollers for interest may be worthwhile under appropriate supervision, but it should not displace required Scratch lab skills.

First plan the program’s expected behaviour

A program is a set of instructions implementing a purpose. Before placing blocks, the student should understand what the project must do from start to finish. A requirement such as ‘increase the score when the player touches a target’ contains a trigger, condition and state change. If those are not separated, a program may add points continuously instead of once per contact.

Write a brief plan for a fictional game: initialise score to zero; start after the green flag; move the player with arrow keys; add one point only for a valid collision; end at ten points. The plan is not the exam’s official game, but it illustrates how to translate human instructions into precise control logic.

Flowcharts make the sequence visible

The syllabus includes interpreting flowcharts as representations of program order and decisions. A student can draw attractive arrows but still omit the loop that returns to check the next event. Correct flowcharts distinguish a decision from an action and show the paths followed when a condition is true or false. That model can guide later block construction.

Give the teenager a tiny fictional quiz rule: display a question, receive an answer, check it and update feedback. Ask for a flowchart with a meaningful decision and two outcomes. Then compare the chart with the Scratch blocks. If the arrows do not match the behaviour, correct the logic before adding visual effects.

Sequence: the order of blocks matters

Actions normally execute according to the structure of the code. Moving a sprite before resetting its position can produce a different result from resetting first. In games, starting variables, costumes and positions in the wrong order can create confusing opening states. A block that is correct individually can still be wrong when it appears at an unsuitable point.

Use an original three-step sprite example: set the initial x coordinate, set the costume, then display the opening message. Swap the order deliberately and observe differences. A child should be able to predict what happens before running the program. Prediction is evidence of understanding.

Event blocks decide when actions begin

Scratch often uses events such as the green flag, a key press or a sprite click to trigger scripts. Students sometimes attach correct actions to the wrong event, so the program appears unresponsive during the intended interaction. The code may run correctly when manually clicked in the editor but fail in the actual game.

Create a fictional character that should jump only when a designated key is pressed. Ask which event starts the action and whether the program responds at the correct time. Then test a different key. This helps distinguish event selection from movement logic.

Variables store values that can change

A variable is named storage for information such as score, lives, elapsed time or current level. The programmer must decide what it represents, where it is initialised and which actions update it. A score variable left over from a previous run may produce an unexpected starting value unless it is reset appropriately. Naming also matters because vague variable labels make debugging difficult.

Use an original score variable called points, initialise it to zero and update it only after a valid event. Run the program twice and check the starting state. If the score carries over unexpectedly, identify the missing reset rather than manually changing the displayed value.

Initialisation should happen at the right time

Initialising a variable inside a continuously repeating loop can reset it every frame, preventing progress. Conversely, initialising it only when a sprite receives a late message may leave it undefined or inconsistent at game start. The required state belongs to a specific event in the program lifecycle. This is a common cause of programs that seem visually correct but never reach the next level.

Ask the learner to trace a fictional timer from the green flag through several updates. Where should it start at zero? Where should it increase? Place those operations conceptually before building blocks. A clear lifecycle model prevents repeated trial-and-error clicking.

Conditions make a choice based on information

IF executes an action only when a condition is met, while IF-ELSE offers two possible paths. The 2027 syllabus includes nested IF up to one level. A condition can be syntactically valid but express the wrong game rule. For example, awarding points when a sprite is not touching a target reverses the intended action.

Use a fictional rule: if the player touches a star, increase points; otherwise continue movement. Write the two outcomes in plain language, then assemble corresponding blocks. Test both contact and non-contact states. The goal is correct logic, not merely recognising a colourful IF block.

Nested IF should not become a maze

One level of nested selection is included in the prescribed scope. It can be useful when a second test matters only after the first is satisfied, but overly complex nesting can obscure the program’s purpose. Students should identify whether the inner condition is truly dependent or whether two separate decisions would be clearer.

Imagine that a bonus is awarded only when the player touches a goal and still has time remaining. Ask whether the conditions can be combined with AND or expressed in a simple nested decision. Trace each possible case before implementing it. The student should understand the rule, not simply choose the longer code.

AND requires both conditions to hold

The logical AND operator is appropriate when all specified conditions must be true. If the student mistakenly uses OR, an event may trigger when only one requirement is met. A game could award a bonus whenever the player is near the target, even after the timer expires. Testing only the successful case can hide this error.

Create a truth table for touching the target and having time left. Test all four combinations. Then implement the rule and verify that only the intended case awards points. Truth tables translate verbal rules into dependable programming behaviour.

OR accepts either qualifying condition

OR fits situations where either of two conditions is sufficient. A student using AND may unintentionally require both and create an impossible or overly restrictive event. The correct operator depends on the game’s specification. Similar-looking blocks can express fundamentally different rules.

Make a fictional safety game in which touching either of two coloured hazards should end a round. Test each hazard alone and then both. The child should explain why OR is appropriate. This reasoning transfers to spreadsheet logic and formal problem-solving.

NOT reverses a condition

NOT converts a true condition to false and vice versa. It can be useful for a loop continuing while a game has not ended, but a misplaced NOT can invert the logic. Students sometimes read ‘not touching’ as the same as ‘touching’ when scanning nested blocks quickly. The resulting bug may appear as continuous scoring or premature termination.

Write two short rules in ordinary language: move while not touching the wall, and stop when touching it. Then map each to the appropriate condition. The learner should predict the action for both states before testing.

Comparisons matter at boundary values

The syllabus includes greater-than, less-than and equality comparisons. A game rule such as ‘finish at ten points’ may behave unexpectedly if the counter jumps from nine to eleven and the program tests only exact equality. Understanding boundary conditions helps make control logic robust. Students should implement precisely what the brief requires and test plausible edge cases.

Use a fictional score rule that ends when a threshold is reached. Check results at one below, exactly at and above the threshold. Ask why one comparator may suit the design better than another. The aim is careful specification interpretation rather than a universal magic symbol.

Repeat loops execute a stated number of times

A repeat loop can perform an action multiple times without duplicating blocks. A common mistake is putting an update outside the loop when it should occur on each iteration, or repeating an initialisation that should happen only once. The effect of the program depends on the blocks contained inside the loop.

Use a small animation that changes x position by five units four times. Predict the final displacement before running it. Then move the update outside the repeat block and compare. This demonstrates loop scope more clearly than a memorised definition.

Forever loops need appropriate controls

A forever loop repeatedly checks or executes actions while the program runs. It is useful for monitoring keys or movement, but can also cause a score to increase rapidly when the player stays in contact with a target. A program that looks as though it has a score bug may actually be executing exactly what the repeated instruction demands.

Create a fictional contact test and observe what happens while two sprites overlap. Then introduce a way to distinguish a new valid contact from continuous overlap. The learner should explain why the original behaviour occurred before changing the code.

Repeat-until and while loops depend on conditions

Conditional loops run according to whether a condition has been satisfied. Their termination must be reachable, otherwise a process can continue unexpectedly. Students should distinguish a loop condition checked before or during execution according to the block’s semantics. A missing variable update can prevent the loop from ending.

Use a counter starting at zero and increasing to five. Trace each iteration in a table and show when the stopping condition becomes true. Then remove the update conceptually and ask what happens. This teaches termination without a complicated game environment.

Random numbers support variation but need limits

The syllabus includes generating and using random numbers. These can vary a target position or select a challenge, but the range and required behaviour must remain appropriate. Randomness does not excuse a game that places a sprite outside the usable stage or generates impossible states. A correct program keeps randomness within a valid specification.

Create an original sprite that appears at a randomly selected x position within a safe range. Check that the location remains visible across several runs. Then narrow the range and explain the effect. The student should see that random selection still follows deterministic rules about what values are allowed.

Coordinates define positions on the Scratch stage

The Scratch stage uses x and y coordinates. A student may confuse horizontal and vertical movement or assume that dragging the sprite once sets a permanent starting point. Specific coordinates are important when the task requests an exact position, boundary or movement. A program can look approximately right while missing a stated location.

Place a sprite at a given invented coordinate and move it ten units horizontally. Which coordinate changes? Then move vertically and compare. Reset before each trial. Understanding the grid allows accurate programmed movement rather than endless manual adjustment.

Orientation and rotation change movement

Sprite direction affects how motion commands behave. A student may make a character travel the wrong way because its orientation was not set, or rotate unexpectedly because the rotation style differs from what the task intends. Position and orientation should be treated as separate properties of the game state.

Use a fictional arrow sprite and set its initial direction, then execute one movement. Rotate it and repeat. The learner should predict the new behaviour. Such practice shows why a seemingly correct movement block can produce the wrong direction under another starting state.

Costumes allow states to be shown visually

Sprites can have several costumes, which may represent walking, collecting an item or reacting to an event. A program can switch costumes at specified times or conditions. Students sometimes change the costume but forget to reset it when the game restarts, causing an incorrect initial appearance. The costume is part of the state, not merely decoration.

Create two original costumes for an invented character, one neutral and one celebrating. Change to the second after a valid scoring event and reset at the green flag. Then restart twice. If the initial appearance is wrong, examine where costume initialisation occurs.

Backdrops define the stage’s current scene

The stage can change backdrops to represent a new level, instruction screen or ending. A student may create the required backdrop but never trigger its display. The logic should link the scene change with a particular event or message. Multiple sprites may also need to respond to the change consistently.

Use an original two-scene game in which an opening backdrop changes after a start button is clicked. Test whether unrelated sprites remain visible or hidden as required. The student should identify which scripts respond to the event instead of manually changing the scene in the editor.

Show, hide and layer behaviour

Game specifications may ask a sprite to appear only at particular stages. A student can correctly move the character yet leave it visible on a start screen where it should be hidden. Resetting visibility when the program starts and changing it at the proper event are common practical needs. A visual object should behave according to the game’s logic.

Create a fictional target that appears after a countdown and hides when collected. Run the game more than once and observe whether the target returns at the right time. The learner should trace show and hide commands as state changes, not random visual adjustments.

Broadcast messages coordinate different sprites

One script can broadcast a message that triggers another object’s code. This allows sprites and backdrops to coordinate without each being manually clicked. A common bug arises when a message is broadcast but no receiving script is listening for the correct message name. Another occurs when the receiver starts before its required initial data are ready.

Build an original mini-game where reaching a score threshold broadcasts ’round-complete’ and a second sprite responds with feedback. Then deliberately change the receiver’s message name and observe the failure. The learner should identify the cause before correcting it.

Multiple scripts can run at the same time

The 2027 syllabus explicitly includes recognising concurrent code sequences in Scratch. A sprite may run a movement loop while another script handles input or sound. Students who assume everything executes as one simple top-to-bottom sequence can be surprised by conflicting updates. Understanding concurrent scripts helps explain otherwise mysterious behaviour.

Use two scripts that both change the same variable under different events. Predict whether they might interfere and test. Then assign separate responsibilities or introduce a controlled trigger. The practice illustrates concurrency in a safe block-based environment without needing advanced threading concepts.

Keyboard and mouse inputs trigger meaningful actions

An event can depend on a key press or mouse click, but the correct input needs to be connected to the intended behaviour. Students may assign the wrong key or use a continuous key-state test when the specification requires one action per press. The difference can change how quickly a score increases or how far a character moves.

Create a fictional character controlled by arrow keys and a clickable start button. Test each input separately and in combination. Ask whether the behaviour matches the brief. This develops reliable interaction rather than reliance on the programme looking animated.

Contact between sprites supports collision rules

The syllabus includes checking contact between sprites or coloured areas. Collision detection can trigger collecting items, losing lives or changing scenes, but the rule depends on the exact contact condition. A sprite that overlaps a target for several frames may satisfy the condition repeatedly. The programmer must consider whether repeated triggering is intended.

Use a simple original game where touching a star should add one point and move the star away. Test what happens if the star remains in place. Discuss why moving it, waiting for separation or managing a state variable could avoid duplicate scoring under an appropriate design. The goal is to understand the logic, not copy a mysterious workaround.

Lists store ordered groups of values

Lists or arrays can contain several related items, such as questions, words or scores. The syllabus includes creating and initialising lists, reading and writing items, inserting and deleting at indices, checking membership and joining lists. A student may confuse an item’s value with its position, especially when the list changes after deletion.

Use a fictional list containing three quiz prompts and ask what appears at the second position. Insert a new item and repeat. Then delete an entry and explain how the positions change. This builds reliable indexing rather than relying on visual guesswork.

Membership tests answer a clear question

Checking whether an item is or is not in a list is different from reading the item at a known index. The first asks about presence; the second retrieves by position. A student using an index check to decide membership may fail when the list order changes. The correct operation follows the purpose of the game rule.

Imagine an original vocabulary game with a list of accepted answers. Ask how to check whether an entered word belongs to the list. Then rearrange its order and test whether the acceptance rule still works. This reveals why membership is not the same as a fixed position.

Joining lists can create a new sequence

The syllabus includes joining two lists or arrays. When combined, ordering and duplicate items may matter to later operations. Students should not assume that joining lists automatically removes duplicates or sorts contents unless the chosen blocks explicitly do so. A program may appear to work with a small test but fail when repeated values are present.

Create a fictional list of science terms and another of mathematics terms, then join them. Check the resulting order and whether any repeated word remains. Explain how that affects a subsequent search or quiz selection. This connects data structures with program behaviour.

Custom blocks reduce repetition

Scratch supports defining reusable sequences as custom blocks. These can organise an operation such as resetting player state or updating the scene. A custom block does not magically fix logic; it executes the instructions placed inside it. The name should communicate its role so the learner can inspect the program more easily.

Create an original reset routine setting score, position and costume to initial values. Call it when the game starts and verify that all three properties are restored. If one remains unchanged, inspect the custom block’s contents. This teaches abstraction through meaningful function.

Sound effects and voice need appropriate controls

Module 6 includes playing sounds, recording voice and basic sound editing such as trimming and volume adjustment. An audio effect should occur at the intended event, not repeat continuously because the relevant block sits inside an uncontrolled loop. Sound can support feedback, but excessive playback may obscure the game or make it difficult to test other actions.

Use a self-recorded short sound to acknowledge a correct answer in a fictional game. Test whether it plays once per event. Then examine trimming and volume in the approved software. Only use original or authorised audio; personal recordings should be made with consent.

An input prompt should be handled consistently

Scratch can ask a question and accept text input. The program then needs to compare that input with the intended answer. A common mistake is assuming the user always enters exactly the same spacing or capitalisation as the developer, or testing a response before the input has been received. The specified comparison rules should be followed.

Create a simple original quiz with one authorised answer and test correct, incorrect and empty responses. Decide what the task expects for each case. This develops robust interaction rather than a game that only works for the teacher’s demonstration.

Debugging begins with the expected result

A bug is a difference between intended and actual behaviour. Randomly moving blocks may temporarily change the symptom but provide little understanding. A stronger debugging method records what should happen, observes what actually happens, isolates the earliest divergence and tests one change. The mistake may involve event triggers, variable initialisation, conditions or sprite state.

Choose a fictional game that unexpectedly awards two points per collision. Reproduce the behaviour, inspect the repeated condition and make one targeted correction. Then test several contacts. If it still fails, revise the explanation. The process builds an independent computing mindset.

Test boundary cases, not only success

A program can look correct when the learner performs its intended action exactly once, yet fail when the score reaches a threshold, the timer expires or a key is pressed rapidly. Testing boundary values reveals weak logical assumptions. The syllabus includes debugging because programs must behave as specified across relevant cases, not simply during one demonstration.

For a fictional five-point game, test scores four, five and six where feasible. Also test restarting after completion and clicking when the game is inactive. A systematic test table makes issues visible and connects Scratch programming with mathematical reasoning.

Separate a logic error from a visual error

A hidden sprite may appear to be missing because visibility is wrong, even when its movement code works. A score might show a correct value on screen while an internal variable used elsewhere is incorrect. Identifying whether the failure concerns state, display or logic prevents unnecessary editing of unrelated blocks.

Ask the pupil which behaviour is wrong and what evidence would discriminate among causes. Try showing a variable or temporarily using a clear indicator during practice. Then restore the requested interface before submission. Debugging should isolate a mechanism, not add random effects.

Saving an editable Scratch project is essential

The official practical examination requires candidates to submit softcopies of their work, with the allotted 135 minutes including saving time. A functioning game that exists only in a temporary editor state may not be available for marking. The correct file location, format and name come from the current examination-centre instructions. Home habits should reflect those requirements.

After finishing a practice project, save it, close or reload it safely and test whether the script and assets remain. Check one input event and one score update in the reopened version. The student should perform this procedure independently rather than trust a parent to preserve the work.

A fictional Punggol-themed Scratch game

Imagine a completely invented educational game in which a character collects symbols associated with a reading challenge. The character moves on a coordinate grid; collecting a valid symbol increases score; touching a forbidden zone removes one life; reaching a stated threshold changes the backdrop. This is an original teaching scenario, not an official SEC examination question or a real school project.

Ask the student to break the requirements into events, variables, conditions, loops and visuals before constructing them. Test each part separately, then combine. If the combined game fails, identify the first interaction that changed the expected behaviour. This is more transferable than copying a polished video tutorial.

A 135-minute exam demands priorities

Programming is one part of a single 135-minute Paper 2 that also includes media and spreadsheet work. Students should satisfy essential functional requirements before spending extensive time on optional costumes or sound effects. A complete functioning project can be more valuable than a visually elaborate file with broken scoring or missing interactions.

During a mock, note how long the student takes to create the basic logic, test it and save. If visual decoration consumes excessive time, change the order of work. The syllabus does not prescribe an exact number of minutes for Programming; good preparation builds realistic independent pacing.

A twelve-week Scratch preparation plan

Weeks one and two establish a baseline game with one event and score. Weeks three and four practise variables, conditions and truth tables. Weeks five and six develop repeat and conditional loops, stopping rules and random numbers. Weeks seven and eight focus on sprite coordinates, costumes, backdrops and messages, with earlier skills revisited.

Weeks nine and ten add lists, custom blocks, inputs, sound and deliberate debugging. Weeks eleven and twelve integrate a fresh game task with the other Paper 2 practical components under realistic timing and with a file audit. Success means the learner can implement an unfamiliar brief without another person assembling the blocks.

Punggol schools, independent practice and safe learning

Families may research Edgefield Secondary, Greendale Secondary, Punggol Secondary and Yusof Ishak Secondary through MOE SchoolFinder and official school materials. The national K237 syllabus is an available subject, not proof every school offers it to each cohort. Confirm the child’s registered course and its actual approved lab software before arranging support.

A matched three-student tutorial may allow learners to explain each other’s bugs, but every pupil must build and test a new project independently. Some children need only school lab practice and short home tasks; others benefit from focused teaching of conditions or lists. Avoid projects using private data or copyrighted media without permission.

FAQs and the official K237 references

Is Scratch the whole Computing Paper 2? No; Programming is one of three compulsory tasks. What is its approximate mark allocation? About twenty-five of eighty. Does the official syllabus include lists and custom blocks? Yes. Do Microcontrollers form part of the practical Paper 2? The K237 syllabus marks them Paper 1 only. Does a project need to be saved before time ends? Yes; the 135 minutes include saving required work. Are all programming outputs games? The specified module includes game programming, while general computational thinking supports it.

See SEAB’s 2027 G2 directory and the official K237 syllabus, Module 6 and the programming-block appendix. The Paper 2 overview, Spreadsheets and Media Software complete the practical map. Start with one original two-sprite game and a written three-case test plan.