DEV Community: 袁潇

What I Learned Building a Level-Based Walkthrough Site for a Puzzle Game

袁潇 — Mon, 13 Jul 2026 14:30:35 +0000

Building a walkthrough site sounds simple until you try to do it well.

At first, the content model looks obvious: one game, many levels, one page per level. Add a title, a route, a few screenshots, some metadata, and the site is done.

The problem is that players do not search for a walkthrough because they want a page to exist. They search because they are stuck. If the page does not understand the exact moment where the player is stuck, it may rank, but it will not be useful.

I ran into this while working on content around Car Sort: Color Puzzle, a mobile puzzle game where players sort colored cars into matching garages. The game looks simple, but later levels depend heavily on move timing, temporary space, and avoiding early decisions that make the board impossible to recover.

That makes it a good case study for developers building SEO-driven content sites, especially sites with many similar pages.

Start With the User State, Not the Route

The natural way to model a walkthrough page is:

level number
title
image
steps
conclusion

That is a valid data shape, but it is not enough. A stuck player usually arrives with a more specific problem:

They used all temporary spaces.
A color is trapped under blockers.
Their board no longer matches the solution.
They filled a garage too early.
They do not know which color should move first.

So the real content model needs to represent decision context, not only the final route.

For a Car Sort level, a useful page needs fields like:

openingLayout: what the board looks like before the first move
mainBottleneck: the color, lane, or garage that controls the route
routePriority: what must be solved first and what should wait
stepNotes: the move sequence with reasons
recoveryAdvice: how to diagnose the most likely failed state

This changes the page from a static answer into a guide. The user can compare their own board against the page and understand why their attempt diverged.

Repetition Is the Main Risk in Level-Based SEO

When a site has dozens or hundreds of pages with the same page type, repetition becomes the default failure mode.

The route may be different, but the prose can drift into the same wording:

"Plan your moves carefully."

"Keep space open."

"Do not move too quickly."

Those sentences are not wrong. They are just not enough. If they appear on every level page, they stop being useful. They also signal that the page is built from a shared template rather than from the actual level.

For level-based content, I use a simple rule: the page has to describe something that is only true for that level.

In Car Sort, that might be:

a top shelf that should stay open until the middle clears
a bottom column that becomes dangerous if opened too early
a red batch that looks ready but should wait
a narrow loop that must be cleaned before final garage work
a center blocker that controls access to two colors

This kind of detail protects the site from thin content. It also makes the walkthrough better for the player.

The Page Should Explain Why, Not Just What

A move list is useful, but only up to a point.

If the page says:

Move blue.
Move yellow.
Move red.

The player can follow it only if their board matches exactly. If they are already three moves into a failed attempt, the route may not help them understand the mistake.

A better step note explains why the move is safe:

Move the blue car first because it clears the center blocker without using the only open garage.
Hold yellow until the lower lane is free; moving it now splits the batch.
Finish red only after blue is grouped, because red will otherwise consume the temporary space needed for cleanup.

That is still concise, but it gives the user a mental model. It also improves the page's content quality because each step carries level-specific reasoning.

For a walkthrough site like Car Sort Walkthroughs, this difference matters. The user is not only looking for a solution. They are looking for the reason the solution works.

Programmatic Structure Still Needs Human-Level QA

There is nothing wrong with programmatic structure. In fact, it is usually necessary for a level-based site.

The issue is letting the programmatic layer do the editorial thinking.

A good build pipeline can enforce technical rules:

every level has a page
every page has a canonical URL
every page appears in the sitemap
every page has Open Graph metadata
every route links to the right source asset
every image has useful alt text

Those checks are important, but they do not prove the guide is good.

For walkthrough content, I would add editorial QA rules:

Does the page mention the actual board structure?
Does it name the bottleneck?
Does the route explain why the opening works?
Does it warn against the most tempting wrong move?
Does the recovery advice match a real failure state?
Are long paragraphs repeated across other pages?

Some of these checks can be partially automated. For example, you can scan for repeated long lines across Markdown files. You can detect missing sections. You can flag pages below a minimum length.

But the important part still requires judgment. A guide can pass a schema check and still be useless to a stuck player.

Internal Links Should Follow Player Intent

Internal linking on a walkthrough site should not only distribute SEO value. It should match how players move through the game.

For a level-based puzzle, useful internal links include:

previous level
next level
nearby difficult levels
level hub
beginner strategy guide
common stuck-pattern guide

