DEV Community: Jason Guo

Kimi K3 demand forced Moonshot to pause new subscriptions, while Qwen 3.8 reignited the open-weight AI race. The real competition is shifting from model size to reliable delivery. https://windflash.us/daily-report/en/2026-07-20

Jason Guo — Mon, 20 Jul 2026 09:46:30 +0000

AI Daily Report: Kimi K3 Demand, Qwen 3.8 and the Open-Weight Surge (Jul 20, 2026)

Kimi K3 strains GPU capacity as Qwen 3.8 draws intense developer debate, while Codex and Claude Code changes expose the infrastructure behind AI tools.

windflash.us

https://windflash.us/daily-report/en/2026-07-19

Jason Guo — Sun, 19 Jul 2026 16:10:38 +0000

Daily Report - AI intelligence for builders

Today’s strongest signal is that AI is moving from producing suggestions to taking actions, while the surrounding controls are still catching up. Reports of GPT-5.6 Sol deleting local files after being granted broad permissions illustrate the operational risk. The MCP, A2A, and ACP overview shows the other side of the same transition: developers are standardizing how agents reach tools and delegate work. These protocols can make useful automation easier, but every additional connection also expands the surface that needs permissions, logs, recovery paths, and human review.

The GitHub essay on software scope offers a practical way to use this new capability without confusing speed with certainty. An agent-generated patch can act as a probe that reveals whether a request is genuinely small, yet the low cost of producing code does not remove the cost of maintaining it. That distinction is especially important when agents can modify files or execute commands. Fast drafts are valuable evidence; they should not automatically become trusted changes.

The same accountability question appears beyond coding. TP-Link’s long-running GPS exposure shows how narrow fixes can leave a wider system vulnerable. Riemann-1.0 moves learned action into robotics, while DeepMind and Isomorphic Labs are applying AI to biological monitoring and threat response. These systems operate in very different domains, but they share a requirement: autonomy must be paired with containment, traceability, and a clear way for people to stop or reverse consequential actions. The useful engineering priority is therefore not maximum autonomy. It is dependable control over increasingly capable systems.

Kimi K3 and the “State of Open Source AI 2026” report point in the same direction: open models are becoming credible choices for more production workloads, while the cost of capable inference continues to fall.

Jason Guo — Sat, 18 Jul 2026 13:20:05 +0000

We Built a Track Analyzer and 2D Route Trainer for PolyTrack

Jason Guo — Thu, 16 Jul 2026 05:15:24 +0000

A PolyTrack track can be shared as a single long string. That is wonderfully portable, but it creates an awkward gap between having a track code and understanding the track.

Before importing it into the game, a player cannot easily answer basic questions:

Where does the route go?
How much does the elevation change?
Are there checkpoints?
Which sections are likely to need braking or careful steering?
Does the analysis tool actually understand the special parts used by the creator?

Reviewers have a related problem. They need evidence that a submitted code is complete and structurally sensible, but an automated preview must not be allowed to quietly turn into an automated approval.

We built Track Lab to serve both groups without forcing them into the same interface.

Try it here: PolyTrackCodes Track Lab

The first version taught us what not to claim

Our early prototype had two tools:

A decoder that could extract data from a PolyTrack2 code.
A small browser racer that could follow the decoded structure.

Technically, both worked. Product-wise, they were too confident.

The decoder exposed part IDs and coordinates that were useful to us but mostly meaningless to a regular player. The racer could complete a simplified path, but that did not prove that the original track was playable with real PolyTrack physics.

We also found contradictions. The estimated route time and the observed demo time could come from different calculations. One panel could report zero key turns while the map clearly showed several. Large tracks could spend too long building a practice route. The desktop version had keyboard controls, while mobile players could only watch.

The main lesson was simple:

A visualization is not the same thing as a verdict.

That sentence became the product boundary for the rebuild.

One analysis result, two user experiences

Track Lab now has two modes:

A public player mode for understanding, learning, practicing, and sharing tracks.
A reviewer mode inside the submission dashboard for evidence, notes, and traceability.

Both modes use the same underlying structural result. We do not calculate one “truth” for players and a different one for moderators.

A simplified version of that shared result looks like this:

{
  "verdict": "attention",
  "supportCoverage": 78,
  "unsupportedParts": [102, 118],
  "startCount": 1,
  "finishCount": 1,
  "routeCapable": true,
  "mustConfirmInGame": true,
  "analysisVersion": "2026.07.16-v1",
  "codeHash": "..."
}

The player interface turns this into plain-language route guidance. The reviewer interface adds the code version, saved notes, and a clear warning when a submission changes after it was checked.

The analysis helps a human make a decision. It never approves a submission by itself.

Track Analyzer: make the route understandable first

The public analyzer supports two starting points:

Paste a private PolyTrack2 code.
Select a track already published in the PolyTrackCodes library.

Pasted codes stay in the browser by default. Published tracks get stable URLs that can be shared without copying the full code.

The first screen focuses on information a player can use immediately:

Track name, author, and environment.
Route support percentage.
Start, finish, and checkpoint counts.
Height range.
A conservative result: normal, needs attention, problem found, or unable to determine.

