DEV Community: GameHzLab

I Stopped Testing Card Games One Move at a Time

GameHzLab — Thu, 05 Nov 2026 04:27:56 +0000

Suggested DEV description: A legal move is not proof that a game can finish. Here is how full-match simulations caught freezes, duplicate cards, broken round transitions, and rule bugs across five browser card games.

Suggested DEV tags: testing, typescript, gamedev, webdev

One of my card games once passed every rule test I had and still froze halfway through a match.

The deck contained the right cards. Players followed suit. Trick winners were calculated correctly. Scoring examples matched the rulebook. None of that helped when the computer reached a state where it was waiting for a player who had already been removed from the hand.

That bug changed the way I test turn-based games.

I still write small tests for individual rules, but I no longer treat them as evidence that a game works. A playable game has to move through every phase, survive every hand boundary, and eventually stop for the right reason.

Today I run complete simulated matches for five browser games: Spades, Hearts, Euchre, Contract Bridge, and Oh Hell. The computer players do not need to be clever in these tests. They only need to make legal decisions quickly enough to expose problems in the game loop.

This is the testing approach that has caught the bugs my example-based tests missed.

A legal move proves very little

Consider a follow-suit test:

it("requires a player to follow the led suit", () => {
  const state = makeState({
    lead: card("10H"),
    hand: [card("2H"), card("AS")],
  });

  expect(() => playCard(state, "AS")).toThrow();
  expect(playCard(state, "2H")).toBeDefined();
});

This is useful. It proves one rule under one arrangement of cards.

It does not prove that:

the next player gets a turn;
the fourth card closes the trick;
the correct player leads next;
all cards remain accounted for;
the final trick reaches scoring;
the next round starts with an empty table;
the match eventually ends.

Most of the painful bugs in my games lived in that list. Each transition looked reasonable on its own. The failure only appeared after several correct transitions were combined.

Use the computer player as a test driver

Once a rules engine accepts actions without depending on the DOM, a computer player becomes a useful test driver.

Here is the basic shape of the Oh Hell simulation in my test suite:

let state = createGame();
let moves = 0;

while (state.phase !== "gameSummary" && moves++ < 2500) {
  if (state.phase === "dealing") {
    state = beginBidding(state);
  } else if (state.phase === "bidding") {
    state = submitBid(state, state.turn, chooseBid(state, state.turn));
  } else if (state.phase === "playing") {
    const card = chooseCard(state, state.turn);
    state = playCard(state, state.turn, card.id);
  } else if (state.phase === "collectingTrick") {
    state = collectTrick(state);
  } else if (state.phase === "roundSummary") {
    state = startNextRound(state);
  }
}

assert.equal(state.phase, "gameSummary");
assert.ok(moves < 2500);

There is nothing sophisticated about the loop. That is the point. It keeps asking the engine, "What phase are you in, and what legal action moves you forward?"

If the state machine enters an unhandled phase, the test stops making progress. If turn ownership is wrong, the next action is rejected. If a round transition forgets to reset a field, a later invariant fails.

The computer player is not being tested for skill here. It is supplying valid traffic to the engine.

Always give the simulation a move budget

A test that waits forever is worse than a test that fails.

Every simulation has an upper bound:

while (!state.gameOver && moves++ < MAX_MOVES) {
  state = takeNextLegalAction(state);
}

assert.equal(state.gameOver, true);
assert.ok(moves < MAX_MOVES, "match exceeded its move budget");

The number should be comfortably above a valid game's worst case, not a timeout measured in milliseconds. A move budget makes the failure deterministic and tells me something useful: the state machine did not converge.

This caught an Euchre problem in lone hands. The maker's partner was meant to sit out, but one turn-advance path still landed on that seat. The UI looked like it was thinking. The simulation simply consumed its move budget and failed.

The fix was to make "next active seat" a rule shared by every turn transition, rather than skipping the partner in only the visible play loop.

Check conservation laws after every action

Card games come with unusually good invariants. Cards should not appear, disappear, or exist in two places at once.

For Hearts, I collect cards from every live location after each play:

const cards = [
  ...Object.values(state.hands).flat(),
  ...state.currentTrick.plays.map((play) => play.card),
  ...state.completedTricks.flatMap((trick) =>
    trick.plays.map((play) => play.card)
  ),
];

assert.equal(cards.length, 52);
assert.equal(new Set(cards.map((card) => card.id)).size, 52);

