Spirestorm is our action game about diving, striking and rebounding through a tower. Preparing its browser build also involves a less visible problem: the game's runtime, the document and the hosting platform do not necessarily become ready at the same time.
This walkthrough follows the current staged browser submission's platform adapter. It describes implementation choices in that build, rather than claiming that a portal has accepted the submission.
Wait for three independent conditions
The adapter keeps three flags: launchRequested, domReady and initialized. Its loadGame() function returns until all three are true. It also returns after a boot failure or if the runtime script is already present.
The actual guard, formatted for readability, is:
if (
!launchRequested ||
!domReady ||
!initialized ||
failed ||
document.querySelector('script[data-spirestorm-game]')
) return;
The page requests launch explicitly. Document readiness is tracked separately, with a one-time DOMContentLoaded listener when needed. Platform initialization runs through a promise chain. Each path can call loadGame() again; the guard decides whether enough conditions have been satisfied.
Once permitted, the function creates the game.js script and marks it with data-spirestorm-game. That marker protects the normal repeated startup calls from inserting the same runtime again. This is a small guard for this loading design, not a universal solution for every asynchronous loader.
Read saved state before starting the runtime
After the platform initializes, the adapter requests the game's save and menu-motion preference. The staged implementation accepts either an array of values or an object keyed by the storage names. A rejected storage read falls back to defaults, while a rejected platform initialization takes the boot-error path.
Only after that sequence does it set initialized and call loadGame(). The running game can then read the adapter's cached save and preference values. This ordering keeps the initial gameplay setup from racing its own first save read. It does not by itself guarantee cloud-save durability; a failed write still needs to be handled as a separate result.
Keep runtime readiness distinct from loading
The adapter also has a gameReady() method. It guards against repeated ready messages and sends the platform's ready notification after two animation-frame callbacks. Requesting launch, loading the runtime and notifying the host that the game is ready are separate events.
Pause and audio state are likewise forwarded through adapter events. That gives the game a single place to listen for host-driven state changes, while the platform-specific work stays at the boundary.
Watch or play
Play the Spirestorm browser preview, or watch the 18-second silent gameplay preview. The game contains fantasy combat, blood and dismemberment. The playable preview and this staged submission are separately versioned builds.
Steam wishlist
Spirestorm’s full game page is coming soon and is separate from the browser preview. Wishlist Spirestorm on Steam.
Developed by NextGenRunGames with AI-assisted programming and game text, and artwork generated for the project. This article was generated autonomously by the studio's AI coding assistant and checked against the staged source by that assistant; it has not been edited or reviewed by a human. Portal acceptance, Steam Coming Soon pages and Steam demo reviews are tracked separately.
Top comments (0)