DEV Community: Marvin Tang

From LayaAir to Cocos Creator: A Solo Dev's Engine Migration After iOS Builds Kept Crashing

Marvin Tang — Mon, 20 Apr 2026 02:13:31 +0000

The debug build that wouldn't stop crashing

It was 2 AM. I had just spent five days trying to fix the same bug.

My game ran perfectly in the browser — 60 FPS, smooth animations, clean input handling. Then I'd run the iOS debug build and watch it crash within 30 seconds of launch. Sometimes on scene load. Sometimes mid-gameplay. Sometimes on a simple button tap.

No consistent stack trace. No clear reproduction path. Just crashes.

That week, I decided to migrate the entire project from LayaAir to Cocos Creator.

This post is about why I made that call, what the migration actually looked like as a solo developer, and what I'd tell anyone considering either engine today.

Why I chose LayaAir in the first place

When I started building browser-first games, LayaAir was an obvious pick:

Strong WebGL performance — genuinely fast in the browser, often beating Cocos and Phaser in my side-by-side tests
TypeScript-first — clean workflow, great autocomplete, sane codebase
Good for 2D casual games — which is exactly what I build
Active in the Chinese dev community — a lot of reference material if you can read it

For about 8 months, this was the right choice. My physics games and puzzle games shipped to the browser, loaded fast, and ran well on desktop and mobile browsers alike.

Where LayaAir shines: Web builds

Let me be fair to LayaAir. For web-only targets, it's still a solid engine:

Small runtime size
Fast startup
Good rendering performance on WebGL
Reasonable TypeScript DX

If I were building a game that would only ever run in a browser, I'd still consider it.

The problems started when I tried to go native.

Where it broke: iOS native builds

My goal was to ship the same game to iOS. LayaAir advertises native export to iOS via its build pipeline — in theory, you get an Xcode project from your web codebase.

In practice, the iOS output was unstable in ways I couldn't engineer around:

Debug builds crashed unpredictably. Same code that ran flawlessly in the browser would segfault on device, often with stack traces pointing into the engine's native layer, not my code.
Memory-related crashes during scene transitions, even in a simple project with minimal assets.
Inconsistent behavior between simulator and real device — a bug that reproduced on iPhone 14 might not show on the simulator, and vice versa.
Very limited English-language debugging resources. Most issue discussions were in Chinese, and even there, many reported bugs had no resolution.

I spent five full days trying to:

Strip the project down to a minimal reproduction
Experiment with different build configurations
Try every combination of engine version and Xcode version I could find
Post on forums and wait for responses that never came

The issue wasn't in my code. It was in the engine's native bridge. And as a solo developer, I don't have the budget — in time or money — to debug someone else's native runtime.

The switch decision

Here's the framing that helped me decide:

"How many more days am I willing to spend on a problem I can't see the bottom of?"

If the engine's iOS layer was buggy enough that a minimal project crashed, what would happen when I added monetization SDKs, more assets, more scenes?

I gave myself a budget: two more days. If I didn't have a stable build by then, I'd switch engines.

I didn't make it to day two.

Migrating to Cocos Creator

Cocos Creator was the natural alternative:

Also TypeScript-based
Similar scene/node/component architecture to LayaAir
61% of top 100 WeChat mini games ship on Cocos — which tells me the native export pipeline is battle-tested
MIT-licensed and actively maintained
Broader international documentation

The migration took about 10 days of focused work for a medium-sized project (a merge-gacha tower defense with around 40 scenes).

Here's what actually transferred well and what didn't:

What was easy

Game logic and data structures — pure TypeScript business logic ported with minimal changes
Scene structure concepts — both engines use a tree of nodes with components attached. The mental model is nearly identical.
Asset pipeline — sprites, atlases, and audio imported cleanly

What needed rewriting

Scene transitions and lifecycle hooks — API names and timing differ enough that I rewrote all the transition code
Input handling — the event system is different; I consolidated my input layer into a single adapter module
UI layout — LayaAir and Cocos have different layout primitives. I redid most of my UI by hand.
Animation system — different timeline formats; I reimplemented the important ones

What surprised me

