Web3 Game Development: The ChillChat Case Study

Why Fora Soft wrote this Web3 game development playbook

Most Web3 game development guides are written by people selling token launches. This one is written by the team that shipped the game. We’re Fora Soft, a software development company that has built video and real-time products since 2005 — 250+ projects, 50 in-house engineers, and a 100% Job Success Score on Upwork across 935 jobs. ChillChat is one of ours: a 2D pixel-art social game that grew a real-time chat and voice layer, then added an NFT ownership layer, and raised an $8.35M round on the strength of the product.

We’re writing it down because the mistakes in this space are expensive and repetitive. Teams bolt a marketplace onto a game nobody plays yet, put gameplay state on-chain and watch it stutter, or broadcast every voice stream to every player and melt the client at 200 people. We hit those walls on real timelines with a real budget, so the numbers here are things we measured, not things we hope are true.

If you’re a founder or CTO scoping a Web3 game, read this as a build log with the sales pitch removed. Where a decision could have gone either way, we say which way we went and why. Where we haven’t tested something past a certain scale, we say that too. Our other engineering write-ups — on what WebRTC development actually costs and choosing a chat backend — follow the same rule.

What Web3 game development actually means

Web3 game development is building a game where players provably own some of their in-game assets on a blockchain, while the game itself still runs as a normal real-time application. The chain records ownership and transfers; the game engine, servers, and networking do everything else. In practice that means a standard game (client, backend, database, real-time transport) plus a thin ownership layer: smart contracts, wallets, and a marketplace.

The word that trips teams up is “on-chain.” You do not put gameplay on a blockchain. Movement, physics, chat, and voice happen dozens of times per second and must feel instant; a public chain confirms transactions in seconds and charges a fee per write. So the working definition we use: the chain is a shared ledger of ownership, not a game server. Everything latency-sensitive stays off-chain, and only ownership-changing events — mint, buy, sell, transfer — ever touch the chain.

That single split — ownership on-chain, gameplay off-chain — is the difference between a Web3 game that plays like a game and one that plays like a checkout page. The rest of this piece is how we drew that line on ChillChat.

ChillChat in one paragraph

ChillChat started as a 2D pixel-art social game: build a character, decorate a personal space, wander a shared world, and talk to whoever’s nearby. We added viewport-filtered text chat and proximity voice so a crowded room felt like a room, not a switchboard. When the community started asking to actually own the cosmetics they’d made and collected, we added an NFT layer on Polygon — ERC-721 for unique items, ERC-1155 for fungible cosmetics — with wallet login and an in-game marketplace. Along the way we migrated the engine from Phaser to Godot to hold frame rate at scale and ship the same build to web, iOS, Android, and desktop. The product raised an $8.35M Series A from institutional Web3 investors.

Everything below unpacks that paragraph into decisions you can reuse: the architecture, the voice math, the engine call, the token design, the cost, and the pitfalls we dodged.

The anatomy of a Web3 social game

A Web3 social game has three planes wired to one client. Two of them are latency-critical and stay off-chain; one is the ownership ledger and never sits in the hot path. Drawing them as separate planes early kept us from the classic trap of treating “the blockchain” as if it were the database.

Figure 1. The three planes of a Web3 social game. Gameplay and real-time run off-chain; the chain plane stores ownership only, and one backend service is the sole component that submits on-chain transactions.

The game plane handles rendering and authoritative state: the pixel-art world, the tile grid, and deterministic rewards (earn item X by doing Y, no gacha). The real-time plane handles chat and voice. The chain plane holds NFT contracts, wallets, and IPFS-pinned metadata. A Node.js backend sits underneath as the referee, it owns authoritative game state, runs moderation, and is the only component allowed to submit transactions on-chain, which is how players mint without ever touching gas on their first item.

The payoff of this separation is testability. We can load-test the real-time plane without a wallet in sight, and we can swap the chain (or add a second one) without touching movement code. If you take one diagram from this article into your own design review, take this one.

The game plane: pixel-art editor and deterministic rewards

The thing that made ChillChat sticky wasn’t the chain, it was letting players build. A client-side pixel-art editor (24×32 sprites, roughly 768 bytes each) let people design characters and decor, which meant the world filled with content we didn’t have to draw. User-generated content is also what later gave the NFT layer something worth owning: you can’t sell scarcity in items nobody made or wanted.

Rewards are deterministic on purpose. You earn a specific item by doing a specific thing, not by rolling a loot box. That’s partly a trust decision and partly a regulatory one — randomized paid rewards tied to tradable tokens is exactly the combination that attracts gambling scrutiny. Keeping earning deterministic kept the economy legible and kept us off that third rail.

Viewport-filtered text chat that scales

