DEV Community: george

Preventing Focus Loss From Launching a Charged Jump in a Three.js Arcade Game

george — Tue, 21 Jul 2026 09:58:56 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

The bug

Solstice Leap is a small Three.js arcade game where the player holds a control to charge a jump and releases it to launch. That makes the distinction between an intentional release and an interrupted input important: a jump can spend daylight, break a streak, or end a run.

I found a bug in that distinction. While charging, switching browser tabs, using Alt + Tab, or otherwise moving focus away from the game caused the character to jump automatically. The game treated the browser's blur event as though the player had deliberately released the jump control.

I recorded the bug in Issue #1 and fixed it in PR #2.

Reproduction

Start a run.
Hold Leap, the game button, or Space to begin charging.
Before releasing the input, switch away from the browser window.
Return to the game.

Before the fix, the loss of focus called releaseCharge(). The next landing check then resolved a jump the player did not choose to make, often ending the run with "Missed the platform."

// Previous focus-loss behavior
window.addEventListener("blur", releaseCharge);

blur is not an input-release event. It tells the application that it has lost focus, not that the player has committed to a charged jump.

The fix

I separated the two outcomes in the input lifecycle:

Signal	Correct behavior
Deliberate `pointerup` or `keyup`	Release the charge and launch the jump
`blur`, a hidden document, or `pointercancel`	Cancel the charge and return to aiming

The new cancellation path clears charge state, restores the player's charged visual scale, removes the button's charging state, and refreshes the UI. Crucially, it does not call the launch code.

function cancelCharge() {
  if (!state.charging || state.mode !== "charging") return;
  state.charging = false;
  state.charge = 0;
  state.mode = "aiming";
  runtime.player.scale.setScalar(1);
  jumpButton.classList.remove("charging");
  updateUI();
}

The browser and pointer cancellation events now use that function instead of releaseCharge():

jumpButton.addEventListener("pointercancel", cancelCharge);
root.addEventListener("pointercancel", cancelCharge);

window.addEventListener("blur", cancelCharge);
document.addEventListener("visibilitychange", () => {
  if (document.visibilityState === "hidden") {
    cancelCharge();
  }
});

Intentional releases are unchanged. pointerup and keyup still call releaseCharge(), so the central charge-and-leap mechanic retains its timing and feel.

Validation

I verified the change in the browser against both sides of the input boundary:

Held Leap, triggered the window blur path, and released the pointer. The game returned to aiming mode, the leap count remained 0, and no game-over overlay appeared.
Held and deliberately released Leap. The game still launched the player and resolved the landing as normal.
Ran node --check game.js to verify the JavaScript syntax.

The merged PR changes only game.js (+18/-3), so the repair stays tightly focused on the faulty input semantics. The current production source is available in the merged pull request and in the live game.

Why this matters

Focus changes are ordinary behavior: players switch windows, operating systems interrupt input, and mobile browsers hide documents. Those events should never silently become gameplay commands.

The fix makes the game more resilient by requiring an explicit release before it launches a charged jump. A player can now leave and return to the game without an accidental action deciding the run for them.

A Jump That Should Not Kill You: Fixing a False Game Over in a Three.js Arcade Game

george — Tue, 21 Jul 2026 07:20:22 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

In my browser game, Solstice Leap, the player holds to charge a leap from one floating platform to the next. The intended challenge is simple: read the distance, commit to a charge, and land safely before daylight runs out.

One tiny interaction exposed a surprisingly important rule bug: pressing and immediately releasing the jump control could trigger a Game Over, even though the player had not actually left the platform.

That felt unfair immediately. A game can punish a bad jump, but it should not punish a jump that went nowhere.

The symptom

The game computes travel from the charge amount:

const travel = state.charge * config.maxJumpDistance;
const end = start.clone().add(direction.multiplyScalar(travel));

For a nearly zero charge, end is almost identical to start. The character still plays the jump animation, but returns to the platform it started on.

My landing rule only checked whether the final position was on the next platform. Since a very short jump could never reach that platform, the game interpreted it as a miss and ended the run.

The faulty rule, simplified, was this:

if (isSafeLanding(landing, nextPlatform)) {
  advance();
} else {
  gameOver();
}

It was a clean rule, but it modeled the wrong world. The player did not have only two states, "land on the next platform" or "fall." There was a third valid state: "still safely on the platform I started from."

Reproducing the bug

The fastest reproduction was deliberately boring:

Start a run.
Press the jump control.
Release it immediately.
Watch the character hop in place and receive a game-over screen.

This was also a useful reminder that edge cases do not need exotic inputs. The most ordinary input sequence can reveal an assumption that is invisible during happy-path testing.

The fix: keep the origin in the jump state

The jump simulation already kept a landing object for the animation. I changed that object so it records both collision candidates: the platform the player left and the platform the player is trying to reach.

runtime.landing = {
  start,
  end,
  origin: current,
  target: next,
  startedAt: performance.now(),
  duration: 610 + state.charge * 280,
  height: 1.55 + state.charge * 2.25,
};