Notice the wording in the result above. The route structure is recognized, but the tool still asks the player to confirm jumps, height changes, special surfaces, and unknown parts in the real game.

That is intentional. “100% route support” only means that the current structural rules recognize the decoded part types. It is not a promise that we have reproduced the game engine.

A map you can actually inspect

The route overview supports:

Zooming and dragging.
Fitting the complete route into view.
Switching between all parts, roads, control points, and unknown parts.
Separating lower and upper height layers.
Inspecting a part in plain language, with raw coordinates kept in advanced information.

The analyzer also produces an estimated height profile and calls out unsupported content instead of hiding it behind a green status.

This progressive disclosure mattered more than we expected. Most players want the route and its difficult sections. A smaller group wants part IDs, rotations, bounds, and raw decoded data. Both can get what they need without making the first screen look like a debugging console.

Review Racer: a trainer, not a physics clone

The subtitle now states the boundary directly:

2D route trainer based on decoded track structure

Review Racer can:

Demonstrate a simplified route with Auto Coach.
Let the player drive manually with a keyboard.
Restart or respawn.
Start practice from a specific sector.
Show route progress, braking guidance, target speed, and turn-in suggestions.
Keep a personal best in the player’s own browser.

Every automatic result uses deliberately limited language:

Simplified route connected
Route gap found
Current tool cannot determine
Confirm in the real game

You will not see “this track is playable” generated from an Auto Coach finish.

Mobile controls are part of the product

The original prototype treated mobile as a smaller display. That was not enough for a player tool.

Review Racer now provides large touch targets for steering, driving, and braking. The route remains visible above the controls, and coach feedback continues below them.

This sounds like a small UI addition, but it changed our acceptance criteria. We now test the tool as something a player should be able to use, not merely something that happens to render on a phone.

The most important performance feature is knowing when to stop

Large community tracks are valuable test cases because they expose optimistic algorithms quickly.

Instead of always attempting to build a complete trainer model, Track Lab now separates structural inspection from route training.

If a track is too large or too poorly supported:

The analyzer still shows the useful structural result.
Review Racer does not start an expensive route build.
The page explains that the limitation belongs to the tool, not necessarily to the track.
The player can still inspect the map and confirm the uncertain areas in PolyTrack.

This prevents two bad outcomes at once: a frozen page and a false “broken track” report.

The reviewer workflow keeps its history

Inside the submission dashboard, reviewers can run the same analysis without copying the code into another page.

Each saved check records:

The analysis version.
A fingerprint of the submitted code.
Route support coverage.
Unsupported content.
Whether route training is reliable enough to open.
Items that require a real-game check.
The reviewer’s playtest result and notes.

When the creator submits a changed code, the old result is marked as outdated. This is important because “we checked this submission” is only meaningful if we can also answer “which version did we check?”

The dashboard remains ad-free, and the final approval remains a human action.

How we tested it

We built a fixed set of 31 real PolyTrack2 tracks covering small layouts, large layouts, missing controls, low support, and complex community tracks.

Together, those tracks contained 84,087 decoded parts.

In the current test set:

20 tracks produced a route that was suitable for the simplified trainer.
11 tracks were safely limited because they were too large or had insufficient supported route data.
Missing-start and missing-finish cases were prevented from entering route practice.
Desktop Auto Coach, keyboard controls, mobile touch controls, large-track protection, and ad-free tool pages were checked in a real browser.

The point of this test set is not to prove that the analyzer understands every PolyTrack component. It is to make sure unsupported cases stay visible and predictable as we add support over time.

What we learned

1. Product language is part of correctness

Changing “playable” to “simplified route connected” was not a copy edit. It corrected the meaning of the result.

2. Unknown must be a first-class state

A tool that only has pass and fail will eventually turn uncertainty into a false pass. We use four states: normal, attention, problem, and unable to determine.

3. Derived numbers need one source

Route points, sectors, hazards, turn counts, and time estimates now come from the same route result. This removes a whole category of contradictory UI.

4. Player tools and moderation tools can share logic without sharing a page

Players need route understanding. Reviewers need evidence and history. A shared result plus different presentations gives us consistency without a cluttered interface.

5. A graceful limit is better than an ambitious freeze

When the tool does not know enough, it stops and explains why. That is a feature, not a failure.

What comes next

Our next steps are deliberately incremental:

Recognize more PolyTrack2 road and special components.
Improve jump, gap, and multi-level route analysis.
Compare a player’s driven line with the suggested route.
Calibrate difficulty and practice advice with real player feedback.
Connect track analysis more deeply with published track pages.

Community challenges, voting, and leaderboards may come later, after the analysis itself has earned enough trust.

For now, Track Lab is already useful for the thing we originally wanted: helping a player look at an opaque code and understand the track waiting inside it.

Try the tools:

If you build developer tools for games, I would love to hear how you draw the line between a useful approximation and an overconfident verdict.

Save Our Devs Day: Why July 15 Matters for Everyone Who Ships Games

Jason Guo — Wed, 15 Jul 2026 13:31:10 +0000