Global chat in a social game doesn’t mean everyone reads everything, that’s a spam firehose. We filter by the viewport: you receive messages from senders whose region overlaps yours, resolved with spatial hashing so the lookup stays cheap as the map grows. A player in the north plaza simply doesn’t get packets from the south market.

Concretely, the world is a tile grid split into regions, each region a hash-bucket key. When you send a message, the server looks up the buckets your region touches and fans out only to subscribers there. Cutting delivery to on-screen senders dropped broadcast traffic by roughly 60–70% versus naive global chat in our tests, and it kept the chat readable, which matters more than the bandwidth. If you’re weighing hosted chat SDKs against a custom build for this, our chat backend buyer’s guide walks the trade-offs.

Voice at scale: area-of-interest routing

The short answer on voice: never broadcast. In a 500-player room, full-mesh or broadcast voice asks every client to decode ~500 streams, the client saturates, latency runs past a second, and connection cost grows O(N²). The fix is an SFU (selective forwarding unit) that forwards only the streams a player actually needs: the ones nearby.

Figure 2. Broadcast melts the client at scale; an SFU that forwards only speakers inside a ~20 m radius holds each player at ~8–12 streams and <150 ms end-to-end regardless of room size.

We ran voice on a LiveKit SFU with area-of-interest (AOI) routing: a player only subscribes to speakers within roughly a 20-metre in-world radius. That holds each client at about 8–12 concurrent audio streams and end-to-end latency under ~150 ms whether the room has 50 people or 5,000. The load driver is density, how many people crowd into one spot, not the global headcount. If you’re deciding between routing topologies, LiveKit’s own docs are a solid primer (docs.livekit.io), and our real-time audio benchmarks cover latency budgets in depth.

The engine ceiling: Phaser vs Godot

We started ChillChat in Phaser because it’s fast to prototype in and ships to the web instantly. It got us to a playable, growing game. Then we hit its ceiling: on mid-range phones, once a shared scene pushed toward ~1,500 players and HD art, Phaser stuttered and spiked memory, holding only 25–30 FPS. That’s the playable floor, not a target.

Figure 3. The engine ceiling we measured. Phaser held 25–30 FPS at target scale; migrating to Godot held 45–60 FPS with HD textures and built-in networking. The cost we weighed was the ceiling, not the invoice.

We migrated to Godot. It held 45–60 FPS at the same scale on the same hardware, brought HD textures and built-in multiplayer networking, and — because it’s MIT-licensed (docs.godotengine.org) — carries no per-seat engine fees as the player base grows. The migration cost real weeks of porting. Here’s the honest framing: the up-front spend on migration was smaller than the compounding cost of a ceiling that capped growth and made every optimization sprint return less. We haven’t stress-tested the Godot build past ~5,000 concurrent in one scene — beyond that you’re into sharding the world, which is a different article.

From mobile-only to cross-platform

ChillChat launched mobile-first, but a social world lives or dies on where your friends are, so we needed one build across web, iOS, Android, and desktop. Godot exports to all four from a single codebase, which is a big reason the migration paid for itself twice: once in frame rate, once in reach.

The catch worth naming: cross-platform doesn’t mean identical. Wallet flows differ (mobile deep-links vs desktop browser extensions), input differs, and app-store policies on tokens and purchases differ by platform and change often. We treated the shared engine as the easy 80% and budgeted explicit time for the per-platform 20% — store rules especially. Under-budgeting that last fifth is how “we’re cross-platform” turns into three months of surprises.

When Web3 actually earns its place in a game

Web3 earns its place when players already want to keep, trade, or carry out what they own, and it fails when it’s a solution to a demand that isn’t there yet. On ChillChat, the ask was organic: people who’d spent hours making pixel-art cosmetics wanted them to be genuinely theirs, sellable, and safe from a single company switching off the servers. That’s a real problem ownership solves.

Two questions we made ourselves answer honestly before writing a contract. First: is the in-game economy already alive without blockchain, are people trading in soft currency, is there real demand? If not, tokens create speculation, not play. Second: do players actually fear losing what they own? If nobody worries about a shutdown, on-chain ownership solves a problem they don’t have. We link readers to the counter-case in the “when not to” section on purpose — saying no to Web3 is a valid answer.

NFT integration architecture: wallets, contracts, marketplace

The ownership layer is three parts: token standards, a chain, and custody. We used ERC-721 for unique items and ERC-1155 for fungible cosmetics, both finalized Ethereum standards (EIP-721, EIP-1155) so wallets and marketplaces interoperate out of the box. Item art and traits are pinned to IPFS so they survive client changes and don’t depend on our servers staying up.

