Commit 07b621

2026-06-08 12:58:03 lisa: C05-3: add the three thinking-step pages plus a Godot creative-thinking page - Shoulders of Giants (Step 1), Connect the Dots (Step 2, rebuilt with a Godot double-jump trace), Plan B Ready (Step 3) — all game/Godot-flavoured, scaffold-faithful - Creative Thinking for Your Godot Project — seven optional moves (diverge, grey-box prototype, remix, constraints, game feel, ecosystem remix, document pivots) to generate creative-thinking evidence - Added C5-3 section to the home index Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

sd/C05/C05-home.md ..
@@ 24,6 24,15 @@
	- [UX Characteristics](/sd/C05/UX%20Characteristics) — the four UX characteristics (affordance, interoperability, security, usability), each with videos and worked examples
	- [The Annotation Verb Ladder](/sd/C05/The%20Annotation%20Verb%20Ladder) — climbing Identify → Describe → Document → Explain so your design-log notes don't stall at "identify" in the no-AI Annotation validation
+	## C5-3 — Critical & creative thinking
+
+	The three steps that make your design thinking visible, plus extra creative-thinking moves for the Godot cohort:
+
+	- [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants) — Step 1: research existing and possible solutions to inform your design
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots) — Step 2: trace one feature from mood board → mock-up → data dictionary → IPO → pseudocode, linked to your SRS
+	- [Plan B Ready](/sd/C05/Plan%20B%20Ready) — Step 3: document design risks and specific contingencies
+	- [Creative Thinking for Your Godot Project](/sd/C05/Creative%20Thinking%20for%20Your%20Godot%20Project) — extra moves to show creative thinking, tailored to a Godot game
+
	## Templates and scaffolds
	Reusable starting points for C05 deliverables:
/dev/null .. sd/C05/Connect the Dots.md
@@ 0,0 1,125 @@
+	> **DRAFT** — under teacher review.
+
+	# Connect the Dots
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	C5-3 asks you to do more than produce nice-looking designs — it asks you to make your **thinking visible**. The performance descriptors say it clearly:
+
+	> "Outlines the connections between the design ideas using annotations · Documents the connections between the design ideas and solution requirements · Documents the connections between the design ideas, solution requirements and the detailed designs."
+
+	Notice the three rising levels: annotate → link to requirements → trace all the way through to code-level artefacts. Each level builds on the one before, and stopping early is the single most common reason students miss the top band.
+
+	---
+
+	## Level 1 — Annotate your designs
+
+	An annotation is not a description. Saying "the button is red" tells the reader what you built. A real annotation tells them **why** — and implies you considered an alternative.
+
+	Test yourself with this question: *Can I name the thing I didn't do, and explain why I rejected it?*
+
+	| Weak annotation (describes) | Strong annotation (justifies) |
+	|---|---|
+	| "The button is red." | "Red delete button — follows the stop-sign convention and creates friction before an irreversible action, reducing accidental deletion. Considered orange but red is the universal danger signal." |
+	| "I used a sans-serif font." | "Inter (sans-serif) chosen over a serif font — cleaner at small sizes on screen; the target display is 1080p at arm's length, where serifs add noise." |
+	| "The health bar is at the top-left." | "Health bar anchored top-left to match the player's primary scan path; tested top-right in early sketch but eye-tracking research shows players check top-left first in action games." |
+
+	The more you justify, the more evidence you give a marker that you made a **deliberate design decision**, not a guess.
+
+	> [!TIP]
+	> If your annotation could also describe someone else's completely different design, it is too vague. Revise until it only makes sense for *your* choice.
+
+	---
+
+	## Level 2 — Link to your SRS requirements
+
+	Every design feature exists because of a requirement. Level 2 makes that link **explicit and traceable** — using the exact same reference numbers as your SRS document.
+
+	If your SRS says FR-3 and your design log says "requirement 3" or "functional requirement about jumping", the marker cannot confirm the trace. Use the **same label**, exactly.
+
+	Include a traceability table in your design log. Here is an example from a Godot game project:
+
+	| Design element | Requirement (SRS ref) | Justification |
+	|---|---|---|
+	| Double-jump shown as two small arc icons on HUD | FR-3 (player may jump twice before landing) | Icons make the remaining jump count readable at a glance during gameplay, satisfying FR-3's need for real-time feedback on jump state. |
+	| Health pickup glows green for 0.5 s on collection | FR-7 (player receives visual confirmation of pickup) | Glow duration is long enough to register but short enough not to distract; fulfils FR-7 without impeding player focus. |
+	| Settings screen accessible from pause menu only | NFR-2 (system shall not interrupt active gameplay) | Restricting settings access to the pause state ensures NFR-2 is never violated by an accidental menu trigger mid-run. |
+
+	> [!NOTE]
+	> Your table does not need to include every design element — but every element in the table must have a matching SRS entry. If you invent a reference number, markers will look it up and find nothing.
+
+	---
+
+	## Level 3 — Trace through to detailed designs
+
+	The top band requires you to show a feature flowing continuously from inspiration all the way into code-level artefacts. Here is one complete trace for a **double-jump** feature in a Godot platformer.
+
+	```mermaid
+	flowchart TD
+	A["Mood board<br/>Platformer jump-feel references<br/>(Celeste, Hollow Knight)"] --> B["Sketch<br/>Early HUD concept showing<br/>jump-arc indicator"]
+	B --> C["Mock-up<br/>Annotated HUD with<br/>two arc icons, colour states"]
+	C --> D["Data Dictionary<br/>jumpsRemaining : Integer<br/>Range 0-2, default 2"]
+	D --> E["IPO Chart<br/>Input: jump key pressed<br/>Process: check jumpsRemaining<br/>Output: apply upward force or block"]
+	E --> F["Pseudocode<br/>IF jumpsRemaining is above 0<br/>THEN apply force and decrement<br/>ELSE play error sound"]
+	```
+
+	Each node in that chain leaves evidence in a different artefact. A marker reading your folio can pick up any artefact — the data dictionary, the IPO chart, the pseudocode — and trace it back to the mood board and forward to the next layer.
+
+	> [!TIP]
+	> The most common failure point is stopping at the mock-up. A beautifully annotated mock-up earns Proficient. Full traceability into the data dictionary, IPO and pseudocode is what earns the top band.
+
+	---
+
+	## Performance ladder
+
+	| Band | What your evidence shows |
+	|---|---|
+	| Basic (1–4) | Designs exist but have no written reasons; annotations describe rather than justify |
+	| Developing (5–6) | Some annotations present; connections to requirements implied but not mapped |
+	| Proficient (7–8) | Annotations clearly outline connections between design ideas; alternative choices mentioned |
+	| Strong (8–9) | Traceability table maps design elements to SRS references with justification |
+	| Excellent (9–10) | Full trace from inspiration through mock-up into data dictionary, IPO and pseudocode; every artefact is connected |
+
+	---
+
+	## Quick checklist
+
+	- [ ] Every significant design element has an annotation that **justifies**, not just describes
+	- [ ] Each annotation names the alternative I rejected and why
+	- [ ] My traceability table uses **exact SRS reference numbers** (FR-x, NFR-x)
+	- [ ] Every SRS ref in my table actually exists in my SRS document
+	- [ ] I can trace at least one feature from mood board all the way to pseudocode
+	- [ ] My data dictionary has an entry for every variable named in my IPO charts
+	- [ ] My IPO charts connect to my pseudocode (same variable names, same logic)
+
+	---
+
+	## Check Your Understanding
+
+	**Q1. What is missing from this annotation: "I used a dropdown because it looks cleaner"?**
+
+	>| The annotation describes an aesthetic preference but gives no justification. It does not name what "cleaner" means in context (fewer visible options, reduced cognitive load, less screen space?), does not reference an alternative that was considered (e.g. radio buttons, a list box), and does not link to any SRS requirement. A strong revision would explain *why* a dropdown serves this specific design better than the alternative and cite the relevant requirement.
+
+	**Q2. You have a well-annotated mock-up with a traceability table. What extra evidence pushes you into the top band?**
+
+	>| You need to trace at least one feature all the way through to detailed design artefacts: a data dictionary entry (naming the variable, its type and valid range), an IPO chart that uses the same variable names, and pseudocode that implements the logic from the IPO chart. The mock-up and table earn Strong; the continuous trace from mock-up into data dictionary, IPO and pseudocode is the Excellent-band move.
+
+	**Q3. Why must the SRS reference numbers in your traceability table match your SRS document exactly?**
+
+	>| The traceability table is only useful if a reader can verify the link. If your table says FR-3 but your SRS labels it FR-03 or "Requirement 3" or omits a number entirely, the marker cannot confirm the connection exists — and may treat it as unsubstantiated. Consistency of labelling is what makes a trace auditable.
+
+	---
+
+	## See also
+
+	- [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants)
+	- [Plan B Ready](/sd/C05/Plan%20B%20Ready)
+	- [Sketch vs Mock-up](/sd/C05/Sketch%20vs%20Mock-up)
+	- [Data Dictionary](/sd/C05/Data%20Dictionary)
+	- [IPO Charts — Process Means Steps](/sd/C05/IPO%20Charts%20-%20Process%20Means%20Steps)
+	- [VCAA Pseudocode — Not Python](/sd/C05/VCAA%20Pseudocode%20Not%20Python)
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	---
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/Creative Thinking for Your Godot Project.md
@@ 0,0 1,125 @@
+	> **DRAFT** — under teacher review.
+
+	# Creative Thinking for Your Godot Project
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	C5-3 rewards **both** kinds of thinking:
+
+	> *"Documents the process of critical **and** creative thinking through the development of design ideas and the detailed designs."*
+
+	The three required steps — [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants), [Connect the Dots](/sd/C05/Connect%20the%20Dots) and [Plan B Ready](/sd/C05/Plan%20B%20Ready) — mostly show your **critical** thinking: analysing, tracing, planning. This page is about the **creative** half — extra, optional moves that generate strong creative-thinking evidence. Because you have locked in **Godot**, they fit naturally into a game project.
+
+	> [!NOTE]
+	> This is still **design** evidence (C05), not the build (C06). The point of each move below is to *develop and refine a design idea* — and to **capture it in your design log** (a sketch, a screenshot, a short note). The artefact is what the marker reads.
+
+	---
+
+	## Move 1 — Diverge before you converge
+
+	Don't design the first idea that works. Generate **many** — five rough versions of a mechanic, a level layout, or a menu — *then* choose one.
+
+	- Sketch 5 quick options on one page.
+	- Circle the one you'll build, and write one line on **why each other option was rejected**.
+
+	> [!TIP]
+	> The rejected ideas are not wasted — a documented "I considered A, B and C, and chose B because…" is exactly the creative-thinking evidence that scores. Keep the idea sheet.
+
+	---
+
+	## Move 2 — Grey-box prototype to test a design idea
+
+	Build a quick, ugly, playable Godot scene — plain boxes, no art — just to feel whether a design idea actually works. Play it, then change the design based on what you felt.
+
+	- Use placeholder shapes (a `ColorRect` or a cube) instead of art.
+	- Write a **before / after** note: "I planned a double-jump, but in the prototype it felt floaty, so I changed the design to a dash."
+
+	This is prototyping to refine the **design**, documented as design thinking — capture a screenshot and the note for your folio.
+
+	---
+
+	## Move 3 — Remix and combine
+
+	Creativity is often two old ideas combined into a new one. Take two things you like and mash them together, then document the reasoning.
+
+	- "Tetris + tower defence", "a cooking game with rhythm-game timing".
+	- Write what each part contributes and why the combination is more interesting than either alone.
+
+	---
+
+	## Move 4 — Use a constraint as a creativity engine
+
+	A blank page is hard; a tight limit sparks ideas. Set yourself a deliberate constraint and design within it.
+
+	- One button only. One screen. No text. A single colour. Sixty seconds per round.
+	- Document the constraint you chose and the design it forced you into.
+
+	---
+
+	## Move 5 — Design the "game feel"
+
+	How a game *feels* is a design decision, not an accident. Treat feedback — screen shake, sound, particles, timing, a little pause on impact — as a design dimension and make deliberate choices.
+
+	- For one key action (a jump, a hit, a pickup), list the feedback you'll add and why.
+	- Note what you're trying to make the player **feel** (snappy, weighty, satisfying).
+
+	---
+
+	## Move 6 — Stand on the Godot ecosystem's shoulders — creatively
+
+	You don't have to invent everything. Study how others solved a problem, then adapt it into something of your own.
+
+	- Browse the in-engine **AssetLib** (Godot Asset Library) and the official **Godot demo projects** to see how a pattern is built.
+	- Study open-source Godot games (itch.io, GitHub) and published games for a mechanic or UI idea.
+	- Use free **CC0** art to prototype — e.g. [Kenney](https://kenney.nl/) or [OpenGameArt](https://opengameart.org/) — so your design work isn't blocked waiting on art.
+
+	> [!TIP]
+	> **Credit everything**, even free CC0 assets and ideas you adapted. A Credits list is an integrity requirement — and noting "adapted from X" is also creative-thinking evidence. This overlaps [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants), but here the emphasis is on the *creative remix*, not just the analysis.
+
+	---
+
+	## Move 7 — Document your pivots
+
+	When you change a design idea partway through, that change is gold — **if you capture it**.
+
+	- Save the **before** (the original mock-up or sketch) and the **after**.
+	- Write one or two sentences on what triggered the change and why the new design is better.
+
+	A folio full of documented pivots tells the marker a real thinking process happened.
+
+	---
+
+	## Capture it for your folio
+
+	None of this counts unless it's **documented**. As you try these moves, drop into your design log:
+
+	- the sketch / idea sheet (Move 1, 3, 4)
+	- a screenshot of the grey-box prototype + your before/after note (Move 2, 7)
+	- a short written reason for each design choice
+
+	---
+
+	## Check Your Understanding
+
+	1. In one line each, what's the difference between *critical* and *creative* thinking in C5-3?
+
+	>| **Critical** thinking analyses and judges — comparing solutions, tracing requirements, planning for risk. **Creative** thinking generates and combines — producing new ideas, remixing, exploring options. C5-3 rewards documenting *both*.
+
+	2. You sketched five menu layouts and built the second one. Why keep the other four?
+
+	>| Because the rejected options *are* the evidence. "I considered five layouts and chose this one because…" documents a creative process — far stronger than presenting one design as if it appeared from nowhere.
+
+	3. Pick one move above you could do for your Godot project this week, and name the artefact you'd save for your folio.
+
+	>| Any reasonable answer — e.g. *Move 2: grey-box a jump mechanic and save a screenshot plus a before/after note*, or *Move 1: sketch five HUD ideas and keep the idea sheet with reasons for rejecting four*.
+
+	---
+
+	## See also
+
+	- [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants) — researching existing solutions (C5-3 Step 1)
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots) — tracing ideas to requirements to designs (C5-3 Step 2)
+	- [Plan B Ready](/sd/C05/Plan%20B%20Ready) — contingencies and mitigations (C5-3 Step 3)
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/Plan B Ready.md
@@ 0,0 1,111 @@
+	> **DRAFT** — under teacher review.
+
+	# Plan B Ready
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	Good designers expect things to go wrong. A planned mechanic turns out to be too hard to build in Godot. Scope creep means you now have five levels but none of them are finished. A plugin breaks two days before your submission. Markers at the top band are not looking for a perfect project — they are looking for evidence that you thought ahead and documented what you would do when things did not go to plan.
+
+	> *"Documents possible contingencies when developing solution designs · Documents possible solutions to mitigate issues."*
+
+	---
+
+	## Identify design risks
+
+	Start by reading through your detailed designs and asking: *what could prevent this from working?*
+
+	Every project has risks. The ones below come up regularly in Godot game projects.
+
+	| Risk type | Example in a Godot project |
+	|---|---|
+	| Technical limitation | The shader or particle effect you designed is beyond your current Godot skill and cannot be built in time |
+	| Scope creep | You planned three levels and ten enemy types — now none of them are polished enough to submit |
+	| User misunderstanding | Playtesters cannot figure out the controls or game objective without explanation |
+	| Dependency failure | A Godot add-on or plugin is unsupported in your version and breaks your build |
+	| Client change | Your teacher or peer reviewer asks you to rethink a core mechanic after you have already built it |
+
+	You do not need a risk for every row — two or three well-chosen risks that are genuinely specific to your design are worth more than a generic list.
+
+	---
+
+	## Document contingency plans
+
+	A contingency plan is a specific, documented backup — not "I'll figure it out later". Vague intentions do not score marks. For each risk you identify, write down exactly what you will do instead.
+
+	| Risk | Contingency |
+	|---|---|
+	| Drag-and-drop inventory mechanic is too complex to implement in Godot in time | Fall back to a numbered list with up/down arrow buttons — see mock-up B in the design log |
+	| Scope creep to five levels means none are complete | Cut to a vertical slice: one polished level with all core mechanics working rather than five rough ones |
+	| Godot inventory add-on breaks or is unsupported | Implement a simple custom Resource-based inventory using built-in Godot nodes only |
+
+	Notice that each contingency names a specific alternative — a different design, a different node, a different scope. That specificity is what the performance descriptors reward.
+
+	> [!NOTE]
+	> Contingencies are not admissions of failure. Documenting a backup plan shows that you understand your design well enough to know where it is fragile.
+
+	---
+
+	## Show the backup designs
+
+	A contingency plan is stronger when you can point to something concrete — a second mock-up, an alternative pseudocode path, or even a rough sketch in your design log.
+
+	For example:
+
+	> "If the drag-and-drop proves too complex, the fallback is a numbered list with up/down buttons — see mock-up B."
+
+	You do not need a fully polished alternative. A labelled wireframe or a short pseudocode snippet that shows the alternate logic is enough to demonstrate that you have actually thought the backup through.
+
+	> [!TIP]
+	> There is a ready-made fillable table to organise your contingency plans: [Plan B Contingency Table](/sd/C05/Plan%20B%20Contingency%20Table). Fill it in as you finalise your designs, not after submission.
+
+	---
+
+	## Performance levels
+
+	| Level | What it looks like |
+	|---|---|
+	| Basic | No contingencies documented — design assumes everything will work |
+	| Developing | Risks are identified but no solutions are offered ("this might be a problem") |
+	| Proficient | Possible contingencies are documented for identified risks |
+	| Strong | Specific, actionable backup solutions are documented — not just "I have a plan" but "here is the plan" |
+
+	The jump from Proficient to Strong is the jump from naming a contingency to documenting a mitigation: a concrete design decision, a specific alternative, a referenced mock-up.
+
+	---
+
+	## Quick checklist
+
+	- [ ] At least two design contingencies documented (specific to your project)
+	- [ ] Each contingency has a documented mitigation — not "I'll think about it"
+	- [ ] Contingencies are specific to YOUR design, not generic
+	- [ ] Backup designs are referenced or sketched in your design log
+
+	---
+
+	## Check Your Understanding
+
+	**1. Why does "I'll think of something" not score marks at the top band?**
+
+	>| The performance descriptor says *documents possible solutions to mitigate issues* — documenting requires a specific, written plan, not an intention. A vague statement gives the marker nothing to assess and demonstrates no forward thinking about your design.
+
+	**2. What is the difference between identifying a risk and documenting a mitigation?**
+
+	>| Identifying a risk means naming something that could go wrong (e.g. "the shader might be too complex"). Documenting a mitigation means writing down a specific alternative you will implement instead (e.g. "if the shader is too complex, I will use a solid colour tint via a CanvasModulate node — see mock-up B"). One is observation; the other is a design decision.
+
+	**3. Name one realistic risk for a Godot game project and write a specific contingency for it.**
+
+	>| Example risk: art assets (character sprites and backgrounds) take longer to create than expected, leaving the game with placeholder squares at submission. Contingency: use free CC0 assets from itch.io or Kenney.nl (credited in the asset list) so that design and coding can continue without waiting on custom art. This is specific, actionable, and keeps the project moving.
+
+	---
+
+	## See also
+
+	- [Shoulders of Giants](/sd/C05/Shoulders%20of%20Giants)
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots)
+	- [Plan B Contingency Table](/sd/C05/Plan%20B%20Contingency%20Table)
+	- [Creative Thinking for Your Godot Project](/sd/C05/Creative%20Thinking%20for%20Your%20Godot%20Project)
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	---
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
/dev/null .. sd/C05/Shoulders of Giants.md
@@ 0,0 1,110 @@
+	> **DRAFT** — under teacher review.
+
+	# Shoulders of Giants
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	> *"Identifies existing and possible solutions to inform design ideas."*
+
+	Great designers rarely start from a blank screen. Before you sketch your first UI or write your first script, you study what's already out there — games and tools that solved a similar problem — and you let those solutions shape your thinking. This is C5-3 Step 1, and it's one of the fastest ways to lift the quality of your design work.
+
+	---
+
+	## Why look at existing solutions?
+
+	Every game released on itch.io, every open-source Godot project on GitHub, every polished mobile app represents thousands of hours of design decisions — many of them hard-won. When you examine them carefully, you borrow the lessons without repeating the mistakes.
+
+	The study design asks you to identify **existing** solutions (things already built) **and possible** solutions (approaches that could work, even if no one has built exactly what you need yet). Both matter. A solution doesn't have to be popular to be useful — it just has to be relevant to the problem your SRS describes.
+
+	> [!NOTE]
+	> Aim for at least 2–3 solutions. A mix of sources gives you stronger evidence: commercial games, open-source Godot projects, student examples, or competitor apps your client already uses.
+
+	---
+
+	## What counts as an existing solution?
+
+	For a Godot game project, look at:
+
+	- **Published games** — especially ones in your genre. Play them and take notes, not just screenshots.
+	- **Open-source Godot games** — search GitHub for Godot projects similar to yours. You can read the actual code and scene structure.
+	- **itch.io game jams** — a goldmine of small, focused games that solved one design problem well.
+	- **Game tools and engines** — if your SRS mentions a specific mechanic (inventory, dialogue trees, tile maps), look at how existing Godot plugins or other engines approach it.
+	- **Partial matches** — a game that shares only one relevant feature still counts. You don't need a perfect clone of your idea.
+
+	> [!TIP]
+	> Possible solutions include approaches you haven't seen implemented yet — for example, "a card-based level select that doesn't exist in my genre but would suit my players." Identifying a possible solution and explaining why it fits your SRS is strong analytical thinking.
+
+	---
+
+	## Analyse each solution in a table
+
+	Don't just list the games you looked at. Break each one down:
+
+	| Solution | What it does well | What it does poorly | How it relates to my problem (SRS link) |
+	|---|---|---|---|
+	| Celeste (Maddy Makes Games) | Clear, readable level-select map; instant restart on death encourages retry | No in-game hint system for stuck players | My SRS requires a level-select screen and a low frustration loop — both addressed here |
+	| Open-source Godot platformer (GitHub: example/repo) | Clean scene structure; reusable state machine for player movement | No save system; UI is placeholder only | My SRS requires persistent progress — I can see what's missing and plan accordingly |
+	| Candy-match mobile game (competitor app client uses) | Card-grid layout scanned quickly by players; satisfying feedback sounds | Heavy monetisation interrupts flow | My SRS calls for a similar scan-friendly layout without ads |
+
+	> [!NOTE]
+	> Every cell must be your own analysis, not a copy of a review. If you can't say how the solution relates to your SRS, you haven't finished the analysis.
+
+	---
+
+	## Connect findings to your design
+
+	The table is evidence. The connection is the argument. You must make the link **explicit**:
+
+	> **Worked example:** After studying how *Celeste's* level-select map uses a simple node-and-path layout, and after looking at a card-grid layout in a mobile match game that my client already plays, I decided to use a **card grid** for my level-select screen. A grid lets players scan all available levels at once without scrolling — which suits my SRS requirement that players can jump back to any completed level in under two taps.
+
+	Notice the structure: *"Because [existing solution] does [specific thing], I decided [specific design choice] because it addresses [SRS requirement]."* That's the sentence pattern that gets you to Proficient and beyond.
+
+	---
+
+	## Performance levels
+
+	| Level | What it looks like |
+	|---|---|
+	| Basic | Names one solution with a brief description |
+	| Developing | Describes features of one or two solutions |
+	| Proficient | Identifies existing AND possible solutions and uses them to inform design ideas |
+	| Strong | Analyses multiple solutions with explicit links from specific findings to specific design choices |
+
+	---
+
+	## Quick checklist
+
+	- [ ] 2–3 solutions identified (mix of existing published games, open-source projects, or other relevant software)
+	- [ ] Each solution analysed: strengths, weaknesses, and relevance to your SRS
+	- [ ] At least one explicit "because X does Y, I decided Z" connection written out
+	- [ ] Both existing products AND at least one possible alternative considered
+	- [ ] Table cells contain your own analysis, in your own words — not copied from reviews
+
+	---
+
+	## Check Your Understanding
+
+	**Q1. Why does the study design ask you to identify "possible" solutions, not just popular ones?**
+
+	>| Popular games are designed for large audiences with different needs from your client. A possible solution — even one that doesn't exist yet in your genre — might be a better conceptual fit for your SRS. Considering possible alternatives shows you're thinking about the design space, not just copying what's trending.
+
+	**Q2. What's the difference between "I looked at 3 games" (Developing) and Strong-level evidence?**
+
+	>| At Developing, you describe what the games do. At Strong level, you connect specific findings to specific design decisions: "Because Game X uses a card grid for level select, and my SRS requires players to resume quickly, I adopted a card grid." The explicit link — not the number of games — is what earns the higher band.
+
+	**Q3. Name one good source of existing solutions for a Godot game project.**
+
+	>| Good answers include: itch.io (searchable by genre and engine); GitHub (search "godot" + your mechanic, e.g. "godot inventory system"); open game jams; or commercial games in your genre that you can play and document. Open-source projects are especially useful because you can study the scene and script structure, not just the look.
+
+	---
+
+	## See also
+
+	- [Connect the Dots](/sd/C05/Connect%20the%20Dots)
+	- [Plan B Ready](/sd/C05/Plan%20B%20Ready)
+	- [Creative Thinking for Your Godot Project](/sd/C05/Creative%20Thinking%20for%20Your%20Godot%20Project)
+	- [C05 Resources](/sd/Resources/C05-Resources)
+
+	---
+
+	← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)