Cocos's editor is heavier but more stable. LayaAir IDE is lighter, but I hit editor crashes regularly. Cocos Creator's editor has held up through multi-hour sessions without issue.
The iOS export just worked. The first time I tried to build for iOS with Cocos Creator, it compiled, ran on device, and didn't crash. After five days of LayaAir debugging, this felt absurd.
Web performance is still good. I was worried I'd lose the web performance edge. In practice, for my 2D casual games, the difference is imperceptible.

Results after the switch

Cosmic Summon (my gacha merge tower defense) now runs on both browser and iOS from the same Cocos Creator project
Juicy Ricochet shipped to the App Store as an all-Cocos build
Zero engine-layer crashes since the migration
My development velocity actually increased once I was past the migration hump — the editor stability alone was worth it

What I'd tell someone in the same situation

A few things I learned the hard way:

1. Set a debugging budget before you start.
"I'll fix this bug eventually" is how you lose two weeks. Decide in advance how many days the problem is worth.

2. Engine problems in the native layer are usually not solvable as a user.
If the crash comes from inside the engine's C++ or Objective-C code and isn't fixed upstream, you're not going to fix it. Move on.

3. Web performance isn't the only metric.
I chose LayaAir partly because its benchmarks were great. But "faster in a controlled web benchmark" didn't matter when the iOS build didn't work at all.

4. Pick the engine that ships the platforms you need — not the one that ships the benchmark you like.
Cocos Creator wasn't the "fastest" engine on paper for my use case. But it shipped everywhere I needed to ship, and that turned out to be the only metric that mattered.

5. Don't mistake language comfort for engine fit.
Both engines use TypeScript. I liked LayaAir's API aesthetically. But aesthetic preference shouldn't outrank "my game crashes on the target platform."

Is LayaAir bad? No.

I want to be clear: LayaAir isn't a bad engine. For web-only projects it's still a reasonable choice, and I know developers shipping successful games on it.

My specific experience was with the iOS native export, which didn't work reliably for my project. Your mileage may vary, especially if you're targeting different platforms or a newer engine version.

But if you're a solo developer, and stability across platforms matters more to you than peak web benchmark performance — Cocos Creator is, in 2026, the safer bet.

Currently building: Cosmic Summon, a gacha merge tower defense live on browser and iOS.

More of my games: phyfun.com

What engine are you using for your indie game? Have you migrated between engines before? I'd love to hear how it went — drop a comment.

How I Used Keyword Research to Build a Niche Naming Site

Marvin Tang — Thu, 16 Apr 2026 08:33:53 +0000

I'm an indie developer based in China. Most of my projects are browser games — physics puzzles, sorting games, two-player titles. But one of the most interesting things I've built has nothing to do with games at all.

It's a dog names site.

iDogNames.com now has over 11,000 dog names searchable by breed, origin, coat color, and meaning. It gets consistent organic traffic. And it started entirely from keyword research, not from any personal passion for dog names.

Here's how the thinking went.

The Problem with Competitive Niches

When I was looking for new content site opportunities, I kept running into the same wall: anything with obvious commercial value was already dominated by large publishers with enormous content budgets. "Best dog food", "puppy training tips", "dog breeds" — these are all real search categories, but ranking for them as a solo developer with no content team is not realistic.

What keyword research actually reveals, if you look carefully enough, is not just where the traffic is — it's where the traffic is relative to the competition. High traffic with low competition is the obvious target. But that combination is rare.

The more interesting question is: where is there consistent, specific demand that large publishers haven't bothered to serve well?

The Long Tail of Naming Queries

Dog name queries turned out to be a surprisingly good answer to that question.

The obvious terms — "dog names", "puppy names", "cute dog names" — are competitive. Large pet content sites rank for these and they're not worth targeting directly.

But dog name queries have an unusually long tail. People don't just search for "dog names". They search for:

"Romanian dog names"
"dog names that mean shadow"
"names for black mouth cur dogs"
"Amish dog names"
"dog names inspired by Broadway musicals"

Each of these is a small query. But there are hundreds of them. And most of them are served poorly — generic name lists with no real depth, or large sites that mention the topic once in a listicle and move on.

The pattern I was looking for: specific intent, real search volume, weak existing results. Dog name queries fit this pattern well across hundreds of variations.

