One day I started wondering what it would take to build an online game that felt a little like MapleStory. I was not trying to recreate a full MMORPG—just a colorful 2D world where people could choose a character, explore, fight monsters, and see other players moving beside them.
That idea became MapleFighters.io. I have rebuilt it more than once and learned far more from the difficult versions than from the easy ones.
What is MapleFighters.io?
MapleFighters.io is a small multiplayer game that runs in a web browser. There is nothing to install. You choose a character, enter the lobby, move through portals, fight monsters, and chat with other players.
It has only two maps and a focused set of features, but it includes the complete journey from pressing a movement key to another player seeing it on their screen. That small shared moment is what the whole project is built around.
The first playable version
The first version preserved in this repository was developed between 2017 and 2018. It began with basic communication between a Unity game and a server, then slowly became something recognizable.
Players could create an account, choose a character, run, jump, climb, use portals, chat, and travel between the maps. There was a minimap, an NPC, and eventually a blue snail that could move and react to the player.
It was rough, but it had a heartbeat.
It also revealed the problems hidden inside a multiplayer game. Movement had to feel immediate to one player while still looking believable to everyone else. The shared world had to understand collisions, monsters, and map changes without sending every tiny event to everyone.
By the time this version became v0.1.0, I had proved that the idea could work. I had also made the code complicated enough that adding more features was becoming painful.
So I started again.
Rebuilding what players could not see
For several years, much of the work happened below the surface.
I replaced large parts of the original server. The Box2D physics library helped track collisions and world interactions, while another system kept each player focused on what was nearby.
That second problem sounds minor, but it changed the way the whole game worked. Imagine a map divided into neighborhoods. When a player enters a neighborhood, the game tells them about nearby people and monsters. When they leave, those distant objects disappear from their view. Players no longer need updates about everything happening across the entire world.
The result was less wasted work and a rule I could explain in one sentence: players receive updates about what is near them.
This period taught me that progress is not always visible. Sometimes the game looks the same even though every future change has become easier.
Putting the game in a browser
The next big step was removing the installation process.
The game was still made in the same engine, but it could now open like a normal website. A small page handled loading and fullscreen controls while the game connected to the shared world in the background.
This created a new problem: every game update also had to become a new website build. Doing that by hand was slow and easy to get wrong, so I automated it. A change to the Unity project could produce a browser version, move the right files into the website, and prepare the next release.
Players never saw the automation, but it made every release repeatable. “Works on my computer” was no longer enough; the same process had to build the version everyone else would receive.
When the project became too big
By the v1.0.0 release in 2023, the project had become much more than a game and a server.
Login, character data, chat, and the game server list each had their own service. Several programming languages and databases were involved.
On paper, it looked like the architecture of a much larger online game. In practice, it was a lot of machinery for two maps and a blue snail.
Every service added another connection to configure, another release to coordinate, and more ongoing operational work—from bumping dependencies to managing production deployments.
The next version improved the game by deleting a large amount of it.
I removed the extra services, moved chat into the main game server, and let players start without the old account system. The project returned to two pieces: the website that delivers the game and the server that runs the shared world.
The lesson was clear: an architecture can be clever and still be the wrong size. Simple is better than complex, but achieving simplicity is rarely easy.
How the current game works
When someone opens MapleFighters.io, the browser loads the game and places their character in a map with the nearby players, monsters, NPCs, and portals.
Walking and jumping appear immediately, while the shared world keeps nearby players in sync. The same flow handles animations, attacks, speech bubbles, and objects entering or leaving view.
Behind the scenes, the server manages the maps, monsters, collisions, health, and portals. Restarting it resets the world and disconnects current players—a limitation that also keeps this cooperative learning project honest and approachable.
Learning that deployment is part of the game
Eventually, the project moved from my computer to a cloud server. Releases became mostly automatic, and an extra layer of protection filtered unwanted traffic before it reached the website.
Putting the game online brought a surprise: public servers attract unwanted attention almost immediately. The logs filled with bots searching for accidentally exposed secret files and other common mistakes. They were not targeting MapleFighters.io personally; they were checking every server they could find.
I limited which traffic could reach the server. It was a useful reminder that game development does not end when the game becomes playable. Loading, updates, hosting, and security are part of the experience too.
What I learned
None of the earlier versions was wasted. The first taught me how to create a playable loop. The rebuild taught me how to keep a shared world understandable. The oversized version taught me that more pieces do not automatically make a better game. Moving to the browser taught me that delivering a game is part of building it.
The project is still small, and that is now one of its strengths. One person can follow the journey from a key press, through the shared world, and onto another player's screen.
MapleFighters.io is not a miniature commercial MMORPG. It is a playable record of learning how online games are made—and of learning when to build more, when to rebuild, and when to let go.