We deployed on Polygon (docs.polygon.technology), an EVM layer-2 where a mint costs on the order of a cent rather than dollars. Custody is deliberately forgiving: players log in with MetaMask, WalletConnect, or an email-based Magic wallet, so a non-crypto player never has to understand seed phrases to own an item. And because the backend is the only component that submits transactions, we subsidize first mints, the player earns an item and it appears; gas is our problem, not theirs.

The chain choice matters more than teams expect. Here’s how the main options compare for a consumer game where fees and finality are felt by players, not just the treasury:

For ChillChat, Polygon was the obvious pick: players mint often, values are small, and a cent-scale fee we can subsidize keeps the experience feeling like a game rather than a trading terminal.

Marketplace economy design: fees, supply, sustainability

A marketplace is an economy, and economies need a designer or they inflate. We charge a flat 5% marketplace fee on secondary sales — enough to fund operations and gas subsidies without taxing players into inactivity. The fee is visible and fixed; hidden or variable fees are how trust leaks out of a game economy.

Supply is the harder half. Because earning is deterministic and some cosmetics are capped, scarcity is designed rather than dumped — we don’t mint unlimited copies of “rare” items, which would make the word meaningless. The sustainability test we hold ourselves to: if speculation vanished tomorrow, would players still want these items for play and self-expression? On ChillChat the answer was yes, because the items started as things people made and used, not as financial instruments with art stapled on.

What Web3 game development costs

Straight answer: the blockchain is the cheap part. The expensive parts of a Web3 game are the same as any real-time multiplayer game — engine work, networking, art pipeline, backend, and QA across platforms. The ownership layer is a slice on top, and most of its cost is legal and security review, not Solidity.

Here’s an illustrative shape of where budget goes on a ChillChat-class build (ranges, not a quote, your scope moves these a lot; we build with an agent-assisted engineering process that pushes our own estimates below typical market rates, so treat these as conservative planning numbers):

A worked example on the one number people always ask about, the engine call. Say optimizing the existing Phaser build another quarter costs roughly X, and it buys you maybe 3–5 FPS while the ceiling stays near 1,500 players. Migrating to Godot costs roughly 2–3×X once, but lifts the ceiling to 5,000+ and removes per-seat engine fees forever. If the migration buys even one more year of growth headroom, the one-time 2–3×X beats paying X every quarter for shrinking returns. We ran that math and migrated. For the real-time side specifically, our WebRTC development cost breakdown has concrete dollar ranges.

Should you build an NFT marketplace inside your game?

Short answer: only if the game already works without it. An in-game marketplace amplifies an economy that exists; it cannot manufacture one. Run the concept through three gates before you commit engineering time.

Figure 4. The three gates we run before building an in-game NFT marketplace. Any “no” means fix the game first — blockchain won’t rescue a game players don’t already value.

Gate one: is there real trading demand in soft currency already? Gate two: are players asking for ownership that survives a shutdown? Gate three: can you fund 3–4 months of contracts, audits, and gas subsidies safely? Three yeses and the ownership layer earns its keep. Any no, and the honest move is to fix the game first — unaudited contracts plus a short runway is precisely how Web3 games get drained.

Pick your Web3 game stack in five questions

1. What’s your concurrency per room? Under ~50 speakers, simple routing is fine; past that, plan for an SFU with area-of-interest routing from day one — retrofitting it is painful.

2. How often do players mint or trade? Frequent, low-value actions demand a cent-scale L2 like Polygon; rare high-value 1/1s can tolerate Ethereum L1 fees.

3. Who pays gas? If you want non-crypto players, the backend must sponsor first mints. Design the mint service as the sole on-chain writer up front.

4. Which platforms at launch? If it’s more than one, pick an engine that exports everywhere from one codebase and budget explicit time for per-store token rules.

5. Do you have audit and legal runway? If you can’t fund a security audit and token counsel, you’re not ready to ship an ownership layer, and that’s a fine place to be for a version one. When you are ready, our dedicated development team can staff the whole stack, and our AI integration work plugs in where moderation and matchmaking need it.

Five pitfalls that sink Web3 games

1. Putting gameplay on-chain. Movement and combat at block speed feels broken. Keep gameplay off-chain; the chain records ownership, nothing more.

2. Tokens before a game. Launching a marketplace for a game nobody plays yet creates speculators, not players, and speculators leave the moment price stalls.

3. Broadcast voice. Sending every stream to every player caps you at a couple hundred people. Area-of-interest routing over an SFU is not optional at scale.

4. Making players hold gas. Forcing a newcomer to buy crypto before their first item kills onboarding. Sponsor first mints from the backend.

5. Shipping unaudited contracts. A bug in a live contract is money walking out the door and can’t always be patched. Budget the audit as a launch blocker, not a nice-to-have.

