DEV Community: Yitao

Building a Multilingual Roblox Site: Lessons from +1 Loot to Forge

Yitao — Sat, 10 Oct 2026 03:20:21 +0000

A WorldPlace case study based on 28 days of Google Search data.

Over 28 days, +1 Loot to Forge recorded 20,225 Google Search clicks across the language versions of its WorldPlace page. The English version received 31.

I run WorldPlace, a website that combines Roblox game information, discovery features, and tools for creators. Its Search Console data gives me a practical way to decide which games deserve closer attention and which questions their pages need to answer.

For this case study, the strongest signals came from localized game pages and searches for in-game reward codes. They raise concrete product questions: how to recognize a game across languages, keep changing information accurate, and help a reader move from a quick answer to deeper research.

Here is what the data shows, and how I would use it to guide the next round of improvements.

What the Search Console data shows

The reporting period is September 8 through October 5, 2026, with the search type set to Web. The property-level chart recorded 58,664 clicks and 719,215 impressions.

To compare games, I grouped the game-page URLs in the 979-row Pages export by their game slug. That brings URLs such as /th/games/1-loot-to-forge and /vi/games/1-loot-to-forge into the same group.

Here are the six leading games by clicks after combining their language versions:

Game	Search clicks	Impressions	CTR
+1 Loot to Forge	20,225	100,338	20.16%
Find the Needle	8,472	68,286	12.41%
Find a Needle in a Haystack	5,592	70,973	7.88%
Command an Army	5,048	93,712	5.39%
Steal an Egg	3,690	131,125	2.81%
Anime Dice	3,170	54,646	5.80%

The Pages export totals 60,478 clicks. That differs from the property-level chart because Search Console uses different aggregation methods for different views. I use the Pages total for page contribution calculations, following Google's explanation of report aggregation.

On that basis, +1 Loot to Forge accounts for 33.44% of exported page clicks. It is the clearest main case for this dataset.

The grouping itself can be expressed with a small Python function. It expects records from the exported Pages table:

import re
from collections import defaultdict
from urllib.parse import urlsplit

def summarize_games(page_rows):
    totals = defaultdict(lambda: {"clicks": 0, "impressions": 0})
    for row in page_rows:
        path = urlsplit(row["Top pages"]).path
        match = re.search(r"/games/([^/]+)/?$", path)
        if match:
            game = totals[match.group(1)]
            game["clicks"] += row["Clicks"]
            game["impressions"] += row["Impressions"]

    for game in totals.values():
        impressions = game["impressions"]
        game["ctr"] = game["clicks"] / impressions if impressions else None
    return dict(totals)

CTR comes from combined clicks divided by combined impressions. Averaging the individual page percentages would give small pages too much influence.

This ranking measures WorldPlace's search performance during one period. It does not establish the most popular Roblox games worldwide or the fastest-growing games this week.

One game can have very different search results across languages

Across the Pages export, non-English URLs received 99.09% of clicks. Vietnamese, Thai, and Brazilian Portuguese pages together accounted for 57.38%.

The language breakdown for +1 Loot to Forge makes that distribution easy to see:

Language version	Search clicks
Thai	6,187
Brazilian Portuguese	3,973
Vietnamese	2,952
English	31

These are results for this site's pages. Ranking, competition, and the queries each page appeared for could all contribute to the difference. A translated URL also does not tell me a reader's native language.

Still, the product implication is substantial: content maintenance has to include the localized pages receiving those clicks.

For a game directory, I would organize localization around a shared game identity. The official Roblox link and developer belong to that identity. Local titles, spelling variants, and explanatory copy belong to the language version.

That gives readers two useful things at once: wording they recognize and a clear way to confirm which game the page describes.

It also makes updates easier to reason about. If a developer changes a reward announcement, that is a change to the underlying game information. Every language version using that information becomes a candidate for review.

The translation can sound natural while still pointing back to the same source.

What reward code searches mean for a game page

For readers outside Roblox, a game code is a string a player may redeem for an in-game reward. It is different from the game's source code.

Of the 1,000 exported queries, 753 contained recognizable code or redemption terms, including code, codes, โค้ด, and 코드. Those queries contributed 20,379 of the sample's 22,640 clicks, or about 90%.

Examples included code xúc xắc anime, an Anime Dice code query in Vietnamese, and code tìm kiếm cây kim, a Vietnamese query about finding a needle and reward codes.