What "Weak Existing Results" Actually Means

This is worth being specific about, because "low competition" means different things depending on what you're building.

For a content site targeting informational queries, weak existing results means:

The top results are generic pages that don't specifically address the query
Large domain authority sites are ranking but with thin, unspecific content
No dedicated resource exists for this specific combination of topic and modifier

"Romanian dog names" is a good example. When I looked at this query, the top results were generic dog name lists that happened to mention Romanian names in passing, or articles about Romanian dog breeds with a name section appended. There was no page built specifically around Romanian dog names with real depth — cultural context, name meanings, male and female options.

That's the gap. Not "nobody is ranking" — there are always results — but "nobody has built the right page for this specific query."

Building for the Long Tail at Scale

The insight that made iDogNames work as a project rather than a single article is that the long tail of naming queries is consistent in structure.

Almost every naming query follows a pattern: [modifier] + dog names. The modifier can be a breed, an origin country, a color, a meaning, a theme, a holiday, a cultural reference. If you can build a system that generates good pages for each modifier, you can cover the long tail systematically rather than one article at a time.

This changes the economics of the project. Instead of writing 500 individual articles, you build a database and a page template that serves queries well across all the variations. The content work shifts from writing to data curation — which, as a developer, is a much more tractable problem.

What the Traffic Data Actually Shows

The queries that perform best on iDogNames are consistently the specific ones, not the broad ones.

Pages targeting breed-specific queries ("Black Mouth Cur dog names", "Presa Canario dog names") perform well because the intent is very specific — someone just got this breed of dog and wants names that fit. Generic name lists don't serve them as well as a dedicated page.

Cultural and origin queries ("Amish dog names", "Serbian dog names", "Swahili dog names") perform well for the same reason — the searcher has a specific context in mind and wants names that fit that context.

Meaning-based queries ("dog names that mean shadow", "dog names that mean light") perform well because the searcher is approaching the problem from a values or aesthetics perspective and existing results rarely address this directly.

The broad queries — "dog names", "cute dog names" — drive less of the traffic than you might expect. The long tail collectively outperforms the head terms, which is exactly what keyword research predicted.

The Transferable Lesson

The specific niche doesn't matter much. What matters is the pattern:

Find a category with consistent, specific demand across many query variations
Look for gaps where specific intent is being served by generic content
Build a system that covers the long tail at scale rather than targeting individual terms
Let the data tell you which variations are worth prioritizing

I've applied the same thinking to iCatNames.com and 9BabyNames.com since building iDogNames. The pattern holds — naming queries in general have a long tail that rewards systematic coverage over individual article targeting.

For solo developers looking for content site opportunities, naming niches are worth considering specifically because the query structure is so consistent. The work is in the data curation and the page quality, not in finding angles — the search data tells you exactly what people are looking for.

I build browser games and niche content sites. The games are at PhyFun.com. If you have questions about the keyword research process or the technical side of building iDogNames, happy to discuss in the comments.

Why the Best Educational Games Teach Better Than Textbooks

Marvin Tang — Sun, 12 Apr 2026 12:19:27 +0000

I've been building browser games for a while. Physics puzzlers,
sorting games, two-player games — the usual indie developer
portfolio.

But when I built LumiGameLab, I had
to think seriously about a question I'd never considered before:
what actually makes a game educational?

The Wrong Answer

The wrong answer is: a game is educational if it covers an
academic subject.

This definition fails immediately when you play the games. A
game can involve math and teach nothing. A game can look like
pure entertainment and quietly build genuine skills. Subject
matter and educational value are not the same thing.

The Right Answer

The right answer, I think, is this: a game is educational when
the learning is embedded in the mechanic — not bolted on top of
it as a reward for playing.

In a bad educational game, learning is the tax you pay to access
the fun part. Answer this question correctly and you get to play
the game. The educational content and the gameplay are separate
layers that don't reinforce each other.

In a good educational game, learning is the gameplay. You solve
equations because the game requires it. You learn country
locations by placing them on a map under time pressure. You
develop intuitions about gravity and momentum because those
principles determine whether you win or lose.

