DEV Community: SkyWalker

A Capability-First Loading Screen for Browser Horror Games

SkyWalker — Sat, 01 Aug 2026 13:29:05 +0000

Browser horror games often fail at the moment immersion is supposed to begin: audio is blocked, pointer lock is denied, a fullscreen request happens without a gesture, or saved settings are unavailable. A capability-first start screen turns those surprises into clear choices.

Detect support, but request permission later

Feature detection can happen during setup. Permission requests must stay behind a user action.

const support = {
  webAudio: "AudioContext" in window || "webkitAudioContext" in window,
  pointerLock: "pointerLockElement" in document,
  fullscreen: "fullscreenEnabled" in document,
  storage: storageAvailable()
};

function storageAvailable() {
  try {
    const key = "__horror_test__";
    localStorage.setItem(key, "1");
    localStorage.removeItem(key);
    return true;
  } catch {
    return false;
  }
}

Do not call requestPointerLock() or resume an audio context during page load. Browsers expect a trusted click or key press.

Make one explicit start action

The start button can initialize audio and request pointer lock. Fullscreen should remain a separate opt-in control because it changes the whole display.

async function startExperience(canvas, audioContext) {
  const results = [];

  try {
    await audioContext.resume();
    results.push({ feature: "audio", ok: audioContext.state === "running" });
  } catch (error) {
    results.push({ feature: "audio", ok: false, error });
  }

  try {
    await canvas.requestPointerLock();
    results.push({ feature: "pointerLock", ok: true });
  } catch (error) {
    results.push({ feature: "pointerLock", ok: false, error });
  }

  return results;
}

Failure should not trap the player. Offer keyboard turning when pointer lock is unavailable, captions when audio is muted, and a windowed layout when fullscreen is disabled.

Show a readable preflight summary

A small checklist is better than a generic compatibility warning:

Audio: ready, muted, or needs interaction
Mouse capture: available or keyboard fallback
Save data: persistent or session only
Motion: full or reduced
Flash effects: enabled or disabled

For reviewing how browser horror experiences introduce controls and different subgenres, Online Horror Games is a useful third-party directory reference. It should be presented as a curated directory, not as the developer of every listed game.

Preserve atmosphere without hiding consent

A start screen can still be atmospheric, but permission buttons need direct labels. “Enter” may look dramatic; “Start with sound” tells the player what will happen. Never disguise a fullscreen or notification request as ordinary navigation.

Listen for pointerlockchange and visibilitychange. When capture is lost or the tab is hidden, pause input and expose a clear resume action. Do not recapture the pointer automatically.

Test the failure paths

Test with autoplay blocked, sound muted at the operating-system level, pointer lock rejected, local storage disabled, reduced motion enabled, keyboard-only input, and a mobile browser without mouse capture. Also verify that pressing Escape restores a usable menu.

Capability checks are not about excluding older devices. They let the game choose a safe fallback before tension depends on a feature that might not be available. That creates a more reliable opening and avoids turning browser security prompts into the scariest part of the experience.

Deterministic Snake Movement on a Wrapping JavaScript Grid

SkyWalker — Sat, 01 Aug 2026 13:27:42 +0000

Grid-based snake movement is a good example of a system that should be deterministic even when rendering is smooth. If movement depends directly on animation-frame timing, a slow frame can skip cells, collision behavior changes across devices, and replay tests become unreliable.

The solution is to separate the fixed simulation step from visual interpolation.

Model positions as integer cells

Keep the authoritative snake body as integer coordinates.

const state = {
  width: 24,
  height: 18,
  direction: { x: 1, y: 0 },
  body: [
    { x: 8, y: 7 },
    { x: 7, y: 7 },
    { x: 6, y: 7 }
  ],
  food: { x: 15, y: 11 }
};

Pixels belong only in the renderer. Collision checks, food placement, scoring, and replay data should all use cells.

Advance at a fixed rate

An accumulator lets the simulation run in exact ticks even when requestAnimationFrame is irregular.

const stepMs = 100;
let previous = performance.now();
let accumulator = 0;

function frame(now) {
  accumulator += Math.min(now - previous, 250);
  previous = now;

  while (accumulator >= stepMs) {
    update();
    accumulator -= stepMs;
  }

  render(accumulator / stepMs);
  requestAnimationFrame(frame);
}

Capping the added time prevents a tab that was asleep for a minute from executing hundreds of updates at once.

Wrap coordinates without negative-modulo bugs

JavaScript's remainder operator can return a negative number. A reusable wrap helper avoids a special case on every edge.