This is a keyword classification of the exported sample. Search Console omits anonymized queries and limits table rows, as Google's data-discrepancy documentation explains. The percentage should stay attached to that sample.

For +1 Loot to Forge, the official Roblox description gives a straightforward gameplay outline: build power by clicking, defeat enemies, collect ores, and forge equipment. The developer is Good Bro Studio.

That basic loop gives the page context. The code searches suggest a more immediate task: finding reward information a player can actually evaluate.

An October 7, 2026 source check showed why that requires ongoing attention. The WorldPlace game page still included a [Races] title and references to 30000CCU and 20000CCU. The official Roblox page showed [BOSS] and listed 100000CCU and SORRYBUG in its description.

The pages were showing different updates. That called for a content review. It did not establish whether any of the codes still worked.

For maintaining this information, I would keep three fields distinct:

Source: where the claim came from, such as a developer announcement or a community report.
Verification: whether it was observed in a source, tested in the game, or reported as no longer working.
Checked time: when that particular claim was last reviewed.

A general page update date cannot communicate all three. Refreshing player statistics should not make an older code claim look newly tested.

For this audience, a useful page should make the game identity, reward information, and supporting source easy to find. A concise gameplay explanation can then help readers continue when codes are unavailable or when they want to understand what to do next.

Similar names can belong to different Roblox games

The next two games in the click ranking expose another problem: similar names can make separate records look interchangeable.

Game	Developer	Roblox Place ID
Find the Needle!	aarush's fruit game	83238501165241
Find A Needle in a Haystack!	CrossJump Games	93134232675115

In Find the Needle!, the official description tells players to collect hay, sell it for money, buy upgrades, and find the needle.

In Find A Needle in a Haystack!, players pull hay, feed a horse, upgrade tools, and search alone or with up to three friends. Each run begins with a fresh farm and a new needle location.

The games share a recognizable premise, but their developers, official links, and described systems differ. Combining them could put the wrong instructions, rewards, or statistics on a page.

That is why I would use explicit game identity for content records and keep name matching as a separate lookup step. A localized title can help find a candidate. The official link and developer help confirm it.

The same caution applies to analytics. A query containing “needle” may be ambiguous. Separate query and page exports do not establish which page received that query's clicks. An uncertain match should remain uncertain until more specific data resolves it.

More impressions do not always mean more clicks

Steal an Egg had the most impressions among the game groups: 131,125. It produced 3,690 clicks, for a CTR of 2.81%.

By comparison, +1 Loot to Forge recorded fewer impressions and substantially more clicks.

That gives me a useful investigation target. I would break Steal an Egg down by language, query type, and position before deciding whether its titles, content, or coverage need to change.

The broader site trend adds context:

Period	Search clicks	Impressions	CTR
September 22–28	22,372	212,528	10.53%
September 29–October 5	13,339	268,180	4.97%

In the final week, impressions increased by 26.19% while clicks fell by 40.38%.

The site was appearing in more search results, but those appearances were producing fewer clicks overall. The export does not contain daily data for each game, so it cannot identify which game caused the change.

It does show why a useful review needs both reach and response. A bigger impression count gives me another question to investigate.

Where player information becomes creator research

WorldPlace also includes creator tools. The challenge is deciding how those tools fit the needs revealed by search.

Game detail pages received 99.51% of the exported page clicks. The game ideas generator received 181 search clicks across its language versions. There were also explicit queries such as roblox game idea generator, which contributed 82 clicks in the query export.

Those figures show an initial search signal for creative work, alongside a much larger entry point through game information. They do not describe what readers did after arriving.

I would use the search data to choose research priorities, then examine the game's documented mechanics before proposing a new design.

For +1 Loot to Forge, the documented sequence of gaining power, fighting, collecting materials, and forging suggests a focused question:

Can the first crafting decision offer a tradeoff that a new player understands and notices immediately?

One possible research brief would be a small workshop prototype with two craftable tools. One tool could improve collection speed; the other could open a different route. The first test would examine whether players understand the choice and can explain why they made it.

The reference-game input in WorldPlace's generator provides a place to carry game context into that process. For a useful demonstration, I would record the input constraints, the actual output, and the edits that make the idea small enough to test.

The human decision belongs in the record too. Which suggestion adds a meaningful choice? Which one adds production work? What can a short playtest actually answer?

What I want to measure next

The next round of work should connect search entry points with what happens on the site.

