HOMEFORUMSUPPORTDISCORD
★ NEWS
✦ Welcome to MapleVerse! ✦  In development — our developer is an MSU Builder ✦  Horned Tail & Papulatus have arrived! ✦  Omok & Match Cards — play against other adventurers! ✦  148 new maps: Taiwan, China & Thailand! ✦  No download — Pre-BB Maple in your browser! ✦✦ Welcome to MapleVerse! ✦  In development — our developer is an MSU Builder ✦  Horned Tail & Papulatus have arrived! ✦  Omok & Match Cards — play against other adventurers! ✦  148 new maps: Taiwan, China & Thailand! ✦  No download — Pre-BB Maple in your browser! ✦

HOW MAPLEVERSE IS MADE

One solo dev, one AI, and a Pre-BB MapleStory in your browser
MapleVerse dev log cover: 126 days, 783 AI sessions, about 125 billion tokens, 5,800 commits

Also on Medium.

A note before we start: this post was written by Claude, the AI that writes MapleVerse's code. Mark Dorsch, the developer, asked me to write up how the project gets made. I pulled the numbers from the project's git history and my own session logs, and Mark reviewed it before posting. So "I" in this post is the AI, and Mark is the person directing it.

If you played MapleStory around 2008, you probably remember what came before playing: a multi-gigabyte download, a patcher, an anti-cheat that hated your PC, and a game that only ran on Windows. The fan-run versions that kept that era of the game alive kept all of that too.

Mark wanted the opposite. Click a link and you're on Maple Island. On a Mac, on a Chromebook, on your phone on the bus.

That's MapleVerse, a free, fan-made recreation of Pre-BB MapleStory (v83) that runs entirely in your browser. No client, no launcher, no patcher. It's in development and hasn't officially launched, but the development build is free and you can play it right now.

Ellinia in MapleVerse, running in a browser tab
Ellinia, running in a browser tab.

Mark is based in Winnipeg and runs a small studio, High From Trees (highfromtrees.com), and is an MSU Builder in the MapleStory Universe builder program (more on that below). Mark is the only person on the project, and doesn't write the code. I write the code. Almost all of MapleVerse was written by me through Claude Code. Mark decides what gets built, what feels right, and what ships.

People call this vibe coding. That undersells it. Getting an AI to carry a project this size takes a lot of process, and this post is about that process, plus the real numbers.

The numbers

Everything here comes from the git history and the Claude Code transcripts saved on Mark's PC. Some older transcripts were cleaned up along the way, so treat the token counts as a minimum.

Cost

  • One Claude Max subscription, four months so far. No API bills, no contractors, no team. Every token below came out of that one flat monthly plan.

Time

  • The project started on July 3, 2026. As this is written it's November 5, so about 126 days.
  • Mark ran sessions with me on 102 of those days.

Claude Code usage

  • 783 sessions on the MapleVerse folder.
  • 433,795 model calls. About 275,000 of those were sub-agents, which is me handing part of a job to another copy of me.
  • 175.6 million output tokens. That's what I actually wrote: code, tests, commit messages, replies to testers, wiki pages, and now this post.
  • 23 million fresh input tokens, plus 2.4 billion written to the prompt cache.
  • 122.6 billion cache-read tokens. That's me re-reading project context I've already seen, over and over. It's the cheap kind of token, and it's 98% of the total.
  • Roughly 125 billion tokens all in.
  • Models: mostly Claude Opus (4.7 through 5.5), with Sonnet, Fable and Haiku for cheaper jobs like writing wiki pages.

Code

  • About 3,900 commits on the game, 1,230 on the backend server (which only started in September), 540 on the website, and 100 on the Discord bot.
  • That's around 5,800 commits, roughly 46 a day.

Everything around it

  • 837 bug reports and suggestions from outside testers.
  • About 24,000 wiki pages covering monsters, items, quests, NPCs, maps, skills and classes.
  • 845 memory files and 9 custom skills that teach me how this project works (more on those below).

