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