I want to measure how often readers open an official game source, continue to a related game, or enter a creator tool. Within the generator, I would measure three separate steps: opening the page, completing a generation, and saving a concept.

I also want to compare changes at the same level as the problem. A revised Thai game page needs a view of its relevant queries and search performance, alongside on-site behavior. An increase in total site impressions would not answer whether that particular revision helped.

For now, +1 Loot to Forge gives me a clear priority: review the localized pages that already bring readers in, make the source and status of changing information easier to understand, and connect deeper research to questions those pages can support.

The next useful improvement may be a clearer answer on a page someone already needs.

If you maintain a multilingual directory or content product, how do you keep translated pages in sync when the underlying information changes?

Data source: my WorldPlace Google Search Console export for September 8–October 5, 2026. Page comparisons combine language versions by game slug. CTR is calculated from summed clicks and impressions. Public game descriptions were checked on October 7, 2026.

AI disclosure: AI tools were used for research, analysis, outlining, and drafting this article. The Search Console data came from my WorldPlace property.

Post-Mortem: How My Web Game Hit 130k MAU with $0 Marketing (and Survived an AdSense Ban)

Yitao — Thu, 28 May 2026 04:12:49 +0000

A transparent case study on indie game growth: from accidental multi-language localization to a successful B2B pivot in the US market, and scaling revenue after an AdSense restriction.

For the past few months, I’ve been fighting in the trenches of the indie game market. It has been a wild, stressful, and almost surreal ride. By the end of the 2025 holiday season, one of my projects impostergame.net hit a milestone of 100,000 Monthly Active Users (MAU). For a developer who has spent years in the "newbie" phase of the global market, this was incredible validation. But the story behind the numbers is far more chaotic than the charts suggest.

A Happy Accident: Scaling to 130k MAU

The initial success of this site was largely due to luck. While developing the game, I was using Claude Code. Due to some imprecise prompting on my part, Claude ended up generating a version of the site localized into five different languages.

The UI looked much better than I expected, and I didn't have the heart to roll back the code. So, I took a leap of faith and launched all five languages simultaneously. Usually, my habit was to launch in English first and indefinitely postpone other locales.

That "accidental" decision turned out to be the catalyst for our explosion. Within a month of launch, the Spanish version took off. We saw a massive influx of users from Spain, followed by a surge from Mexico and Latin America. By Christmas and New Year’s, the traffic peaked at 130,000 MAU. Looking back, if I hadn't unintentionally launched with multi-language support, this story wouldn't exist.

The Great Pivot: From Spanish B2C to US B2B

After the holiday craze, the Spanish traffic began its natural decline, dropping to a low of about 80,000 MAU. However, I noticed something interesting: our US-based English traffic was starting to climb.

To capture this new momentum, I began adding more content and diving deep into SEO optimization. Through analysis with Gemini, I realized my multi-language implementation was riddled with bugs—specifically, my canonical tags were a disaster.

I spent several rounds of deep-diving with Gemini to "perform surgery" on the code, starting with the English homepage. I optimized the SEO metadata and copy step-by-step, while leaving the high-traffic Spanish pages untouched to avoid any sudden drops.

Unexpected Target Audience
As the Spanish traffic waned, I successfully migrated our core audience to the higher-value US market. The ad value (RPM) in the US is 5 to 10 times higher than in the Spanish-speaking regions. Traffic eventually stabilized back around 90,000 MAU, but with a surprising twist: the new users weren't just casual party-goers. They were teachers and HR professionals using the game for classroom education and corporate team-building events.

The AdSense Nightmare: When "Passive Income" Goes Flat

With high-value traffic stabilized, I naturally applied for Google AdSense. I thought I was on my way to consistent passive income. Instead of "making money while I sleep," AdSense almost made my business "sleep" permanently.

Initially, shortly after successfully integrating AdSense, the site was hit with a restriction because the sheer volume of excited users led to rampant accidental clicks. After the account was restored, my daily CPC and revenue began to steadily recover, and the Click-Through Rate (CTR) was maintained at a very safe 2%.

But then, the "weekend effect" hit. Starting on a Friday, the CTR began to climb. It first approached 2.5% on Friday, and then by Saturday night (the first 6 hours of US time), it skyrocketed past 3%!

The reason? Friction. In a fast-paced browser game, users are anxious to start playing. When ads pop up and interrupt the flow, accidental clicks become inevitable. These "accidental clicks" are flagged by Google as Invalid Traffic.