When the jump finishes, the game now checks the intended target first. A successful landing still advances the run exactly as before. If the target check fails, it checks whether the final position is still within the safe radius of the origin platform. Only after both checks fail does it show a game over.

function finishJump() {
  const jump = runtime.landing;
  runtime.landing = null;
  const landing = runtime.player.position.clone();
  const targetLanding = getLandingDistance(landing, jump.target);

  if (targetLanding.distance <= targetLanding.safeRadius) {
    landSuccessfully(jump.target, targetLanding.distance);
    return;
  }

  const originLanding = getLandingDistance(landing, jump.origin);
  if (originLanding.distance <= originLanding.safeRadius) {
    stayOnCurrentPlatform(jump.origin);
  } else {
    gameOver("Missed the platform");
  }
}

function getLandingDistance(landing, platform) {
  const center = platform.getCenter();
  const dx = landing.x - center.x;
  const dz = landing.z - center.z;
  return {
    distance: Math.sqrt(dx * dx + dz * dz),
    safeRadius: platform.radius * (platform.type === "shadow" ? 0.78 : 0.88),
  };
}

The shared getLandingDistance helper matters here. It keeps the geometry and the platform-specific safe margin identical for target and origin checks, so the new fallback cannot quietly use a looser or inconsistent collision rule.

You can see the complete implementation in the game source.

Making the fallback fair, but not free

I did not want an in-place jump to become a risk-free way to wait, reset a streak, or probe the controls forever. A harmless hop should be recoverable, but it should still have a cost.

The stayOnCurrentPlatform path therefore:

places the player cleanly back at the platform center;
returns the game to aiming mode;
resets the current streak; and
subtracts two daylight points.

function stayOnCurrentPlatform(platform) {
  const center = platform.getCenter();
  runtime.player.position.set(center.x, config.playerY, center.z);
  state.mode = "aiming";
  state.charge = 0;
  state.streak = 0;
  state.daylight = Math.max(0, state.daylight - 2);
  showToast("Still on the platform");
  updateUI();
}

This turns an accidental tap into a visible, understandable recovery instead of a frustrating reset. More importantly, an undercharged leap that actually leaves the platform still fails. The game has not become easier by accident; it has become more honest about what happened.

Input outcome	Previous behavior	Corrected behavior
Immediate release; player remains on origin	Game over	Recover, reset streak, lose 2 daylight
Charge is too short and player leaves the origin	Game over	Game over
Player reaches the next platform	Successful landing	Successful landing

How I checked it

I tested the correction in the browser with the same inputs that revealed it:

An immediate press-and-release now returns to aiming mode with the "Still on the platform" feedback and does not increment the leap count.
A deliberately underpowered leap that travels beyond the starting platform still produces "Missed the platform" and ends the run.
Normal consecutive jumps still advance the player, score the run, and activate special platform effects such as Binary Tape and Prism boosts.

Those three checks protect the behavioral boundary: remaining safe is recoverable, while leaving every safe platform is still a loss.

What I learned

This was not a rendering bug or a physics-engine failure. It was a state-modeling bug. I had treated the target as the only meaningful place at the end of a jump, then accidentally encoded that assumption as a death condition.

The repair was small, but the lesson is larger: when a game action has a start and an intended destination, validate the world the player actually occupies, not only the world the input was supposed to reach.

Small moments of unfairness are loud in an arcade game. Fixing this one made Solstice Leap feel less punishing, more legible, and much more like the game I wanted players to trust.

Try the playable build at Solstice Leap and explore the full project on GitHub.

Solstice Leap: leaping across the longest day with binary tape

george — Sun, 14 Jun 2026 16:03:34 +0000

This is a submission for the June Solstice Game Jam.

What I Built

I built Solstice Leap, a 3D browser arcade game where a glowing sun leaps across floating daylight platforms before the day fades out.

The game starts with a very simple input: hold to charge, release to jump. From there, each run becomes a small timing puzzle about reading distance, managing daylight, and choosing how far to push the streak. The player lands on normal platforms, prism boosts, shadow tiles, moving ledges, and binary tape platforms that write bits into a Turing-inspired protocol.

Live game: https://huanglianggit.github.io/solstice-leap/

Source code: https://github.com/huanglianggit/solstice-leap

Video demo: Watch the 34-second MP4 demo

Video Demo

The demo shows the opening run, distance-based jumping, binary tape platforms, prism boosts, and the first protocol transition from Dawn Tape into Prism Relay.

Direct video link: solstice-leap-demo-short.mp4

How It Fits the Theme

The solstice theme is built into the core loop rather than only the visuals.

The player is literally carrying a sun across the longest day. Daylight acts as the run timer, and every jump either preserves, restores, or drains that light. Prism platforms restore daylight, shadow tiles make survival harder, and the color palette shifts around warm sunlit platforms against a darker evening world.

I wanted the game to feel like a tiny ritual of keeping the day alive: charge, leap, land, recover light, and keep moving before sunset catches up.

Gameplay

Solstice Leap is intentionally readable at first, but it adds pressure through platform variety and protocol goals:

Daylight platforms are the baseline landing targets.
Prism boosts restore daylight and reward momentum.
Binary tape platforms write the current protocol bit.
Shadow tiles are smaller and drain daylight.
Moving ledges appear later and add timing pressure.

