UESL Accessible Game Maker 2.0
A two-week CSP frontend sprint creating a guided, accessible path from game idea to playable and saved result.
UESL Accessible Game Maker helps participants create and play games through a clear, accessible workflow. Our sprint focuses on making the existing editor easier to understand without replacing its game engine, accessibility tools, or save system.
The project already includes a drag-and-drop editor, Canvas game engine, accessibility settings, preview controls, and local or account-based saves.
First-time participants can face too many technical choices at once, making it difficult to reach a confident first playable result.
Add a guided mode that presents one meaningful choice at a time while keeping the advanced editor available. The sprint excludes multiplayer, AI generation, uploads, accounts, publishing, and new backend systems.
Six-step experience
Create a new game or restore a clearly labeled browser draft.
Done when: either path reaches the builder without losing valid work.
Name the game and select the supported platform-runner template.
Done when: missing fields show a useful correction and preserve other choices.
Choose a visual theme, challenge level, and game speed through clear controls.
Done when: Back and Continue preserve every valid selection.
Apply a preset, then adjust contrast, motion, control size, or speed individually.
Done when: at least three settings visibly change the preview.
Start, pause, reset, and exit one proven game-engine template.
Done when: a preview failure returns safely to the builder.
Review the configuration, edit a choice, and save a compatible local draft.
Done when: refresh, restore, and corrupted-data recovery pass.
Team ownership
Each teammate owns implementation, testing, review, revision, and portfolio evidence for one complete part of the workflow.
Own the guided builder interface and navigation between the six steps.
- Build semantic, responsive builder states.
- Connect controls to the shared state.
- Test keyboard order, Back behavior, mobile, and zoom.
Done when: the full path preserves choices and never relies on color alone.
Rohan's IssueOwn the accessible preview while coordinating the sprint and integration checkpoints.
- Build presets and stable preview controls.
- Run standups and maintain the Kanban board.
- Lead reviews, unblock dependencies, and record revisions.
Done when: three settings affect the preview and every sprint gate has evidence.
Ishan's IssueOwn configuration, validation, browser drafts, and the adapter to the existing game data.
- Define the shared builder-state contract.
- Build the parameterized configuration procedure.
- Test missing, conflicting, valid, and corrupted data.
Done when: valid input becomes a compatible preview configuration and drafts restore safely.
Adhvay's IssuePlanning and iteration
- Audit reuse points and agree on the shared state.
- Build each teammate's smallest working slice.
- Integrate Start through Preview.
- Record teacher or peer feedback in the issue.
- Correct interaction and integration problems.
- Complete save, restore, and preview recovery.
- Test keyboard, phone, zoom, and invalid data.
- Deploy, teammate-verify, demonstrate, and reflect.
Backlog → In Progress → Code Complete → Deployed → Verified.
Each pull request links its issue, lists its tests, receives teammate review, and records the resulting revision.
Testing and CSP evidence
Create a named game → apply an accessible preset → override one setting → preview → save → refresh → restore.
Keyboard and focus · reduced motion · 200% zoom · phone and desktop · validation · corrupted-draft recovery · preview controls · save and restore.
Issues, commits, Kanban movement, teammate reviews, feedback, and correcting revisions document collaboration and iteration.
Inputs are game and accessibility choices. Events navigate, validate, preview, save, and restore. Outputs are feedback and configured gameplay. Data is stored in one builder-state object.