Despite my emergency efforts to reduce ad density and increase spacing, the AdSense penalty arrived. My account was restricted for the second time. Ironically, the very next morning—while my account was under restriction—I received a notification from my bank. My first-ever AdSense payment of $145.66 had arrived. It was my first taste of passive income from the global market, yet I felt no joy. Knowing my revenue had flatlined again left me in a state of constant anxiety.

The AI Intervention and the 80-Email Comeback

"In the depths of this frustration, I started questioning if the site was even worth keeping. I asked Gemini, "Based on my current traffic, what is the estimated valuation of this site if I were to sell it?""
Gemini: Gemini analyzed the data and gave me a surprisingly firm answer: "If I were you, I absolutely wouldn't sell right now." Instead, it recommended moving away from AdSense and looking for a gaming-specific ad platform.

That was the wake-up call I needed. I abandoned AdSense and reached out to Venatus, a premium ad network for the gaming industry. Over the next week, I exchanged nearly 80 emails with their account managers to get the integration right.

$1,279.55 Revenue
We got it live just before the Spring Festival. Since then, revenue has stabilized. Even as traffic naturally dipped to 50,000 MAU after the peak season, the site generated $1,279.55 over the last three months. As the Venatus "onboarding" period ends and eCPMs improve, there is significant room for growth.

Long-termism: The Future of Web Games

Reflecting on this "roller-coaster" journey, I’ve realized that web-based games still have incredible vitality in today’s ecosystem.

Frictionless is a Superpower: The "no download, just play" nature of web games is a massive discoverability weapon. It allowed me to leverage SEO and accidental localization to reach 130k users with zero marketing spend.
Intent Matters More Than Volume: Raw traffic is great, but the intent of that traffic defines your ceiling. Moving from "pure entertainment" (Spanish casual users) to "utility/tool" (US educators and HR) is what gave the product long-term sustainability.
Built for Resilience: A monetization system must be built on a deep understanding of user behavior. Moving from the AdSense nightmare to a specialized partner like Venatus taught me that the urge to maximize short-term revenue must always be balanced against platform rules and user experience.

Today, ImposterGame covers its server costs and generates a healthy profit through ads and a small number of subscriptions. This is just the beginning. For indie devs, real success isn't just about going viral once—it’s about building a stable, compliant, and sustainable business loop in a volatile market.

I hope these lessons help other developers exploring non-traditional growth paths. If you want to experience the frictionless web game mentioned in this case study, try a round with your friends at ImposterGame.net. You can also find more of my technical deep-dives on my personal devlog.

Next.js 15 + Supabase: I Accidentally Blew Past My Quota by 1000% (and How “Local‑First” Saved It)

Yitao — Fri, 30 Jan 2026 06:25:47 +0000

TL;DR: My “perfectly reasonable” real-time architecture for an online party game turned into a billing horror story — first with Supabase Realtime broadcasts, then with Redis + polling. The fix wasn’t “optimize the server.” It was stop needing the server for the common use case.

1. The morning my dashboard tried to jump-scare me

One morning I woke up to warning emails from Supabase and Vercel:

“Your project has significantly exceeded its Realtime message quota.”

I opened the dashboard and had to re-check that I was looking at the right project.

In just a 10-day span, Supabase Realtime (Broadcast + Presence) had processed roughly 50,000,000 messages (the bill line item showed 54,557,731 Realtime Messages).

That wasn’t “a little over.” It was 1000%+ over the included quota.

For context: I run Imposter Game — a browser-based party game (think “Liar Game” / social deduction) that works with 3 to 99 players. No installs, no logins — just open a URL and play.

User growth is great… until your side project starts throwing punches at your wallet.

2. Technical post-mortem: two failures back-to-back

The stack

Framework: Next.js 15 (App Router)
Database: Supabase (Postgres)
Realtime: Supabase Realtime (Broadcast + Presence)
State: Upstash Redis (Vercel KV)

Failure 1: Broadcast everything (Supabase Realtime)

My first approach was the classic “real-time multiplayer” instinct:

Any state change? Broadcast it immediately.
Timer? Send updates every second.
Presence? Track joins/leaves live.

Here’s the core math that bit me: Supabase charges on egress messages — effectively:

1 event × number of subscribers in the room (N)

So with N = 50 players:

Every second: 1 timer tick × 50 recipients = 50 messages/sec
One 15-minute round (900 sec): 50 × 900 = 45,000 messages
Add votes, reactions, and Presence traffic…and the number explodes.

