Two selves. One timeline —
Record to capture action... Replay to cooperate...
Your only teammate is yourself!
Currently features 12 core levels (7 Easy, 4 Hard, 1 Special) plus 10 Legacy levels – classic puzzles from earlier builds – with 3 achievements to unlock!
(If you get stuck on a hard level for more than half an hour, that’s totally normal – don't worry! Check out the guide here!)
📽️ Gameplay Preview · 🔗 Related Websites · 👥 Team Members
📋 Kanban Board · 🗓️ Workshop · ❤️ Acknowledgements
👉👉👉
👈👈👈
Game guide preview - Easy level 1 with tutorial system
Featured level preview - Easy 4 'Illusions' & Hard 3 'Symbiosis'
The first special level is now available - More coming soon!
Can’t get enough? Let's try the Map Editor and create your own levels!
itch.io is an open and popular marketplace for independent digital creators with a focus on indie video games.
More platforms coming soon!
We have more than one solutions in each level, so we recommand you to play it by yourself first!
More solutions walkthrough videos are coming soon...
The Phantom Chat System for U Help U.
Chat with your phantom past self — just like in the game!
| Name | |
|---|---|
| Zhiqing Zhang | ek25873@bristol.ac.uk |
| Siqi Xu | lv25773@bristol.ac.uk |
| Xuelin Ma | pw25500@bristol.ac.uk |
| Yiyuan Yao | jg25755@bristol.ac.uk |
| Jingran Zhang | sx25997@bristol.ac.uk |
| Wenlei Miao | hz25681@bristol.ac.uk |
| Link | Overview chart | Description |
|---|---|---|
| Week 01 README |
 |
Game Research - Analysis of over 50 games. Reference Games |
| Week 02 README |
 |
Drawing App and Two game ideas. |
| Week 03 README |
 |
Paper prototypes of two games and the final game idea. |
| Week 04 README |
 |
Defined user stories and functional/non-functional requirements. |
| Week 05 README |
 |
Designed architecture diagrams and implemented core systems. |
| Week 06 README |
 |
Released the first playable Demo 0 with core mechanics. |
| Week 07 README |
 |
Added two difficulty levels and iterated levels based on user evaluation. |
| Week 08 README |
 |
Ran user tests and analyzed SUS/NASA-TLX results.Click to view our form |
| Week 09 README |
 |
Merged key code and updated levels from evaluation findings. Finish our demo1 and demo2. |
| Week 10-12 README |
 |
Refined Demo 1 and Demo 2 levels and mechanics (also playable in the current build!). |
| Week 13 README |
 |
Finalise the game’s final version and begin vedio making. See our final video here |
| Week 14 README |
 |
Improve our report and add sustainability and AI statement part, continue making our video. |
| Week 15 README |
 |
Prepared flowcharts and presentation script for the final demo showcase. |
2026-group-13/
├── README.md ← You are here — main project documentation
├── assets/ ← Images, GIFs, and diagrams used in this README
├── docs/ ← Game source code and technical documentation (see Design § 4 for full structure)
└── week-log/ ← Weekly lab logs (see Workshop section above for overview)
- Introduction
- Requirements
- Design
- Implementation
- Evaluation
- Process
- Sustainability, ethics and accessibility
- Conclusion
- Contribution Statement
- AI Statement
- 1 U Help U brief introduction
- 2 Core Gameplay (How to Play)
- 3 Game Goals
- 4 Core Highlights (Differentiation)
- 5 Recording System Exhibition
- 6 Game Entities Exhibition
U Help U is a 2D side‑scrolling platformer puzzle game built around self‑collaboration. Players record their actions to generate a “Past Self”—a physics-based entity that faithfully reproduces previous movements. By standing on, boosting, or blocking one another, players turn their past attempts into the foundation for present success.
Standard Key Controls
- Both selves are fully physics‑driven and affected by gravity
- Both act as solid platforms for each other
- Vertical stacking is allowed; horizontal overlap is prevented
- Primary: Reach the designated endpoint
- Advanced: Complete in the shortest time possible
- Empower players through "self‑collaboration"
- Stimulate spatial reasoning and forward planning
- Demonstrate how past efforts enable present breakthroughs
- Action‑Based Fidelity: Playback reacts dynamically to the environment via physics
- Bidirectional Interaction: Both selves serve as functional platforms for one another
- Non‑Punitive Design: Encourages experimentation with no death or time penalties
 
• Phase Description: The player observes the level terrain and mechanism distribution. The system is on standby, ready to record position and interaction logic. |
 
• Phase Description: The system captures the motion path and interaction in real-time. |
 
• Phase Description: Recording finished. The phantom appears in a transparent state. |
 
• Phase Description: The phantom repeats all actions recorded. |
 
• Phase Description: Playback ends. The phantom returns to a transparent state, awaiting instructions. |
| Name | State / Form | Image | Description |
|---|---|---|---|
 | Idle Animation |  | The player yawns if idle for 2 seconds. |
| Dynamic Trail Effect |  | Trailing effects are generated while the player is moving. | |
| Jump & Landing VFX |  | Visual feedback and particle effects triggered during jumping and landing. | |
| Death Animation |  | Feedback animation triggered when colliding with obstacles or hostile targets. | |
 | Invisible when Idle |  | The phantom remains invisible when no playback is occurring. |
| Visible during Playback |  | The phantom becomes visible and gains collision volume during playback. | |
 | Default Animation |  | Idle state when not in interaction. |
| Dialogue Trigger |  | The NPC displays a cute expression during interaction. | |
 | Stomp Kill |  | Patrol units; can only be defeated by stomping from above. Stomping allows the player to jump higher. |
| Killed by Enemy |  | The player is defeated when colliding with an enemy from the side. |
| Name | State / Form | Image | Description |
|---|---|---|---|
 | Legacy Activation |  | Opened by standing on two buttons simultaneously in older versions. |
| Current Activation |  | Activated by stepping on a button to release electrical current. | |
 | Basic Form |  | Standard metal spikes; a permanent hazard. |
| Colored Form |  | Colored spikes controlled by buttons; colors correspond to logic switches. | |
 | Inactive |  | Waypoints in the scene waiting to be activated. |
| Auto-activation |  | Automatically activates when the player is nearby; the player respawns here after death. | |
 | Proximity Prompt |  | Press the 'E' key to interact when close to the sign. |
| Detailed Reading |  | Interact to read the detailed content provided on the board. | |
 | Inactive |  | Initial silent state; teleportation is unavailable. |
| Active |  | A number appears on the gate when active; players press the key to teleport. | |
 | Physical Collision |  | Features real collision volume and is pushable, following realistic physics. |
| Name | State / Form | Image | Description |
|---|---|---|---|
 | Dynamic Fade |  | Hidden UI that surfaces only when the player approaches specific interactive objects. |
| Unit Key Tips |  | Contextual key prompts for NPCs, Teleport Points, or Signboards. | |
 | Proximity Trigger |  | Text notifications triggered when the player approaches. |
| Name | State / Form | Image | Description |
|---|---|---|---|
 | Electrical Activation | | Player/Phantom steps on the button to release current and activate the final gate. |
| Current Fade / Gate Close |  | When the button is released, the current fades and the gate eventually closes. | |
 |
Button-Controlled Spikes |  |
Press the button to toggle spike visibility; the player dies upon contact when spikes are visible. |
 | Button-Controlled Platform |  | Press the button to toggle platform visibility; the platform gains collision when visible. |
| Name | State / Form | Image | Description |
|---|---|---|---|
 | Platform Form |  | Visual representation of the floating platforms. |
 | Ground Form |  | Visual representation of the standard walking ground. |
 | Wall Form |  | Visual representation of the terrain boundaries and walls. |
- 1 Ideation process
- 2 User Stories
- 3 Onion Model
- 4 Early-Stage Design
- 5 Use-Case Diagram
- 6 Requirements Definition
During the first stage of our game design, the first problem that came to us was which type of games we should choose. Each member of our group did detailed research about the specific game type he or she wanted to design, and finally carried out six ideas(each member with one idea). Then our group arranged a meeting and played all the games that could serve as prototypes for our game. The original ideas include Roguelike, Tower Defense, Simulation, PvP, puzzle-solving, etc. And after several hours of discussion, we finally decided to design a 2D platform puzzle-adventure game.
However, a distinctive characteristic of our game is an important part that sets it apart from others. While trying various puzzle games, a game called U vs U attracted us, which has the key game mechanics that players need to find ways to escape from their past selves or kill them before their past self reaches the finish line. That is really an amazing mechanic that only needs one player, but needs to think from two different sides. And the concept of two selves existing in different times and spaces is also quite novel. As a result, we finally decided on the final idea of our game: U help U, a 2D platform puzzle-adventure game in which the player can release a clone through an operation called recording. The clone will replay all the movements and operations that were done by the player during recording time, just like the player’s phantom(The principle behind the recording is to capture each key press during the recording time, and let the clone repeat the movement caused by these key presses during replay time, so it is also called capture). What the player needs to do is to cooperate with the phantom to clear each level. In our initial concept, we can design each level with a different style, so that the player can play various kinds of games in our game.
Based on this initial game idea, we formulated a series of user stories to help us prioritize the tasks. Our user stories are based on the format “As a **, I want to **, so that__”, to consider different requirements from different sides. Here are some crucial user stories on basic game controls, core game mechanics, game interactions, and user interface. Click here to view the full user stories, the epics we developed in the early stages, and their completion status.
Table 1: A Few User Stories
In addition to player-centred user stories, we also considered requirements from the perspectives of designers and developers. This helped us ensure that the game would not only be enjoyable for players, but also practical to extend, balance, and maintain during development.
Overall, these user stories provided a structured way to translate our initial game concept into a clearer set of development goals. They helped us identify the most important gameplay expectations from different perspectives, prioritise key tasks during development, and ensure that both player experience and project maintainability were taken into account. They also served as a bridge between the early design idea and the more detailed functional and non-functional requirements defined later in the project.
Figure 1: Onion Model: Stakeholders
The stakeholder onion model was also used to identify the main groups involved in or affected by the game, and to clarify their different roles and levels of influence throughout our project.
Table 2: Stakeholder in Onion Model
During our early design stage, we mainly focused on designing different levels with various gameplay styles, such as roguelike in one level and shooting in another, but all combined with the record and reply mechanism. Because there are still some great ideas and map designs that were carried out by some group members. In this way, players can not only focus on puzzle solving using clones, but also can enjoy other different kinds of game styles in only one game. But with the deepening of research and development, we find that the game as a whole seems a bit disjointed. If each stage uses a different style, it seems that it is hard to find a suitable theme for the whole game. So we changed the development strategy to only focus on puzzle solving with the record(capture) system.
In our first sprint(first demo version), we mainly focused on creating one level with a relatively easy puzzle(two buttons, the player and phantom need to press them at the same time) to let players and testers get familiar with the game mechanics and how to cooperate with the record & replay system. For players who are more confident in their gaming skills, we also developed a level where players need to time their use of phantom as stepping stones carefully to cross the chasm.
Figure 2: Early design prototypes and gameplay concepts
Figure 3: Use-Case Diagram
Above is our use-case diagram and the following table summarizes the main purpose and design value of it:
Table 3: Use-Case Diagram Table
We attended each lab and testing marathon, gathering advice and feedback from different testers and players. After weekly meetings and bug fixing, our finalized functional and non-functional requirements are as follows:
Table 4: Functional Requirements for U help U
Table 5: Non-Functional Requirements for U help U
Figure 1
This class diagram illustrates four core classes in the game and their collaboration: AppCoordinator, EventBus, SwitcherMain, and LevelManager, which are responsible for overall orchestration, event dispatching, page switching, and level management respectively.
Figure 2
The sequence diagram shows the initialization order of these four core classes during game startup.
| EventType | Description |
|---|---|
| LOAD_LEVEL | Requests loading a specific level and entering gameplay. |
| UNLOAD_LEVEL | Requests unloading the current level and clearing resources. |
| RETURN_LEVEL_CHOICE | Returns to the level‑selection screen. |
| AUTO_RESULT | Triggers level result evaluation (win or lose). |
| PAUSE_GAME | Pauses all gameplay updates. |
| RESUME_GAME | Resumes gameplay updates. |
| SIGNBOARD_INTERACTED | Player interacts with a signboard to display its message. |
| SIGNBOARD_OUT_OF_RANGE | Player leaves signboard range and the message is hidden. |
| NPC_DIALOGUE_START | Begins an NPC dialogue sequence. |
| NPC_DIALOGUE_NEXT | Advances to the next line of NPC dialogue. |
| NPC_DIALOGUE_END | Ends the NPC dialogue and returns control to the player. |
The event system adopts a publish–subscribe model to centrally manage the dispatching of game events.
Figure 3
The LevelManager handles orchestration, Level executes level logic, CheckpointSystem manages respawn points, and Room represents spatial partitions within a level.
Figure 4
The Switcher is responsible for switching between static UI pages and level pages, and forwarding update and draw calls to the currently active page.
Figure 5
The sequence diagram illustrates the execution order of the game’s main loop: each frame calls update() to refresh system states, followed by draw() to render the interface.
Figure 6
The Game Entity System defines all in game entities, providing unified data structures, shared behaviors, and consistent interfaces for characters, platforms, and interactive elements. The GameEntity base class provides fundamental attributes, while derived classes may include additional components such as collision and control components.
Figure 7
The collision system implements a complete pipeline of collision detection → collision resolution → collision response, ensuring correct physical interactions, trigger events, and blocking behavior between entities.
- CollideSystem orchestrates the entire collision process.
- CollisionDetector determines whether two entities collide.
- CollisionResolver determines the collision direction and outputs a collisionMsg for the next stage.
- CollisionResponder performs the actual response based on the resolved result.
Figure 8
The character control system processes native browser keyboard events, interprets player intent, validates whether the intent can be executed, and maps validated actions to updates of velocity and acceleration in the character’s movement component.
Figure 9
The physics system updates entity positions by applying velocity and acceleration.
Figure 10
The UI module manages all interface rendering and interaction logic, including static pages, level pages, UI components, and transition effects.
Figure 11
The recording system is the core mechanic of the game. It manages recording states, captures player actions, and replays them. RecordSystem serves as the central component, combining RecordUI for interface rendering and relying on Clip to store recorded data.
Figure 12
The state machine defines the full lifecycle of the recording system—from Ready to Record, to Recording, to Ready to Replay, and finally Replaying. It ensures that the recording and replay processes are controllable, resettable, and free from state conflicts through explicit states, input events, and action logic.
Figure 13
Figure 14
The mechanism system manages reusable level mechanisms, including circuit based door unlocking and controllable moving platforms. Diagram V shows the class structure of the mechanism system: ButtonPlatformLinkSystem and WireIndicatorSystem handle different linkage logics.
The docs/ directory contains the complete game — the entry point index.html loads main.js, which bootstraps p5.js and hands control to AppCoordinator. Everything is split into four top-level areas:
docs/
├── index.html ← Game entry point (open in browser to play)
├── main.js ← p5.js sketch init; creates AppCoordinator
│
├── css/
│ ├── style.css ← Global game stylesheet (~55 KB)
│ └── loading-screen/
│ └── startup-loading.css ← Startup splash-screen styles
│
├── js/ ← All game logic (~200 files)
│ ├── AppCoordinator.js ← Top-level orchestrator; wires all systems
│ ├── AssetsManager.js ← Centralised asset (image / audio) loading
│ ├── AudioManager.js ← Background music & SFX playback
│ │
│ ├── event-system/ ← Publish-subscribe EventBus
│ ├── switchers/ ← SwitcherMain — routes update/draw to active page
│ │
│ ├── ui/ ← All rendered interfaces
│ │ ├── pages/ ← Full-screen pages (menu, level-choice, settings …)
│ │ ├── components/ ← Reusable UI widgets (buttons, overlays, timer HUD …)
│ │ ├── keyboard/ ← Keyboard-navigation layer for accessibility
│ │ └── windows/ ← Modal windows (pause, result, signboard …)
│ │
│ ├── game-runtime/ ← Core game loop; LevelManager + Room + Checkpoint
│ │
│ ├── game-entity-model/ ← Entity class hierarchy
│ │ ├── base/ ← GameEntity base class & shared components
│ │ ├── characters/ ← Player, Phantom, NPC, Enemy
│ │ ├── interactables/ ← Box, Door, Button, Spike, Checkpoint, Teleport …
│ │ ├── terrain/ ← Ground, Platform, Wall tiles
│ │ └── prompts/ ← KeyPrompt, TextPrompt proximity indicators
│ │
│ ├── collision-system/ ← Detect → Resolve → Respond pipeline
│ ├── physics-system/ ← Velocity/acceleration integrator; gravity
│ ├── character-control-system/ ← Keyboard-event → validated action → movement
│ │
│ ├── record-system/ ← Record / Replay core mechanic
│ ├── replayer-voice/ ← Voice cues played back during replay
│ │
│ ├── mechanism-system/ ← Button–Wire–Door and Button–Spike/Platform links
│ │ ├── demo1/ ← Demo 1 specific mechanisms
│ │ └── demo2/ ← Demo 2 specific mechanisms
│ │
│ ├── level-design/ ← Static level data files
│ │ ├── demo1/ demo2/ ← Tutorial / legacy demo levels
│ │ ├── easy/ ← Easy-difficulty levels (7 levels)
│ │ ├── hard/ ← Hard-difficulty levels (4 levels)
│ │ └── special/ ← Special levels
│ │
│ ├── user-levels/ ← Map Editor + community sharing system
│ ├── timer-system/ ← In-level stopwatch & leaderboard timer
│ ├── achievement-system/ ← Achievement definitions, unlock logic, toast UI
│ ├── tutorial-system/ ← FSM-driven onboarding flow (Easy 1)
│ ├── loading-screen/ ← Startup asset-loading screen
│ ├── key-binding-system/ ← Rebindable keyboard controls
│ ├── i18n/ ← Bilingual strings (English / Chinese)
│ ├── sound/ ← Sound-event helpers
│ ├── develop-mode/ ← Debug overlays (disabled in release)
│ ├── utils/ ← Shared utility functions
│ └── addons/
│ └── p5.sound.min.js ← p5.js audio library
│
├── assets/ ← All game media
│ ├── audio/
│ │ ├── bgm/ ← Background music (menu, settings, 10 level tracks)
│ │ └── sxf/ ← Sound effects (jump, land, interact, death …)
│ ├── images/
│ │ ├── bg/ ← Full-screen level & menu backgrounds
│ │ ├── player/ ← Player sprite sheets (8 directions + death)
│ │ ├── npc/ ← NPC character sprites
│ │ ├── tiles/ ← Terrain & interactable tile sprites
│ │ ├── idle-action/ ← Idle-yawn animation frames
│ │ └── achieve/ ← Achievement icon images
│ ├── fonts/
│ │ └── HYPixel11pxU-2.ttf ← Chinese pixel font
│ └── text/ ← Story scripts & signboard hint text (EN + ZH)
│
└── docs/ ← Per-system technical documentation (Markdown)
- 1 Overall Implementation Approach
- 2 Technical Challenge 1 — Leaderboard System
- 3 Technical Challenge 2 — Level Editor & Sharing System
- 4 Other Functions
U Help U is implemented using the p5.js library and follows an object‑oriented, modular architecture.
The game loop runs in a fixed update–draw cycle, coordinating physics updates, collision detection, UI rendering, and level logic.
Core systems such as the LevelManager, UI system, Record System, Leaderboard System, and Level Editor communicate through well‑defined interfaces.
During development, we encountered two major technical challenges:
- implementing a robust leaderboard system that supports guest/registered accounts, name conflict resolution, and data migration;
- designing a fully functional level editor with upload/download sharing and safe serialization.
We also implemented multiple supplementary features.
Our initial approach stored all data in localStorage. This failed because:
- data could not be shared across devices
- multiple players could not coexist
- renaming caused data overwrites
- name conflicts were impossible to resolve cleanly
We also tried uploading raw JSON, but this created issues with duplicate names and inconsistent data formats.
We implemented a dual‑layer data architecture:
- stores guest progress
- caches leaderboard data for fast loading
- supports offline play
- stores global leaderboard entries
- resolves name conflicts
- maintains persistent user accounts
-
Guest → Registered migration
- merges local data into the registered account
- preserves all scores
-
Rename system
- renaming does not affect uploaded records
- leaderboard auto‑refreshes
-
Name conflict resolution
- duplicates automatically become
Alex#1,Alex#2, etc. - preserves the player’s preferred name
- duplicates automatically become
-
Real‑time leaderboard
- uploads score after each level
- sorts by completion time
- highlights the current player
Leaderboard system and brief introduction
-
Powerful Account System
- Brief introduction
Account system brief introduction
- Identity Selection Screen and naming rules
Identity Selection Screen in the game
- Specific implementation
Specific implementation
- Duplicate name detection flow
Duplicate name detection flow
- Ethics & Sustanability
Ethics & Sustanability
Our first attempt stored the entire level object directly.
This caused:
- circular references in JSON
- inconsistent behavior across browsers
- inability to load maps on other devices
- old maps breaking after updates
We designed a clean, safe JSON structure:
- tile grid
- entity list
- triggers and links
- metadata (author, version, timestamp)
Before upload:
- remove runtime states (velocity, collision flags, temporary variables)
- validate map size, entity types, coordinates
After download:
- reconstruct objects from JSON
- auto‑fill missing fields for backward compatibility
- reject invalid or malicious data
- upload to server
- browse community maps
- download and play instantly
Level editing system operation guide
Change and zoom in/out platform
Movement of the map view camera
Moving and placing component elements in the level editor
You can upload your own level to the map plaza by the 'upload' button
By 'save' button, relevent code will be automatically copied, you can paste it directly
Adjust the total number of rooms (game screens) using the Room +/- buttons
The camera transitions to the next room automatically as the player moves
The system allows for the dynamic adjustment of the protagonist's initial position at any time
The tutorial system is built on a Finite State Machine that divides the guidance flow into multiple stages. It leads players through seven sequential levels, ensuring a steady progression toward mastering the core recording and playback gameplay.
- Global Recording Control: Temporarily takes over the global recording system to precisely manage game execution and pause states
- Input Interception: Intercepts and gains exclusive control over keyboard input to restrict player actions, ensuring tutorial steps are completed in the correct sequence
- UI & Localization: Features a global mask with "hole-punch" (cutout) highlighting for guidance prompts, with full i18n support for multi-language compatibility
- Skip & Interruption Logic: Supports a one-key "Skip Tutorial" via the ESC key, with built-in logic to handle clean process interruptions
- State & Resource Management: Manages state synchronization during phase transitions and ensures automatic cleanup of UI resources and boundary conditions
- System Integrity: Fully implements the onboarding flow while strictly maintaining the independence of original game modules and ensuring no interference with core business logic
 
• Phase Description：In Easy Level 1, players can interact with the Notice Board to view the tutorial. |
 
• Phase Description：The tutorial system highlights the Key Control section of the recording UI and prompts the player to press the Record key to capture input. |
 
• Phase Description：The tutorial highlights the entire Recording UI and displays a notification that the maximum recording duration is 5s. |
 
• Phase Description：Displays an active recording prompt and informs the player that they can press the Capture Key (C) at any time to quit the recording early. |
 
• Phase Description：After recording, the system highlights the Phantom spawn area and the Key Control section of the recording UI. |
 
• Phase Description：During playback, the system informs the player that the Phantom will precisely replicate the sequence of actions just recorded. |
 
• Phase Description：The tutorial ends, and a "Congratulations" notification shows up. |
The game features two distinct difficulty modes, each with its own level sequence. Easy Mode introduces the fundamentals of recording and playback, while Hard Mode layers in complex timing and spatial challenges. This difficulty curve has been data-tuned through user testing to ensure a smooth, rewarding learning experience.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Level 6 |
Level 7
Level 1 — Room 1 |
Level 1 — Room 2 |
Level 2 — Room 1 |
Level 2 — Room 2 |
Level 3 — Room 1 |
Level 3 — Room 2 |
Level 4 — Room 1 |
Level 4 — Room 2 |
The Phantom Dialogue System is a key narrative component. NPCs trigger dialogue sequences through progressive speech bubbles with animations to enhance immersion. Decoupled from the core logic via an Event Bus, the system manages multi-stage triggers and states, enriching the narrative without interrupting gameplay.
Phantom Dialogue Prompt |
Phantom Chat Window |
This centralized hub manages player preferences including audio, keybindings, and language. Subsystems use a unified configuration interface decoupled from rendering logic, ensuring changes are instantaneous and persistent.
Settings Main Panel |
In‑Game Settings |
Players can independently adjust BGM and SFX volumes or customize keybindings. The system includes conflict detection to prevent overlapping inputs. All settings are saved locally and restored automatically upon restart.
Audio Settings Panel |
Keybinding Settings Panel |
The pause menu allows players to resume, restart, or return to level selection. Upon activation, game logic and physics updates are frozen, maintaining state for a seamless resume. It is fully integrated with the global keyboard navigation system.
In-Game Pause Menu
The game supports English and Chinese, switchable via settings. Using a centralized language pack (key-value mapping), all text is decoupled from the UI. Language switches trigger real-time refreshes without reloading levels, providing a seamless localized experience.
Language Settings Panel
The game features a range of achievements covering various aspects, such as performing specific actions. Achievement data stored persistently in local server, whenever a player meets the trigger conditions, the system displays a notification and updates the progress. This system is decoupled from the core gameplay module and responds to various in-game actions via event listeners, facilitating the future addition of new achievement types. The overview of our achievement system can be seen as follows.
Achievements Overview
During gameplay, if players meet the conditions for unlocking an achievement, the in-game display is shown as follows:
Unlock achievement as you play
Player can also check their achievement overview in achievement gallery. In this page player can see all the achievements. Locked and unlocked achievementa are displayed in different ways. Asuming achievement description and condtions for achieve unlocked achievements can also be viewed here.
locked Achievement |
Unlocked Achievement |
Achievements Gallery
We implemented full keyboard navigation. The main menu, level selection, and pause interface are compatible with both mouse and keyboard inputs, accommodating diverse player preferences.
- Supports focus navigation via Arrow keys and WASD
- The selection highlight (white border) is hidden by default; it appears only during keyboard navigation and disappears immediately when switching to mouse input
- Space or Enter confirms the selection, while ESC exits the current menu or returns to the previous screen
Menu page: default state
Menu page: mouse hover
Menu page: keyboard selection
World selection page: mouse hover
World selection page: keyboard selection
Paused menu page: mouse hover on 'Setting'
Paused menu page: keyboard selection on 'Setting'
Issue: Players require clearer, real-time guidance on game controls and mechanics. Static instructions are insufficient.
Action Plan: Implement bilingual (English and Chinese) proximity-based tooltips. Following the TA's recommendation, UI prompts (e.g., "Press [E] to interact" / "按 [E] 互动") will dynamically appear when the player's character approaches specific interactive elements, such as buttons or traps.
This aligns with Nielsen's "Recognition rather than recall". By providing contextual instructions exactly when and where they are needed, we significantly reduce the players' cognitive memory load.
Issue: Transitioning directly into Level 1 introduces too many mechanics at once, causing a steep learning curve for new players.
Action Plan: Design and insert a simple "Tutorial Level" prior to the first official stage. This safe, low-stakes environment will allow players to practice basic movements and test the core mechanics without the threat of failing. It doesn't need to be too complex; it should mainly introduce the game's controls to new players.
This addresses "Error prevention" and enhances "User control and freedom", ensuring players are comfortable with the physics and controls before facing actual challenges.
Below is a gameplay demonstration of the initial tutorial:
Figure1: Initial tutorial
The latest version of the game's tutorial can be found in the 4.1 Tutorial System section.
We conducted a quantitative user evaluation with 27 participants, using a within-subjects design to compare the user experience between Level 1 and Level 2. Participants completed the NASA Task Load Index (TLX) and System Usability Scale (SUS) after playing each level. We then ran a Wilcoxon Signed-Rank Test (with an alpha level of 0.05) to determine if there were significant differences in perceived workload and usability.
-
System Usability Scale (SUS): The test yielded W = 84.5 and p = 0.063. Since p > 0.05, there is no significant difference in usability between the two levels, although a slight downward trend was observed as complexity increased. Both levels maintained scores near or above the industry average of 68 (Level 1 mean: 75.06; Level 2 mean: 65.0). This indicates that the core UI and interaction mechanics remain relatively stable and accessible, even when players are faced with higher task difficulty.
-
NASA Task Load Index (TLX): The test yielded W = 43.5 and p < 0.001. Since p < 0.05, there is a significant difference in perceived workload between the two levels. The absolute mean score increased from 39.71 (Level 1) to 50.20 (Level 2). This significant increase confirms that the difficulty progression was effectively perceived by the participants, successfully raising the cognitive and mental demands of the game as intended for the second level.
Below is a photo of players engaging with our game:
Figure2: Other players playing our game
Throughout the development process, we adopted an immediate manual testing approach, testing features as we implemented them and using the browser console with console.log for additional verification. Whenever a new functional module was completed, we immediately operated it manually in the browser and checked whether its actual behaviour matched our expectations, allowing us to identify and fix problems before they spread further through the system.
We also inserted console.log statements at key points in the code to track the runtime state of different modules in real time, including data reading and writing, the loading of images and page modules, keyboard navigation and key bindings, the triggering of tutorial flows, the starting of timers, collision detection between the player and the clone, etc.
Figure: A small sample of console log screenshots
Following the black-box testing approach introduced in the course, we designed structured testing checklists for each functional module. From the user’s perspective, only focused on inputs and observable outputs. The test cases in each checklist were divided into three categories: normal flows, boundary cases, and potential issues. Each checklist was implemented as an interactive HTML document that supports adding and removing test items as well as exporting and sharing, making it easier to tick off items one by one and track progress.
Figure: Partial testing of the local player system
Links to the individual testing checklists:
- Account System Test Checklist
- Game Flow Test Checklist
- Local Player System Test Checklist
- Tutorial System Test Checklist
- Phantom Collision Test Checklist
Figure: Feedback gathered during testing
In the testing checklists, we tested around 380 items in total, with a final pass rate of over 95%.
- 1 The Tools and The Specific Cooperation Methods We Used
- 2 Role Allocations and Distributions
- 3 Excellently Executions During The Process
- 4 Challenges Encountered and Adjustments
-
Meetings (In-person and Online):
In-person meetings are conducted after class to facilitate face-to-face discussions, which enhance efficiency and allow for flexible supplementation of any limitations associated with online meetings. Online meetings are primarily held via Tencent Meeting, with at least one full-group meeting per week to synchronize overall progress and strategic direction. Specific issues related to the module will be addressed by the relevant team members at any time as needed. -
Kanban and Idea Tracking (Notion):
Notion is used for task allocation, progress tracking, and the consolidation of new ideas. Any emerging ideas related to game design or system architecture are recorded in a timely manner, enabling all team members to review and discuss them, and ensuring that valuable insights are not lost in transient chat records. -
Wechat Group:
The primary channel for rapid information dissemination. Any updates to tasks on Notion are communicated synchronously within the group. Obstacles or urgent issues are raised in the group at the earliest opportunity. -
Version Control (GitHub):
The only platform to submit all codes and releasing versions. -
Other Tools:
- Class Diagram Tool — (Lucidchart)
- Drawing Tool — (Procreate)
- Estimation Tool — (Planning Poker)
- Voting Tool — (Online anonymous questionnaire)
- Parallel Development — (Git Branching)
- AI Assistance — (Copilot, Claude)
- Continuous Version Iteration:
A functional demo was completed in the early stages of the project, followed by frequent updates throughout development. Each delivery also constituted a fully playable version, with no incomplete prototypes submitted which follows the idea of delivering working software frequently in Agile method.
-
Embracing Changes:
New ideas continued to emerge throughout the development process. Even when changes required modifications to underlying code logic or core gameplay, sometimes involving complete rewrites, we were willing to pursue them. Rather than settling for a sub-optimal version, we prioritized making meaningful improvements. -
Bold Architectural Refactoring:
Without altering any existing functionality, we repeatedly carried out comprehensive refactoring of the code base to enhance scalability and maintainability. Even in the mid-to-late stages of the project, when structural issues were identified, we committed plenty of time to rewriting, ultimately achieving a clear, well-organized, and extensible code structure.
-
Fragmented Collaboration and Lack of Integration:
In the early stages of the project, team members had limited experience in project development, JavaScript, and game design. As a result, individuals explored independently, leading to siloed work, insufficient communication, and knowledge fragmentation. This was reflected in unclear code interfaces and limited understanding between modules.
Adjustment: The team transitioned to a module ownership structure, where each member took responsibility for a specific component, overseeing its design, development, and integration while still contributing to other modules. This significantly improved communication, strengthened inter-module coordination, and enhanced integration efficiency in later stages. -
Loose Progress Management:
Initially, there were no clearly defined deadlines, resulting in a slow and unstructured workflow.
Adjustment: Deadlines were established for each task, with module owners mutually monitoring and ensuring progress. -
Inefficient Information Synchronization:
Task updates were recorded only in Notion without proactively informing all members, leaving some unaware of others’ progress and making code integration difficult.
Adjustment: It was agreed that all Notion updates would be simultaneously communicated in the WeChat group, which noticeably improved responsiveness. -
Pace Misalignment:
During the project, there were differences in working pace and standards of completion among team members, which is common in diverse teams. Variations in individual approaches occasionally led to misaligned pacing and misunderstandings in collaboration.
Adjustment: Through ongoing discussions, the team gradually aligned on a shared pace and common goals. Continuous communication helped establish a more consistent workflow, making collaboration smoother and effectively reducing potential misunderstandings. -
Low Efficiency in Full-team Meetings:
Meetings involving all six members often became unfocused, and the involvement of non-relevant participants led to inefficient use of human resources and slower decision-making.
Adjustment: A hybrid approach combining full-team and small-group meetings was adopted. Full-team meetings were held weekly to align on overall direction, while specific issues were addressed in smaller meetings of 2–3 members as needed.
We evaluate our game across three dimensions: Environmental, Social, and Technical, while treating Ethics and Accessibility as cross-cutting concerns. They are related to whether players can access and engage with the game effectively, the core mechanics are communicated in a clear and equitable manner, and whether the project can be responsibly developed and sustained in the future.
One of the games’ most obvious features is its relatively lightweight web-based format. As U Help U is developed using p5.js and runs directly in the browser, rather than being distributed as a large standalone package, players can access the game without the need for heavy downloads, installations, or frequent patch updates.
Performance optimization is also an important part of environmental sustainability. In system design and implementation, we strive to avoid placing unnecessary computational load on the browser, adopted several Green Software Foundation-style practices, to improve maintainability and avoid wasteful rework. For example, we deliberately selected lightweight 2D assets, to reduce GPU usage during runtime and maintain more controlled overall resource consumption. In addition, we seek to limit the size of image and audio assets, thereby lowering bandwidth demands and energy consumption during loading and data transfer.
Of course, we cannot exaggerate and say that this project is "fully environmentally friendly", but during the development process, our careful consideration was given to balancing environmental impact with rendering/computational efficiency and resource lightweighting.
This dimension is most closely linked to ethics and accessibility. For ethical, our gamne offers an experience that departs from traditional platform games. Rather than progressing through combat, enemies, or domination, advancement is achieved through observation, recording, and collaboration with your 'past self'. No time limit, no death penalty, players will feel that "each attempt holds value." Yes, our game is not just about providing entertainment; It also shaping how players understand failure and challenge.
Accessibility is also central to social impact. From visual clarity, the 'present self' is represented as a solid mauve 
figure, while 'past self' is depicted as semi-transparent dusty rose 
. We also add bilingual prompts, context-sensitive tutorials, and clearer onboarding processes. Additionally, we have implemented a configurable key binding system in the game settings, allowing players to customize controls according to their personal preferences. All aimed at reducing the cognitive barrier with understanding the time-based clone game mechanic.
However, we should be honest that our current accessibility support remains limited. Features like color-blind modes, screen reader compatibility, and broader accommodation for physical impairments have not yet been fully implemented. Meanwhile, leaderboard-linked identities may also create comparison pressure for some players. Nevertheless, from a social and ethical perspective, this project has taken a meaningful step forward.
From technical, the game is built upon a modular framework composed of multiple independent systems, including scene /level management, an event system, collision handling, character control, recording functionality, achievement system, etc. This structure allows us to separate different responsibilities, reducing the risk of "a change in one place affecting the whole system".
For example, during frame updates driven by draw, collision, control, physics, and level management are broken down into relatively clear modules, allowing mechanisms like switches, doors, traps, and characters to interact through a more transparent messaging mechanism rather than relying on tightly coupled, hard-coded connections. Furthermore, our current system limits the collection of player information; the game can be played without requiring players to input data involving personal privacy.
The impact of technical design extends beyond whether the game simply functions; it also includes what we learned through development and what the project contributes to future work. It also carries ethical implications: if we claim this is an open, collaborative, and extensible project, then the codebase shouldn't be limited to the original author's readability. Instead, it should provide a clear code structure, comprehension pathways, and well-defined module boundaries for future maintainers and students taking the course. The direction is clear: our project is not just a working prototype, but a system that can be responsibly maintained and extended over time.
Figure: Class Exercise Example - SusAF sustainability awareness framework
In summary, in the scope of a student project, our project U Help U shows a substantial engagement with issues of sustainability, ethics, and accessibility. While some aspects have not yet been fully realized for the game, sustainability is inherently embedded into the project itself: our backlog, planning, and iterations. We will pay careful attention to each line of code, provide meaningful support to diverse players, and make a deliberate commitment to enabling future development in a responsible manner.
Our project: U Help U, successfully transforms an abstract idea into a coherent and playable game. Instead of relying on combat, the game requires players to record the actions of their "present self" and then cooperate with their "past self" to complete levels. The core challenge is one of planning, observation, and spatial reasoning rather than reflex alone.
-
First is that a good game concept alone is not enough; it must be supported by communication between the team and players, a detailed structure, and an iterative mechanism. This helped us move from vague ideas like just "record and replay" toward clearer player-centered goals.
-
Second came from the implementation level: When the core mechanics are built upon "precise replay," the technical system becomes an indispensable part of the gameplay itself. Because the loop relies on the "past self" to accurately reproduce previously recorded actions, even minor deviations in timing, collision, or movement can cause level solving to fail. Therefore, shifting from "recording coordinates" to "recording input," combined with a fixed time step, is a fundamental design decision that determines the viability of the gameplay.
-
Third concerns software engineering practices. Early development is slow due to flawed engineering and failed to adequately solve extensibility. But after that, we subsequently refined our development strategy by drawing ideas from more mature examples, clarifying interface boundaries, and reorganizing the codebase into clearer modules.
For technical, it can be summarized as jumping behavior, stacked interactions, box collisions, record-system state management, and level balancing. In game architecture, for example, the inheritance hierarchy of the entity tree is difficult to perfect in a single pass. To solve this, we adopt “generality” as the key criterion for determining ownership.
Another is teamwork. We initially encountered issues with unclear interface definitions. We then collaboratively refined the shared interfaces, explicitly identifying the key data that needed to be accessed by other systems (position/velocity), as well as the methods that should be exposed for external use (including state updates and input handling).
From design, a key was ensuring that the “record and replay” mechanic did not merely remain novel but was also genuinely intuitive and easy to understand. Thus, we developed a coherent narrative framework supported by in-game signposts, research logs, and guided instructions, helping players recognize that clones should be treated as collaborators.
Looking ahead, if we have the chance to develop a larger next version, the project offers many promising directions, such as multi-phase recording, custom level creation, hidden challenge routes, and community-based competition. Building on this foundation, additional features could include in-game shops, cosmetic rewards, pets, AI-guided NPCs, and level sharing systems. The sequel could further develop the game’s worldbuilding. Through elements like signposts, archival records, NPC dialogue, and memory fragments, the concept of “collaborating with your past self” can evolve from a gameplay mechanic into a more emotionally resonant narrative experience.
Figure: The future development directions of our game
Overall, our project successfully achieved its core creative objective: transforming repetition into something meaningful. Previous attempts are not discarded because of failure but become practical resources for driving progress. Yes, what truly drives progress is never a single perfect attempt, but rather continuous repetition, revisions, iteration, and the value accumulated from all past efforts.
| Contributor | Contribution |
|---|---|
| Zhiqing Zhang | 1.2 |
| Wenlei Miao | 1 |
| Xuelin Ma | 0.95 |
| Jingran Zhang | 0.95 |
| Yiyuan Yao | 0.95 |
| Siqi Xu | 0.95 |
Team contributions for the Project.
All members completed their assigned work. Zhiqing and Wenlei made greater contributions as they took the initiative to do extra work beyond the required scope.
AI was only used for assistance purposes. The core game mechanics, level design, logical reasoning, code debugging, feature integration and final implementation were all carried out and verified by the team members.
AI was used in the following aspects:
-
Repetitive code & draft generation - we used AI to reduce the workload caused by large amounts of repetitive logic in code development. For instance, in areas such as level structure, entity creation, event listening, configuration snippets and sections with a high degree of repetitive logic, AI was used to generate a first draft based on our existing code pattern. In this way, we could focus more on designing each unique level instead of writing similar level code over and over again. And the core game mechanics, level design, logical reasoning, code debugging, feature integration and final implementation were all carried out and verified by the team members.
-
Suggestions on CSS style and layout - We manually selected, modified, and applied these suggestions.
-
Translation - AI helped translate in-game text, UI prompts, code comments, and technical documentation. We reviewed and refined translations for accuracy.
-
Art style - the artistic style of our game is totally generated by AI (Because we don’t have any team members who are particularly good at art :D).
SINCERE THANKS to all the playtesters who provided valuable feedback and suggestions to improve the game:
Zhiqing Zhang 张芷晴
────────
Yiyuan Yao 姚亦远
────────
Wenlei Miao 苗文蕾
────────
Xuelin Ma 马雪琳
────────
Siqi Xu 徐思齐
────────
Jingran Zhang 张婧然
────────
Everyone who tested our game in the Workshop on Tuesday
────────
Everyone who tested our game in the Testathon
────────
Every course lecturer and TA who supported our course and workshop and tested our game demo
────────
高云飞
────────
sjx
────────
三字人 Y
────────
雪梨来咯
────────
Arupin
────────
张子睿
────────
Robin Huang
────────
7
────────
yyy 好友
────────
饼干
────────
Wanlan Qiu
────────
Yuanyuan
────────
Junqi
────────
Yiran
────────
Rish
────────
Helen
────────
Prapulla
────────
lftc
────────
XY
────────
Maran
────────
Huayang
────────
Zhi
────────
Wanru
────────
Every friend who wished to remain anonymous
────────
Every anonymous online playtester
Most importantly, special thanks to the six of us — the team behind U Help U:
Zhiqing Zhang 张芷晴
────────
Yiyuan Yao 姚亦远
────────
Wenlei Miao 苗文蕾
────────
Xuelin Ma 马雪琳
────────
Siqi Xu 徐思齐
────────
Jingran Zhang 张婧然
We are also deeply grateful to the following individuals, whose support made a real difference:
Pete
Who played through every level of our Demo V1 and gave invaluable feedback that helped shape the final game.
────────
Yunfei
A team member's undergraduate supervisor who offered countless suggestions and words of encouragement from the very start of the project all the way through to the end.
────────
An anonymous Chinese friend
Despite severe regional network restrictions causing extremely long loading times, they persisted through a version with missing textures and numerous bugs to give us honest feedback.
────────
A game industry professional
A seasoned game professional with over 6 years of game development experience — who took the time to play our game and offered high praise. Their recognition gave the whole team a tremendous boost of confidence.