Major technical changes, with dates and commit references. The original aim was local social games on phones people already used. The current direction is standalone games that people can run and share, including multiplayer, beyond the life of the Homegames servers.
Six architecture snapshots
Where does the game live?
Follow the simulation, the files, and the connection between players. These are overlapping arrangements, not six clean replacements: the public demo and TLS work developed together, and self-hosting remained an option as hosted services grew.
Game runs herePlayer clientStored files / recordsSupporting serviceLive play / peer dataLoad / save / setup
01 / 2018–2019
A game server in your home.
One computer runs the game. Phones and other browsers draw its output and send input back.
Scroll the diagram sideways on a narrow screen. Its connections are also described below.
Game runs
Your Node server owns the shared simulation; browsers render it.
Files live
On the server’s disk. The July prototype sends pixels; by December 2018 it sends scene descriptions.
Snapshot: the scene-based local arrangement at the end of 2018. Later dashboards and discovery build on it.
The public demo moves the server out of the player’s home. Visitors can try Homegames without installing their own server.
Scroll the diagram sideways on a narrow screen. Its connections are also described below.
Game runs
On the demo operator’s server. A public host is enough; this is not yet the later account, editor and publishing platform.
Files live
With the operator. The first README link is HTTP; later code explicitly supports certificates on picodeg.io.
The maintainer recalls an improvised TLS setup, possibly after an HTTP-only start. The exact early proxy and deployment topology are unconfirmed; boxes here represent responsibilities, not a machine inventory.
Evidence behind this diagram
homegames-core · d38f2ce — January 5, 2019: README links the running Layer Test at http://picodeg.io.
homegames-core · 4c4e13e — December 2020: “working on picodegio”; loads key.pem/cert.pem for HTTPS.
03 / Experiments in 2019 · automation in 2020–2021
Secure transport, same game host.
HTTPS serves the client and WSS carries live play. Certificate and discovery services help a home server become reachable with a trusted name.
Scroll the diagram sideways on a narrow screen. Its connections are also described below.
Game runs
Still on the selected Node host. TLS encrypts transport; it does not move the simulation.
Shared services
Optional discovery, DNS and certificate provisioning. The TLS server can also load certificates supplied by its operator.
This stage overlaps the public demo. The drawing combines the later helper-assisted self-hosting path; it does not claim all of these services existed in January 2019.
Later variant: a public relay, December 2022
A short code connects visitors to your running server. Both sides connect outward to the relay; in this mode it forwards live frames and input throughout the session. The game and its source stay on your machine.
Evidence behind this diagram
homegames-core · 7ec0550 — January 13, 2019: HTTPS/WSS experiment using localhost certificate files.
04 / Services grow in 2021–2024 · snapshot: spring 2026
Creation and play become a platform.
Studio, source history, publishing and hosted sessions share a server-backed workflow. The browser is the interface; the platform holds the durable content and runs hosted games.
Scroll the diagram sideways on a narrow screen. Its connections are also described below.
Game runs
Hosted Core launches game sessions. Browsers connect to the chosen session over WSS; the content API is not the live frame relay.
Files live
Hosted source history, metadata and assets support editing and publishing. Background services perform validation and other jobs.
This is a late snapshot of the hosted architecture, not one simultaneous launch. Earlier versions used different account, storage and publishing services; self-hosting continued alongside it.
Evidence behind this diagram
api · eb03859 — November 2024: MongoDB/RabbitMQ migration.
api · f26c5a2 — March 2026: Forgejo-backed project and revision operations.
homegamesio · 1efdd32 — April 2026: request a hosted session, then connect using its WebSocket URL.
05 / July–October 2026 · RTC integration October 3
The game host moves into a browser.
One player’s browser becomes the authoritative game host. Other players join over WebRTC, while the hosted catalog and source services still supply the game.
Scroll the diagram sideways on a narrow screen. Its connections are also described below.
Game runs
In one player’s browser. Guests render scenes and send input; they do not run a second authoritative simulation.
Files live
Hosted source, assets and catalog still participate. Moving gameplay off Core happens before removing centralized content ownership.
This transition explains why “peer-to-peer gameplay” did not yet mean “no content backend.” A commit date establishes implementation work, not a deployment date.
homegamesio · 13a9737 — October 3: browser-hosted Play, Studio integration and HTML exports.
api · 60c4667 — October 3: hosted-game validation for RTC listing and sharing.
homegamesio · fd55ab5 — October 9: catalog and public-room discovery remain part of the flow.
06 / Current local work · October 14, 2026
Keep the game. Host the session.
The website distributes static tools and curated games. Your projects live on your device; portable files and peer transfers let them travel without a central game repository.
Scroll the diagram sideways on a narrow screen. Its connections are also described below.
Game runs
In the host browser, or an optional self-hosted Node server using the same package. The browser host must stay open; there is no automatic host migration.
Files live
Studio projects in IndexedDB; exported ZIP/HTML wherever you keep them. Recipients can save independent copies. Exports are not full Studio-history or progress backups.
Shared services
Static hosting and private signaling; optional STUN/TURN. Self-hosted HTTPS can still use homegames.link and certificate services, whose own database/queue needs remain separate.
Working tree, not a deployment announcement. Saved games can play locally without Homegames. Automatic rooms currently end if signaling disconnects; manual pairing is a separate path and some networks still need a relay. Play and copy have separate UI flows, but joined players can currently request source through the gameplay protocol.
Local audit: homegames-core/docs/local-ownership-audit.md. Remaining work includes execution isolation, play/copy permissions, workspace recovery, migration exports and release-device/network checks.
012018–2019
Drawing, browsers, and a home server.
The earliest code sends a shared drawing to connected browsers. By the end of 2019, Homegames has a dashboard, separate game sessions, and a way to find the server on a local network.
The early arrangement
Home servershared game state
↔
Browsersdrawing + input
The game runs on a machine in the house. Connected browsers display it and send input back.
The repository starts; a drawing prototype follows.
The first commit on May 12 contains a README and license. A prototype arrives in July. By July 22, a server keeps a 320 × 180 pixel buffer and broadcasts drawing changes to connected browsers over WebSocket.
Commit evidence
homegames-core · ebacc4e — The earliest commit in the checked history; repository setup, not a working game.
Squisher changes from a rendered pixel grid to a description of entities: their colors, positions, and sizes. The browser draws the scene. That division between game state and browser rendering becomes a central part of Homegames.
Commit evidence
homegames-core · e991517 — The serialization and rendering changes are visible in the Squisher and browser code.
Find the server without typing its local address.
The homegames.link service is documented as an optional way to find a Homegames server in the same household. A server registers its local address; the service redirects a browser to it. It is a discovery helper, not a tunnel to another network.
Commit evidence
homegames.link · 787c675 — README describes registration over WebSocket and lookup by public IP.
A dashboard connects the games.
The dashboard lists games, starts sessions on allocated ports, and tracks those sessions. A Home button provides a route back. Homegames now has a shell around the individual games.
Commit evidence
homegames-core · b7acb9b — “working dashboard plus working home button.” Author date is December 14; committer date is December 24 in the replayed history.
022020
The framework gets its own home.
Rendering, game logic, and shared data structures begin to separate into reusable projects. The repository split makes the individual pieces easier to develop independently.
Repository boundary / January 2020
core → squish + web
The new repositories contain pieces of an existing project. Their initial commits are not the beginning of Homegames.
Squish and the browser client split out.
Squish gains its own repository with GameNode, colors, serialization, and tests. The existing browser client moves into homegames-web. Core removes its embedded browser files and shared primitives.
Commit evidence
squish · 514ea6d — January 15: framework implementation and tests.
Core adds a Dockerfile and instructions for running the Homegames backend in a container, connected to the browser client. This packages the server as a whole; containers for individual game sessions arrive later.
Commit evidence
homegames-core · 71462fc — Adds the Dockerfile, build exclusions, and README instructions; later merged into Core main.
BRANCH EXPERIMENT
An early WebRTC experiment.
A separate development branch adds peer-connection negotiation and data channels, using WebSocket for setup. It is an early experiment, not the browser-hosted multiplayer implementation added in 2026.
Commit evidence
homegames-core · 7ebb883 — Found on archived web-rtc-node / game-thing remote branches; not an ancestor of the current Core HEAD.
homegames-common starts collecting HTTP, certificate, and account helpers. The game framework remains Squish; this library handles code needed across the surrounding platform.
Commit evidence
homegames-common · 7508074 — Early shared helpers, described by the commit as working with homegames.io.
032021–2022
A catalog, a launcher, and more ways to play.
Homegames grows the systems around the games: accounts, distribution, versions, validation, and remote connections. Local loading develops alongside those services.
Separate services support finding, submitting, distributing, and connecting to games.
A combined launcher and website accounts.
The homegames launcher starts Core and the browser server together. Website signup, login, and email confirmation follow in February, backed by the account service. The launcher is not yet an Electron application.
Commit evidence
homegames · 8440f50 — January 13: forks the installed Core and Web packages.
gatekeeper · 318d01d — December 2020 account handlers use Cognito for signup and confirmation.
homegamesio · c284bdd — February 7: website signup/login interfaces and confirmation page.
The catalog gets a publishing workflow.
The landlord service exposes searchable game records and versions. Homedome adds a pipeline that downloads a chosen GitHub commit, inspects its files, runs a tester, and contacts the repository owner for approval.
Commit evidence
landlord · e377a8f — April 7: game and version records, queries, submission approval codes.
homedome · 6ff065e — July 24: code download, index.js checks, strace-based inspection, and approval email. Some validation/publication functions remain stubs; this is not a security guarantee.
Pick a version of a game.
The dashboard gains working version selection. The chosen version is passed through download and session launch, and downloaded versions are stored separately.
Commit evidence
homegames-core · 4962801 — “Game versions (#55)” connects version selection to download and execution.
Load games from a local library.
Downloaded-game storage and metadata expand in May. In July, Core can scan a configured local game directory and launch a custom game directly from a path. Games do not all have to begin with a catalog lookup.
homegames-core · 1328561 — July 16: LOCAL_GAME_DIRECTORY scanning and START_PATH. Downloading itself predates these changes.
Controllers and remote invitations.
Homepad supplies gamepad input. A WebSocket relay allows remote players to join a running server using a short code, forwarding game frames and player input. Multiplayer still passes through that relay.
The platform gains a consolidated API, a desktop shell, and saved game data. Other changes improve offline behavior and let operators choose more of their own infrastructure.
Local games survive failed network lookups.
“Revive offline” adds fallbacks to local game details and search results. If a remote request fails, the dashboard can still show games it already has.
A single HTTP server wires together game and asset creation, public game/version data, publishing, and contact handling. The API becomes a common entry point for the platform’s services.
Commit evidence
api · cdaf001 — Routes are connected here; the March 5 initial commit has fewer active routes.
Publishing tests move into a container.
Homedome, the publishing-validation worker, adds a Docker path for downloading and testing submitted game code in July. A dedicated validation image is checked in during December. Containerized testing becomes part of the publishing pipeline.
Commit evidence
homedome · 093dd04 — July 1: the publish handler invokes dockerPoke and runs the submitted archive through a Docker container.
homedome · 79825fc — December 28: adds Poker-Dockerfile with Node and strace. These early changes do not yet specify the network and resource restrictions added in 2026.
Version 1.0, then an Electron shell.
Core and the launcher are versioned 1.0.0 on July 10. On August 20, the launcher adds an Electron window and local HTML shell. These are distinct changes a month apart.
Child sessions load and store local JSON data and pass saveGame and saveData to game constructors. A click-count example demonstrates restoring progress between sessions.
The website adds game pages with descriptions, creators, version counts, publication dates, and a way to try a game. Developer profiles collect a creator’s games and profile details, including a configurable QR code.
Commit evidence
homegamesio · 7f3fe1f — Adds game.html, dev.html, routes, and the related website and profile controls. Earlier February 19 work survives on a separate development branch; this commit is in the current site ancestry.
More of the platform can be hosted elsewhere.
The API moves users, assets, and game data toward MongoDB, and background jobs toward RabbitMQ, with local password handling. Core makes its API address configurable. The separate worker repository, started in September, adds certificate issuance and local-model content generation in November.
Commit evidence
api · eb03859 — November 11: “Support self hosted stuff”; MongoDB and RabbitMQ changes. Some AWS integrations remain.
worker · c205ce6 — November 24: ACME certificate requests and content generation through node-llama-cpp. The first queue consumer was committed September 15 at 8abc598; its publishing handler was still a stub.
052025BRANCH WORK
Agent-assisted game experiments.
The 2025 history includes a concentrated run of game prototypes and experiments with agentic development. Lemonade, Thangs, and an expanding camera test carry assistant credits in their metadata; Cursor project rules and a ViewableGame guide appear alongside the code.
Preserved on a development branch
hot-potato-improvements-jan-2025
36 commits dated 2025, including 24 on July 19–20. These original commits are outside the current Core main ancestry. This chapter records the experiments without treating them as released features or assuming none of their code was reused later.
Hot Potato updates start the branch’s year.
Core adds Squish 1.3.6 and updates Hot Potato. The branch keeps its January name as later work moves into other games.
Commit evidence
homegames-core · 4c0b706 — Adds the Squish version, updates the runtime map, and changes Hot Potato.
Lemonade, Cursor rules, and a survival prototype.
A Lemonade Stand prototype implements ingredients, recipes, pricing, weather, and customer simulation. A Cursor project-structure rules file is committed the same day. On July 16, Thangs adds a block-based survival prototype with enemies, projectiles, and per-player camera views.
homegames-core · 41ff442 — July 16: more Lemonade work and the new Thangs prototype, credited to “User & Assistant”.
A camera test grows into a resource-and-combat game.
Enhanced View Test begins with player movement and independent camera views. Over a dense run of revisions it gains resource gathering, combat, upgrades, and a lemonade-stand system. The code is then split into managers, systems, and configuration modules. A ViewableGame development guide documents view handling, coordinates, and rendering patterns.
Commit evidence
homegames-core · 496afef — July 19: initial Enhanced View Test, marked isTest and credited to “Assistant”.
A Halloween prototype is added on October 19 and replaced by Halloween Words on October 25. Further revisions add and adjust falling items, collision handling, images, and sound. The branch’s game experiments continue beyond the July burst.
homegames-core · c9313bd — October 26: continued Halloween Words revisions; the game credits Joseph Garcia.
Branch and authorship notes
All 36 commits are present in the locally available origin/hot-potato-improvements-jan-2025 history; none is an ancestor of the checked-out Core main at 61a9f58. Counts use unique commits with author dates in 2025, not lines of code or releases.
The maintainer recalls this as a period of agentic-development testing. The checked-in assistant credits and Cursor rules support that context; they do not identify which model wrote each change or establish a game's release status.
062026
Studio expands. Games move into browsers.
Editing, media creation, publishing, and debugging gather in Studio. Docker adds isolation to server-side game runs and publishing tests. Browser execution, downloadable HTML, and RTC then change where games can run.
A different place to run the game
Host browsersimulation + display
↔
Guest browsersRTC + player input
Connection signaling still uses a service. The host tab must remain open. The October 3 implementation is not yet independent of Homegames signaling.
Studio adds browser editing and version history.
The first Studio implementation includes a game list, file tree, editor, saved versions, and restore controls. Each game has a Forgejo repository behind the API. Projects still live on hosted infrastructure at this stage.
Commit evidence
homegamesio · 5109c22 — Adds studio.html and studio.js; initial editor and history interface.
api · f26c5a2 — Forgejo-backed file operations, commits, restoration, and repository creation.
Preview, draw, and record inside Studio.
Studio gains Run, Restart, and Stop controls, with preview updates after editing. An asset library follows, including uploads, audio previews, a pixel drawing tool, and microphone recording. These first previews send game code to a server.
Commit evidence
homegamesio · 4ee055a — March 29: preview panel and server-backed preview lifecycle.
homegamesio · 2400f81 — April 14: asset browser, drag-and-drop upload, 32 × 32 drawing exported as PNG, and microphone recording uploaded as WebM.
Local servers can isolate individual games.
A Core development branch adopts a shared session manager that can start each game in its own Docker container. The work reaches main in July. Game source is mounted read-only, with memory, CPU, and process limits. The original implementation falls back to a child process when Docker or its image is unavailable.
Commit evidence
homegames-common · 7103bb9 — Adds GameSessionManager and Docker helpers: per-game containers, dropped capabilities, read-only source, optional writable saves, and a fork fallback. Running sessions still have network access.
homegames-core · bf92d5e — April 15: branch implementation adds the homegames-runner image, container entry point, validation script, and dashboard integration. This original commit is outside current main ancestry.
homegames-core · 406d10e — July 5: the Docker image, validator, and session-management changes enter current Core main through the broader #102 commit.
Publish a saved version and share a preview.
Studio adds publishing controls beside saved commits, with pending, published, and failed statuses plus retries. Templates, shareable preview links, and live logs follow. The API also replaces Elasticsearch catalog queries with MongoDB search and lists games with published versions.
Commit evidence
homegamesio · b91ee32 — April 19: per-version publishing, status polling, errors, and retry controls.
api · 75f179e — April 19: publishing endpoints and MongoDB catalog search. A similar April 15 Elasticsearch-removal commit exists on a separate branch.
homegames-client starts its own repository, separating browser rendering, input, and connection handling from the web server around it. Earlier browser history remains in Core and homegames-web.
Commit evidence
homegames-client · e1a11c4 (local repository; no remote configured) — Initial extracted browser client. Source evidence is available in the local repository.
Publishing requires an isolated runtime check.
The newer publishing worker downloads the selected commit and tests it in Docker with networking disabled, a read-only filesystem, resource limits, and a timeout. In May, publishing fails if Docker validation is unavailable, and a syntax-tree scan checks JavaScript files before execution.
Commit evidence
api · 5f6a2bb — April 25: api/worker.js integrates Docker validation after source, size, and license checks. At first, it could skip the runtime check if the helper was unavailable.
homegames-common · 3a77c60 — April 15 foundation: validation containers have no network, dropped capabilities, a read-only root/source, bounded temporary storage, and CPU/memory/process limits. Timed-out containers are stopped and removed.
api · a5f2117 — May 23: Docker validation becomes mandatory; AST-based source scanning covers JavaScript files across the submitted archive. The runtime check loads and briefly exercises a game; it is not a proof of safety.
Reusable media and AI editing join Studio.
The asset browser adds personal and public collections, search, tags, and publishing controls. An AI edit interface proposes game-code changes for review. API queue endpoints and the separate worker’s local model runner follow, connecting an editing request to a generated result.
Commit evidence
homegamesio · a04c90c — May 30: public asset catalog and “Ask AI to edit”; returned code enters the editor as an unsaved change.
api · 76f635f — June 14: AI request, status, and result routes, with source and prompt sent to the inference queue.
worker · d732b86 — June 20: the queue worker hands game-editing jobs to a persistent Python child and posts results back to the API.
worker · 58a442b — June 20: adds the local MLX model runner, authoring prompt, JavaScript syntax validation, and retry loop. Studio’s AI UI is temporarily hidden on July 5 and re-enabled August 15.
A game can run locally—and download as HTML.
The client gains a LocalSession that runs game code in the browser. The API can package source, declared assets, and the client runtime into one HTML file. This early download path explicitly excludes multiplayer games.
Commit evidence
homegames-client · 29b7406 (local repository; no remote configured) — LocalSession, browser game loader, and local input dispatch.
api · 02e6967 — Local-play manifests, asset bundles, and standalone HTML generation.
Start making a game without an account.
Guest Studio lets someone choose a template, edit it, and run it locally in the browser. A saved guest draft can be restored or carried into a hosted project after signup. Accounts are still required for the hosted workflows at this stage.
Commit evidence
homegamesio · 43cf7a3 — Guest templates, locally saved drafts, browser previews, and conversion to a hosted project; server-backed sharing remains available separately.
api · 3d59c1b — Public template-file endpoint supports guest creation.
Inspect scenes and scrub recorded frames.
Studio adds a scene-tree inspector, node highlights, recorded-frame scrubbing, and input-event markers. A second simulated local player helps test multiple views. Find-in-file, syntax checks, staged file changes, and recovery of unsaved drafts improve the editor around it.
Commit evidence
homegamesio · 7206fc5 — Adds the inspector, frame recordings retained after Stop, second-player preview, and editor recovery. Recordings capture rendered snapshots and input markers, not deterministic game replay.
Publishing checks the archive more closely.
Validation adds a substantive README requirement, rejects symbolic links in the submitted archive, and checks the declared game name and Squish version before running it. Validation warnings are kept with the publishing result.
Commit evidence
api · 603fc0e — Extends api/worker.js with archive checks, static metadata parsing, supported-version checks, and warning persistence.
Artwork and sound can leave Studio as files.
Drawing gains configurable dimensions, shapes, fill, undo, and touch or stylus input. Audio tools can layer, split, mute, and mix sounds into WAV files. Artwork, recordings, and mixes can be downloaded directly without an account or API.
Commit evidence
homegamesio · 6e59ed2 — Expanded drawing and audio tools, local media downloads, mobile navigation, and project search and archive controls.
RTC multiplayer reaches the browser host.
Website Play, Studio previews, and downloaded HTML games gain RTC invitations. Friends join the existing game running in the host’s browser. Studio no longer needs to upload preview source to Core just to share that session.
homegames-client · 82c29d4 (local repository; no remote configured) — Adds RTC sessions, data-channel handling, and sharing UI.
homegamesio · 13a9737 — Browser-hosted Play and Studio sharing; documents RTC in downloaded games.
api · 60c4667 — RTC listing validation and downloadable-game sharing.
The public site puts playing first.
The homepage and catalog center on game cards, featured games, and live rooms hosted in players’ browsers. Search and filters get shareable URLs. Game pages use the selected version’s manifest to offer play, multiplayer, download, and source options.
Commit evidence
homegamesio · fd55ab5 — Rebuilds game discovery and version-aware play options. This is committed local history; it does not establish a deployment date.
07OCTOBER 2026 →IN PROGRESS
Portable games. Fewer dependencies.
The current local refactor packages source, media, and a player together. It also removes accounts and hosted publishing from the active workflow and adds a manual connection path that can bypass Homegames signaling.
A file you keep
Export an ordinary ZIP of source and media, or one playable HTML file with the game and its runtime inside. A saved HTML game can run locally without loading Homegames.
A copy you share
Send the complete project over an RTC data channel. Once received, a copy has its own life: it can be played, saved, edited in Studio, or passed on again.
A smaller website
Build game pages and downloads as static files. Keep Studio projects in the browser. Remove accounts and centralized publishing from the active path.
A way around
Exchange connection offers and answers manually to pair loaded players without Homegames signaling. Keep a home server as another option.
Current connection paths
What if Homegames goes away?
homegames.io + connection API · available
Your gamesaved file + browser
↔RTC
Your friendloaded player
The convenient path. Open your game and invite a friend. Homegames signaling introduces the browsers; one browser runs the game and exchanges play data with the other over RTC.
The saved file also supports local play without the website. Ordinary automatic invitations still depend on the connection service.
An illustration of the design, not a live network test.
Independent of Homegames does not mean independent of the network. The host must stay open. Public STUN is optional; some networks require a TURN relay, which the manual interface does not configure. Automatic rooms currently close when signaling disconnects; they do not switch to manual pairing on their own.
Current work, not a release announcement
This chapter describes the local refactor inspected on October 14, 2026, including uncommitted work. It is not a claim that these changes are deployed.
Joining a live game and receiving an independent copy are different actions. Source exports do not automatically include Studio snapshot history or the sender’s game progress.
Current direction
From hosted services to standalone games.
The refactor is still in progress. Its focus is portable game files, browser-hosted multiplayer, and fewer required services. The timeline will continue as that work becomes committed and released.
This is a selection of turning points from the local Git histories, not a release calendar. Dates are commit author dates. Coverage includes locally available branches and commits that may not have been pushed. Expand a milestone to inspect its source; a commit records work, not necessarily a public launch. The 2020 RTC experiment and 2025 game experiments are explicitly marked as branch work outside the current Core main ancestry. The final chapter describes work in progress as of .
The chapters group technical changes; they do not infer personal motivations. The original aim and current direction above come from the maintainer. The timeline and diagrams are static HTML and remain readable without JavaScript. The logo and font are served by this site; following source links needs the linked site.
Repositories behind the timeline
homegames-core — earliest experiments, game sessions, dashboard
