Devlog #3: Edge Case World Switching

Hello everyone! I am Amerhane, one of the two programmers on this project, and I was tasked with coming up with the world switching mechanic that Edge Case will use. I really enjoyed making it, and I'm looking forward to showing it off in the final game. I want to talk a bit about about how the mechanic works under the hood, and the decisions I made when making it. I got the idea for this system from Epic Games "Bullet Train", where they use a shader to show the world unloading at the end of a level, and it looked great. Taking that and using a tutorial video on creating a similar shader to that, I ended up with what you see.

Here is a quick video of the transition in its current state: https://youtu.be/tsNSRPnZyOI

So there were a few things that I knew starting out that the switching needed to do. First was it needed to, naturally, switch between the two worlds. Doing this was very simple, as the player character would store a reference to the real world level, and the game level, "Genesis", and when the switch button was pressed, the player would be sent to one or the other. After the player's location and rotation in their current level is then stored and they are teleported, I used a simple swapping algorithm to switch the two variables so the player can always go back to the same spot they were in. I also knew as our levels grew in complexity, they would take longer to load, so I added a brief transition and loaded the new level asynchronously while the transition played (basically a not-so-hidden loading screen.)

The next thing took some iterating on to get the timing of everything. Based on whether the player was in Genesis or not, or in other words, if the effect needed to show loading in or unloaded out, the timing of the animations needed to change. As shown in the picture above, if the player is going into Genesis, the animation needed to play first, and then trigger the load in when the headset was in place. Speaking of the headset, getting the timing with the animation of putting on and taking off the headset had to be perfect. To do this, animation tags had to be used that would call an event the transition blueprint was bound to.

As far as the actual visuals of the animation, they are controlled on a timeline that changes a scalar parameter of the transition post-process shader, and as this parameter is increased or decreased, the shader changes: https://youtu.be/w-M--fwXuWM Controlling this value at runtime is a simple timeline. The only other thing missing was the fade to black and white transition on the start and ends of the transition. jdwaugh, the lead animator on the team, came up with the great idea of having a UI widget fade in and out between the animations and the transition sequence, and so we added that in and the final product is what you see.

This was a fun thing to work on, and I think it turned out quite well. Thanks for reading! Keep an eye out for more devlogs coming from other members of the team in the coming weeks!

Talk to you all again soon,

Amerhane