Checking only at the end of a round is too late. If a card is duplicated on play 17 and silently removed on play 31, the final count may look fine. An assertion after every action identifies the transition that broke the invariant.

The same idea applies to values other than cards:

A Hearts round contains 13 hearts and, unless someone shoots the moon, 26 penalty points.
A four-player trick has four plays; a lone Euchre trick has three.
Bridge ends a played deal with 13 completed tricks.
Each Oh Hell round records one bid and one result per player.
Team trick totals in Spades must equal the number of completed tricks.

These checks are cheap, precise, and much more useful than taking screenshots of the final score.

Test phase transitions as first-class behavior

I used to think of phases as UI labels: bidding, playing, scoring. Now I treat them as part of the public contract of the engine.

A transition test should verify both sides of the boundary.

When Hearts finishes its final trick, for example, I care about more than the score:

expect(state.phase).toBe("round_end");
expect(state.completedTricks).toHaveLength(13);
expect(state.currentTrick.plays).toHaveLength(0);
expect(totalCardsInHands(state)).toBe(0);

That empty currentTrick assertion matters. Without it, the next deal can begin while the previous four cards are still considered active. I found exactly that bug after the UI appeared to play the final trick twice.

Round boundaries deserve their own assertions because they carry more cleanup than ordinary turns: dealer rotation, passing direction, vulnerability, scores, active seats, bids, and visible trick state may all change together.

Seed randomness when you need to replay a failure

Random deals are useful because they explore arrangements I would not think to write by hand. They are also frustrating when a failing deal cannot be reproduced.

For repeated engine tests, I inject a small seeded generator:

function seededRandom(seed: number) {
  let value = seed >>> 0;

  return () => {
    value = (Math.imul(value, 1664525) + 1013904223) >>> 0;
    return value / 0x100000000;
  };
}

for (let seed = 1; seed <= 20; seed++) {
  playCompleteDeal(seededRandom(seed));
}

If seed 14 fails, I can run only seed 14, inspect the exact deal, and turn it into a focused regression test.

Production shuffling still uses cryptographic randomness. Test randomness has a different job: explore several paths while leaving a receipt.

Do not let the test AI cheat

Because every hand exists in browser memory, it is easy to give a computer player the entire game state. That makes the test convenient, but it can hide bugs.

An AI that sees all hands may always find a legal escape from a bad situation. A real player-facing AI only knows its own cards and public information.

I prefer interfaces shaped like this:

chooseCard({
  hand: state.hands[seat],
  currentTrick: state.currentTrick,
  completedTricks: state.completedTricks,
  publicBids: state.bids,
  trump: state.trump,
});

The test driver should use the same information boundary as the game. This does not secure browser memory from a determined user. It prevents the implementation from becoming accidentally omniscient.

It also makes failures more honest. If the computer cannot choose a legal card from the information it is allowed to receive, either the AI interface or the engine state needs attention.

Simulations found different bugs in different games

The value of this approach became clearer as I added games with different structures.

Spades exposed tied end conditions. Reaching the target score is not enough when both teams are tied; the match must continue until one leads.

Hearts exposed cleanup errors at the final trick and score conservation problems around shooting the moon.

Euchre exposed active-seat bugs when a player went alone. A seat still existed at the table but no longer owned turns in that hand.

Bridge exposed control problems around Dummy. The seat holding the cards and the player choosing the card are not always the same person.

Oh Hell exposed round-progression assumptions because the hand size changes every round and the dealer cannot always choose every numeric bid.

None of these needed a browser to reproduce. The browser showed the symptom; the engine simulation reduced it to a repeatable state transition.

What full-game simulation does not test

Engine simulations do not replace browser tests.

They will not tell me that a mobile hand overlaps the trick area, that a dialog covers the player's cards, or that a moving card changes its face halfway through an animation. I still need visual checks and a small number of end-to-end interactions for those problems.

I use three layers now:

Small rule tests explain a specific rule and fail precisely.
Full-match simulations prove that legal actions can carry the engine to a valid ending.
Browser checks cover layout, input wiring, and animation behavior.

The middle layer was the one I was missing. It is fast enough to run with every change and broad enough to catch disagreements between individually correct rules.

Start with one ugly simulation

You do not need property-testing software or a brilliant AI to begin.

Pick the simplest legal action at every turn. Add a move budget. Assert that the match ends. Then add one invariant whenever a bug teaches you what must always remain true.