Result: ~50M messages in about 10 days, quota obliterated.

Failure 2: “Fine, I’ll use Redis + polling”

My next thought was also extremely common:

“Realtime is expensive. Let’s store state in Redis and have clients poll.”

So I turned off the broadcast approach and switched to:

State stored in Upstash Redis
Client polls GET /api/game-state once per second

This looked “cheaper” in my head. It wasn’t.

If each poll triggers ~3 Redis commands (Room/Round/Player):

10 concurrent users × 1 poll/sec × 3 commands = 1,800 commands/min

And Upstash’ free monthly quota (500k commands)?

It evaporated in less than half a day.

I ended up adding a credit card for Pay As You Go just to keep the app alive.

At that point I had to admit it:

“Congrats. I just wrote my own DDoS script.”

(Also: Vercel and Upstash being in different regions increased RTT and made the whole thing feel even worse.)

3. The real realization: I was solving the wrong problem

My initial “solutions” were all server-side optimizations:

batch Redis reads (MGET)
reduce timer update frequency (1s → 5s)
compress payloads

Then I paused and pictured the real-world usage.

Most people play party games… in the same room, around the same table.

So why were 10 friends at a campsite burning LTE data and battery life, constantly syncing with a server across the planet?

The problem wasn’t “how do I scale my server cheaper?”

It was:

“How do I remove the server from the default experience?”

4. The pivot: Local‑First, client‑only (“no server” mode)

I made a bold call:

For in-person play, don’t use the network at all.

Not “serverless.” Not “edge.”

Just 0 API calls.

New architecture: client-only pass-and-play

One phone acts as the host. Players pass the device around to confirm roles (“pass and play”), then play together locally.

The Local Mode component is a use client Next.js client component, but internally it behaves like a little state machine.

Local timer (no drift, no server)

Instead of server setInterval, I use requestAnimationFrame + Date.now() to compute time-left deterministically.

// useGameTimer.ts (simplified)
useEffect(() => {
    const startTime = Date.now();
    let animationFrameId: number;

    const tick = () => {
        const elapsed = Math.floor((Date.now() - startTime) / 1000);
        const newTimeLeft = Math.max(duration - elapsed, 0);

        setTimeLeft(newTimeLeft);

        if (newTimeLeft > 0) {
            animationFrameId = requestAnimationFrame(tick);
        }
    };

    animationFrameId = requestAnimationFrame(tick);
    return () => cancelAnimationFrame(animationFrameId);
}, [duration]);

(Yes, background tabs have constraints — but this is optimized for in-person local play, where the app stays in the foreground.)

State transitions happen in memory

Role assignment (3–99 players), voting, win conditions — everything runs in browser memory.

const nextPhase = () => {
    setGame(prev => {
        if (prev.phase === "voting") {
            const result = calculateWinner(prev.votes); // local compute
            return { ...prev, phase: "result", winner: result };
        }
        // ...
    });
};

No network round trip means phase transitions feel instant.

INP optimization for 99 players

Rendering and updating a 99-player list can get janky fast.

React 18’s useTransition helped keep heavy updates non-blocking:

const addPlayer = () => {
    startTransition(() => {
        setGame(prev => {
            const newPlayers = [...prev.players, createNewPlayer()];
            return balanceRoles(newPlayers);
        });
    });
};

Security note (because someone will ask)

Online mode still requires server-side validation.

But in Local Mode, the person holding the phone is effectively authenticated by physics.

Your friends’ eyeballs are the anti-cheat.

Result: costs down, UX up

I restructured the site:

Local Game (Offline Mode) became the main CTA on the homepage.
Online Game stayed as a backup feature (“Remote Mode”).

What changed

Realtime messages: ~50M → near zero (because most sessions moved to Local Mode)
Redis usage: easily kept within free/low tiers
Reliability: no more games dying due to disconnects (even in basements, mountains, and spotty areas)

The best part: users preferred the version with no installs, no logins, and no dependency on good internet.

Takeaway

As developers, we’re often drawn to “real-time,” “websockets,” and “edge everything.”

But the best scaling strategy I’ve learned recently is:

Don’t optimize the server — make the server unnecessary.

Sometimes an Array.map beats a Redis cluster.

Try it

👉 Play Imposter Game

It’s a real demo of a smooth 99-player local party game built with React — no app install required.