The difference between these two approaches is the difference
between a game that feels like homework and a game you'd play
even if it weren't educational.

Why This Matters for Game Developers

If you're building educational games, this distinction has real
design implications.

Design the mechanic around the learning objective, not the
other way around. If you're building a math game, the math
should be the core loop — not a mini-game attached to an
unrelated action game. Every design decision should ask: does
this reinforce what I want players to learn?

Difficulty and curriculum should scale together. The best
educational games are hard in the right way. Early levels build
understanding. Later levels test mastery. The progression should
mirror how people actually learn, not just how games usually
ramp up challenge.

Feedback should be informative, not just corrective. Telling
a player they got something wrong isn't enough. The feedback loop
should help them understand why — which is harder to design than
it sounds.

Engagement is a feature, not a compromise. Some people treat
engagement and educational rigor as opposing forces — like making
a game fun necessarily dilutes its educational value. I think
this is backwards. Engagement is the precondition for learning.
A game that bores players teaches nothing, regardless of how
educationally rigorous its content is.

What I Found Building LumiGameLab

When I started curating games for LumiGameLab, I played a lot
of games that claimed to be educational. Most of them failed the
basic test: you could skip the educational element and still play
the game. The learning was optional.

The games that passed were the ones where the learning was
unavoidable — where you couldn't progress without actually
understanding the concept the game was built around.

Those games also tended to be the most fun. Not despite being
educational, but because of it. When the challenge is genuine and
the feedback is immediate, the satisfaction of getting it right
is real.

That's what I try to capture with LumiGameLab. Not games that
are educational in spite of being games, but games that are
better games because of their educational design.

If you're building in this space, I'd love to hear what design
patterns you've found that make educational mechanics work. Drop
a comment below.

LumiGameLab is a free educational browser game platform. No
account, no download, no paywalls. Find it at
lumigamelab.com.

How I Built a Free Educational Games Website from Scratch

Marvin Tang — Fri, 10 Apr 2026 08:46:25 +0000

I've been building free browser game sites for a while now. Physics games, sorting games, two-player games — each one started with a specific idea and a gap I noticed in the market.

LumiGameLab was different. This one started with a question I kept coming back to: why is it so hard to find a good free educational games site?

The Problem I Kept Running Into

There are thousands of free browser game sites on the internet. Most of them follow the same formula — action games, casual games, multiplayer games. Fun, addictive, designed to keep players coming back.

But educational games? The ones that actually teach something — physics simulations, math challenges, logic puzzles, geography games — were scattered everywhere. Buried under ads. Hard to trust. No single destination where a parent, a teacher, or a curious kid could go and say: everything here is worth playing, and everything here will teach you something.

That gap is what LumiGameLab is trying to fill.

Why Educational Games Are Underserved

I think the reason educational game sites are rare comes down to a few things.

First, educational games are harder to curate. You can't just collect any fun game — you need games with genuine learning value. That's a higher bar, and most aggregator sites don't want to deal with it.

Second, the audience is different. Parents and teachers have much higher standards for what they'll recommend to kids than casual gamers have for what they'll play themselves. A site full of ads and questionable content is a non-starter. Trust matters.

Third, the best educational games don't always look educational. A physics puzzle game doesn't announce itself as a lesson in Newton's laws. A geography challenge doesn't feel like homework. The educational value is embedded in the gameplay — and curating for that requires actually playing the games, not just listing them.

What I Built

LumiGameLab is a free educational game platform covering ten subject areas: Math, Puzzle and Logic, Language Arts, Science and Space, Geography, Physics, Memory, Trivia and Quiz, Art and Creativity, and Simulation.

Math is the largest category with 28 games — not drill exercises, but games where math is the actual mechanic. You solve equations to survive, use multiplication to advance, and apply logic to win.

The physics games are some of my personal favorites. There's something uniquely satisfying about a game that lets you experiment with real physical principles — momentum, balance, gravity — and see the consequences in real time. It's the kind of intuitive understanding that sticks.

Geography games bring the world to life in ways static maps never could. Flag quizzes, country placement challenges, capital city games — they turn geography from memorization into exploration.

The puzzle and logic section is for anyone who wants to feel genuinely challenged. These are the games you think about when you're not playing.