My first simulations were long while loops inside test files. Some still are. They are not the prettiest code in the project, but they answer the question I actually care about:

Can this game finish, repeatedly, without losing track of its own rules?

A passing unit test can tell me that one move was correct. A completed simulated match tells me that the moves still agree with one another hundreds of transitions later.

That distinction has saved me more debugging time than any individual test helper.

The five games mentioned here are playable at Trick Card Games. The engines are still evolving, but every new rule now has to survive more than a carefully chosen example. It has to survive the whole game.

What Building Four Browser Card Games Taught Me About State

GameHzLab — Thu, 22 Oct 2026 12:02:44 +0000

I started with Spades. The rules engine worked, the computer players could finish a hand, and the score came out correctly. Then I watched an opponent play a card and saw its face change halfway across the table.

Hearts found a different failure: the last trick of a round appeared twice. Euchre let a player go alone, but the sitting-out partner still looked active. Bridge could reach a valid contract and then stall because the human player was supposed to control Dummy rather than the seat at the bottom of the screen.

None of those bugs came from misunderstanding the card rules. They came from the boundary between game state and what the player sees.

I now have four playable trick-taking games in the browser: Spades, Hearts, Euchre, and Contract Bridge. They share cards, a table, menus, themes, and animation ideas, but they do not share the same game loop. Building them changed how I think about state in small games.

You can see the current result at Trick Card Games. This is what I learned while getting there.

Share the table, not the rules

The first temptation was to make one large CardGame abstraction. Four players sit around a table, everyone follows suit, somebody wins a trick, and scores are updated. It looked like an obvious inheritance tree.

It was not.

Spades has a bidding phase and a trump suit that must be broken. Hearts passes three cards before most rounds and scores penalty cards rather than contracts. Euchre uses 24 cards, changes the effective suit of the left bower, and may remove one partner from a lone hand. Bridge has an auction, an opening lead, a visible Dummy hand, vulnerability, and a declarer who controls two seats.

The useful shared layer turned out to be much smaller:

card dimensions and face rendering
hand fans for the four seats
dealing and trick-collection animation
table themes and card backs
menu, full-screen, sound, and speed preferences
common layout rules for desktop and mobile

The rules engines stay separate. That duplication is cheaper than an abstraction full of flags such as hasPassing, hasDummy, canGoAlone, and trumpMustBeBroken.

The rule I use now is simple: share presentation when the player expects consistency; keep domain state separate when the games use different language.

The engine owns the truth

My UI used to answer rule questions because the answer felt easy. Can this card be played? Is the hand over? Whose turn is next? That worked until one screen and one engine answered the same question differently.

Now the UI sends an action and waits for a result. It does not calculate legality on its own.

type PlayAction = {
  seat: Seat;
  card: Card;
};

type PlayResult = {
  state: GameState;
  playedCard: Card;
  trickComplete: boolean;
  roundComplete: boolean;
};

function playCard(state: GameState, action: PlayAction): PlayResult {
  // Validate turn, ownership, and follow-suit rules here.
  // Return a new state plus the facts the UI needs to animate.
}

This matters even in a single-player browser game. Buttons, keyboard input, computer turns, and animation callbacks can all try to advance the same hand. There should be one place that is allowed to say what happened.

It also made testing easier. The engine does not need the DOM, timers, CSS transitions, or a browser. A test can play an entire match as fast as the CPU allows.

An animation needs its own snapshot

The card-face bug in Spades was caused by reusing a DOM node while the underlying hand changed. The animation began with one card, the next render reused the element, and the face changed before the movement finished.

The fix was not a longer delay. The moving card needed an immutable snapshot.

const result = playCard(state, action);

const animationFrame = {
  card: { ...result.playedCard },
  from: getSeatPosition(action.seat),
  to: getTrickPosition(action.seat),
};

patchVisibleHand(result.state, action.seat);
await animateCard(animationFrame);

state = result.state;
renderTrick(state.currentTrick);

The animation reads animationFrame.card, not "whatever card is currently at index 7." The hand can shrink without changing the object that is moving.

This also stopped me from rerendering every hand after every play. Opponent card backs should lose one card; they do not need to disappear and rebuild. A small DOM patch looks steadier and is much easier to follow on a phone.

A completed trick is a transaction

The Hearts round bug was more subtle. The fourth card was played, the engine marked the round complete, and two pieces of UI code both tried to finish the trick. One collected the cards. The other rendered the "final" trick again before opening the score summary.

