Advanced Prototyping - Week #34
Guiding through portals
2025-01-20 - Menu zone logic
I'm going to proceed like I did in week 33 for the limbo zone, but this time dealing with the menu zone.
Let's see what I designed in week 25, and in particular on 2024-08-27:
...after entering from the limbo, [the player] will be drawn to the zone where they can open a portal to the adjacent platform. When in position, the floating particles will morph to the gesture needed to open the portal, prompting the player to do that same gesture.
When the "skeleton avatar" hands match the "particles hands", they will activate the portal to the adjacent platform.
...
the player should take a step forward while sticking to the same gesture. We should teach this by having the "particles hand" go forward into the portal, pushing the player to follow in the same way.
Then, this sequence needs to be repeated twice, one to go to the new game platform and another to actually enter the gameplay session crossing a bridge portal.
I also did this sketch showing the three steps:
Let's draft the code for this zone.
Basically, I need to set the same type of hint, but on three different spots.
At least for now, it's totally fine to hardcode these spots.
In the menu zone, I had labelled only the start, new_game and continue_game platforms.
I added a center label to the... well, central platform, so that I can easily look it up from the zone logic.
Skipping the lookup of the zone and platforms, this should basically be it:
RTLocation playerLoc = m_rPlayerStateManager.getCurrLocation();
Hex.EDir? portalOpeningSlice = null;
if (playerLoc.m_platformId == startPlatform.m_id) {
portalOpeningSlice = Hex.EDir.S;
} else if (playerLoc.m_platformId == centralPlatform.m_id) {
portalOpeningSlice = Hex.EDir.SE;
} else if (playerLoc.m_platformId == newGamePlatform.m_id) {
portalOpeningSlice = Hex.EDir.S;
}
if (portalOpeningSlice.HasValue) {
rSmartParticlesSM.setPortalHint(
new RTSpot(playerLoc, portalOpeningSlice.Value)
);
}So, depending on the current platform the player is standing on, I set a "portal hint" on that same platform, on the correct hexagonal slice to guide them from the start platform to the bridge portal connecting the new game platform and the first gameplay zone.
Let's pause for a minute.
Last week I guided the player through the mirror portal which shows up when starting the game.
Now, I need to guide them through the "normal" portals, which require a gesture to be activated, meaning that I must finally make use of the gesture hint I implemented in week 32.
This means that I need a different behaviour for these hints, and rethinking about it, my naming of the hint mode (`EHintMode.portal`), last week, was wrong: that was the behaviour needed specifically for the mirror portal.
I'm going to refactor `EHintMode.portal` to `EHintMode.mirrorPortal`, updating all the references in last week code accordingly. Then, I'm going to re-introduce a "brand new" `EHintMode.portal` to use for the new behaviour.
I did the changes I mentioned, and some other minor fixes. Tomorrow I'll proceed with the logic of the new hint mode.
2025-01-21 - Portal opening hints
As the "normal" portals don't open automatically like the mirror portal, we need a slightly more complex FSM.
Let's go back to the predicates I used last week:
`
C` : player "captivated", meaning that the hint sphere is in their FOV`
P`: player "positioned", meaning they're in the correct spot to open the portal`
L`: player "looking" towards the portal (more precisely: properly rotated to open it)`
T`: timeout, some specified time has passed
I'm adding a new one:
`G`: opening gesture recognized
Now, to keeps thing manageable I'll try an approach where the hints are given in sequence, and if you fail to do a step after a certain timeout, the flow is sent back to the beginning. Unless one doesn't invalidate the previous predicates (for example: by moving from the spot), the flow should naturally go the "current" step (with no unwanted delays).
I implemented the new FSM and started testing it.
The core logic works pretty well, but there's a lot of work to be done before I can consider this part "complete".
There are still the glitches I briefly showed in the video at the end of the previous articles, and new ones related to transitioning to the `show_anim` state (that we didn't use with the mirror portal).
I'm going to try and fix everything in the remaining days of the week.
2025-01-22 - Hint particles appearance and disappearance
So, the two most unpleasant things in the current state of the hints are
the "looking towards portal" check is not well tuned, meaning that it stops guiding the player gaze too soon
the hint visuals (both "hint sphere" and "hint clip") appear/disappear abruptly
Let's face the appearance/disappearance problem first.
I'm going to add, at the state management level, two 0-1 values, `hintParticlesVisibility01` and `hintClipVisibility01`. I'm going to animate such values towards 0 or 1 depending on if these elements must be visible or not in a certain state.
Then, in the elements "presentation" scripts, I'm going to use these values to tune the placeholder VFX. I'm going to reuse the `VfxBhv` script I already used to handle the enemies and other elements, which easily allows me to change size, particles emission rate and colors. Good enough for now.
Ok, I did the `VfxBhv` refactoring and added a bit of logic to fade the visibility values, in the main smart particles state manager.
It doesn't look great, but it's far better than an instant visibility change.
Not worth a video, but I'll capture one tomorrow after fixing something else too.
2025-01-23 - Improving the gaze-guide
Today I'm going to work on improving the code used by the hint system to check if the player is properly rotated towards a portal.
The current check was built upon the one used to see if it was possible to open a portal. Why that's not good enough?
Well, up to now it's been possible to open portals backwards, or looking quite "sideways", as long as you are on the right half of the platform. If that's a good idea or not, is a topic for another day.
Right now, the point is that such check doesn't work well with the "gaze guide" hint: I want to check that the player is "precisely" looking towards the destination platform, before considering the suggestion by the hint system successful (and transitioning to the following state).
I implemented a simple check using the dot product between the direction towards the destination platform, and the player look direction projected on the ground.
When the dot product is close to one (currently, greater than `0.95f`), it's considered good.
It's not perfect, but I'd say the system starts to properly "guide" me to open the portal!
The `guide_look` fade out is pretty ugly, but at least is there.
Instead, the `guide_anim` clip showing the hand gesture still appears/disappears abruptly.
2025-01-24 - Fading the gesture hint
Today I have very little time available, but I should manage to do at least a little thing: remove the instant appearance/disappearance of the arms giving the hint about how to perform the portal opening gesture.
Ok, it was pretty quick: I just added a parameter to the "particles body" VFX to set the spawn rate of the particles, and hooked it up to the `hintClipVisibility01` I had already added a couple of days ago.
This is a test of the complete sequence, opening and crossing the three portals of the menu zone.
Next week I'm going to be super busy, so I'll probably be back with a new post in two weeks. Or three. But hopefully two. Stay tuned!