The project described here aims to transform the standard turn-based combat in RPG Maker MZ into a more cinematic, action-oriented experience using MZ3D. The prototype, named hsrBattleSystem_mz3d.js, replaces the default battle scene with a custom scene where units occupy a 3D or 2.5D arena derived from the project map. The system already shows a side turn order line driven by unit speed, places characters and enemies on the map, and provides an interface with portraits, HP/MP, energy, and skill points. The goal is not only to change the UI but to make the map itself a functional battlefield where movement, camera work, and animations matter.
This write-up summarizes what works now and asks for targeted suggestions on camera layout, positioning, UI scaling, plugin modularity, and compatibility with 3D models. Current controls and mechanics are rudimentary but functional: basic attack is mapped to Q and restores skill points, skill is mapped to E and costs skill points, and skill points begin at 3 and cap at 5. Custom icons can be assigned through actor notes using tags like <strong></strong>, and images are loaded from img/hsrbattlesystem/. Specific configuration markers are supported as map event tags, for example <hsrbattle = ‘actor_1’> through <hsrbattle = ‘actor_4’> and <hsrbattle_enemy = ‘enemy ID’>.
Design goals and priorities
The central design intent is to build a foundation for a dynamic combat experience: a speed-based timeline where each unit acts according to their stats, the camera centers on the acting unit, and characters visually orient toward targets. That implies three important constraints: camera stability so players can maintain spatial awareness, clear visual feedback for action readiness, and a UI that surfaces the most relevant information without blocking the 3D arena. Emphasize readability in the interface and preserve the possibility of swapping 2D sprites for 3D models when MZ3D is configured. Future expansions envision animated skill effects, movement-based attacks, ultimates, and target-selection visuals that take advantage of the map geometry rather than overlays.
Camera placement and movement
For camera setup, consider a hybrid approach: a default wide-angle orbit that keeps the whole arena legible, with a dynamic short zoom to the active actor for cinematic emphasis. Implement the camera as a separate manager class so it can interpolate smoothly between positions and follow rules like focus priority and collision avoidance with geometry. Use easing curves when changing views and allow a stabilized fallback when many rapid turns occur. A camera manager also makes it easier to support optional features like portrait cut-ins or cinematic camera shakes for ultimate moves while preserving the player’s sense of location on the map.
Positioning, markers, and map integration
Two main strategies exist for positioning: rely on map events as physical anchors or configure battle slots through plugin parameters. Map events provide intuitive visual editing in the editor and make the arena editable by designers, while plugin parameters are better for programmatic or procedurally generated positions. A hybrid model often works best: use map events as default markers for designers and allow parameter overrides for encounters that need deterministic placement. Keep marker tags readable and exported as entities when displaying them in documentation; for example <hsrbattle = ‘actor_1’> and <hsrbattle_enemy = ‘enemy ID’> are useful to store on event notes.
Compatibility with MZ3D models
To improve compatibility with MZ3D 3D models, abstract your rendering and animation layer so the battle logic talks to an interface rather than directly to sprites or models. Define a small render adapter API that supports actions like face target, play animation, and move to position. This allows the same battle system to operate with 2D sprites, 2.5D billboards, or full 3D rigs without touching core logic. Also, load model assets asynchronously and provide fallbacks to 2D graphics when models fail to load or MZ3D is not present.
UI, balancing timeline, and custom skills
Design the UI to be modular and resolution independent: build components in relative screen space, use scalable vector-like assets where possible, and allow toggles for compact layouts. Present a compact timeline and a larger info panel that can be hidden. For balancing the speed-based timeline, introduce action cooldowns or diminishing returns for consecutive turns, and cap maximum consecutive actions with a simple energy drain mechanic to prevent runaway loops. Another option is to weight initiative ticks so high-speed units act more frequently but not infinitely by implementing recovery windows.
Creating custom skills with minimal conflicts
For custom skills, avoid overloading the RPG Maker database. Instead, maintain an external skill registry inside the plugin where each custom skill has a unique identifier and a behavior script or data-driven rule set. Provide hooks to reference these skills from database entries, but keep execution isolated in the plugin to prevent clashes. Use clear namespacing and document note-tag structures such as <hsrbattle_attack = ‘image’> and <hsrbattle_expertise = ‘image’> so designers can attach icons and properties without editing core files.
In summary, the prototype already performs core functions like custom battle scenes, map-based placement, a speed-driven order line, camera focus on active units, and basic input mappings. The next steps are polishing camera logic, refining UI scaling, hardening MZ3D model support, and defining a clean skill architecture. Feedback on camera strategies, marker workflows, UI layouts for multiple resolutions, and timeline balancing techniques is welcome to guide the next iteration of hsrBattleSystem_mz3d.js.