I fixed that by treating trick completion as one transaction:

lock player input
place the fourth card
leave all four cards visible long enough to read
record the winner exactly once
animate the cards into the winner's pile
clear the trick surface
either start the next trick or open the round summary

There is only one owner for that sequence. A collection guard prevents another render path from entering it, and a transition token makes old timers harmless after a new game starts.

if (isCollectingTrick) return;
isCollectingTrick = true;

try {
  await showCompletedTrick();
  await collectTrick();
  advanceAfterTrick();
} finally {
  isCollectingTrick = false;
}

The important part is not the boolean. It is deciding that "fourth card played" and "ready for the next action" are different moments.

Turn ownership is not the same as seat ownership

Bridge made this impossible to ignore.

The human normally sits South. If South becomes declarer, the human also plays North's exposed Dummy cards. If North becomes declarer, South may be Dummy, and the computer declarer must choose cards from the human's visible hand.

A check like this is wrong:

const humanCanPlay = currentTurnSeat === "south";

The real question is who controls the seat for this contract:

function isHumanControlledSeat(
  seat: Seat,
  contract: Contract | null,
): boolean {
  if (!contract) return seat === "south";

  if (seat === "south") {
    return contract.dummy !== "south";
  }

  return seat === contract.dummy && contract.declarer === "south";
}

Euchre has the same distinction in a smaller form. When somebody goes alone, the partner still owns a seat at the table, but does not own a turn in that hand.

Once control became an explicit function, the UI prompts, legal-card highlighting, and computer loop all used the same answer.

Computer players should not receive hidden cards

A browser has all four hands in memory, so it is easy to write a computer player that accidentally cheats. Passing the whole GameState into chooseCard() is convenient, but it also gives the function information a real player would not have.

The safer interface accepts only what that seat is allowed to know:

chooseCard({
  hand: hands[currentSeat],
  currentTrick,
  completedTricks,
  contract,
  publicBids,
});

The function cannot inspect an opponent's hand because it never receives one. This is not security in the usual sense; a determined player can inspect browser memory. It is protection against my own implementation mistakes and a way to keep the computer's decisions honest.

Full-game simulations catch more than unit examples

Rule-level tests are still valuable. I test that the left bower belongs to trump in Euchre, that Hearts has exactly 26 penalty points, and that Bridge scoring handles vulnerable and doubled contracts.

But the tests that have saved the most time run complete games.

They check invariants such as:

every deal contains the expected number of unique cards
no player breaks follow-suit rules
each trick removes one card from every active hand
the round reaches scoring rather than stalling
the dealer and vulnerability rotate correctly
a tied end condition continues when the rules require it
the next round starts with an empty trick surface

A simulation does not care whether the computer plays brilliant cards. It cares that hundreds of legal decisions eventually reach a valid result. That is exactly where turn-loop bugs tend to hide.

Static pages and interactive tables can coexist

The site uses Astro to generate the surrounding pages and TypeScript clients for the tables. The rules, scoring explanations, FAQs, and links arrive as HTML. The game code loads only where a table needs it.

That split has been useful for reasons beyond performance. A playable game needs fast input and local state. A rules page needs stable URLs, readable headings, internal links, and content that still exists before JavaScript starts.

Putting the table and its guide on the same page also gives players somewhere to check a rule without leaving the game entirely. The product and the documentation can share a URL without sharing an execution model.

What I would do differently

If I started again, I would establish three boundaries before drawing the first card:

The engine is the only owner of legal state transitions.
Animations consume snapshots and never infer card identity from a changing array index.
Each async transition has one owner, one lock, and a clear cancellation path.

I would still build separate engines for the four games. Their differences are the interesting part. The common table should make them feel like one product, but it should not pretend their rules are the same.

Card games look small because the board fits on one screen. Their state is not small. Hidden information, strict turn order, delayed animation, partnerships, and round transitions create plenty of room for two individually correct systems to disagree.

Most of my hardest bugs lived in that disagreement. Making the boundary explicit did more for the games than adding another clever computer strategy ever could.

The four games are playable at Trick Card Games. I am still refining the engines and the table, but the state model is finally carrying more of the weight than the UI timers.

Maximizing Internal Link Equity

GameHzLab — Mon, 08 Jun 2026 13:35:14 +0000

To ensure search engine crawlers discover our updated routes, we overhauled our linking structure:

Dynamic Sitemap integration: Our dynamic sitemap.ts now automatically queries and appends all category routes, assuring 100% indexability.
Footer & Header Linking: Added trending categories directly to the Footer to pass down PageRank and link equity to deep subpages.
Localized Image SEO: Updated rendering components (like MahjongCard) to include dynamic, localized alt tags to capture traffic from image search engines.
Virtual Category Routes: Moved virtual groupings like "Recently Played" and "Hot" from memory-based state hooks to indexable URL-driven pathnames.
Key Takeaways
By shifting from a basic, single-relationship setup to a robust, search-friendly architecture:

🚀 Database queries are 10x faster thanks to slug-based database indexing.
🤖 CMS content velocity increased by 99% by building an LLM-assisted schema generation script.
📈 Search crawlability was maximized through dynamic metadata, localized canonical alternates, and automated JSON-LD schemas.
If you are building a directory-based web application or content portal, investing early in structured database columns, dynamic schemas (JSON-LD), and automated AI enrichment pipelines will pay massive dividends down the road.

If you are building a directory-based web application or content portal, investing early in structured database columns, dynamic schemas (JSON-LD), and automated AI enrichment pipelines will pay massive dividends down the road.

What does your Next.js SEO stack look like? Let us know in the comments below!

🚀 From HTTP Loopbacks to Direct Service Layer: How We Fixed 403 Errors and Boosted Performance

GameHzLab — Thu, 26 Mar 2026 05:45:24 +0000

We just hit a major architectural milestone at GameHzLab! 🚀

After weeks of refactoring, we have successfully migrated our project's backend from a "Loopback-heavy" architecture to a Direct Service Layer pattern. If you’ve ever struggled with your own WAF blocking your server-side requests, this one is for you.

🛑 The Problem: The "403 Forbidden" Wall
Previously, our Server Components (Home, Category, and Detail pages) on GameHzLab fetched data by making internal HTTP requests to our own API routes. While this felt "modular," it introduced a critical point of failure: Cloudflare WAF.

Our server's internal requests were occasionally flagged as suspicious by our own firewall, leading to intermittent 403 errors and broken page renders.

🛠️ The Solution: gameService.ts
We introduced a unified gameService.ts to act as our data "Source of Truth."

Direct Database Access: Server components now call the service layer directly to fetch data from Supabase.

Bypassing the WAF: Since these are internal function calls rather than outbound HTTP requests, we have completely eliminated the risk of being blocked by our own security layers.

Architecture Standardization: All API routes have been refactored into lightweight wrappers around gameService, making the codebase cleaner and significantly easier to maintain.

📈 The Results

Major Performance Boost (TTFB) By cutting out the overhead of the internal network stack (DNS lookup, TCP handshake, and TLS negotiation for every internal request), we’ve slashed our Time to First Byte (TTFB).

Estimated Impact: We expect a 100-200ms reduction in page rendering latency across the platform.

GA4 Data Purity 🛡️ Analytics are only useful if they are accurate. We noticed that server-side crawlers were inflating our numbers.

We’ve implemented a server-side bot detection logic in layout.tsx. Now, when known crawlers visit GameHzLab, the GA4 script is no longer loaded. This protects our analysis from "noise" and ensures our data reflects real human engagement.

💡 Key Takeaway
If you are building with Next.js or any modern SSR framework, avoid the temptation to "fetch your own API" from within Server Components. It adds latency, introduces security hurdles, and complicates your architecture. Go direct.

Check out the live results at: www.gamehzlab.com

Have you faced issues with WAFs blocking your own server-side requests? Let’s discuss in the comments!

webdev #nextjs #architecture #performance #supabase #refactoring

How I Saved My Serverless Game Platform from Bot Traffic using Cloudflare WAF

GameHzLab — Mon, 23 Mar 2026 06:04:01 +0000

Tags: #webdev #security #serverless #nextjs #cloudflare

The Problem: 0% Engagement and 5xx Errors
Recently, while developing my H5 game platform gamehzlab.com, I noticed a disturbing trend in GA4: 100% bounce rate and 0.0% engagement time.

Despite having nearly 2k unique visitors, the "users" were spending only 2 seconds on the site. Even worse, Google Search Console started reporting 5xx Server Errors, preventing my games from being indexed.

