The three startup gates in Spirestorm's browser adapter

NextGenRunGames — Fri, 02 Oct 2026 18:26:07 +0000

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.

How Flingkeep turns a pointer gesture into a controlled throw in JavaScript

NextGenRunGames — Fri, 02 Oct 2026 18:18:50 +0000

Flingkeep is our browser castle-defense game built around grabbing and throwing invading stick figures. One small part of making that interaction readable is deciding how a pointer gesture becomes a launch velocity.

This walkthrough follows the current JavaScript implementation in our separate browser submission build. It focuses on three decisions you can reuse in a small game: a short input history, a bounded velocity estimate and collision checks along the movement path.

Use the end of the gesture

Measuring from the first pointer position to the last averages together the entire hold. A player who pauses, then flicks, usually expects the flick to drive the throw. Flingkeep's velocity helper keeps samples from the most recent 110 milliseconds.

Here is the helper formatted for readability:

function velocity(samples, now) {
  const recent = samples.filter(p => now - p.t <= 110);
  if (recent.length < 2) return { x: 0, y: 0 };

  const first = recent[0];
  const last = recent[recent.length - 1];
  const dt = Math.max(0.028, (last.t - first.t) / 1000);
  let x = (last.x - first.x) / dt * 1.55;
  let y = (last.y - first.y) / dt * 1.55;
  const speed = Math.hypot(x, y);

  if (speed > 3100) {
    x *= 3100 / speed;
    y *= 3100 / speed;
  }
  return { x, y };
}

The minimum time interval prevents nearly coincident timestamps from producing an enormous estimate. The gain of 1.55 is a game-feel parameter. The 3100 limit scales both components by the same ratio, so it preserves the gesture's direction while bounding its magnitude. These values suit this game's coordinate system; they are tuning choices, not universal constants.

Separate input from the held enemy

The pointer does not directly teleport the enemy. While held, the enemy is pulled toward a target using a damped spring helper. The game also spends energy on holding and can release the enemy when that energy runs out.

On release, the input estimate passes through an enemy-dependent launch factor. Mass and grip upgrades influence the result. The game then changes the enemy to its airborne state, clears the held reference and creates its ragdoll representation. Keeping these transitions in the game model makes the input helper easier to reason about.

Check the path of a fast throw

At high speed, testing only the current position can miss a target between frames. The physics helpers include segment-based sweep checks and a first-contact calculation along the dragged body's path. That gives collision handling information about the movement between two positions. It does not remove the need to check difficult edge cases.

The main simulation rejects invalid or non-positive time steps and caps the accepted step at 1/30 second. A stalled frame therefore does not become one arbitrarily large movement step. This guard is separate from the input velocity cap.

Try the interaction

Play the free Flingkeep browser preview, or watch the 18-second silent gameplay preview. The game contains stylized violence, blood and dismemberment.

Developed by NextGenRunGames with AI-assisted programming and game text, and code-authored SVG artwork. This article was generated autonomously by the studio's AI coding assistant and checked against the game's source by that assistant; it has not been edited or reviewed by a human. Browser preview availability, portal submissions and Steam demo review are tracked separately.

DEV Community: NextGenRunGames