July 15 wasn’t just another news day in games.

While Xbox union workers marched under Save Our Devs banners across multiple studio cities, Steam charts were celebrating something very different: Palworld 1.0 peaking at 855,525 concurrent players — the game’s second-highest peak ever.

That contrast is the story.

On one clock, capital is concentrating on franchises, cutting ~3,200 Xbox roles, and asking remaining teams to ship sequels faster. On the other, players are still showing up for full launches, World Cup–timed Fortnite crossovers, PC ports like Arknights, and small-team Early Access bets.

Same industry. Two clocks.

I put together a full daily brief covering:

Save Our Devs rallies and the mute-only layoff-call reporting
Glen Schofield’s retirement after 35 years
Palworld’s 1.0 Steam surge
Fortnite × Beckham timing ahead of the World Cup final
Arknights PC locked for August 13
Godot 4.7.1 shipping as a production stability drop
Indie notes: Taival, Verde, Tokyo Valkyries, Graphite
If you make games — or care about the people who do — this is worth a 10-minute read:

👉 Game Daily — July 15, 2026

Curious what you think:
Is peak concurrent a health metric anymore, or just a distraction from whether mid-budget teams can still finish what they start?

From "Age of Inference" to "Age of Orchestration" — AI Daily Jul 8, 2026

Jason Guo — Wed, 08 Jul 2026 04:42:38 +0000

If you've been building agentic systems lately, you've probably hit the same wall:
the model isn't your bottleneck anymore. The glue is.

Tool calls. State management. Retrieval. Result handling. The CPU work happening
between model steps — that's where latency hides now.

NVIDIA's new Vera CPU was literally designed around this problem. That's a signal
worth paying attention to.

Here's what I found worth reading in today's AI news sweep:

🏗️ Infrastructure

NVIDIA Vera CPU targets agentic throughput specifically — not inference FLOPs,
but the orchestration overhead in multi-step AI workflows. If you're architecting
agentic pipelines, this reframes where to optimize.

🔬 Research

Multiplayer Interactive World Models — a 5B-parameter latent diffusion model
generates 4-player Rocket League matches at 20 FPS on a single B200. It conditions
on multiple agents' action streams simultaneously while maintaining physical coherence
for 5+ minutes. They're releasing dataset, training code, and a live demo.

This is the "spatial intelligence" problem finally cracking open.

🛠️ Open Source

Rowboat — a local-first desktop AI coworker (open-source, Claude Desktop
alternative). Everything stored as plain Markdown on your machine, no cloud sync.
Includes an email client, browser, meeting note-taker, and background agents.
Runs on Mac/Windows/Linux with MCP extensibility.