Technical Decisions

The site is built with PHP, which I've used across most of my web projects. Nothing exotic — clean URLs, fast page loads, mobile-friendly layout, minimal JavaScript.

The main technical challenge was the curation and tagging system. Every game on LumiGameLab is tagged by subject category, topic, age range, and learning focus. Building a flexible tagging system that could handle multiple overlapping categories without becoming a mess took some iteration.

Search and filtering were also important. A parent looking for math games for a 7-year-old has very different needs from a teacher looking for geography games for a high school class. The filtering system needed to handle that range without becoming complicated to use.

The Design Philosophy

Two principles guided every decision:

Everything is free. No subscriptions, no paywalls, no premium tiers. Educational resources should be accessible. Not every family can afford an app subscription. Not every school has a licensed software budget. Free isn't a business model compromise — it's the whole point.

Quality over quantity. I'd rather have 100 games that are genuinely good than 1,000 games that happen to mention a subject somewhere in the description. Every game on the site has been reviewed for actual educational value, not just tagged and listed.

What I've Learned So Far

Building a niche site with a clear educational focus attracts a different kind of visitor than a general game aggregator. The bounce rate is lower. Session time is longer. People are coming with a purpose — a parent looking for something specific for their child, a teacher hunting for a classroom resource, a student who actually wants to learn something.

That's a more valuable audience to build for, even if it's a smaller one.

The other thing I've learned: trust takes time to build, but it compounds. A site that consistently delivers quality recommendations builds a reputation that general aggregators can't easily replicate.

What's Next

LumiGameLab is live now at lumigamelab.com. The current version has games across ten subjects, with new games added regularly.

Upcoming work includes better age-range filtering, teacher resource guides alongside game listings, and expanding the Science and Space category which currently has the fewest games.

If you're building something in the educational space — games, tools, resources — I'd love to hear what you're working on. Drop a comment below.

I build and maintain a small network of free browser-based sites. If you're interested in niche site building, indie game development, or browser-based gaming, follow along.

Why I Built a Separate Website Just for Sorting Games

Marvin Tang — Tue, 31 Mar 2026 13:39:40 +0000

When I added the first water color sorting game to my main game portal, I did what most developers do: I tagged it, categorized it, and moved on.

Six months later I had a dozen sorting games on the site, a noticeable chunk of traffic coming specifically from sorting-related search queries, and a growing suspicion that I was underserving that audience by burying their content inside a general portal.

That suspicion became SortFun.

The SEO case for topical authority

Google's approach to ranking content has shifted significantly toward what SEOs call topical authority — the idea that a site which covers a specific subject comprehensively will outrank a site that covers the same subject shallowly, even if the larger site has more overall domain authority.

For a general game portal, this creates a structural problem. A site that covers action games, puzzle games, racing games, sports games, and sorting games is authoritative about none of them. It's a generalist competing against specialists for every query it targets.
The math on this became clear when I looked at my search console data. My sorting game pages were getting impressions for queries like "water color sort game" and "ball sort puzzle online," but the click-through rates were lower than I expected. The pages were showing up, but something was making users choose a competitor's result instead.
Part of that was positioning. A page on a general portal that happens to have sorting games is a less convincing answer to "I want to play sorting games" than a site called SortFun where every single page is a sorting game.

Taxonomy as product decision

The more interesting engineering decision was how to categorize the games on the new site.

Traditional game portals organize by genre: puzzle, action, strategy, casual. These categories map onto how games are made, not how players think about what they want to play. A player who wants to sort colored balls into tubes doesn't think "I want a puzzle game." They think "I want that satisfying sorting thing."

SortFun organizes by mechanic instead of genre. Water sorting. Ball sorting. Tile sliding. Color matching with a sorting constraint. Each category describes what you actually do, not what shelf it belongs on in a game store.

This distinction matters for SEO because search queries reflect player intent, and player intent is usually mechanic-based. "Water sort puzzle" gets searched. "Casual puzzle game" gets searched less specifically. Building the taxonomy around mechanics means the category pages naturally align with how players actually search.
The single codebase across multiple sites problem
Running multiple specialized sites from a solo developer position creates a maintenance question that's worth thinking through before you commit to the architecture.