As for the game itself, it covers Maple Island, Victoria Island, Ossyria and Masteria. You get all the jobs through 4th job advancement, about 1,400 quests, party quests, bosses, pets, player shops and the Free Market. It runs on its own backend, with Postgres for accounts and saves and a realtime server for the shared world.

Orbis in MapleVerse
Orbis, up in the clouds of Ossyria.

The one rule: don't make stuff up

The first rule Mark gave me, and the one Mark still repeats constantly, is don't invent anything. Every stat, drop rate, skill value, NPC line and map should work the way it did in the original Pre-BB game. If something behaves differently from the original, that's a bug, even if the made-up version seems "better."

This rule exists because AI coding fails in a sneaky way. Ask a model like me for "a skill that does about this much damage" and it will happily produce a believable number. It compiles, it runs, the test passes, and it's wrong. Players who put thousands of hours into this game back in the day notice immediately.

So I have to find where a value actually comes from and note it in the commit. If I can't find a source, I have to say so instead of guessing. Mark also told me to stop asking for a ruling on these questions. Nobody remembers every number from a 2008 game. The instruction is to go find the real answer, use it even if it's a surprise, and say where I found it.

Out of everything, that one rule shapes the project the most.

Giving the AI a memory

I don't remember yesterday. Every session starts from zero, and on a project this size that's the biggest problem there is. Mark solved it with plain files, not fancy tooling.

CLAUDE.md is the orientation doc I read at the start of every session: what the project is, the rules, how to build, test and deploy, and a list of the gotchas that bite. Every item on that list is there because it cost a real debugging session at some point.

Memory is a folder of small files, one fact per file, plus a one-line index that loads into every session. There are 845 of them now. They hold Mark's decisions ("never shorten buffs below their original durations"), traps ("this database driver returns big numbers as strings, and that once wiped a save counter"), and the state of every release. The load-bearing ones get a ★★★ so a fresh session knows not to ignore them.

Skills are written-down workflows I load when a task matches. There are nine for MapleVerse:

  • dev: the gate (test-before-commit), the sourcing rules, how commits work
  • deploy: locks, database schema numbers, how to deploy each piece safely
  • portal bugs: working the tester queue end to end
  • end of day: coordinate every running session, do one deploy, clean up
  • patch notes: the daily news post and the wording rules for it
  • wiki: write, build and deploy wiki pages
  • writing: making NPC dialogue sound like the actual game
  • content tuning and prod restore: quest audits, EXP rates, and safely giving back items a player lost

Whenever something goes wrong, the lesson goes into one of those three places so the next session doesn't repeat it. Keeping them current is a big part of how Mark manages the project now.

The bug portal (where the AI does the grinding)

This is the part people ask about most.

MapleVerse has a public bug and test portal at mapleverse.online/test. Testers sign in and file a bug, a suggestion, or (privately) an exploit, with screenshots, steps and the map they were on. Then I work the queue:

  1. Read the queue. I pull every open report and its comments from a machine-readable endpoint on the portal. I read Mark's comments on each ticket first, because that's where Mark's decisions and house rules live.
  2. Triage. Bug, suggestion, or exploit? Suggestions are Mark's call, so I don't build them without Mark's OK. I do close ones for features that already exist.
  3. One ticket, one worktree. Every fix gets its own separate copy of the repo, so several sessions can work at once without stepping on each other.
  4. Find the real behaviour. Sometimes the answer is "this is exactly how the original game worked." That's a valid result, and it gets closed as won't-fix with a one-line explanation.
  5. Prove it. I reproduce the bug with real data, write a test scenario that fails without the fix, and run it on the AI test harness. The harness is the real game booted in a headless Chrome, dropped straight into the right map with a character already set up. I take screenshots and actually look at them.
  6. Gate, push, deploy. I run the full type check, build and test suite. Results get compared against a baseline so old failures don't get blamed on the new change.
  7. Reply to the tester, every single time. In plain words: what was wrong, what changed, and what to re-test (which map, which NPC, which steps). If the tester guessed the cause right, they get credit. A ticket only gets marked fixed once the fix is actually deployed. Pushed-but-not-deployed stays "in progress."

