Blame

07b621 lisa 2026-06-08 12:58:03
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>
1
> **DRAFT** — under teacher review.
2
3
# Shoulders of Giants
4
5
The Hamilton and Alexandra College · Year 12 · 2026
6
7
> *"Identifies existing and possible solutions to inform design ideas."*
8
9
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.
10
11
---
12
13
## Why look at existing solutions?
14
15
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.
16
17
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.
18
19
> [!NOTE]
20
> 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.
21
22
---
23
24
## What counts as an existing solution?
25
26
For a Godot game project, look at:
27
28
- **Published games** — especially ones in your genre. Play them and take notes, not just screenshots.
29
- **Open-source Godot games** — search GitHub for Godot projects similar to yours. You can read the actual code and scene structure.
30
- **itch.io game jams** — a goldmine of small, focused games that solved one design problem well.
31
- **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.
32
- **Partial matches** — a game that shares only one relevant feature still counts. You don't need a perfect clone of your idea.
33
34
> [!TIP]
35
> 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.
36
37
---
38
39
## Analyse each solution in a table
40
41
Don't just list the games you looked at. Break each one down:
42
43
| Solution | What it does well | What it does poorly | How it relates to my problem (SRS link) |
44
|---|---|---|---|
45
| 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 |
46
| 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 |
47
| 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 |
48
49
> [!NOTE]
50
> 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.
51
52
---
53
54
## Connect findings to your design
55
56
The table is evidence. The connection is the argument. You must make the link **explicit**:
57
58
> **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.
59
60
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.
61
62
---
63
64
## Performance levels
65
66
| Level | What it looks like |
67
|---|---|
68
| Basic | Names one solution with a brief description |
69
| Developing | Describes features of one or two solutions |
70
| Proficient | Identifies existing AND possible solutions and uses them to inform design ideas |
71
| Strong | Analyses multiple solutions with explicit links from specific findings to specific design choices |
72
73
---
74
75
## Quick checklist
76
77
- [ ] 2–3 solutions identified (mix of existing published games, open-source projects, or other relevant software)
78
- [ ] Each solution analysed: strengths, weaknesses, and relevance to your SRS
79
- [ ] At least one explicit "because X does Y, I decided Z" connection written out
80
- [ ] Both existing products AND at least one possible alternative considered
81
- [ ] Table cells contain your own analysis, in your own words — not copied from reviews
82
83
---
84
85
## Check Your Understanding
86
87
**Q1. Why does the study design ask you to identify "possible" solutions, not just popular ones?**
88
89
>| 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.
90
91
**Q2. What's the difference between "I looked at 3 games" (Developing) and Strong-level evidence?**
92
93
>| 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.
94
95
**Q3. Name one good source of existing solutions for a Godot game project.**
96
97
>| 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.
98
99
---
100
101
## See also
102
103
- [Connect the Dots](/sd/C05/Connect%20the%20Dots)
104
- [Plan B Ready](/sd/C05/Plan%20B%20Ready)
105
- [Creative Thinking for Your Godot Project](/sd/C05/Creative%20Thinking%20for%20Your%20Godot%20Project)
106
- [C05 Resources](/sd/Resources/C05-Resources)
107
108
---
109
110
← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)