Mapping Workflow

Goal

We needed a workflow that enabled us to create new beatmaps quickly and consistently. These were our requirements:

• Allows manual placement of notes and platforms
• No code changes when shipping new songs
• Compatible with the MSW engine's limitations
• Simple to learn and easy to iterate/playtest on

Since the game was meant to be live-service, every new beatmap needed to be added directly into existing systems without requiring any new gameplay code.

Engine Constraints

The largest challenge wasn't gameplay design, it was the MSW engine itself. Being the first rhythm game on the platform meant we had innovate from scratch to solve our problems.

• Data Restrictions
  • MSW only supported CSV tables as structured gameplay data. This meant we couldn't use custom serialized formats for note charts commonly used in rhythm games.
• No Editor Tooling
  • The engine provided no custom editor APIs or tooling framework. Unlike engines such as Unity or Unreal, we could not build custom inspectors, timeline tools, or level editors directly inside the engine.
• Limited Audio APIs
  • Most importantly, MSW lacked the audio sampling functions necessary for frame-perfect rhythm gameplay. Without access to precise audio timing, traditional rhythm gameplay became unreliable and difficult to synchronize accurately.

Iterating the Core Gameplay

Our original vision was a traditional rhythm game, where gameplay relied on precise timing with "okay", "good", and "perfect" scoring based on player timing. However, after being shot down by our engineering supervisor for the engine lacking audio sampling, we had to pivot to a new direction: Rhythm-Inspired Combat.
Instead of requiring perfect musical precision, we redesigned gameplay to be combat-driven, but rhythm-influenced. Enemy notes were either hit or miss with little dependence on framerate. This preserved the feel of synchronized action to Maplestory classics while reducing reliance on frame-perfect audio precision. The pivot ultimately made the project feasible while keeping the identity of our original concept.

Building the Beatmap Workflow

Even after redesigning gameplay, we still needed an efficient way to create beatmaps. Instead of building an editor from scratch, I leveraged an existing ecosystem: the osu! beatmap editor. Using the editor, we:

• Calibrated BPM and timing offsets
• Hand-timed gameplay notes
• Planned single-hit and hold-note sequences

This gave us an easy editing experience without needing to build internal tooling. I then wrote a custom Python script that extracted our osu! beatmap data and transformed it into an MSW-compatible CSV format. The parser extracted:

• Note type
  • 0 - Single tap note
  • 1 - Hold start note
  • 2 - Hold end note
• Millisecond timing values
• Ordered note data for runtime playback

Converting Data Into Gameplay

Once imported into MSW, beatmap data existed only as timing values inside a CSV table. The next challenge was turning those values into physical gameplay objects.
I created a BeatmapManager system that loaded beatmap CSV tables and interpreted note timing data at runtime. However, timing alone wasn't enough since gameplay also required actual note objects positioned in the world along with platforms.

MSW handled scene editing poorly and made mass object creation difficult. Every beatmap required the exact number of scene objects matching the note count and manually creating and naming hundreds of objects was not scalable.
Because MSW map (scene) files were editable JSON files, I wrote another Python script that:

• Spawned the correct number of note objects
• Instantiated prefab references automatically
• Named objects sequentially
• Preserved ordering for BeatmapManager parsing

To minimize timing drift, I based note behavior on absolute millisecond timestamps. Instead of calculating timing relative to the previous note, the system compared the current song timer with absolute note timestamp. This prevented timing accumulation errors and reduced frame-dependent inaccuracies.

Outcome

By combining external tools with custom scripts, I created a workflow that successfully worked around the limitations of the MSW engine. The final pipeline enabled:

• Fast beatmap creation
• No gameplay code changes for new songs
• Designer-friendly iteration
• Reliable note timing
• Supervisor approval after a major design pivot

Most importantly, the workflow transformed beatmap creation from a manual engineering task into a repeatable pipeline, making rhythm-combat gameplay feasible in an engine that was never designed for it. We ended up mapping 9 total beatmaps with this workflow within our 3-month development timeline, and I'm proud with how much we accomplished.

Anticheat

Goal

Maple Rhapsody featured leaderboards where submissions gave in-game currency, meaning score integrity mattered. Since rhythm games are highly vulnerable to cheating, I needed a system that protected leaderboard fairness while still keeping gameplay responsive. These were the requirements:

• Prevent obvious score manipulation and leaderboard exploits
• Maintain responsive, low-latency rhythm gameplay
• Work automatically for any beatmap without per-song logic
• Integrate with the limitations of the MSW engine

Since the game was intended for live-service content updates, anti-cheat protections also needed to apply automatically to newly added beatmaps.

Client vs Server Authority

The largest challenge was balancing game responsiveness with competitive trust. A fully client-authoritative system would feel responsive, but players could easily manipulate memory or modify packets to submit impossible scores. Cheated submitted scores would award in-game currency, completely ruining the game's monetization model.

However, making gameplay fully server-authoritative was also unrealistic. Rhythm gameplay depends on immediate hit feedback, audio synchronization, and responsive controls with minimal latency. Waiting on server validation for every note would make gameplay feel delayed and inconsistent.

I needed to compromise between the two and design a hybrid authority model where it was client-authoritative for gameplay feel and server-authoritative for outcomes/rewards.

Solution

Rather than trusting a final score from the client, I moved score validation entirely to the server.

The client handles:

• Beatmap playback
• Audio timing
• Note visuals and responsiveness

The server handles:

• Validating note submissions
• Verifying beatmap progression
• Preventing duplicate or impossible hits
• Recalculating the final score before leaderboard submission

This prevented obvious cheats like:

• Memory-edited scores
• Fake note submissions
• Duplicate hit registration
• Invalid beatmap progression

Because the server loaded the same beatmap dataset independently, the system worked generically across all songs without additional code changes.

Outcome

The final system successfully protected against the types of cheating most likely for the scale of the game.

Cheating is still possible with this setup though. A determined player with exact beatmap timings could still create scripts or hotkeys to automate perfectly timed note inputs. Solving that problem would either not be possible on the MSW platform or require significantly more aggressive detection methods.
For Maple Rhapsody's target audience, a casual, mobile-focused playerbase, this tradeoff made sense. The goal was not enterprise-level anti-cheat, but rather to deter blatant cheating and preserve leaderboard integrity without hurting gameplay feel.

Reflection

This was my first commercial multiplayer game where I had to implement monetization systems, and my first time working on a live service title with ongoing content constraints. It was also my first time working in the Maplestory Worlds (MSW) engine, which introduced several limitations that required new approaches to common gameplay and tooling problems.

Because of this, I learned a significant amount in a short time, especially around building systems that support long-term content and live updates. I also worked under strict deadlines from workshop supervisors while still shipping a full game with multiple systems, including gameplay, monetization, leaderboards, and mapping tools. Midway through development, I had to fully pivot core design direction due to engine limitations, but still delivered the project on time.

Looking back, this project pushed me more than any previous work and fundamentally shaped how I think about building games under real constraints. I'm grateful to Daquan Griffith, my team partner for bringing me onto this project, and supervisors for their guidance and support throughout the process.