Prototype — Timeline Switch Ability
Remember when games added a third dimension to fight bad guys in?
Well how about combat in 4 dimensions?
I’ve had this idea for quite some time now, only to discover that it’s been done a million times before (namely in Titanfall 2 and Dishonoured 2).
The idea is that you can travel between two timelines in the same layout, but be able to affect the layout in the future based on your actions in the past (and vice versa).
And here’s what it looks like in the engine:
And a slowed down version to see the transition more clearly:
This post will mostly be talking about the technical feasibility of this feature, whereas concrete design implementations will be in a separate one, as I’m still working on those.
There are a couple of issues that pretty much anyone will immediately point out when thinking about developing a feature like this, I’ll just go ahead and list a few, then talk about how I solved them:
- Level Production: Creating all levels in both timelines will double the production cost of all levels; syncing the levels is mundane and error-prone.
- Availability: level geometry inconsistency can cause the player to teleport inside geometry.
- Rendering: Having both environments rendered at the same time is too costly.
Level Production:
First of all, what I definitely don’t want is to copy over all geometry every time I make some changes to the base of the layout, for example the architecture that will be exactly the same in both timelines (decals and lightmaps aside).
I also don’t want to jump between two locations to see the difference between the two timelines.
I want to work on a single level, then simply tag which assets are timeline-exclusive, and ideally have a way to filter those assets so I can see what the levels looks like in a single timeline.
Sounds simple enough, and fortunately in UE4, it is.
I split all the levels I’m working on to this structure:
Shared is where most of the work is being done (at least during the blockout and scripting stages), and it contains all assets that I want to appear in both timelines, that way if I move a tree, I won’t have to do that twice.
The layer is duplicated during runtime on begin play, then moved away from its origin by an adjustable offset, Day and Night levels are loaded in, and Night is also moved by the same offset.
So technically speaking, to trigger a timeline switch we simply teleport the player by that same offset, and Bob’s your uncle.
That’s great and all, but as soon as we introduce level streaming into the picture (I’ll be assuming the game is linear, since my demo is), it gets real messy real quick, since every level section is now represented by 3 separate levels.
This is where blueprint utilities come in (one of my favourite things in UE4), which is a way to script the editor with blueprints.
More specifically I’ll be using them to set the visibility of ALL levels based on their function, so in the end I have a button that will switch my view to Day, and another to Night.
This workflow is intended to be used during the prototyping/blockout stage, which requires a lot of iterations.
For art implementation I have a different approach (that I might share in a different post later), which allows baking the levels (lights, streaming, geometry) just as easily.
Availability:
For the ability availability, I wanted to make sure I didn’t go overboard with the collision detection, so doing an overlap check or ray trace on tick is out of the question.
An easy solution would be to only raytrace the other timeline when the player attempts to use the ability, but this means that there will be no indication on whether the player can switch or not until actually trying to, which is not great for gameplay (especially combat).
Another solution would be to do an overlap check every n frames, but if the player’s position changed since the last check it might give a false positive and spawn the player in geometry.
So, obviously, the actual solution would be to combine the two, and do the constant check only to update the visualizer of the switch (that tells the player if the switch is currently available), and then do a ray trace on use, to check if the player can fit in the destination.
Rendering:
This topic is not done yet, as I’m investigating a couple of methods to make the transition itself more optimized in terms of rendering.