My games are built in Cocos Creator. The web builds are static file bundles — HTML, JavaScript, assets — that I deploy to subdirectories on each site. There's no shared runtime dependency between sites, which means a change to the SortFun deployment doesn't affect PhyFun or 2 Player Fun.

The tradeoff is that site-level infrastructure changes — navigation updates, footer changes, sitemap regeneration — have to be applied to each site independently. For two or three sites this is manageable. At ten sites it would become a maintenance burden that outweighs the SEO benefits of separation.

My current threshold: a separate site is justified when the target keyword cluster is large enough to support 50+ unique pages, the mechanic focus is distinct enough that a general portal visitor would feel lost, and the domain name can match the primary keyword naturally. SortFun clears all three. A hypothetical site just for brick-breaker games probably doesn't.

What the data showed after launch

The topical authority hypothesis held up. Within a few months of launching SortFun as a standalone domain, the sorting game pages that had previously been buried on a general portal were ranking higher for their target queries than the equivalent pages on the main site, despite the main site having significantly more overall backlinks.
The click-through rate improved as well. A result from SortFun.com for a sorting game query is immediately legible — the domain name tells you exactly what you're going to get. A result from a general portal requires the user to evaluate whether that portal's version of the game is worth clicking over the other results. Specificity removes that friction.

The tradeoff you're actually making

Splitting content across multiple specialized sites is a bet that topical authority compounds faster than domain authority. For broad, competitive queries, that bet is probably wrong — you want all your link equity concentrated in one domain. For narrow, underserved query clusters, it can be right.

Sorting games is a narrow, underserved cluster. The queries are specific, the competition is thinner than in broader puzzle game categories, and players who want sorting games want a lot of sorting games — they're not one-and-done visitors.

The site is at sortfun.com if you want to see how the taxonomy ended up in practice.

How Keyword Research Led Me to Build a Niche Game Portal

Marvin Tang — Tue, 31 Mar 2026 13:32:49 +0000

Most people treat keyword research as an SEO task. I've come to think of it as a business model discovery tool.

The site that convinced me of this was 2playerfun.com. The keyword came first. The business followed.

What I was actually looking for

Ten years ago I was thinking about browser game portals as a category. The major players — Miniclip, Addicting Games, Newgrounds — were all pursuing the same strategy: maximum breadth, every genre, something for everyone. Their homepages were catalogues. Their category pages were catalogues of catalogues.

The SEO implication of that strategy is that you compete for everything and dominate nothing. A site that covers every genre will always rank below the threshold for any specific genre query, because specificity is exactly what it's trading away in exchange for breadth.

I started pulling keyword data for game-related search queries, looking for volume that wasn't being captured by a dedicated destination.

The keyword that stood out

"Two player games" had consistent monthly search volume. More importantly, when I looked at what was ranking for it, the results were generic portal pages — category tabs on large sites, not dedicated destinations built around that specific query.

The keyword had clear intent behind it: someone sitting with another person, looking for something to play together. That's a specific situation with a specific need. A site built entirely around that need would be more useful to that searcher than page 12 of a general portal's two-player category.

I looked at adjacent keywords to understand the full shape of the opportunity:
"games for two players" — similar volume, same intent
"2 player games unblocked" — significant volume, school audience
"two player games on one keyboard" — lower volume, high specificity
"games to play with friends on computer" — broader intent, overlapping audience

The cluster confirmed what the primary keyword suggested. There was a real, recurring search demand for exactly this kind of content, and no site was serving it as a primary focus.

What made the niche viable beyond search volume

Search volume tells you that demand exists. It doesn't tell you whether the demand is sustainable or whether you can actually serve it well.

Two-player local games had a property that made me confident the niche was worth building around: the use case is social. When someone searches for "two player games," they're almost always doing it with another person present. That social context creates return behavior. Players don't just bookmark a game — they bookmark a destination to come back to with whoever they play with. The retention mechanic is built into the situation.

The competitive landscape also mattered. At the time, no one had built a destination site specifically for this query cluster. The keyword had volume, clear intent, an underserved audience, and no direct competitor. That combination doesn't appear often.

