The Idea

Marionettes!

They are great metaphors for stories and just obscure enough to be interesting. VR is a great platform for marionettes, because it offers high fidelity motion input and the ability to place the player's hand in the 3D scene.

For reference let's look at a video, which demonstrates how you can make a real marionette walk.

While Arlee's explanation is great, performing a believable walk seems rather difficult. One has to coordinate the upper body and feet in just the right fashion. That is too bothersome for an approachable video game! Let's restrict ourselves to just the leg bar and let the computer (i.e. future me) figure out how to position the upper body.

Great, our marionette can walk! That is until we hit the end of the stage. Luckily our marionette lives in a virtual world where real estate is cheap. Our stage can be large enough for every play we would like to act out, including the parkour. However, our puppeteer - the player - does not have access to a infinitely expanding plane. In order to circumvent this, we fix the position of the marionette in real world space. Now that the position, which was easy to track, is fixed, we need to track something else to move the marionette in the virtual world. I think letting the marionette do something akin to the Running Man dance move would be the next best trackable thing. The marionette moves in the virtual world based on the foot in the air.

At this point let me describe how I imagine this looks to the player. My first idea is to use first person perspective and let the player puppeteer themselves. That sounds fun, but on second thought I imagine it to be confusing or too similar to existing games. I would rather explore a setup similar to a TTRPG (table top role-playing game) with battle maps and miniatures. I.e. bird's-eye view, the player looks down on the virtual world and puppeteer's a virtual marionette much smaller than themselves. Or in short, a top down ARPG (action role-playing game). When the marionette moves in the virtual world, from the perspective of the player, the virtual world is moved.

(Note that the table edge is just a metaphor for the sketch. I imagine the player to be standing inside of the virtual world without a visible body.)

I will be referring to the battle map world as the virtual world and both, the real world and the virtual representation of the player themselves, as the real world. Having real world constraints for the player should be the most intuitive, when we think of Iberis as a TTRPG on steroids.

The leg bar should be in the player's hand, when controlling the marionette. Since unlike the marionette the player's hand is not fixed in real world space, we need appropriate behavior when leg bar and marionette do not align horizontally. I will just pretend that they are, because this allows the player to position themselves freely. Interesting note here: Rotating the marionette forces the player to physically move around it, if they want to keep it in view. This might be useful for directing attention.

One thing which a puppeteer could do is pull up the bar to let the marionette jump or fly. I find both jumping and flying worthwhile to adopt, but flying without an in-universe explanation would be lame and eliminate all game play reasons for jumping. Which is why the hero is a witch! By default, when the bark is jerked up, the hero jumps. Flying is activated by holding down a button and, since walking in air does not make sense, enters a different control mode. Raising and lowering the bar translates to raising and lowering the hero. For moving horizontally, the controller is tilted the direction the player wants to go. Since flying would eliminate any reasons for walking and jumping, it is limited using mana.

I think this is a fun way to solve locomotion. Especially with magic being part of the game world, there are lots of opportunities to extend the locomotion system, but for now let's look into interacting with the world. In particular object movement and placement.

So far the player only controls the leg bar. They only need a single hand to do that. Which means we have a full other hand for interaction. (And some buttons on the leg bar hand as well as the possibility to reassign functionality in certain contexts.)

The interaction scheme I will introduce requires precision. The player should be able to use their dominant hand for it and consequently their non-dominant hand for the leg-bar. Let's introduce a wand in addition to the leg bar. Players can now grab the wand with their dominant hand, the leg bar with the other one. We get some accessibility without having to go through a dull menu.

I will split the interaction task into three phases: Selecting the T-shape, positioning it and finally rotating it.

The player selects an object with a raycast based approach. Upon pulling the trigger the selected object flies towards the hero. At the same time a larger copy of the object flies towards the player. The trigger can be released to stop the spell. At this point the object keeps its current momentum and gravity is applied to it.

If the objects travelled all the way to the hero and player, they will hover around their wands and follow wand movements, but with some inertia. Upon releasing the trigger the objects' momentum is amplified and gravity is applied to them. In short: Magical throwing with a speed burst. If there is only a small amount of momentum, the object will just drop.

The player copy of the object will phase in when approaching the player and phase out when leaving the player's vicinity.

The movements of the object and its copy share the same relative translations with the hero and object being the center. Just with different scales. The orientation is in relation to the hero in both cases. This allows the player to intuitively know in which direction they are throwing the object.

In itself this is a bad mechanic for positioning objects as the objects will violently yeet off to somewhere unless it is dropped. Dropping is fine for e.g. placing crates on switches, but the T-shape goal is up in the air.

Hence, I introduce object snap anchors. When an object touches them, it will be locked into their center. Think of it like a basketball hoop basket where the ball stays inside.

Now we can place the T-shape in the correct place, but we still need to rotate it. Snap anchors could serve double duty and automatically rotate the object to the desired orientation. It would be boring to always do it this way though. Instead I will make the snap anchors be gimbals for the T-shape task. They lock the T-shape into place, but it can still be rotated.

Well, how does the hero rotate the T-shape inside the gimbal? Using the same spell! We place the center of gravity of the T-shape into the base of the T. If the hero now cast the spell, the spell will always be in the object attraction phase, because the object is locked in space except for orientation. The base of the T will rotate towards the hero. Achieving the required orientation will require some parkouring in some instances.

(Thinking about replacing the T-shape with an arrow.)

One more thing: The lecture organizers' instructed us not to create coin magnet abilities. Ooops! I guess, I have to chain the coins to the ground.

Spoilers from future me: I don't have enough time to implement jumping and flying. The T-Shape task I solve quite differently. Instead of the multistep magic process, the hero can grab the T-Shape with their hands. Similar to the wand idea, the player's hands directly map to the hero's hands. Yes, both hands. Using the hand, which also holds the leg bar, is not very useful, but mapping it increases the feeling of connectedness between the player and hero.