The page should not force the player into a random article cluster. If someone is on Level 80, they probably care about Level 79, Level 81, or a broader strategy page that explains the mechanic causing trouble.

This is one area where content architecture and UX overlap. A good internal link gives the player a natural next action. It also helps search engines understand the relationship between pages without making the page feel artificial.

Metadata Is Easy; Intent Is Hard

For a Next.js content site, metadata can be handled cleanly:

title
description
canonical
Open Graph
Twitter card
JSON-LD
sitemap

These are necessary, but they are not the hard part. The hard part is matching the user's actual intent.

For a query like "Car Sort Level 100 solution," the intent is direct and urgent. The page should not open with five paragraphs about mobile puzzle history. It should quickly confirm:

this is the correct level
this is a solution walkthrough
the route is visible
the explanation is specific

Then it can add deeper notes for players who want to understand the route.

A good structure is:

Confirm the level and solution.
Give the route reference.
Explain the opening layout.
Walk through the route.
Add recovery advice.
Link to adjacent levels.

That order respects the user's state. It also prevents SEO work from becoming visible in a bad way.

A Practical Checklist for Walkthrough Pages

Here is the checklist I would use before publishing a new batch of level pages:

Each page has a unique title with the level number.
Each page describes the actual board, not a generic puzzle situation.
The opening move is explained more carefully than the easy cleanup.
The route includes reasoning, not only color order.
The page names one likely mistake.
The page links to previous and next levels.
The canonical and sitemap entries are correct.
Images or route references match the level.
No long paragraph is reused across multiple level pages.
The page reads like it was written after playing the level.

The last point is the most important one. Players can tell when a guide is written from the actual game state. They can also tell when it is just a template with the level number changed.

The Bigger Lesson

Level-based walkthrough sites are a useful reminder that SEO pages are still product surfaces.

The page is not only an acquisition asset. It is part of the user's experience with the game. If the player leaves the page with a better route, the page worked. If they leave with a copied answer but no understanding, it only half-worked.

For developers, the technical system matters: routing, metadata, content collections, image handling, build checks, and internal links. But the content model matters just as much. A walkthrough page needs room for judgment: board structure, bottlenecks, timing, and recovery.

That is what I would keep in mind when building any high-volume guide site.

Do not just create pages at scale. Create pages that understand the problem the user brought with them.

What No Humanity Teaches About Readable Chaos in Browser Games

袁潇 — Mon, 13 Jul 2026 14:29:32 +0000

There is a strange design challenge hiding inside bullet-hell games: the screen should feel impossible, but the player should still believe the next second is their fault.

That balance is difficult. If the game is too clean, it loses pressure. If the game is too chaotic, it becomes unreadable. The player stops learning and starts blaming the system.

No Humanity is a useful browser-game example because it leans into short-run survival. The page presents it as a free web game, and the local build is a Unity export centered on repeatable attempts: launch, dodge, fail, restart, improve. You can play it here: No Humanity.

This article looks at the design from a developer's perspective. How do you make a small web game feel brutally intense without making it feel random?

The Main Loop Is Survival, Not Completion

No Humanity does not need a long campaign to create engagement. Its loop is simple:

spawn -> read hazards -> dodge -> survive a little longer -> fail -> retry

That loop works because the goal is not to "finish" the game in the traditional sense. The goal is to push survival time further while building pattern memory.

For developers, that means the design problem is different from a level-based puzzle game. You are not only asking, "Can the player solve this?" You are asking:

Can the player read the next threat quickly enough?
Can they recover from a bad position?
Can they understand why a run ended?
Can they restart before frustration becomes exit intent?

Short-run games live or die on that last point. If the retry loop is slow, every failure becomes heavier than the gameplay deserves.

Readable Chaos Needs Layers

Bullet-hell survival works best when hazards arrive in layers, not as visual noise. A player can handle multiple threats if each one has a readable role.

In No Humanity, the page and guide evidence describe lasers, missiles, sudden patterns, and arena pressure. Those are different types of danger:

Lasers can create hard boundaries.
Missiles can create targeted pressure.
Spawned patterns can compress open space.
Arena edges can turn a dodge into a trap.

The important part is that these threats should not all communicate in the same way. A missile should feel different from a laser. A forming beam should teach the player to move before the line becomes fatal. A sweeping pattern should reward players who keep open space available.

Readable chaos is not the absence of clutter. It is the presence of hierarchy.

Small Movement Is Better Than Panic Movement

The site guide for No Humanity emphasizes small corrections over dramatic dodges. That is a strong lesson for any developer building a high-pressure arcade game.