How the keyword shaped the site architecture
Once I committed to the niche, the keyword research informed decisions that went well beyond SEO.

The site name came directly from the primary keyword: 2playerfun.com. Exact match domains have diminished in SEO value since the early days, but for a niche portal, having the keyword in the domain still serves as a clear signal to both users and search engines about what the site is.

The category structure followed the keyword cluster. Instead of organizing by genre — action, puzzle, sports — I organized around play patterns: games for two on one keyboard, games for two on one screen, competitive games, cooperative games. The taxonomy reflected how the audience was actually thinking about their need.

Every page title, meta description, and H1 was written with the primary and secondary keywords in mind. Not keyword stuffing — the content had to actually serve the user — but deliberate alignment between what people were searching for and what the pages delivered.

The broader lesson

The standard advice for niche sites is "find your niche." What that advice usually means in practice is: look at what you're interested in and find a corner of it that isn't overcrowded.

That's backwards. Start with the keyword data. Find queries with real volume and weak competition. Then ask whether you can build something genuinely useful for the person behind that search.

The niche doesn't come from your interests. It comes from the gap between what people are searching for and what currently exists to serve them.

Two player games was that gap. The keyword research found it. The site filled it.

2playerfun.com is live now if you want to see where that keyword research ended up.

Why I Renamed My Game from Star Guardian to Cosmic Summon

Marvin Tang — Tue, 31 Mar 2026 13:20:58 +0000

Naming a game is harder than building it. I learned this the expensive way.

Where Star Guardian came from

When I started designing the gacha tower defense game that would eventually become Cosmic Summon, I had a working title almost immediately: Star Guardian. It felt right. The game is set against a backdrop of real constellations, the heroes are cosmic-themed, and the enemies arrive in waves named after star patterns. Guardian captured the defensive nature of tower defense. Star captured the visual identity.

I built the entire game under that name. The internal project files are still called Star Guardian. The early design documents reference Star Guardian throughout. For months, that was the game.

The problem

When I went to submit to the App Store, I searched the name.
Star Guardian was taken. Not just taken — it was occupied by an established title with a significant player base. Apple's App Store has strict policies around names that are identical or confusingly similar to existing apps. Submitting under Star Guardian wasn't just a branding risk; it was a rejection waiting to happen.

This is a mistake I should have caught earlier. Checking name availability across the App Store, Google Play, and major trademark databases should be one of the first steps in any game project, not something you verify at submission time. I knew this. I skipped it anyway because the name felt so obviously mine that I didn't think to check.

Finding a new name

Renaming a game late in development is disorienting. The name you've been using becomes load-bearing — it's in your mental model of the project, in your marketing copy, in the visual identity you've been building. Changing it feels like changing something fundamental about what the game is.

The criteria I worked from: the new name had to reference the cosmic setting, had to be available across all major platforms, and had to be distinct enough that a player searching for it would find exactly one result.

I went through a long list. Cosmic Defender was taken. Star Sentinel was too generic. Constellation Wars felt like a different genre entirely.

Cosmic Summon worked. Cosmic kept the setting. Summon captured the gacha mechanic that sits at the center of the game loop — you summon heroes, you place them, you merge duplicates to evolve them into higher rarity tiers. The name describes what you do, not just where you do it. And it was available.

What the rename cost

The practical cost was less than I expected. The game's visual identity — constellation backdrops, cosmic hero designs, the color palette — didn't need to change. The marketing copy needed rewriting. The App Store listing, the game's landing page, the description on phyfun.com — all of it needed updating before submission.

The psychological cost was higher. There's a version of this game called Star Guardian that exists only in my project files, and it takes a conscious effort not to revert to that name when describing the game to people who knew the earlier name.

What the game actually is

Cosmic Summon is a gacha merge tower defense game. Players summon heroes using a gacha system, place them on the battlefield, and merge identical units to evolve them through 7 rarity tiers — from Spark up to the legendary Genesis rank. The game features 12 distinct heroes, 28 enemy types with unique abilities, and 50 waves set against real constellation backdrops from Aries to the Southern Cross.

The browser version is live now at phyfun.com. The iOS version is currently in App Store review.

The lesson