function wrap(value, size) {
  return ((value % size) + size) % size;
}

function nextHead(head, direction, board) {
  return {
    x: wrap(head.x + direction.x, board.width),
    y: wrap(head.y + direction.y, board.height)
  };
}

For a hard-wall variant, replace wrapping with a bounds check. Keeping this policy in one function makes game modes easy to compare.

Queue turns between ticks

Fast keyboard input can contain two turns before the next simulation step. Store a small queue, but reject an immediate reversal that would send the head into the second segment.

const turnQueue = [];

function isOpposite(a, b) {
  return a.x + b.x === 0 && a.y + b.y === 0;
}

function queueTurn(nextDirection) {
  const last = turnQueue.at(-1) ?? state.direction;
  if (!isOpposite(last, nextDirection) && turnQueue.length < 2) {
    turnQueue.push(nextDirection);
  }
}

function update() {
  state.direction = turnQueue.shift() ?? state.direction;
  const head = nextHead(state.body[0], state.direction, state);

  const ate = head.x === state.food.x && head.y === state.food.y;
  const bodyToCheck = ate ? state.body : state.body.slice(0, -1);
  const hitSelf = bodyToCheck.some(p => p.x === head.x && p.y === head.y);

  if (hitSelf) return endGame();

  state.body.unshift(head);
  if (!ate) state.body.pop();
  else state.food = placeFood(state);
}

Notice that moving into the current tail cell is legal when the snake is not growing, because the tail leaves on the same tick.

For comparing different browser snake layouts and control styles, this collection of snake games provides several third-party examples in one place.

Deterministic food placement

Build the list of free cells and choose from it using a seedable random generator. That makes replays and failing tests reproducible. It also avoids an unbounded “keep guessing until a cell is free” loop when the board is nearly full.

Useful tests include crossing every edge, two queued turns, reversal attempts, eating on the next tick, entering the previous tail position, filling the final free cell, and pausing with a partially filled accumulator.

With cell-based state and fixed ticks, rendering can be as smooth as desired without changing the rules. The same recorded input sequence will produce the same board on a fast laptop, a slow phone, or a headless test runner.

Building Fair Rhythm-Game Judgement Windows in JavaScript

SkyWalker — Sat, 01 Aug 2026 13:21:24 +0000

A rhythm game can feel unfair even when its note chart is correct. The usual cause is timing logic that mixes wall-clock time, animation frames, and audio playback position. A fair judgement system needs one authoritative clock and explicit windows for each result.

This walkthrough builds a compact JavaScript model suitable for a browser rhythm game or prototype.

Use the audio clock

Do not advance song time by adding the duration of each animation frame. Frames can be delayed by background tabs, garbage collection, or a busy device. Instead, sample the playback clock on every frame.

function songTime(audioContext, startedAt, offset = 0) {
  return audioContext.currentTime - startedAt + offset;
}

The same clock should drive note positions and input judgement. The renderer can interpolate smoothly, but it must not become the source of truth.

Represent notes and windows explicitly

A chart note needs a timestamp, lane, and state. Judgement windows should be data so they can be tuned and tested.

const windows = [
  { name: "sick", maxErrorMs: 45, score: 350 },
  { name: "good", maxErrorMs: 90, score: 200 },
  { name: "bad",  maxErrorMs: 135, score: 50 }
];

function judgeNote(noteTime, inputTime) {
  const errorMs = Math.abs(inputTime - noteTime) * 1000;
  const result = windows.find(window => errorMs <= window.maxErrorMs);

  return result
    ? { ...result, errorMs }
    : { name: "miss", score: 0, errorMs };
}

Using the absolute error makes early and late hits share the same grade, while retaining the signed error separately is useful for calibration feedback.

Pick the nearest eligible note

When two notes are close, judging only the first item in an array can punish a valid input. Filter by lane and unresolved state, then choose the nearest timestamp.

function nearestNote(notes, lane, inputTime, missWindowMs = 160) {
  return notes
    .filter(note => !note.resolved && note.lane === lane)
    .map(note => ({
      note,
      distance: Math.abs(note.time - inputTime) * 1000
    }))
    .filter(candidate => candidate.distance <= missWindowMs)
    .sort((a, b) => a.distance - b.distance)[0]?.note;
}

Resolve the selected note exactly once. Keyboard repeat events, touch duplication, and simultaneous listeners should never score the same note twice.

Account for device latency

A calibration offset belongs at the input boundary:

const calibratedInputTime = rawInputTime - inputOffsetMs / 1000;

