Blame
|
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) |
|||||||
