Practical Assignment 1 · Lab Sprint
Turn your game idea
into a written plan
You already have a game in mind. This worksheet walks you through every section of the marking guide — one question at a time — so you leave today with the backbone of your design report written.
How to use this worksheet: Work through each section in order. Type directly into the boxes — your answers are saved in your browser. When you're done, use the Export button at the bottom to copy everything into your Word document. Each answer you write here can go almost directly into your submission.
Session goal: Complete Parts 1 and 2 (the design report sections) today, and sketch your Unity prototype plan. Part 1 + Part 2 = 12 marks — the majority of this assignment is written planning, not just building.
1
Game Type & Mode
Part 1 · Game Concept Document
1
What type of game is it? And is it single-player or multiplayer?
e.g. runner, platformer, puzzle, strategy, shooter, simulation…
Strong Example
Gravity Shift is a single-player 3D puzzle platformer. The player controls a robot navigating floating platforms by reversing gravity with a hold-to-activate button.
0 characters
2
In one sentence: what is the player's main objective?
What are they trying to achieve? This becomes the opening line of your objectives section.
Strong Example
The player must guide the robot from the Start Platform to the Goal Portal on each level by collecting all Energy Cells and avoiding Danger Spikes.
0 characters
2
Objectives & Rules
Part 1 · Game Concept Document
The marking guide checks each of these individually. A vague paragraph covering all of them scores lower than specific, separate answers for each. Write a short paragraph (3–5 sentences) for each box.
3
Winning and losing conditions — what exactly ends the game?
Be specific. What event triggers a win? What event triggers a loss?
Strong Example
Win: Reaching the Goal Portal after collecting all Energy Cells completes the level and unlocks the next one.Lose: Falling into the void or touching a Danger Spike resets the level. There is no life counter — the game encourages experimentation.
0 characters
4
What can the player do? What can they NOT do?
List specific actions and restrictions — not general descriptions. Think: controls, abilities, prohibited actions.
Strong Example
Can do: Tap left/right to move; swipe up to jump; hold Gravity Button to reverse gravity; double-tap to dash.Cannot do: Jump while gravity is reversed; move during the 0.5s gravity flip animation; revisit a collected Energy Cell.
0 characters
3
Challenges & Difficulty
Part 1 · Game Concept Document
5
What challenges prevent players from achieving their goals?
List at least 4 distinct obstacles, hazards, or mechanics that create difficulty.
Strong Example
Moving platforms requiring precise timing · Danger Spikes on both floors and ceilings (critical when gravity flips) · Energy Cells in hard-to-reach positions requiring creative gravity use · Narrow corridors where a misstep causes a fall · Time pressure on Hard difficulty
0 characters
6
Describe your difficulty levels. How does the game get harder?
Name the levels (Easy / Medium / Hard) and describe what changes between them.
Strong Example
Easy: Wide platforms, fast gravity recharge, no time limit.Medium: Standard platform width, normal recharge rate, optional time-bonus scoring.
Hard: Narrow platforms, slow gravity recharge, moving Danger Spikes, optional time limit.
0 characters
4
Environment & Audience
Part 1 · Game Concept Document
7
Describe the game environment and context. Where and when is the game set?
Visual setting, artistic style, narrative backdrop. Give the marker a clear mental picture.
Strong Example
Set in a decommissioned space station drifting in low orbit, featuring a low-poly metallic aesthetic with glowing blue energy conduits and a star-filled void background. Each of the 10 levels represents a different station section (Engine Room, Research Lab, Command Deck) providing visual variety within a coherent sci-fi theme.
0 characters
8
Who is your intended audience? Be specific about age, interests, and comparable games.
Mention age range, gamer type (casual/core), and 1–2 existing games your audience likely plays.
Strong Example
Primary: Casual mobile gamers aged 16–35 who enjoy puzzle or platformer games. Secondary: Players of Monument Valley, Alto's Odyssey. Rated G — suitable for all ages despite the primary demographic.
0 characters
5
Why It Is a Good Mobile Game
Part 1 · Game Concept Document — 1 paragraph required
This paragraph is explicitly listed in the marking guide. It needs to go beyond "it's fun" — reference actual properties of good mobile games. Use the prompts below as a framework.
What makes a good mobile game? Tick all that apply to yours:
Short play sessions (3–10 minutes each)
Intuitive touch controls (minimal learning curve)
Clear, immediate feedback to player actions
Easy to pause and resume at any point
Runs on varied hardware (low performance requirements)
"One more try" loop that encourages replaying
Simple to learn, hard to master
Designed around portrait/one-hand play
9
Write your "why it is a good mobile game" paragraph (4–6 sentences).
Use the checklist above. Explain HOW your specific game design delivers each quality — don't just list them.
Strong Example (opening sentences)
Gravity Shift suits mobile because each level is completable in 3–7 minutes — matching typical commute-length sessions. Controls use only tap, swipe, and hold gestures, requiring no complex on-screen buttons. The instant respawn on failure creates a strong "one more try" loop without punishing the player's time investment…
0 characters
Part 2 · Game Design Document
6
Functional Requirements
Part 2 · Game Design Document
Functional = what the system does. Each requirement is a specific feature or behaviour your game will have. Aim for 6–8 requirements. Write them as: "The game shall…" or "The player can…"
10
Write your Functional Requirements (6–8 minimum)
Click "Add row" to grow the table. ID format: FR-01, FR-02… Priority: High / Medium / Low
| ID | Requirement description | Priority |
|---|---|---|
7
Non-Functional Requirements
Part 2 · Game Design Document
Non-functional = how the system performs. Think: performance, hardware targets, file size, platform version, orientation. Aim for 3–5.
11
Write your Non-Functional Requirements (3–5 minimum)
| ID | Requirement |
|---|---|
8
User Interface Design
Part 2 · Game Design Document
Describe every screen in your game. For each: name the screen, list every UI element and its function. You'll add screenshots from Unity later — describe the design intent here.
12
Main Menu screen — list every element and its function
Strong Example
Game Title logo (top third, centred) — branding. Play Button (large, centre) — navigates to Level Select. Settings Button — opens difficulty and audio settings. Credits Button — shows developer info. Background: animated starfield particle system.
0 characters
13
Gameplay HUD — list every on-screen element and its function
Score display, health bar, controls, pause button — whatever your game shows during play.
0 characters
14
Any other screens (Game Over, Level Complete, Pause Menu, Settings) — describe each briefly
0 characters
15
Why does your interface have a good design? (1 paragraph — required by marking guide)
Reference real mobile UI principles: touch target size (≥44px), thumb reach zones, contrast ratios, minimal cognitive load, immediate feedback.
Strong opening
The interface follows mobile UI best practices in three key ways. First, all interactive elements meet the 44×44px minimum touch target (Material Design guidelines), ensuring accurate tapping during fast gameplay. Second, primary controls are positioned in the lower third of the screen within the natural thumb reach zone…
0 characters
9
Use Cases — Screen Navigation
Part 2 · Game Design Document
16
Describe how a player navigates through all your screens. Trace two paths: (a) normal play, (b) pausing and retrying.
Write it as a flow: "Player launches app → Main Menu → taps Play → Level Select → taps Level 1 → Gameplay…"
Strong Example
Path A (Normal play): App launch → Main Menu → [Play] → Level Select → [Tap Level] → Gameplay → [Collect all cells + reach portal] → Level Complete → [Next Level] → Gameplay (next level).Path B (Pause & retry): Gameplay → [Pause button] → Pause Menu → [Retry] → Gameplay (level resets) OR [Menu] → Main Menu.
0 characters
Part 3 · Unity Prototype Plan
10
Unity Prototype Plan
Part 3 · 6 marks — use this section to plan your build
The marker checks for: game objects, materials, lighting, camera, physics, C# scripts, touch/sensor input, and external assets. You don't need everything perfect — but you need evidence of each skill area.
Scene & Game Objects
Scripts I Will Write
Mobile Input Implementation
External Assets to Import
Unity Skill Coverage — check each area you plan to demonstrate:
Game objects with parent/child hierarchy
Materials and textures applied to 3D objects
Lighting (directional light, shadows, or ambient)
Camera setup (follow cam or Cinemachine)
Physics (Rigidbody, Collider, triggers)
C# scripts using MonoBehaviour lifecycle (Start, Update)
Touch screen input (Input.GetTouch / touchCount)
External asset imported and used in scene
Recommended build order for Weeks 5–6: Set up your scene and game objects first → get basic movement working with touch input → add physics and collisions → import external assets → implement game logic (score, win/lose) → add UI screens last. Start with what is hardest to learn, not what looks nicest.
Ready to write your report?
Your answers above form the backbone of your Word document. Copy them into Microsoft Word, expand each answer into full paragraphs, and add your Unity screenshots. The sample submission file shows how the finished document should look.
Your answers are stored in your browser. If you close the tab, they will still be here when you return on the same device.