Hollow’s Resolve is an open-world RPG prototype developed as my Game Design & Development Final Project. The goal is to build the kind of RPG foundation where dialogue, spawned characters, and combat interactions can all happen in the same living world without every scene needing a pile of one-off fixes.

Most of the work so far has been on the systems underneath the game. I have been focusing on the parts that players only notice when they break: conversations that start with the right character in the right place, cameras that frame faces instead of empty actor origins, and fights that do not turn into endless no-damage punching matches.

Dynamic Dialogue Runtime

One of the main systems is a dialogue path that can spawn missing speakers on demand. If a conversation references an NPC that is not currently in the world, the game can create that actor at the authored dialogue transform, track that it was spawned for the conversation, and clean it up afterward.

That matters for an open-world RPG because dialogue should not depend on every possible participant already being hand-placed in the level. Some characters can exist because the scene needs them, while others can be resolved from the story data at runtime. The system keeps that flexible without leaving temporary actors behind.

The tricky part was timing. The actor can exist before its final visible character has finished applying meshes, appearance data, sockets, and bone transforms. If the conversation camera asks for a head position too early, it can frame the wrong spot even though the NPC technically exists.

Camera And Visual Readiness

The current dialogue implementation handles that by gating the first spoken line. Before the first camera shot begins, it checks every speaker avatar that needs a visual character. If a visual is not ready, the dialogue waits briefly, listens for the visual-ready signal when available, and also polls on a short retry interval as a fallback.

The wait is intentionally bounded. A broken character setup should not freeze the entire conversation, so the system has a maximum wait time and then continues with a fallback. Once the visual reports ready, it still waits a small number of settle frames, because “the mesh exists” and “the world-space head transform is stable” are not always the same moment.

The head targeting code also avoids a common shortcut that caused problems earlier: using the actor eye point and only correcting height. For these characters, the visible body can live on a separate visual actor, so the full head location has to come from the actual mesh the player sees. When that lookup succeeds, the dialogue stores a local head offset so later camera calls can keep using a reasonable value even if the actor moves.

The resulting flow is:

• find or spawn the speaker actor,
• wait for the visible character to initialize,
• wait a couple of frames for transforms to settle,
• resolve the configured head socket or bone,
• cache the local head offset for stable fallback behavior,
• clean up spawned conversation-only speakers when the dialogue ends.

Combat Reliability

Combat has had a similar theme. When characters are built from custom visual pieces, it is easy for hit detection or damage ownership to point at the wrong thing. A punch might hit the visible mesh but fail to resolve to the character that should take damage. A faction rule might quietly cancel damage that looked valid on screen.

Recent work has been about making those relationships explicit: the visible character, the owning actor, the collision setup, the damage target, and the rules that decide whether an attack should count. It is not glamorous, but it is the kind of plumbing an RPG needs before content can scale.

The combat side has a few separate failure modes that all look the same to the player: two characters swing forever and nobody takes damage. The hit can land on a visual mesh that is not connected back to the owning character. The mesh can have the wrong collision response. The attack can resolve to the correct character but then be canceled by faction rules. Or the damage path can be valid, but the ability state on one side is not initialized yet.

The important design lesson is that combat should not assume the actor hit by a trace is automatically the gameplay target. Hollow’s Resolve needs a clear chain from visible mesh to owning character to damage receiver to faction decision. Once that chain is explicit, the game can support more flexible character construction without making every combat interaction fragile.

Open-World Implications

These systems are small in isolation, but they are the kind of small systems that decide whether a larger RPG is maintainable. A handcrafted scene can tolerate hacks. An open-world game cannot. Characters may be spawned, streamed, customized, moved, despawned, or reused by different quests, and the surrounding systems still need to agree on who they are.

That is the direction we are taking with Hollow’s Resolve: build the runtime rules before piling on content. Dialogue should be able to ask for a speaker and get a real character. Cameras should target the character the player sees. Combat should route through the actual gameplay owner, not whichever component happened to be hit first.