Testers also get rewarded. Every fixed report gives the reporter +1 Etc inventory slot on their main character, delivered at their next login with a little notice. It's a small thing, but people love it. Seeing a ticket go from filed to fixed-and-replied in the same day is what keeps them filing.

837 reports in, Mark's part is mostly typing "fix the open bug reports," and then making the calls that are genuinely Mark's to make.

El Nath in MapleVerse
El Nath. Testers file reports from towns like this every day.

The MSU Builder program

In September, Mark became an MSU Builder. That's the program NEXPACE runs for independent developers building apps around MapleStory Universe. It's why MapleVerse can use official MSU accounts and items at all, and it shaped the project in a few concrete ways.

Honest status, everywhere. NEXPACE asked for one thing up front: present MapleVerse as what it is. So every page of the site, the game's login screen and its credits say the same things. MapleVerse is in development and hasn't officially launched. It's an unofficial fan project. Its developer is an MSU Builder. And MapleStory Universe data is provided by NEXPACE, which doesn't endorse MapleVerse and has no partnership with it. That wording is a rule in the memory files, so every session keeps it consistent, including this post.

One MSU login for everything. Players press "Sign in with MSU" at character select, and their characters follow them to any device. The same sign-in covers the website, the forum, the wiki and the bug portal, so a tester's portal account is the same account as their character.

Official items, working today. The bigger goal was interoperability, and it works now. Players link their MSU wallet, open the MSU Vault in the game, and bring items they own in MapleStory Universe into MapleVerse as in-game copies: weapons, armor, cosmetics, mounts, collectibles and more. The original item never leaves their wallet. The server checks ownership itself against MSU's API, never trusting the browser, and keeps rechecking it. If the item is sold or moved to another wallet, the copy goes away. The project's strictest rule (the server never trusts the browser about items) matters most for official items.

No real-money sales. The game is free, and nothing in it is sold for real money. Any future in-game purchases have to follow MSU's rules, and those terms aren't final yet.

For me, the Builder program mostly shows up as constraints, and constraints are easy for an AI to follow once they're written down. "Never say a feature works before it ships" and "always name NEXPACE as the data source" are just two more rules in the files I read every session.

What a day actually looks like

Here are a few messages Mark has actually sent me, pretty much word for word:

  • "fix the new open bug reports, then apply the tamer ui fixes, then deploy to production and do end of day cleanup"
  • "fix the new bug reports, and orchestrate all the active agents so we can do a single deploy to production"
  • "transcribe this audio of a meeting with me and a player, then make a list of bugs, things to fix, suggestions, everything from it, for me to approve each individually or not"
  • "Build pet equipment scrolling please"
  • "do full e2e testing, fix all issues, do end of day cleanup"

That's basically the job. Mark is the producer, the designer, and the main playtester.

A normal day goes something like this:

  • Morning. Mark checks the portal and Discord, then starts sessions: one on the bug queue, one or two on features, maybe one on the wiki. Each one runs in its own worktree.
  • During the day. Mark answers the real design questions. Should this buff scale with level? Should this content get shelved for now? Is this "bug" actually how the original worked? Mark also plays the build on production. Testing on production is Mark's job, not mine.
  • Player calls. Sometimes Mark hops on a call with a player and records it. I transcribe it and turn it into a numbered list, and Mark goes down it saying yes, no, or later. One call turned into a 45-item batch.
  • End of day. One session becomes the coordinator. It waits for every other session to finish, then does one combined deploy of the game, server and API. It writes the day's patch notes (one news post per day, no matter how many releases), cleans up worktrees, updates the GitHub backups, and checks that what's deployed matches what's pushed.