The Trap: Global Bot Fight Mode
My first instinct was to toggle Cloudflare's "Bot Fight Mode".
Result: It backfired.
While it stopped some bots, it also blocked my game's .wasm and .data files. The AI-based protection was too aggressive, treating large binary fetches as suspicious activity, effectively breaking the game for real players.

The Solution: Smart Tiered Defense
I shifted from "Global Blocking" to a Custom WAF Rule strategy. Here is the logic that finally balanced security and accessibility:

Targeted Challenges
Instead of challenging everyone, I targeted high-risk, low-engagement regions (e.g., specific data center hubs) and excluded verified crawlers.
The "Verified Bot" Green Channel
I used the Known Bots field to ensure Googlebot and Bingbot could always reach the site, even when my manual rules were strict.
Protecting the Entry Point Only
By restricting the challenge to the root path (/), I ensured that once a human passed the initial check, their browser could freely download game assets without further interruption.

Current Status: The Road to Indexing
After deploying these changes and validating the fix in GSC, 129 pages are now in the "Discovered - currently not indexed" queue with a status of "Started". This means Google has acknowledged the server is healthy again and is re-queuing the content for crawl.

Key Takeaways for Indie Devs:
Don't trust "Bot Fight Mode" blindly for asset-heavy sites (Wasm/H5 games).

Prioritize Cache Rate: My initial cache rate was only 1.33%. Boosting this via Cache Rules is the best way to shield your Vercel/Supabase origin.

Watch GA4 Engagement: If it’s 0%, you don't have a traffic problem; you have a bot problem.

From 280MB to 1MB: How I Optimized Performance and SEO for My H5 Gaming Platform

GameHzLab — Thu, 19 Mar 2026 09:14:59 +0000

Building a global H5 gaming platform like GameHzLab is a race against both loading times and search engine indexing. When I discovered my initial API payloads were hitting 280MB and search engine visibility was stagnant, I knew a deep architectural overhaul was required.

Through a combination of extreme asset compression and a V2 SEO strategy, I managed to slash payloads by over 99% and achieve an 866.7% growth in organic search traffic within weeks. Here is the technical breakdown of that journey.

1. The Performance Revolution: Slashing Payloads
In web gaming, every second of loading time correlates directly to user drop-off. My primary goal was to ensure the "instant play" promise of H5 games.

API Optimization: By refactoring backend logic and utilizing Serverless Edge Functions, I successfully reduced the primary API response from 280MB to under 1MB. This ensures a smooth experience even for players on unstable mobile networks.
Engine & Texture Compression: For games built on Cocos and Unity, I moved away from standard PNGs to WebP and ASTC formats. I also implemented engine stripping to remove unused modules (like 3D physics for 2D games), ensuring every byte downloaded contributes to the immediate gameplay.

2. SEO V2: Category Hubs as Traffic Magnets
To help search engines better understand the site's hierarchy, I upgraded the classification system from simple query parameters to a robust link structure.

Route Rewriting: I shortened category paths from /category/ to a more concise and authoritative /c/.
Dynamic Routing: I implemented dynamic /[locale]/c/[id] routes for every supported language. This created stable "landing hubs" for high-volume categories like Mahjong or Puzzle games.
Structured Data (JSON-LD): By adding Breadcrumbs and CollectionPage schemas, I explicitly informed Google about the site's structure, leading to better rich-snippet representation in search results.

3. Content Enrichment: The "Game DNA" Factor
SEO is as much about content quality as it is about code. I expanded the content for all 15 core categories to increase authority.

Deep Descriptions: Each category page now features unique descriptions optimized for long-tail keywords.
Game DNA System: I developed a system that maps player psychology to gameplay. This interactive element has significantly increased "dwell time"—I've even observed individual US-based players staying engaged for over 36 minutes.

4. Real-World Impact: By the Numbers
The data from Google Search Console and GA4 confirms the success of these optimizations:

Search Visibility: The site achieved an average ranking of 16.4 with a healthy 4.5% click-through rate (CTR).
Traffic Explosion: Organic search traffic grew by 866.7%.
Global Reach: While I initially saw a spike in 4-second "bot-like" traffic from Singapore, the platform has successfully attracted high-value "real" players from the United States with engagement times exceeding 30 minutes.

Conclusion
For a solo developer, extreme performance is the baseline for retention, and structured SEO is the lifeline for growth. By leveraging Next.js and a lean asset strategy, GameHzLab demonstrates that a single engineer can build a platform capable of competing on a global scale.

Explore the results at GameHzLab.com