DEV Community: NextGenRunGames

A practical first-minute playtest for browser games

NextGenRunGames — Mon, 12 Oct 2026 11:42:14 +0000

A browser game can be easy to open and still be hard to understand. In a short playtest, the first minute can reveal whether players see the main action, understand its result, and know what they can try next.

Show the action before the instructions

Start a new player at the normal opening state. Let them play without coaching. Note when they make their first meaningful input, when they recognize what happened, and when they reach a decision that changes the next attempt.

The right sequence depends on the game. In Flingkeep, a player grabs an attacker, chooses an angle, and releases it toward the siege. In Spirestorm, a dive and rebound lead into a choice to bank a haul or climb farther. In Line & Lode, the player casts a claw, tunes its pull, and tries to free ore before the chain snaps. Each loop asks the preview to make cause and effect visible quickly.

Ask about understanding, not approval

After the play session, ask:

What did you think the goal was?
What told you that an action had worked or failed?
What did you want to try next?

These questions help distinguish a confusing goal from feedback the player did not notice. Ask after play rather than explaining during the attempt; otherwise the test measures your instructions as much as the game.

Change one thing and observe again

Choose the earliest moment that caused confusion. Adjust one part of the experience—such as the timing of a cue, the contrast of a result, or the transition into the next choice—then repeat the same short test. Changing several systems at once makes it harder to learn which adjustment helped.

A browser preview does not need to contain a full campaign. It needs to communicate one honest reason to continue and make the current playable state clear. Our current projects and builds are listed at NextGenRunGames, with each project page describing its status.

Some projects use AI-assisted programming and text plus pre-generated AI-assisted artwork. No AI content is generated during gameplay; individual game pages list the relevant details.

Build Steam wishlist links with URLSearchParams: a four-game campaign example

NextGenRunGames — Sat, 10 Oct 2026 16:00:00 +0000

A Steam wishlist campaign needs links that tell you which channel a visitor came from. Here is the small helper we use for our October studio posts. It generates one URL per game and channel, so the copy and the link use the same campaign identifier.

Keep the inputs separate

Store the app ID with the game, and keep the channel name separate from the campaign name. Avoid rebuilding a query string by hand for every post.

const campaign = 'steam_wishlist_oct2026_batch1';

function wishlistUrl(appId, channel, gameId) {
  const url = new URL('https://store.steampowered.com/app/' + appId + '/');
  url.search = new URLSearchParams({
    utm_source: channel,
    utm_medium: 'social',
    utm_campaign: campaign,
    utm_content: gameId + '_v1'
  });
  return url.href;
}

console.log(wishlistUrl('5308920', 'devto', 'spirestorm'));

URLSearchParams handles query encoding. The app ID chooses the destination; the source distinguishes DEV from another channel; the campaign groups the batch; and the content value distinguishes the game and copy version. Those roles are conventions in this example, so choose names that your team can keep consistent.

If you change the caption later, you can increment the content version. Keep the campaign value stable while comparing posts within the same batch. Do not put a reader's name, email address or other personal data in these URLs.

What Steam can measure

Steam's UTM Analytics documentation describes the supported tags and the distinction between visits and eligible tracked visits. Conversion tracking depends on a visitor being logged in to Steam and is subject to privacy limits. A tagged visit is not proof of a wishlist or a sale. We have no campaign results to report yet.

Our practical workflow is to save the actual scheduled post URL alongside its Steam destination, then check publication before recording any engagement. A prepared caption is a draft; a platform-confirmed future post is a schedule.

Four real destinations

The helper is being used for these public Coming Soon pages. Each link below uses devto as its source.

Spirestorm: Your next foothold is an enemy. Dive into a pack, land a strike and rebound higher in Spirestorm. Bank your gold, or risk another climb.
UNDERSTAR: Dig Below, Rise Above: Every shaft you dig becomes part of the next expedition. Explore a persistent mine, fly through caverns and search for lost stars in UNDERSTAR.
Debt & Daylight: Six midnight bills. One physical coin pusher. In Debt & Daylight, aim each coin drop and choose workshop upgrades while the clock runs down. Can your machine cover the next payment?
Line & Lode: How much strain can your next haul take? In Line & Lode, cast a claw, adjust reel force and bring ore home before the chain gives out. Upgrade your rig for the next claim.

These are the full-game Coming Soon pages. Demo availability is separate. Flingkeep's main Steam page is still in review, so it is excluded from these wishlist links.

This article was written by our AI assistant from the current studio campaign and Steam documentation. The games' individual Steam pages contain their content and AI-use disclosures.

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.