The privacy angle lands differently when you read it alongside the EU Council's
latest move to resurrect Chat Control (yes, the mass messaging surveillance law
that already expired in April — they're trying again via expedited procedure).

🧠 Foundation Models

Amazon Nova's Reverse DPO — selective unlearning without degrading model
quality. rDPO lets you make models forget specific data points while reducing
over-deflection. AWS published a technical walkthrough if you're working on
fine-tuning pipelines with moderation requirements.

SenseNova-Vision — treats all computer vision tasks as unified multimodal
generation. No task-specific heads, just natural-language instructions + optional
visual prompts. Interesting architecture direction.

MiniMax models now on Amazon Bedrock — long-context document analysis and
agentic workloads, with the usual AWS security/scaling guarantees.

The thread connecting all of this

The GPU-centric era optimized for what happens inside the forward pass.

The orchestration era optimizes for what happens between forward passes —
context routing, tool dispatch, memory retrieval, multi-agent coordination.

The infrastructure (Vera CPU), the apps (Rowboat), and the research
(World Models) are all pointing at the same transition.

Full report with sources and images: https://windflash.us/daily-report/en/2026-07-08

I publish these daily at WindFlash — 10 curated articles, zero filler.

I Built a Tools Website for Geometry Dash Players — Here's What I Learned

Jason Guo — Sun, 05 Jul 2026 16:49:17 +0000

If you've ever played Geometry Dash, you know the struggle. You want to beat your first demon, but which one? You want to unlock the Vault of Secrets, but you're missing 12 diamonds and can't remember where to farm them. Your screen goes black mid-level and you don't know why. All this information exists — scattered across wikis, Reddit threads, and YouTube comments in six different languages.

I got tired of tab-switching between five resources just to pick my next level. So I built GD Level Tools — a single site that brings the most-needed tools and guides together under one roof.

Level Finder & Demon Tools" width="799" height="596">

What I Built

The site has six interactive tools and seventeen in-depth guides, all designed around real questions Geometry Dash players actually ask:

1. Level Finder

A filterable catalog of 30 curated demon levels. You can filter by:

Difficulty (Auto → Extreme Demon)
Length (Tiny → XL → Platformer)
Skill tags (Wave, Ship, Cube, Timing, Memory, UFO, Ball, Robot, Spider, Mobile-friendly)
Sort by beginner score, mobile score, or name

Each level has its own detail page with a gameplay video, review, skill tags, tips, "who should play / who should skip" sections, and recommended next levels.

2. First Demon Picker

This is the one I'm most proud of. It's a 7-question interactive questionnaire that recommends your ideal first demon based on:

Your platform (PC / Mobile / Both)
Your strongest and weakest skills
Preferred level length
Memory tolerance
Visual decoration preference
Your main goal (just clear it? build skills? have fun?)

The recommendation engine scores each candidate demon against your answers and ranks them by match percentage. Each result comes with a "why it fits" explanation, a "what to watch for" warning, and a practice tip.

No more asking "what should my first demon be?" on Reddit and getting 40 different answers.

3. Demon Progression Planner

Enter how many demons you've beaten, and it tells you exactly where you are on an 8-stage ladder from "First Demon" to "Extreme Demon" — with recommended next levels for your current stage and a full roadmap showing the entire journey.

The stages:

Stage	Demon Count	Example Levels
1. First Demon	0	The Nightmare, The Lightning Road
2. Beginner Easy	1–5	Platinum Adventure, Demon Park
3. Standard Easy	6–15	Shiver, Speed Racer
4. Early Medium	16–30	B, Problematic
5. Medium	31–50	Nine Circles
6. Hard	51–80	Jawbreaker
7. Insane	81–120	Supersonic, Windy Landscape
8. Extreme	120+	Pointercrate Top 150

4. Vault Codes

63 secret codes across all four in-game vaults (The Vault, Vault of Secrets, Chamber of Time, and the new 2.2 Wraith Vault) — searchable, with unlock requirements and what each code gives you.

I was careful to label these as "in-game secret codes, not cheats." They're official codes put in the game by the developer, not exploits.

5. Guides

Seventeen guides across six categories:

Rewards (6): Diamonds, Gold Keys, Demon Keys, User Coins, Master Emblem, Moons
Mods (4): Geode installation, Geode troubleshooting, FPS unlock, TPS explained
Fixes (4): Screen going dark, screen tearing, can't play levels, V-Sync
General (4): All icons, star grinding, 2.2 update, level creation
Skills (1): Practice mode
Demons (2): Best easy demons for beginners, Extreme Demon List 2026

Each guide has step-by-step instructions, FAQ sections, and related guide links.

Why I Built It

Three reasons, in order of importance:

1. The information was scattered

Want to know what your first demon should be? Check the wiki. Want to know if it's mobile-friendly? Check a Reddit thread. Want a gameplay video? Search YouTube. Want to know what to play next? Ask on Discord and hope someone responds.

I wanted one page that answers all of these questions for each level.

2. Existing resources don't account for personal preference

Most "best first demon" lists are just ranked by difficulty. But a level that's easy on PC might be brutal on mobile. A level that's great for wave players might be miserable for ship players. The First Demon Picker accounts for your skills, platform, and preferences — not just a generic difficulty ranking.

3. I wanted to build something with real users

Not a todo app. Not a weather dashboard. A site that solves a problem I personally have, for a community I'm part of. That meant I actually cared about the content quality, the UX, and whether the recommendations were good — because I'd be using it myself.

Tech Stack

Layer	Choice	Why
Framework	Next.js 16 (App Router)	SSR/SSG, file-based routing, metadata API
Language	TypeScript	Type safety for the level data model
Styling	Tailwind CSS + CSS variables	Game-themed dark neon design system
Deployment	Cloudflare Workers	Edge network, generous free tier
Analytics	Google Analytics 4	With Consent Mode v2 for GDPR
SEO	JSON-LD structured data	WebSite, Organization, Article, FAQ, Breadcrumb schemas

The site is 71 static pages — every level, guide, and fix page is pre-rendered at build time. No database, no CMS. All content lives in TypeScript data files, which means:

Zero runtime cost (static files on a CDN)
Type-safe content (can't publish a guide with a missing field)
Git is the CMS (every content change is a commit with history)

A Few Things I Learned

Recommendation engines are harder than they look

The First Demon Picker looks simple — answer 7 questions, get recommendations. But designing the scoring logic took multiple iterations. Early versions recommended the same 3 levels to everyone because the "beginner-friendly" signal overwhelmed everything else.

The fix was weighting by question importance. Your strongest skill matters more than your visual decoration preference. Your platform matters more than your preferred length. Getting these weights right required testing with real players and adjusting.

SEO for a fan site is different from SEO for a SaaS

Most SEO advice online is about building topical authority through blog content. But for a tools site, the SEO play is different:

Tool pages target high-intent keywords ("first demon picker", "geometry dash vault codes")
Guide pages target informational keywords ("how to get diamonds in geometry dash")
Level pages target specific level names ("the nightmare geometry dash")

Each page type needs different structured data. Level pages get Article + FAQPage schemas. The homepage gets WebSite + Organization. Guide listings get ItemList. I built helper functions in src/lib/seo.ts to keep this consistent.

GDPR consent doesn't have to be heavy

I added a cookie consent banner with GA4 Consent Mode v2. The key insight: default to denied, then update on consent. This means:

Page loads → consent is denied (set before gtag.js loads)
User clicks "Accept" → gtag('consent', 'update', { analytics_storage: 'granted' })
User clicks "Decline" → stays denied, but GA4 still sends cookieless pings

Even declined users show up in aggregate analytics. You don't lose all your data by being compliant.

Cloudflare Workers + Next.js is a great combo

The site deploys as a Cloudflare Worker via @opennextjs/cloudflare. Build output is a single Worker that serves 71 static pages from the edge. Cold starts are non-existent. The free tier covers my traffic with room to spare.

The one gotcha: Workers have a 1MB compressed bundle limit on the free plan. I had to be mindful of bundle size, which meant no heavy client-side libraries. All interactivity is vanilla React state — no charting libs, no animation libs, no UI component kits.

What's Next

More levels: The catalog has 30 levels now. The goal is 100+ covering every difficulty tier.
Community submissions: There's a level submission form, but submissions are reviewed manually. I'm considering a moderation workflow.
Versus mode guide: Geometry Dash 2.21 is coming with a competitive mode. That's a whole new content area.
AdSense: The site is structured for AdSense approval (original content, privacy policy, terms, DMCA). Once traffic justifies it, ads will help cover the domain + Workers costs.

Try It

The site is live at geometrydashlevel.com. It's a fan-made project, not affiliated with RobTop Games — I put a disclaimer in the footer and on every relevant page to make that clear.

If you play Geometry Dash, I'd love to hear what you think. What's missing? What tool would you add? What level should I review next?

This is an independent fan site. Geometry Dash is a trademark of RobTop Games. All content is created by fans, for fans.

I Built a WWII-Inspired Tower Defense Game in HTML5. The Hard Part Wasn't the Towers.

Jason Guo — Fri, 03 Jul 2026 16:03:23 +0000

I recently shipped the beta version of Allied Frontline Defense, a WWII-inspired tower defense game built for the browser.

You can play it here:

👉 Play the beta: https://instantgames.top/games/allied-frontline-defense/

And I wrote a full dev-log series here:

👉 Read the full development story: https://instantgames.top/blog/posts/building-allied-frontline-defense-wwii-tower-defense-html5.html

This post is the short version: what looked like a simple tower defense project turned into a surprisingly useful lesson in game readability, map truth, AI-assisted art, and browser-game polish.

Show Image

The pitch was simple
The original idea was direct: build a WWII-style tower defense game and add it to the site.

The first version had the expected pieces:

a battlefield map
dirt roads
infantry, trucks, tanks, and aircraft
machine gun nests
anti-tank guns
artillery
anti-air defenses
waves, upgrades, selling, and victory/loss states
On paper, that sounds like the game.

In practice, it was only the beginning.

A tower defense game is not judged only by whether enemies move and towers deal damage. The player has to believe the battlefield. They need to know where enemies enter, where they travel, where towers can be built, why a tower fires, why a plane is dangerous, and why a wave was lost.

That meant the real work was not just "add more content."

The real work was making the screen honest.

Problem 1: the road must tell the truth
The biggest early issue was enemy path alignment.

The map had a visible dirt road. The enemies had an actual movement path. Those two things were close, but not identical.

That small difference was enough to make the whole game feel wrong.

Sometimes vehicles looked like they were cutting across grass. Sometimes the entrance did not match the bunker doorway. Sometimes tanks crossed near the bridge, but not quite on the bridge deck.

In a tower defense game, the road is not decoration. It is a promise.

If the road says "enemies will travel here," then enemies need to travel there.

I wrote a deeper article about this specific problem here:

👉 Fixing Tower Defense Road Alignment in an HTML5 Canvas Game
https://instantgames.top/blog/posts/tower-defense-road-alignment-html5-canvas.html

Show Image

The eventual lesson was simple: the route should be a source of truth, not a guess layered over a finished background image.

For newer maps, I moved toward drawing the road from the same route data that enemies follow. That way, the visible road and actual enemy movement cannot drift apart.

Problem 2: towers need to aim visibly
The next issue was weapon direction.

The MG Nest and other towers could technically attack enemies, but early visuals made the barrel look like it was not following the target.

That immediately breaks player trust.

In tower defense, a tower is a tiny machine for communicating intent:

the turret turns
the muzzle flashes
the projectile leaves from the barrel
the enemy reacts
If those signals disagree, the player notices.

So the towers had to be redesigned. The battlefield versions became lower-profile, more grounded, and more directional. The weapon barrel, projectile origin, and muzzle flash all needed to point at the same target.

I also had to separate "art that looks good as an icon" from "art that works in live combat." Some AI-generated tower images looked fine in a square panel but felt too upright or too side-on when placed on the map.

The full tower-design breakdown is here:

👉 Designing WWII-Inspired Towers for a Browser Tower Defense Game
https://instantgames.top/blog/posts/wwii-tower-defense-weapon-design-html5-game.html

Show Image

Problem 3: aircraft should not behave like ground enemies
Aircraft were another surprisingly tricky part.

The first air units felt too rigid. They were basically following predictable paths above the battlefield. Later, I made routes freer, but then some planes felt shaky or visually awkward.

The final direction was a hybrid:

keep the generated aircraft visual because it looked better
give each aircraft a freer route across the map
smooth the banking motion
separate the plane body from its ground shadow
make sure aircraft do not appear to fly backward or upside down
Aircraft needed their own movement language. They should not feel like tanks with a vertical offset.

This became part of a larger enemy-design pass. The game grew from simple infantry, trucks, tanks, and planes into a broader roster with scout cars, heavy tanks, bombers, storm infantry, half-tracks, assault guns, and fighter aces.

Some enemies now also fire back at towers.

That changed the game a lot. Towers are no longer permanent objects that only attack. They can be damaged, disabled, and repaired.

The enemy-design article is here:

👉 Creating Smarter Enemy Waves, Aircraft Routes, and Counter-Fire
https://instantgames.top/blog/posts/tower-defense-enemy-design-aircraft-counter-fire.html

Show Image

Problem 4: the map needed layers
The best long-term map solution was to stop treating the battlefield as one finished picture.

Instead, I moved toward a layered map model:

Base art: the terrain, mood, lighting, cliffs, trees, snow, coast, ruins
Road layer: drawn from the actual enemy route
Tower pad layer: buildable positions authored separately from the road
Airspace layer: visual support for freer aircraft movement
Gameplay layer: towers, enemies, projectiles, explosions, smoke, and UI feedback
This made the maps easier to expand and easier to trust.

It also solved the route mismatch problem in a cleaner way. If the road is drawn from the route, enemies and roads stay synchronized.

The full map article is here:

👉 Layered Map Design for a Better HTML5 Tower Defense Game
https://instantgames.top/blog/posts/layered-map-design-html5-tower-defense.html

Show Image

What the beta includes now
The current beta has:

four maps
three missions
twelve waves per mission
six buildable tower types
ground and air enemies
enemy counter-fire
tower damage and repair
smoke/fire effects for damaged enemies
improved battlefield audio
route-aligned roads
a compact command panel
dev-log documentation for the full process
It is still a beta, but it now feels like a real game system rather than a prototype sketch.

The biggest lesson
The biggest lesson from building this game was not about HTML5 Canvas, AI art, or tower defense formulas.

It was about readability.

Players can forgive a beta if it is honest.

They are much less forgiving when:

the road lies
a tower fires in the wrong direction
a plane looks like it is glued to the ground
a build pad appears on the enemy path
an explosion shows a square image boundary
the control panel hides the button they need
Those problems are not just bugs. They are broken communication between the game and the player.

Once I started treating every screenshot as design evidence, the game improved much faster.

Read the full dev-log series
I published the longer development write-up on the InstantGames dev-log:

👉 Start with the main article:
https://instantgames.top/blog/posts/building-allied-frontline-defense-wwii-tower-defense-html5.html

Then continue with the focused case studies:

Road alignment: https://instantgames.top/blog/posts/tower-defense-road-alignment-html5-canvas.html
Weapon design: https://instantgames.top/blog/posts/wwii-tower-defense-weapon-design-html5-game.html
Enemy waves and aircraft: https://instantgames.top/blog/posts/tower-defense-enemy-design-aircraft-counter-fire.html
Layered maps: https://instantgames.top/blog/posts/layered-map-design-html5-tower-defense.html
And if you want to try the beta:

🎮 Play Allied Frontline Defense:
https://instantgames.top/games/allied-frontline-defense/

Make UI and AI Agents Equal Citizens of Your Application

Jason Guo — Fri, 15 May 2026 08:31:47 +0000

Raycast dropped a technical deep dive last week about rebuilding their desktop app from scratch. The headline was about going cross-platform. The buried lede was something much more interesting.
Their new architecture has four layers: a native host shell, a React frontend, a Node.js backend for all business logic, and a Rust core for data and indexing. These layers communicate through typed IPC with compile-time guarantees across all four runtimes.
Here is the part that stopped me mid-scroll: business logic no longer lives inside the UI layer. It lives in a separate process. The UI calls it. Extensions call it. And nothing stops an external process, including an AI agent, from calling it too.
The user clicking "search files" and an agent issuing a search command travel through the same path. The backend does not know which one initiated the request. It does not need to know.
This is a deceptively simple idea with real weight behind it. UI and AI agents become equal citizens of the application.
Most teams adding AI to their product do the opposite. They bolt a chat dialog onto the existing UI, hard-code a few intent mappings, and call it done. It works for demos. It breaks the moment a user asks for something that spans multiple capabilities. The bottleneck is not the model. It is that the application never gave the model a clean interface.
Raycast's bet is that AI agents are not a feature requirement. They are an architecture requirement. The difference determines whether you add a chat box and move on, or you rebuild your foundation so every capability is a typed, discoverable, composable command.
The bet costs something. v2 uses 150 MB more memory than v1. The team is upfront about it. That 150 MB is a down payment on not having to rebuild again in three years when agents are everywhere and your app cannot be called by any of them.
I wrote up a longer analysis of the architecture, the trade-offs, and what it means for product teams building in the age of agents. Read the full piece here.

I Built a WWII-Inspired Tower Defense Game in HTML5. The Hard Part Wasn't the Towers

Jason Guo — Mon, 04 May 2026 15:37:16 +0000

I recently shipped the beta version of Allied Frontline Defense, a WWII-inspired tower defense game built for the browser.

You can play it here:

👉 Play the beta:
https://instantgames.top/games/allied-frontline-defense/

And I wrote a full dev-log series here:

👉 Read the full development story:
https://instantgames.top/blog/posts/building-allied-frontline-defense-wwii-tower-defense-html5.html

This post is the short version: what looked like a simple tower defense project turned into a surprisingly useful lesson in game readability, map truth, AI-assisted art, and browser-game polish.

Allied Frontline Defense beta gameplay

The pitch was simple
The original idea was direct: build a WWII-style tower defense game and add it to the site.

The first version had the expected pieces:

In practice, it was only the beginning.

That meant the real work was not just "add more content."

The real work was making the screen honest.

Problem 1: the road must tell the truth
The biggest early issue was enemy path alignment.

The map had a visible dirt road. The enemies had an actual movement path. Those two things were close, but not identical.

That small difference was enough to make the whole game feel wrong.

Sometimes vehicles looked like they were cutting across grass. Sometimes the entrance did not match the bunker doorway. Sometimes tanks crossed near the bridge, but not quite on the bridge deck.

In a tower defense game, the road is not decoration. It is a promise.

If the road says "enemies will travel here," then enemies need to travel there.

I wrote a deeper article about this specific problem here:

👉 Fixing Tower Defense Road Alignment in an HTML5 Canvas Game
https://instantgames.top/blog/posts/tower-defense-road-alignment-html5-canvas.html

Tanks crossing the aligned bridge route

The eventual lesson was simple: the route should be a source of truth, not a guess layered over a finished background image.

For newer maps, I moved toward drawing the road from the same route data that enemies follow. That way, the visible road and actual enemy movement cannot drift apart.

Problem 2: towers need to aim visibly
The next issue was weapon direction.

The MG Nest and other towers could technically attack enemies, but early visuals made the barrel look like it was not following the target.

That immediately breaks player trust.

In tower defense, a tower is a tiny machine for communicating intent:

the turret turns
the muzzle flashes
the projectile leaves from the barrel
the enemy reacts
If those signals disagree, the player notices.

The full tower-design breakdown is here:

👉 Designing WWII-Inspired Towers for a Browser Tower Defense Game
https://instantgames.top/blog/posts/wwii-tower-defense-weapon-design-html5-game.html

Problem 3: aircraft should not behave like ground enemies
Aircraft were another surprisingly tricky part.

The first air units felt too rigid. They were basically following predictable paths above the battlefield. Later, I made routes freer, but then some planes felt shaky or visually awkward.

The final direction was a hybrid:

Some enemies now also fire back at towers.

That changed the game a lot. Towers are no longer permanent objects that only attack. They can be damaged, disabled, and repaired.

The enemy-design article is here:

👉 Creating Smarter Enemy Waves, Aircraft Routes, and Counter-Fire
https://instantgames.top/blog/posts/tower-defense-enemy-design-aircraft-counter-fire.html

Problem 4: the map needed layers
The best long-term map solution was to stop treating the battlefield as one finished picture.

Instead, I moved toward a layered map model:

It also solved the route mismatch problem in a cleaner way. If the road is drawn from the route, enemies and roads stay synchronized.

The full map article is here:

👉 Layered Map Design for a Better HTML5 Tower Defense Game
https://instantgames.top/blog/posts/layered-map-design-html5-tower-defense.html

What the beta includes now
The current beta has:

The biggest lesson
The biggest lesson from building this game was not about HTML5 Canvas, AI art, or tower defense formulas.

It was about readability.

Players can forgive a beta if it is honest.

They are much less forgiving when:

Once I started treating every screenshot as design evidence, the game improved much faster.

Read the full dev-log series
I published the longer development write-up on the InstantGames dev-log:

👉 Start with the main article:
https://instantgames.top/blog/posts/building-allied-frontline-defense-wwii-tower-defense-html5.html

Then continue with the focused case studies:

Road alignment:
https://instantgames.top/blog/posts/tower-defense-road-alignment-html5-canvas.html
Weapon design:
https://instantgames.top/blog/posts/wwii-tower-defense-weapon-design-html5-game.html
Enemy waves and aircraft:
https://instantgames.top/blog/posts/tower-defense-enemy-design-aircraft-counter-fire.html
Layered maps:
https://instantgames.top/blog/posts/layered-map-design-html5-tower-defense.html
And if you want to try the beta:

🎮 Play Allied Frontline Defense:
https://instantgames.top/games/allied-frontline-defense/

Building a Cinematic 3D F-16 Takeoff Simulation Entirely in the Browser When we think of 3D flight simulations, we usually picture heavy game engines like Unreal or Unity. https://best-games.io/blog/building-a-cinematic-3d-f-16-takeoff-simulation-entirely

Jason Guo — Sat, 04 Apr 2026 08:57:44 +0000

Best-Games.io - Play 200+ Free Online Games Instantly | No Download

Play 200+ free online games instantly! Snake, Mahjong, 8 Ball Pool, racing, puzzle & action games. No download - play in browser.

best-games.io

I Built a Game Site with an iframe — Someone Hit a 210-Second World Record on It

Jason Guo — Tue, 31 Mar 2026 16:25:40 +0000

I'm not a game developer. I'm a Web developer addicted to side projects, and one afternoon I had a thought: instead of spending months building a game from scratch, what if I did something faster to validate the idea first — curate great games and build a genuinely useful game portal around them?

That's how taproad-game.com was born. The technical core is an iframe, but there's a lot built around it. This post is about the rabbit holes I fell into, the lessons I picked up, and why an "iframe site" can actually retain real users.

Why Tap Road?

Before deciding which game to build around, I did a round of keyword research. Tap Road is an HTML5 endless runner developed by AzGames.io — a glowing ball rolls down a neon-lit highway, and players tap or click to switch lanes, dodge obstacles, and collect gems.

The numbers caught my eye immediately: 7 million+ plays, a 4.2/5 rating, and nearly 11,000 reviews. This wasn't some obscure indie experiment — it was a market-validated product with a real player base.

More importantly, the gameplay is dead simple — one tap, zero learning curve. That means anyone who lands on the site can pick it up within 5 seconds, with no onboarding copy needed from me. For a traffic-funnel game site, that's the ideal anchor game.

Why the Game Actually Retains Players

Before building the site, I spent a serious amount of time studying what makes Tap Road work, because I needed to genuinely understand why it's fun before I could write content that would keep visitors around.

The answer lies in its gem economy. There are three gem tiers: common blue gems, purple gems worth 3x, and golden gems worth 10x. The golden gems are always placed in the most dangerous spots — you can go for them, but you'll probably die trying. This design turns every run into a series of micro-decisions: take the risk or play it safe? That tension creates the "just one more game" compulsion, rather than a pure reflex challenge.

Gems are spent in the shop on 30+ ball skins, trail effects, and track themes. The game also has a hidden skin system — the Ghost Ball requires dying 100 times total, the Rainbow Ball requires playing 50 games in a single day, and the Supernova Ball requires collecting 10,000 lifetime gems. These mechanics convert short-term "one more run" impulses into long-term return visit motivation.

The speed system is worth noting too. The game ramps up at three thresholds: 30 seconds, 60 seconds, and 90 seconds. The 10-second window after each speed bump is the most dangerous — top players' strategy is to completely stop chasing gems during that window, focus purely on survival, and only reintroduce gem collection once their hands and eyes have adjusted to the new tempo.

The community-verified world record currently stands at 210 seconds, held by a player known as "NeonRunner" with a full gameplay recording as proof. That number sounds modest until you experience the blistering speed the game reaches past 90 seconds — every tap has to be frame-perfect.

You can try it yourself at taproad-game.com — no download, no signup, runs instantly in any browser.

The Real Challenge of an iframe Site Isn't Technical

Embedding the game took me under an hour. What actually took time was building a valuable content layer around the iframe.

A page that's just an iframe offers no additional value to users and is essentially invisible to search engines. The core question I needed to answer was: why would a player come to my site instead of going directly to the original?

My answer was: become the best information hub for the game.

That meant genuinely researching the game and writing substantive guides — not "click to switch lanes" filler, but verified tips like "stop chasing gems for the first 10 seconds after the 90-second speed increase." It meant cataloguing the hidden skin unlock conditions, gathering world record discussions from the community, and explaining the underlying logic of the gem economy.

Once the content was in place, the site's bounce rate dropped noticeably. Users were spending more time on the page because they were reading guides and checking unlock conditions before and after playing — the content and the game were feeding each other.

The "Unblocked" Audience: An Underrated Niche

The most surprising traffic source after launch was users searching "tap road unblocked." School and workplace networks block a huge number of gaming sites, and students and office workers are exactly the core demographic for quick browser games during downtime.

I specifically optimized the site's technical setup for this — clean HTTPS, a domain with no history of being flagged by content filters — and wrote a dedicated access guide page. This segment now accounts for a meaningful share of traffic, and the user quality is high because they arrive with clear intent.

What I Actually Learned

Going in, I assumed an iframe site was a "low-effort" project I could set up and walk away from. The reality is that a low technical barrier means the competitive moat is entirely in content and execution. Anyone can replicate my technical setup in an hour. Nobody can replicate the guide content and community data I've compiled in an hour.

The other lesson was about product selection logic. Building a site around a game with 7 million verified plays is a fundamentally different risk profile than building around a game that just launched. The former is distribution on top of validated demand. The latter is a bet that demand exists at all. For an indie developer, the former has a dramatically higher success rate.

Finally, the "zero friction" nature of browser games is a real distribution advantage. Under 2 seconds from link-click to gameplay — no platform that requires a download or account creation can match that. If you're considering any game-adjacent project, HTML5 browser games are a seriously underrated space.

If you have thoughts on SEO strategy, content architecture, or monetization for game aggregator sites, I'd love to hear them in the comments. I'm also curious: what's the most "technically simple but operationally complex" side project you've ever shipped?