UESL Accessible Game Maker 2.0
An accessible game-building prototype for UESL, with a visual project overview, frontend/backend architecture, community contact, and live team Kanban.
We are Adhvay, Rohan, and Ishan. We are building an accessible space where UESL participants can create and play their own games, learn through experimentation, and eventually share those experiences with others.
Community contact
Founder and CEO; Programs and Partnerships contact.
Meet the UESL teamUESL connects people with intellectual and developmental disabilities through gaming and technology. Our proposed contribution is a game-making activity where participants can create, experiment, and learn at their own pace.
UESL websiteWhich activities, controls, and accessibility settings would help your participants most?
We are seeking Matthew's feedback on the prototype and its fit for UESL. A rollout or partnership has not been confirmed.
How GameMaker works
Create → play → keep improving. Choose a builder, try an idea, and see it come to life. Our goal is to make game creation an approachable way for UESL participants to experiment and learn.
How it connects
flowchart TB
accTitle: GameMaker frontend and backend
accDescr: The frontend saves game workspaces in browser storage. Login and profile requests go to Flask, which uses SQLAlchemy models to read and update SQLite.
frontend["Frontend<br/>Jekyll + shared OCS<br/>Play · Login · Profile"]
local[("Browser storage<br/>Game workspaces")]
api["Flask backend<br/>Login + profile APIs"]
models["SQLAlchemy models<br/>Read and write data"]
db[("SQLite database<br/>Account data")]
frontend <-->|Game saves| local
frontend <-->|Account data| api
api <--> models
models <--> db
The frontend runs the builder and gameplay. Flask handles login and profile requests, and SQLAlchemy models read and update the SQLite database. Game workspaces currently stay in browser storage; connecting them to accounts is planned.
Choose OpenCS Workbench, Open World, or Racing. Customize characters, environments, and settings in one workspace.
02 · Play and improve
In OpenCS Workbench, turn your choices into code and run the game alongside it. Stop, adjust a choice, and try again to see what changes.
03 · Save and return
Keep a workspace in the current browser and return to it later. Login and profile updates are stored separately through the backend.
Next · Build together
Guided controls, account-connected game saves, multiplayer, and chat are planned. Feedback from UESL participants will help shape what comes next.
Team Kanban
The local prototype brings OpenCS Workbench, Open World, and Racing together with previews and browser saves. Flask login and profile updates connect to SQLite; inherited builder account saving still needs integration.
First-time participants can face too many technical choices at once, making it difficult to reach a confident first playable result.
The original guided-mode sprint below remains a plan: one meaningful choice at a time while keeping the advanced editor available. Login/profile work is tracked separately; multiplayer and chat are future ideas, outside the current demo.
Planned six-step experience
These are acceptance criteria for the guided mode, not the current Play walkthrough above.
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.
To do → In progress → In review → Done. Future work stays in Backlog.
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.