The player scores more for clean center landings and for building streaks. If a jump is undercharged but the sun still lands on the original platform, the run continues. The player only loses when the sun actually falls between platforms or daylight runs out.

How I Built It

The game is a static web project built with:

HTML
CSS
JavaScript
Three.js
Web Audio API

The 3D scene is rendered with Three.js. I used simple geometry, custom materials, canvas-generated textures, lighting, shadows, particle trails, and platform animations instead of external art assets.

The jump system is based on charge duration. A held input maps to travel distance, and the landing check compares the final position against the target platform and the original platform. That made the game feel more fair: a tiny hop that stays on the same pillar is not treated as a miss.

The protocol system generates binary platforms in sequence. Landing on a binary platform writes the next bit into the active tape. Completing a tape advances the run into the next named protocol, starting with Dawn Tape and then moving into Prism Relay, Turing Noon, and Longest Day.

I also added responsive HUD layout, local best-score storage, touch-friendly controls, and a GitHub Pages deployment so the game can be played directly in the browser.

Prize Category

I am submitting this for Best Ode to Alan Turing.

The game uses protocol names, binary tape, deterministic bit targets, and tape-writing platforms as a playful arcade interpretation of computation. The player is not only jumping across platforms. They are also helping a tiny sun-powered machine write and complete binary sequences before daylight runs out.

What I Learned

The most interesting design challenge was balancing a one-button arcade game with enough structure to feel fresh. A pure jumping game became much more interesting once the platforms also carried meaning: daylight recovery, risk, binary progress, and protocol transitions.

I also learned that small fairness details matter a lot. The jump should only fail when the player truly misses the platform, not when they make a harmless hop in place. Fixing that made the controls feel more trustworthy.

What's Next

If I continue developing Solstice Leap, I would like to add:

A sound toggle and richer landing sounds
More protocol variations
A few visual transitions between dawn, noon, and sunset
A leaderboard or shareable run summary
Optional mobile haptics for jump charging and landing

Thanks for checking it out.

AI Agent Skills Are Everywhere. But Which Ones Are Safe to Install?

george — Sat, 13 Jun 2026 09:04:04 +0000

AI agents are becoming less like single chatbots and more like extensible runtimes.

Instead of using a bare model, people are adding skills: coding helpers, research workflows, browser automation, MCP integrations, content generation tools, project-specific instructions, and more.

That is powerful.

But it also introduces a new trust problem.

When you install a third-party skill, you may be giving your agent new instructions, new tool access patterns, new dependencies, and sometimes new scripts. A skill can look helpful in its README while still containing risky behavior.

For example:

reading .env, SSH keys, browser cookies, or API tokens
running curl ... | sh
uploading data to a webhook
using destructive shell commands
telling the agent to ignore higher-priority instructions
including huge prompt files that waste tokens
depending on unpinned or unnecessary packages

As skill ecosystems grow, we need better pre-install checks.

That is why I built SkillPreflight.

What is SkillPreflight?

SkillPreflight is an open-source CLI and GitHub Action that scans AI agent skills before installation.

It performs static analysis and generates a 100-point scorecard covering:

Category	What it checks
Security	Dangerous commands, secret access, exfiltration, prompt injection, remote script execution
Permission restraint	Overbroad activation, unnecessary shell/network/file access
Token efficiency	Oversized skill files, repeated content, poor progressive disclosure
Lightweight footprint	File count, total size, dependencies, large assets
Maintainability	README, license, metadata, examples, documentation hygiene
Reliability	Tests, fixtures, deterministic workflow, error handling
Compatibility	Hardcoded paths, OS-specific assumptions, fragile shell usage

Usage

You can run it without installing anything globally:

npx skill-preflight@latest scan ./my-skill

You can also scan a GitHub repository:

npx skill-preflight@latest scan https://github.com/owner/repo.git

Generate JSON:

npx skill-preflight@latest scan ./my-skill --format json --out report.json

Generate SARIF for GitHub Code Scanning:

npx skill-preflight@latest scan ./my-skill --format sarif --out skill-preflight.sarif

GitHub Action

SkillPreflight is also available as a GitHub Action:

name: SkillPreflight

on: [pull_request, push]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: agent-contracts/skill-preflight@v1
        with:
          target: "."
          fail-below: "70"

Safety model

SkillPreflight does not execute scripts from the skill being scanned.

It only reads files and performs static analysis. The goal is not to guarantee that a skill is perfectly safe, but to surface obvious red flags before users install it.

Why this matters

Browsers have extension permission prompts.

npm has package audits.

Containers have image scanners.

AI agent skills should have pre-install checks too.

As the AI agent ecosystem grows, users need a simple way to ask:

What does this skill actually do, and is it safe enough to install?

SkillPreflight is an early attempt at that.

GitHub:
https://github.com/agent-contracts/skill-preflight

npm:
https://www.npmjs.com/package/skill-preflight

GitHub Marketplace:
https://github.com/marketplace/actions/skillpreflight

I’d love feedback from people building or installing AI agent skills. What checks should be added next?