When NOT to add blockchain to your game

Don’t add blockchain when your game doesn’t have a living economy yet. If players aren’t already trading, gifting, or coveting items in soft currency, tokens won’t create that behaviour — they’ll just add friction, wallets, and legal exposure to a game that needs players first.

Don’t add it when ownership isn’t the pain. If nobody fears losing their stuff to a shutdown, on-chain ownership solves a problem they don’t feel. And don’t add it on a short runway: contracts, audits, and gas subsidies are a real, recurring cost, and doing them halfway is worse than not doing them at all. Plenty of great games have no business being Web3 games, and saying so is the most useful thing a partner can tell you.

The outcome: an $8.35M Series A

The situation: ChillChat had a growing pixel-art social game with real-time chat and voice, and a community starting to ask for ownership of the cosmetics they’d made. The risk was doing Web3 the loud way — tokens first, game second, and burning trust.

The plan: keep gameplay off-chain, add an ownership layer only where players asked for it, migrate the engine to hold frame rate at scale, and subsidize gas so onboarding stayed friendly. Text chat traffic dropped ~60–70% with viewport filtering; voice held ~8–12 streams per client and <150 ms end-to-end under area-of-interest routing; the engine went from 25–30 FPS to 45–60 FPS at target scale after the Godot migration.

The outcome: an $8.35M Series A from institutional Web3 investors — funding a working multiplayer product with a real ownership layer, not a whitepaper. The lesson we’d put on a poster: build the game first, add ownership where players ask, and keep the chain off the hot path. Want a similar assessment of your own concept? Book a 30-min scoping call and we’ll map the split for you.

FAQ

What is Web3 game development?

Web3 game development is building a game where players provably own some in-game assets on a blockchain, while the game itself runs as a normal real-time application. The chain records ownership and transfers; the engine, servers, and networking handle everything latency-sensitive off-chain.

Does Web3 game development mean the game runs on the blockchain?

No. Gameplay — movement, physics, chat, voice — runs off-chain at real-time speed. Only ownership-changing events like mint, buy, sell, and transfer touch the chain. Putting gameplay on-chain is the most common and most damaging beginner mistake.

How much does Web3 game development cost?

Most of the budget is the same as any real-time multiplayer game: engine, networking, backend, art, and QA. The ownership layer is a slice on top, and its biggest cost is usually security audit and legal review, not writing smart contracts. Smart contracts themselves are near-standard once specced (ERC-721/1155).

Which blockchain is best for a Web3 game?

For consumer games with frequent low-value mints, a cent-scale EVM layer-2 like Polygon is the common pick, or a gaming-native L2 like Immutable. Ethereum L1 only makes sense for high-value one-of-one items where fees are noise. ChillChat used Polygon and subsidized first mints so players never paid gas.

Do players need to own crypto to play a Web3 game?

They shouldn’t have to. On ChillChat, players log in with MetaMask, WalletConnect, or an email-based Magic wallet, and the backend sponsors first mints, so a non-crypto player can earn and own items without ever buying gas or handling a seed phrase.

How do you handle voice chat for hundreds of players?

Never broadcast. Use an SFU (we used LiveKit) with area-of-interest routing so each player only receives speakers within a small in-world radius — about 8–12 streams instead of hundreds. Load scales with local density, not the total headcount, so a 50-player and a 5,000-player room cost about the same per user.

Should I build an NFT marketplace inside my game?

Only if the game already has a working economy, players are asking for ownership that survives a shutdown, and you can fund contracts, audits, and gas subsidies for 3–4 months. If any of those is missing, fix the game first, a marketplace amplifies an economy, it can’t create one.

Why did ChillChat migrate from Phaser to Godot?

Phaser stalled near ~1,500 players at 25–30 FPS on mid-range phones. Godot held 45–60 FPS at the same scale, added HD textures and built-in networking, exports to web/iOS/Android/desktop from one codebase, and is MIT-licensed with no per-seat fees. The ceiling, not the migration invoice, was the real cost.

What to read next

Ready to build your Web3 game the right way?

The ChillChat story is one idea repeated at every layer: keep the chain off the hot path. Gameplay, chat, and voice run off-chain in real time; the chain holds ownership. Viewport filtering kept chat readable, area-of-interest routing kept voice cheap at any scale, the Godot migration lifted the frame-rate ceiling, and the ownership layer arrived only when players asked for it.

That order — game first, ownership second — is what turned a pixel-art chat into an $8.35M Web3 product. It’s also the fastest way to tell whether your own concept is ready. We’ve built real-time and video products since 2005; if you want a second set of eyes on where your line between on-chain and off-chain should fall, we’re happy to help.