Atomic Spring

Atomic Spring is a personal colony-simulation project set after a societal collapse. Players manage a settlement, direct characters, and work with limited resources. The project is in development; these notes describe its current implementation rather than a finished commercial release.

The engineering work spans the browser interface, world rendering, simulation rules, and a backend that stores settlement data. The public demo opens with account creation or sign-in before entering the settlement.

The client uses React and Vite, with a PixiJS layer for the world map. React handles interface components while PixiJS draws terrain and structures. The map renderer includes seasonal visual changes and seeded terrain variation.

Keeping rendering separate from simulation rules lets the interface display the world without making drawing code responsible for deciding what a character should do next.

Character actions have explicit types and phases, with target identifiers and tile positions. Movement, work, eating, sleeping, and construction use that state to coordinate actions over time rather than treating each click as an isolated event.

Idle behavior is rule-based. It prioritizes immediate needs and then selects from weighted activities, with personality influencing those weights. This is game AI, not a trained machine-learning model or an LLM agent.

A Node.js and Express API works with PostgreSQL through Drizzle. The data model includes users, worlds, tribes, inventories, structures, resources, and survivors, with relationships between the records.

Persistence and browser simulation are distinct responsibilities. Saving a record is not the same as advancing the simulation: movement, action transitions, and resource interactions also need consistent client-side state.

The repository contains tests for movement scheduling, action transitions, resource mechanics, and simulation updates, alongside API tests and Playwright browser-test files. Those tests target individual rules and interactions rather than relying only on manual playtesting.

Movement, resource use, and character state are closely connected. Regression checks help catch interactions between mechanics, while playtesting remains necessary to understand whether the settlement loop feels coherent. Both are ongoing work as the project develops.