Store the offset locally, show whether a player tends to hit early or late, and let them reset it. Avoid silently changing judgement windows according to performance; that makes scores hard to compare.

For a browser-playable reference when checking lane layout, keyboard controls, and feedback pacing, FNF Online is a useful unofficial fan-game example. It should be treated as a gameplay reference, not as an official release.

Test timing without real audio

The judgement function is pure, so boundary tests are straightforward.

console.assert(judgeNote(10, 10.044).name === "sick");
console.assert(judgeNote(10, 10.046).name === "good");
console.assert(judgeNote(10, 10.091).name === "bad");
console.assert(judgeNote(10, 10.200).name === "miss");

Also test equal-distance notes, two lanes at the same time, repeated keydown events, pause/resume, playback-rate changes, and losing browser focus.

A reliable rhythm engine is less about elaborate math than about consistent ownership of time. Once audio position, note selection, calibration, and scoring are separated, the system becomes predictable for both players and tests.

Implementing FreeCell SuperMoves: Capacity Rules and Edge Cases

SkyWalker — Sat, 01 Aug 2026 13:20:42 +0000

FreeCell looks simple until a player tries to move a long descending run and the interface refuses. The useful programming lesson is that a legal “supermove” is not a special card rule. It is a compact way of representing a sequence of ordinary single-card moves through temporary storage.

This article derives a small capacity calculator that can be used in a browser-based FreeCell implementation, a rules explainer, or automated tests.

The basic capacity rule

Let:

F be the number of empty free cells.
C be the number of empty tableau columns that may be used as temporary storage.
The destination column is not counted as empty storage.

A common implementation uses:

maximum movable cards = (F + 1) × 2^C

With no empty tableau columns, every empty free cell holds one card and the final card can move directly, so the capacity is F + 1. Each usable empty column doubles that capacity because it can hold a previously assembled sub-sequence.

There is an important edge case: if the move itself ends on an empty column, that destination cannot also be used as temporary storage. In code, calculate the storage columns after excluding the destination.

A small JavaScript implementation

function superMoveCapacity(emptyFreeCells, emptyColumns, destinationIsEmpty) {
  const free = Math.max(0, Math.trunc(emptyFreeCells));
  let columns = Math.max(0, Math.trunc(emptyColumns));

  if (destinationIsEmpty && columns > 0) {
    columns -= 1;
  }

  return (free + 1) * (2 ** columns);
}

console.log(superMoveCapacity(2, 1, false)); // 6
console.log(superMoveCapacity(2, 1, true));  // 3

Keeping this function pure makes it easy to test. It should not inspect the DOM or mutate game state. The board parser can count available cells and columns, then pass those numbers into the rule.

Validate the sequence before checking capacity

Capacity is only half of legality. A candidate run must also be internally valid. For standard FreeCell, adjacent cards descend by one rank and alternate color.

function isDescendingAlternating(run) {
  return run.every((card, index) => {
    if (index === run.length - 1) return true;

    const next = run[index + 1];
    return card.rank === next.rank + 1 && card.color !== next.color;
  });
}

function canMoveRun(run, board) {
  if (!isDescendingAlternating(run)) return false;

  const capacity = superMoveCapacity(
    board.emptyFreeCells,
    board.emptyColumns,
    board.destinationIsEmpty
  );

  return run.length <= capacity;
}

Separate validation also produces better UI messages. “This run is not alternating colors” is more helpful than a generic “illegal move,” while “Free one cell to move four cards” gives the player an actionable hint.

Tests that catch real bugs

The most valuable cases sit at the boundaries:

console.assert(superMoveCapacity(0, 0, false) === 1);
console.assert(superMoveCapacity(4, 0, false) === 5);
console.assert(superMoveCapacity(0, 3, false) === 8);
console.assert(superMoveCapacity(2, 2, false) === 12);
console.assert(superMoveCapacity(2, 2, true) === 6);

Also test negative input, fractional values from malformed state, a destination column that becomes empty during a move, and variants whose rules limit how temporary columns may be used.

For a visual explanation of the same rule and examples of movable card sequences, this FreeCell movable-cards guide is a useful companion reference.

Why this approach works well

The formula belongs in the rules layer, not the drag-and-drop handler. That keeps mouse input, touch input, keyboard controls, hints, undo, and automated solvers consistent. A single tested function can answer all of them.

It also makes a nice accessibility improvement. Before a player starts dragging, the interface can announce the maximum movable run length. The rule stops feeling arbitrary, and the implementation stays small enough to reason about.