2024-08-26 - Through the looking glass
I have a busy week, but I'm not going to stop completely!
I feel it's the right week to do a little design.
In week 24, I implemented enemy attacks which can lower the player health. What happens when such health goes to zero? It's time to revisit and evolve the global application flow..
How can I stay faithful to my "total immersion" design principle, and still have a familiar "game" flow with save/load, "runs", pause, and maybe rewind?
I've been thinking about these things for quite some time, and it's time to write about them and flesh out the details.
Remember week 7? I defined two special zones, "limbo" and "menu".
The "limbo" zone should be the zone which acts as a passage from the outside world (or the VR headset "home" environment) to the game world, while the "menu" should let the player start a new game or resume playing a previous game.
In these two "special" zones, it should be acceptable to have some kind of UI elements or messages, but I'd like to keep them minimal anyway.
I need to put myself into the shoes of somebody that has never played or seen the game, and think about what to show them when they start the game.
Loading the "limbo" should be almost instantaneous, and the hexagonal platform should appear in mixed reality. The *Binary Charm* and _Particular Reality_ logos could also float somewhere. This is where I might need to show any disclaimer/warnings about potential epilepsy triggering etc.
Additionally, I will need to make sure that the platform is inside the "guardian" area, and let the user adjust it if they want. Any other configurable options, if any, will go here too.
In the _limbo_, there should basically be no avatar, but only the default semi-transparent hands, just to make the player aware that the hand tracking is working.
Then, I need to push the player roughly near one edge of the hexagonal platform, and facing the opposite edge. This way, the portal to cross, which is going to "split" the platform in two halves when it appears, will open in front of the player, well visible.
Having some kind of arrow stamped on the platform would be effective, but too crude for my taste. What I'm thinking is having a dynamic hint system, based on floating particles, that goes into the player field of view and moves trying to push him into a certain spot.
When the player reaches the required position, a portal splitting the hexagonal platform in two halves will appear. It's going to be like a mirror showing our reflection from another reality: a Particular Reality.
Our reflection should feature what I'm going to call a "skeleton avatar", a minimalistic, stylized upper body that will always track the player body movements after they enter the game world.
With pretty much nothing else to do, the player will have to walk into the portal, or at least reach into it with their hands. When he "touches" the reflected avatar, in a white flash, I will teleport the player to the "menu" zone, and they will find themselves embodying the avatar which was "on the other side" one moment before that.
Obviously, this should resonate with the player, thanks to Alice in Wonderland (and, consequently, Matrix), without forgetting the classic moment from Prince of Persia.
Then what?
2024-08-27 - Teaching locomotion
Ok, yesterday I got to the point where the player goes from the limbo to the menu zone by crossing the portal/mirror, and starts embodying the "skeleton avatar".
In the menu zone, the player should be able to start playing a new game, or resume a previously saved game. Entering this "playing" mode should be made obvious by having a second level of embodiment, where the "skeleton avatar" binds itself to some kind of "flowing energy" (rendered via particle effects).
But first, the player should be taught at least one fundamental thing: how to move between platforms.
For the second time (forced action repetition is the basic way to teach the rules of the game world), the player, standing on the second half of the first platform of the "menu zone", after entering from the limbo, 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.
As we know from one year of DevLog, 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.
After reaching the central platform, the player will need to reiterate the action, but changing direction. So we're slightly making things more complicated, trying to teach "to move to an adjacent platform, you must be in correct half of the current platform, facing towards the destination". The floating particles will suggest the actions to be done, as they already did on the previous platform.
At this point, the player will be on the "new game" platform, which will feature a "bridge portal" which brings to the start of the actual game.
Once again, the floating particles will still suggest what to do. When the player will cross this portal, marking the beginning of a playthrough, the particles which have "guided" the player until now will stick to them, somewhat "activating" the skeleton and marking the start of the gameplay session.
Considering the menu map (without the "continue game" platform), here's a visual representation of the three portal crossings we are going to guide the player through, starting from the bottom and reaching the "gameplay" on the top. The red arrows are movement on a platform (the "step back"/direction change), while the azure crayon shows the "jumps" done crossing an opened portal.
2024-08-28 - Navigating through contexts
Let's recap the flow we have described until now:
the game starts in the mixed reality "limbo", the player doesn't embody an avatar
the player moves to "menu" and embodies the "skeleton avatar", particles float around and give hints
the player enters the "gameplay" stage, and the "skeleton avatar" activates, with particles sticking to it
In the "gameplay" stage, there's a sub context to handle, the one where the game is paused (and maybe gets rewind).
Let's split "gameplay" into "active gameplay" and "paused gameplay", and recap how I'm planning to make each context easy to tell from the others:
Basically, when the game gets paused, the particles should "detach" from the skeleton, standing still even if the player (still driving the "skeleton avatar") moves.
I'd like to have a single "pop context" interaction, that the player can perform to "go up" one level in the stack, like this:
It's like when pressing "esc" pauses the game, and then pressing it again brings you to the main menu. There, another "esc" keypress quits the game.
As there's no standard "esc" interaction for VR, and I'm trying to avoid relying on controllers and "system" gestures, the only problem is finding the right gesture/movement, teaching it to the players, and make them aware that the possibility to perform the interaction is available.
Not relying on the system gesture (which currently, on Quest, is a pinch held for a while) doesn't mean that we don't have to handle it, of course. Actually, by being an intrinsically "immersion breaking" interaction, it might provide me a good opportunity to show a panel teaching how to do an `exitContext()` interaction, if I can't think of anything better.
Anyway, I feel like it's time for one of my FSM diagrams. Let's try to describe the global application flow.
A few comments on the diagram, before calling it a day:
The `
in_limbo_shutdown
` is not really necessary, but I'd like to have it, for symmetry: I'm going to implement a quick animation where you exit the Particular Reality and are briefly sent to the mixed reality you've already seen when launching the game. If you're in a hurry, you can always quit the game straight from the system menu. I'm not sure yet about giving or not the option to go back to the "limbo" without quitting. For now, I'm going to keep it simple and assume that "exiting" from the menu zone implies wanting to quit the game.Walking outside the hexagonal platform is another way to put pause the game, and solves problems like "what happens if the player has a large room and walks to an adjacent platform?".
I haven't considered the "setup" logic yet. I briefly mentioned yesterday, and it's part of the global application flow, so I should formalize that too
Well, I'm going to continue tomorrow...
2024-08-29 - Unfinished business
While reviewing yesterday's work before proceeding, I spotted a flaw.
I wrote that while in the "active gameplay" context, a second way to pause would be to simply walk outside the platform, which would also prevent breaking the game world logic, which forces you to change platform via portals.
But what about walking outside when in the other contexts?
limbo: it's fine, you're basically walking into your room in mixed reality, but to proceed to the game you must step onto the platform
paused gameplay: it's fine too, you might walk around but to resume playing you are forced to go back to the platform
menu: problems! problems! eeek!
If I want to keep some level of consistency, I think that "exiting context" in the menu zone (including stepping out of the platform) must definitely bring back to the limbo, which then is not just for starting and quitting the game, but can potentially be entered and abandoned again at any moment.
When stepping outside the platform while in the "menu" context, the "skeleton avatar" must be detached, the environment should go back to mixed reality, and the player should go back to have the semi-transparent tracked hands.
When going back inside the platform, the "mirror portal" will open again, allowing the player to re-embody the "skeleton avatar" and go back to the same platform they were before switching to the limbo.
If I'm not overlooking anything else, this slightly more complex flow should make sense, and it's now possible to quit the game from the startup scene too, because for additional consistency I would say that at this point walking outside the platform, when in the limbo, should be the action that quits the game.
Let's update yesterday's diagram, and also take the opportunity to add the "setup" part.
Ok, looks like a definite improvement!
I got fancy and assigned different colors to the states, depending on the context they're in, according to this mapping:
I added a preliminary check for the validity of the configuration, and a new `in_limbo_config
` state to take care of fixing it when needed. Then, I added the possibility to go back to the limbo from the menu. Now, `exitContext()
` should be able to work consistently, always mapped to the same interaction, which should be "do a gesture/movement OR step outside the platform".
Of course, to activate the signal by stepping outside the platform, the player will need to step back in first to activate it again (or at each frame outside the platform, we would pop a context, which would quit the game in a handful of frames).
2024-08-30 - Back and forth
I'd like to spend some time thinking about what should hopefully be the last "cloudy" parts about the high level application flow.
I mentioned the "continue game" platform a few times, but never stopped and described how I imagine it working.
And in the diagram, there are two ways to go back to the `in_menu` state:
from `
paused
`, voluntarily performing an `exitContext()
`from `
playing
`, in case of game over
Let's discuss them separately.
Going to the menu zone from the `paused
` state is the easy one. I know how I like this kind of auto-saving system: when I go back to playing, I want to be able to resume the game seamlessly, exactly from the state it was when I had to stop playing.
There's all kinds of things that can force someone to interrupt a gameplay session (battery running out, unexpected call, dinner ready...), and I hate when a game doesn't allow to easily save and then restore later. Forcing the player to leave the application running, paused, is not acceptable to me.
So, I'm just going to autosave whenever one pauses the game. Done that, it doesn't matter what happens next: maybe they quit regularly passing through the limbo, or more abruptly terminating the process from the system menu. Maybe they leave the game running, even if paused, in the headset until the battery runs out.
Let's define some further details. When "exiting the context" of the paused game, we defined that the players find themselves in the menu zone, but where exactly?
I'd like to put them on the "continue game" platform, and I'd like that the "bridge portal" that one can open from that platform is nothing else that a way to step back into the "paused game" that they have just left.
Actually, I'd like the bridge portal to act like a 3D thumbnail of the saved game. When you open it by stepping on the right zone of the "continue game" platform, you can glimpse into the portal and you might recognize the detached particles of your avatar as you have left it when pausing the game. Crossing the portal brings you back to the same "paused" game you had left, and you can reattach your "skeleton avatar" to the particles and restore the execution.
It doesn't matter if you had just paused, in the same execution of the application, of if it's the game you were playing two weeks earlier, before going on vacation.
What happens if you have a saved game, and consequently the possibility to continue but instead you decide to go back to the "new game" portal to start from scratch?
That's a whole other can of worms, let's leave it closed for now, and assume that we handle a single slot: "new game" overwrites it.
What about the "game over" case, when the player's health goes to zero?
I feel it's early to take a final decision about this.
There's many possibilities. I'm going to write some that I might consider.
A checkpoint system. When you lose all your health, you get sent back to the latest checkpoint, with full health. The latest checkpoint might be the current zone entrance.
Forced rewind: you never really "lose", but are forced to rewind to a previous state where you have some health. Might be problematic (limits on the rewind duration), and I'm not even sure rewinding will exist
Game over and that's it. You need to restart the "run" from the beginning, maybe keeping some element of progression from the previous attempts
I really don't know yet. But even about this, like for the save/load, I need to at least take a temporary decision which makes sense for now.
I think I'm going to go with the simples thing, which is the "do nothing" option. I will send the player back to the "new game" platform of the menu zone. They just lost, and can start a new game.
Let's update the diagram to include the newly discussed logic:
The non-coloured states indicate behind the scenes actions that are significant to make the logic work the way I described earlier.
I had to remove the "macro-state" gameplay, because there's no common flow going in nor out.
if we are entering from the "new game" portal, we set up a new game and go into the `
playing
` stateif we are entering from the "continue game" portal, we set up the loaded game but go into the `paused` state, not straight into `
playing
`if we are exiting because of the "game over", we are brought back on the "new game" platform
if we are exiting voluntarily with an `
exitContext()
` from `paused
`, we are brought back on the "continue game" platform
Additionally, I highlighted the `autosave
` logic called when pausing the game.
Ok, that's about it! There are going to be details I have overlooked, but I think I have drafted quite a lot of stuff, which is going to keep me busy for many weeks of implementation.
I can't wait to get started, but well, I will have to, actually, because next week, and maybe the week after that, I will be busy with other tasks. Hopefully, once I get rid of those, I will manage to work for a few weeks without interruptions.