Topic: Blueprint for the Mabinogi Mobile Camera System: Designing a 3D Game Camera System Reimplemented on a Proprietary Component System

Speaker: Jeong Chan-woo - Deputy Team Lead, devCAT

Field: Programming

Recommended Audience: Junior Game Client Programmers

Tags: #Programming #Camera #SystemDesign

[🚨 Presentation Topic] This session covers the development of a proprietary camera system built from scratch to suit the project's unique component system and detailed directorial needs, without relying on Unity's 'Cinemachine.' The presentation shares the workflow of breaking down camera roles into parameters, modifiers, behaviors, and directors, as well as know-how on implementing custom camera-transform-based post-effects, such as camera shake sample correction and timeline-integrated direction.

For gamers, the 'camera' (perspective) is just as important as the controls for a comfortable gameplay experience. If the camera fails to capture the player's desired view or misses key scenes, it can hinder immersion. Jeong Chan-woo, the deputy team lead who designed the Mabinogi Mobile camera system, emphasized the importance of the camera and explained that they designed a proprietary system instead of using Unity's 'Cinemachine' to provide a camera experience optimized for the game.

The Reason 'Mabinogi Mobile' Adopted a Custom Camera

Jeong began by noting that while using Cinemachine is standard for most Unity projects, Mabinogi Mobile chose a different path. He cited two main reasons: first, Mabinogi Mobile uses its own proprietary component system; second, using Cinemachine would impose a rigid framework, increasing both the workload and complexity. Jeong added that attempting to integrate Mabinogi Mobile's custom components with Cinemachine would have required a complex 'bridge layer,' creating a risk of exponential increases in development volume and complexity.

Consequently, the Mabinogi Mobile team decided to design a camera system tailored to the game, as the camera is not a one-off feature but a core element that requires frequent tuning and maintenance.

Jeong explained that a camera system requires clear intent and detail—not just "making it look good automatically," but defining "how the camera should react and stop when moving at a certain angle X seconds after the last manual input." He noted that they designed their own system to maintain full control over the camera and fine-tune the feel of the gameplay.

How the Custom Camera System Was Developed.

Jeong highlighted key aspects of the development process: 'parameter decomposition and intuitiveness,' 'design of modifiers and behaviors,' 'the role of the director system,' and 'editor development for rapid iteration.'

First, by decomposing parameters and ensuring intuitiveness, they avoided handling the camera's final position and transform as raw data, instead breaking them down into intuitive variables (CameraRigProperty) such as distance from the target, angle, and offset. This made calculating smooth transitions (blending) between cameras much easier.

Modifiers—the smallest units handling single functions like rotation, terrain collision detection, and two-shots—were forced into static classes with no internal state to ensure they could be reused anywhere. Behaviors were then designed to structure these modifiers to handle specific situations.

The Director, acting as the final coordinator, selects the highest-priority camera based on the current game state and applies smoothing to prevent jitter, ensuring seamless transitions even when target values change abruptly.

He mentioned that "camera tuning is a series of repetitive tasks where you change one variable and check the feel." To eliminate the waste of restarting the game during development, they built a custom editor that applies values in real-time. By incorporating descriptive sentences from design documents—such as "lock target Y-axis for X seconds"—directly into the editor UI, they reduced communication errors between designers and programmers and enabled intuitive tuning.

He also explained how they overcame rendering issues caused by fundamental differences in matrix standards between Unity and Mabinogi Mobile's C# code. They unified all internal calculations based on C# and only converted to Unity standards just before passing data to the engine. As a tip, he shared that they actively adopted visual debugging, displaying gizmos and graphs directly on the screen to track value anomalies, which significantly boosted development speed.

Challenges Overcome and Benefits of the Custom Camera

Finally, Jeong discussed the challenges overcome and the benefits gained during the development of the custom camera.

The biggest example was overcoming frame drops during camera shake. They used a sine wave vibration method for impact, but found that if the frame rate dropped due to device specs, the peak of the vibration would be missed, leading to weak or lopsided shaking. Because they owned the system, they were able to embed logic to force-correct sampling positions and invert vibration directions, ensuring a heavy and consistent sense of impact in any environment.

He also mentioned applying offset projection without clipping, which perfectly prevented the camera from clipping into the ground or passing through walls. By integrating the timeline effect, they allowed designers to input and edit values directly into skill timelines, building a pipeline that produces diverse visual effects without requiring programmer intervention.

In conclusion, he emphasized that developing this proprietary camera system prevented the risk of spaghetti code and provided a solid foundation for realizing the designers' intent 100% within the game. He ended the presentation by stating that if a game is as tightly coupled with its camera as Mabinogi Mobile and requires fine-tuned adjustments, building a custom camera system is an excellent option well worth the investment.