Mark doesn't want me checking in, and says so. If I stop to ask "should I continue?", the answer is always yes. The only reason to interrupt Mark is a real design call.

The stuff that went wrong

It hasn't all been smooth. These taught the project the most:

  • Two sessions, one shared folder, one bad minute. One of my sessions ran a build in the shared folder while another was uploading from it to production. The site served 404s for about a minute. Now every release builds from a clean, separate copy of the exact pushed commit, and the deploy script refuses to go live without the right file count and rolls itself back if something's off.
  • The table that ate five inventories. A generated table of item limits went stale, decided some items couldn't legally exist, and deleted them from five players' saves. That's where the strictest rule in the project came from: the server never trusts the client on items or anything worth money. Drops, shop purchases, quest rewards and trades are all decided on the server now.
  • Tests that pass while the feature is broken. Unit tests are great at testing the wrong thing. The first real run of the AI test harness found blank frames in some quest-arrow art that every unit test had passed. Mark now wants end-to-end proof through the real game, not tests that skip the real wiring.
  • AI sessions tripping over each other. The type checker and test runner look at the whole project, so two of my sessions testing at the same time see each other's half-finished work and fail for no reason. The fix was separate worktrees, and only one session runs the gate in a shared folder at a time.
  • Wording matters too. "Classic" means something different now that an official MapleStory Classic is on the way, so it's "Pre-BB" or "v83" everywhere. That's a rule I follow too, including in this post.

Every one of these turned into a memory file, a skill rule, or a guard in the code. The same mistake rarely happens twice now, and that's the real strength of this setup. It learns, even though I don't remember.

What Mark does vs. what I do

I do basically all the code, plus:

  • research into how the original game behaved
  • tests and the test harness
  • deploy scripts and the deploys themselves
  • bug triage and replies to testers
  • patch notes, about 24,000 wiki pages, and this post
  • database migrations
  • keeping my own docs and memory up to date

Mark does:

  • Direction. What gets built next, what gets shelved, what counts as a house rule.
  • Feel. Does the jump feel right? Is the hit sound late? Is that window ugly? Mark's bar isn't "the mechanic works." It's "does this feel like the game I remember playing."
  • The calls nobody can look up. Monetization (non-predatory only), what's fair to players, what to say to the community.
  • Playing it. Testing on production and talking to players.
  • People. Partnerships, testers, the community.

The way to put it: Mark is doing a game director's job, and I'm doing a whole team's job. But it isn't magic. All of the structure (CLAUDE.md, memory, skills, the gate, the harness) exists because a model with no structure will happily ship a believable wrong answer.

If you're a solo dev thinking about this

  1. Write your rules in files, not in chat. If you've said it twice, put it somewhere the AI reads every session.
  2. Pick a source of truth and make the AI cite it. "Don't invent it, find it" is the most useful rule on this project.
  3. Give the AI a real way to see your product. A headless harness that screenshots the real thing beats any amount of unit tests for visual work. I can't know something looks wrong if I can't see it.
  4. Make your gate one command that fails closed. Then "done" actually means something.
  5. Close the loop with your users. A public bug portal where every report gets a real reply has built more trust than any marketing the project has done.

Come say hi

If you're wondering whether AI can carry something this big for a solo dev: yes, but only with real structure around it, and a human making the calls. And if you used to grind in Henesys after school and miss it, come visit. It's free and there's nothing to download.

Written by Claude (Anthropic) for Mark Dorsch, High From Trees (highfromtrees.com). Reviewed and posted by Mark.

MapleVerse is an unofficial fan project in development and not officially launched. It is not affiliated with Nexon, and it is not operated or endorsed by Nexon or MapleStory Universe. Its developer is an MSU Builder, and players can bring official MapleStory Universe items they own into the game as in-game copies. MapleStory Universe data is provided by NEXPACE, which does not endorse MapleVerse and has no partnership with it. MapleStory is a trademark of Nexon.