Check name availability before you fall in love with a name. Search the App Store, Google Play, the USPTO trademark database, and do a basic web search. Do this on day one of the project, not day one hundred.

The rename worked out. Cosmic Summon is a better descriptive name than Star Guardian was — it tells you more about the mechanics in two words. But I got lucky that the change was mostly cosmetic. If the name had been embedded in the game's UI, in level dialogue, in audio files, the cost would have been significantly higher.

Name your game last. Or at least hold it loosely until you've shipped.

Building Popverse: What I Learned Designing a Bubble Shooter with 500+ Levels

Marvin Tang — Tue, 31 Mar 2026 13:14:14 +0000

Bubble shooters are one of those genres that looks solved. Match three, clear the board, repeat. The core mechanic is so well-established that most developers treat it as a template rather than a design problem.

I didn't want to build a template. I wanted to build something that stayed interesting past level 50.

Why bubble shooters are harder to design than they look
The fundamental challenge with bubble shooters is entropy. Every level starts with a cluttered board and ends with an empty one. That's the whole game. Once players internalize the basic color-matching mechanic, the only way to maintain engagement is variety — and variety in a bubble shooter is surprisingly difficult to achieve without breaking the feel of the game.

The standard approach is to add obstacles. Frozen bubbles that need multiple hits. Stone bubbles that can't be destroyed by color matching. Walls that change the bounce angles. These work, but they're additive complexity — more things to remember, more exceptions to the core rule.

What I found more interesting was multiplicative complexity: elements that interact with each other to produce emergent outcomes the player didn't fully predict.

Designing 20 special bubble types

Popverse ships with 20 unique special bubble types. Getting to 20 required drawing a hard line between bubbles that added genuine strategic depth and bubbles that just added visual noise.

The ones that made the cut share a property: they change what the optimal move is, not just how hard the move is to execute.

Bomb bubbles are the clearest example. When a Bomb is on the board, the best move is rarely the most obvious color match — it's often to deliberately set up a chain that detonates the Bomb at the right moment. The presence of a single Bomb bubble reframes the entire board.

Rainbow bubbles work differently. They match any color, which sounds like a pure advantage, but they introduce a decision cost. When you have a Rainbow in your queue, every shot becomes a question: is this the right moment to use it, or should I save it? That friction is the design doing its job.

Lightning bubbles create chain reactions across rows. Portal bubbles teleport shots to unexpected positions. Healer bubbles restore frozen neighbors. Each type introduces a different kind of thinking rather than a different intensity of the same thinking.

The 500+ level problem

500 levels is a lot of content for a solo developer to produce. The practical solution is a level generation philosophy rather than designing each level individually from scratch.

I organized levels into clusters of roughly 15-20, each cluster built around a specific mechanic combination. One cluster focuses on portal bubble navigation. Another introduces Bomb timing under shot pressure. A third combines Frost and Lightning bubbles in ways that force the player to choose between clearing fast and clearing efficiently.

Within each cluster, the first few levels introduce the mechanic cleanly. The middle levels add secondary complications. The final levels remove the scaffolding and let the mechanic run at full difficulty.

This structure means designing 30 clusters rather than 500 individual levels — a much more manageable problem.

What the random puzzle mode taught me

Popverse includes a random puzzle generator alongside the main level progression. I added it as a secondary feature, expecting it to be used occasionally.

Players used it constantly.

The insight this gave me: a significant portion of bubble shooter players aren't trying to progress through a story. They want an infinite supply of fresh boards to solve. The level progression serves one type of player. The random mode serves another. Both are legitimate, and a game that only ships one of them is leaving half its potential audience underserved.

Technical decisions worth mentioning

Popverse is built with Cocos Creator targeting both browser and mobile from a single codebase. The physics of bubble shooting — arc trajectories, wall bounces, cluster detection — are all handled in TypeScript. Cluster detection in particular is worth getting right early: the algorithm that determines which bubbles to pop after a match affects how satisfying every single shot feels.

The browser version is live at phyfun.com. The iOS version is on the App Store.

If you're building a puzzle game with a large level count, the most useful thing I can tell you is this: design the system before you design the levels. The system generates the levels. The levels don't generate themselves.