Panic movement feels exciting for a moment, but it often destroys player agency. The player sweeps across the arena, collides with the next hazard, and learns very little. Small corrections are better because they preserve options.

From a design point of view, this means the game should reward micro-positioning:

function applyInput(player, input, dt) {
  const acceleration = input.direction.scale(player.acceleration);
  player.velocity = player.velocity.add(acceleration.scale(dt));
  player.velocity = clampMagnitude(player.velocity, player.maxSpeed);
  player.position = player.position.add(player.velocity.scale(dt));
}

The exact movement model does not matter as much as the feel. The player should be able to make tiny positional changes without overshooting. In a bullet-hell game, precision is not a luxury feature. It is the foundation of fairness.

Open Space Is a Resource

One of the best ways to understand games like No Humanity is to treat open space as a resource.

Health is obvious. Score is obvious. Time is obvious. Space is less obvious, but it is often the most important resource on the screen.

If a player hugs a wall or drifts into a corner, they spend future options. When a new pattern appears, they have fewer escape paths. If they stay near a flexible lane, they preserve choices.

That suggests a useful mental model for enemy or hazard design:

function evaluatePressure(player, arena, hazards) {
  return {
    edgeRisk: distanceToNearestWall(player.position, arena),
    openRoutes: countSafeDirections(player.position, hazards),
    immediateThreats: countCollisionsSoon(player.position, hazards),
  };
}

You do not need to expose these values to the player. But thinking this way helps designers avoid unfair combinations. A hard pattern is fine if at least one route remains readable. A dense pattern is fine if it gives the player time to prepare. A surprise pattern is fair only if the escape action is still possible.

Feedback Should Arrive Before Failure

The difference between "hard" and "cheap" is usually feedback timing.

If a laser appears only when it kills the player, the failure feels arbitrary. If it telegraphs briefly, the player can blame their reaction or positioning. That blame is useful because it leads to learning.

A short-run survival game should give feedback at three points:

Before danger becomes active: telegraph the pattern.
While the player is threatened: make the danger readable.
After failure: make the cause understandable.

This does not require long tutorials. In fact, tutorials can slow this genre down. The game can teach through repeated exposure if the visual and audio feedback is consistent.

Fast Restarts Are Part of the Design

Fast restart is not just a user-experience detail. It is part of the difficulty curve.

When runs are short, players are willing to experiment. They try a smaller dodge. They stay away from the edge. They watch the next missile instead of staring at the score. They learn because the cost of failure is low.

That is why browser delivery fits this kind of game well. A player can load the game, fail quickly, and keep going without setup friction. No download, no long session commitment, no heavy onboarding.

For web developers, this is also a reminder: performance and load time affect game design. A survival loop feels worse if the page, embed, or restart flow drags.

Why No Humanity Works as a Web Game

No Humanity fits the browser because its value is immediate. The player does not need to learn an economy, inventory, skill tree, or story system. The question is visible in the first run:

How long can you survive when the screen keeps taking space away?

That is a good web-game question. It is easy to understand, hard to master, and friendly to quick sessions.

The game also shows a useful principle for developers: intensity is not the same as randomness. A game can feel chaotic while still being learnable if its hazards have roles, its movement is precise, and its feedback arrives early enough.

Takeaways for Developers

If you are building a browser-based arcade or survival game, No Humanity points to a few practical lessons:

Make the retry loop fast enough that failure becomes practice.
Treat open space as a resource, not just background.
Give hazards different visual and timing roles.
Reward small corrections instead of panic movement.
Telegraph danger before it becomes lethal.
Keep the first session simple enough that the player reaches the core loop immediately.

None of these ideas require a massive project scope. They require discipline. You need to decide what the player is supposed to read, what they are supposed to control, and what each failure is supposed to teach.

Final Thoughts

No Humanity is a strong example of compact browser-game design because it understands the value of repeatable pressure. It does not need to be large to feel intense. It needs a clean survival loop, readable hazards, fast retries, and enough precision for the player to believe they can do better next time.

That is the heart of readable chaos: the screen can look overwhelming, but the system must still be teachable.

Try it here: No Humanity

DEV.to Publishing Notes

DEV front matter uses title, published, description, tags, canonical_url, and cover_image.
DEV tags should stay at four or fewer; this draft uses gamedev, webdev, unity, and browsergames.
Leave canonical_url blank if this is an original DEV post. Add the original URL only if republishing from an already live article.
Keep the cover image as the game page image or replace it with an uploaded DEV image before publishing.