Hitbox Configuration, Event Touch, Mobile Controls and Camera Follow

This update focuses on what players feel immediately: collisions that match the sprite, events that can react to each other, controls that work better on mobile, and camera movement that can be directed from the event system.

These changes are small on the surface, but they remove a lot of custom scripting from common RPG situations: traps, enemies, moving objects, cutscenes, and mobile-friendly playtests.

Configure Hitboxes More Precisely

Events and the player can now use custom hitbox dimensions instead of always relying on the default 32 x 32 collision area.

For events, the hitbox is configured per event page. This means the same event can change its collision size depending on its current state. A closed gate, an opened gate, a large boss, or a small collectible can each have a collision shape that fits the active page.

The editor keeps the workflow visual:

• enable the custom hitbox;
• adjust its width and height in RPGJS pixels;
• check the preview directly over the selected sprite;
• save the event page.

At runtime, Studio applies the value to RPGJS with setHitbox(width, height). When no custom value is set, the default RPGJS hitbox is kept.

There is also a Set Hitbox event block. Use it when the hitbox must change during a workflow, for example when an object expands, an enemy enters a different phase, or the player temporarily needs a smaller collision area.

Event Touch Workflows

Touch triggers are now more expressive. Studio can distinguish between:

• Player touch: the player touches an event.
• Event touch: an event touches another event.

This opens the door to gameplay that was previously awkward to model without custom code. A moving enemy can trigger contact logic, a projectile-like event can react when it reaches a target, or a moving obstacle can activate another event when they collide.

Internally, both cases use the onTouch trigger. Studio stores the touch target so the runtime knows whether the workflow is started by player contact or by event-to-event contact.

Better Mobile Support

Mobile play is now easier to test and share. The RPGJS client is configured with mobile support, so games can display mobile controls such as the joystick and action button when played on touch devices.

This matters for Studio projects because mobile support is not only about movement. It affects how fast you can validate the complete gameplay loop:

• walk around with a joystick;
• trigger actions with a touch button;
• test touch-based events on a phone or tablet;
• verify that collisions and camera behavior still feel right on a small screen.

Combined with the new hitbox tools, mobile testing becomes more reliable: the control surface, collision area, and event triggers can be tuned together.

Camera Follow Block

The new Camera Follow block gives event workflows direct control over what the camera follows.

The target can be:

• the player;
• the current event;
• another event on the map.

This is useful for cutscenes and guided moments. You can briefly follow an NPC, reveal a moving object, show where a door opened, then return the camera to the player.

The block also supports smooth movement options, including duration and easing. For quick transitions, the camera can switch instantly. For cinematic moments, it can move smoothly toward the target.

Why These Features Work Well Together

Each feature solves a different part of the same problem: making gameplay behavior match what the player sees.

Hitbox configuration makes collisions more accurate. Event touch lets moving entities react to each other. Mobile controls make those interactions testable on touch devices. Camera follow lets the event system guide attention when the scene needs it.

Together, they make RPGJS Studio projects easier to prototype, easier to test, and easier to polish without leaving the editor.