Behind the scene of Predestination - an Unreal game jam from Unity professional devs - Part 2

If you have spent your time reading up until this part, thank you.

To recap on Part 1:

Link to part 1:  https://jumpcat.itch.io/predestination/devlog/610845/behind-the-scene-of-predest...

where I discussed how we set up the our main scene, we split the environment into 2 parts - new environment and old environment that the player can freely teleport up and down

To make sure that we do not overlap work on the same map, thus being locked by .svn, we duplicated the main map into another map where our artists can freely work on the environments, why I can use another map to work on the programming part for the main mechanics.

One important thing we need to make sure, is that we commit our work in small parts, and commit often. This is to prevent conflict on big binary file, which will be very hard to solve and often end up with discard each other work and waste a lot of time to re-do our work.

So now, into the core of the gameplay, this part will lean towards programming and design our main mechanics

This gif will show you how teleportation works in prototype

The code is frankly 1 liner, which is amazingly handled by UE. Normally, with Unity, i would be afraid that setting a position for the character within a single tick, over a large distance with all physics components included can make the physics engine acting up, throwing your character thousand units away. But UE handles this part smoothly, without any issue at all. All it takes is one single tick in the box (it also let you know that physics part wont be affected)

Also to make the Z location of teleporting dynamic, I set up two different hidden empty objects that I could drag it around in the map. And we just need to know their Z location when the level starts. This way, there is no need for hard coding number, if we somehow want to change the position of our entire map.

One thing sticks out, and it makes this mechanics VERY JANKY

Sometime, the character will get stuck if you teleport to a location where there is a collider.

Now if you remember the video reference that I posted in Part 1, where the developers of Dishonored 2 talked about this same issue. They have spent a lot of time to iron out absolutely all the possibilities where character will stuck. 

Quickly drop it down on my note, to do the same, I will have to push the character out when they got stuck. May be above the object, may be to the side. But what happen if i push the character outside the boundary of the map (my areas is enclosed in small, narrow corner)?  Maybe we can make it game over when the player reaches the outer space, but that would make it significantly frustrating.

I had to divert from this path. 

There is absolutely no way that I have enough time to polish out this mechanics smoothly if I continue to go on this way. Too many possibilities and edge cases to cover. Perhaps there is another way to fix this.

Indeed, there is. And you wont believe that it is only one line of code.

What if I deny the teleportation if I know there IS a collider at the destination that will 100% block out the player? I instantly then knew how to do it. A simple sphere cast at the teleport location, if it hits anything, we just deny the teleportation, and send a message to the player that they will not be able to travel to that location.

Predestination, aint that right?

Awesome! We got all the main mechanics in the game. All I have to do is set in up from the prototype map into the final production map. And playtest it. We believe we got it.

But then, it soon hits us that the gameplay is very tedious and is getting boring real quick.

Even with the objective of collecting hidden items through out the 2 areas, it feels like a chore. There is no sense of challenge for the player. There is a condition to win, but there is no fail state.

So we have to brainstorm a few solutions for this. One of the idea was to add a combat system like Dishonored 2, where the player has to fight against AI enemies in the areas. 

I was very reluctant to go through with this idea. There is no way we could have enough time (at this moment, only less than 2 day left for submission deadline) to implement AI behavior even if UE has a robust built-in behavior tree compares to Unity.

But we did release the final game with some fundamental AI behavior, without the behavior tree

Below here is the process of how we fine tuned the core gameplay through iteration into the final version

To have a combat system, the player would need to have health bar right. And if the player has health bar, there must be items to regain any lost health. That will create more complexity on the map to design and balance. How about we make the health auto regen instead ?

And a great idea came out of this. What if the player also auto loses health as well ? How can we make a logic sense out of it ? It seems obvious more than we thought. Our game environment is in the outer space. We already make the map to appear worn out and decommissioned, so we can make it that it does not support life anymore. Voila, the idea becomes so clear.

Our artists began working on making some of the assets floating in the air to depict this state. While I implement some mechanics so the player can float and flying in the old environment.

Again, thanks to UE, this is another one line of code. Set the movement mode to flying and adjust some parameters with input and thats it.

 I did also tuning it a bit so that it will not be a flying first person view camera. But it slightly is sluggish so that there is a sense of hard-to-control physics in the 0 gravity atmosphere.

The balance becomes so clear, the player will lose the oxygen health bar on the 'old' environment and regen back the oxygen in the 'new' environment. They can float in the old one, and can only walk in the new one. This will always creates the need to switch back and forth between 2 environments, also create a sense of emergency in gameplay.

Final mechanics in production:

So the last touch to balance the need to force the player to go back to 'old' environment, we create patrolling enemy on the new one, they just randomly choose a location to go to. And if they see the player, they will try to chase the player. The player will lose the game if they collides with the enemy. Very fundamental.

Again and again, thanks to Unreal, this feature is insanely quick to implement and tuning. Only need to drag in NavMesh Volume and let it do its magic (calculating pathway for AI to traverse). 

Our map is entirely on flat ground, which makes it every simpler to cook, and prevents any issues with height areas that the AI can walk to. There is a component call NavMeshModifer which also let you block out any areas that you do not want the AI to access. We use this for areas where there is small and tight corner, which may make our AI stuck.

Its all done. A bit of quick ingame tutorial for the user and finally come packaging the final product.

To be honest, as working with a few archviz projects before, we were scared that it might take too long to cook, and the results is buggy and displeasing. Lucky for us, with UE 5.3 it was not a case (Also thank to the assets that we bought on the marketplace has most of this setup already). 

Even though in the final submission there are a few artifacts here and there. But we do believe it is because we have not spent time to work more on the textures and materials instead.

The cooking time, lighting build, full rebuild is only about 15 mins on my machine. You can view its spec below

Conclusion: 

We were lucky to submit the project on time (like 45 minutes before the deadline). The outcome is pretty decent by our standard given how new we are to Unreal Engine. What we have learned from this project:

Planing and Scoping really helps. We can have decent forecast and control the time budget for the final product due to our background of mobile developers in hyper casual market.

We come to work on this project with fresh mind. We are not looking for features parity with Unity or any other engine. We follow how Unreal does it and adapt our mindset to it (for example, using event based architecture instead of looping updates, working with binary assets and source assets instead of only source assets like Unity, using .svn vs git lfs, making a first person view game to be fully supported by the engine's default, accepting to use Blueprint for rapid prototype). 

Playing to the engine strength really does us a huge flavor. Even though it did cost us a few sweat from the start and some annoying issues that we have to solve (described in part 1 if you want to re-read them).

Constraints breed creativity. Without them, the only thing left is procrastination.

Thank you again if you have read until the end here. What a journey! The download for this game is right on the button below. Play it now and tell us what you think about it.

PS: if you still decide to not download the game, it is ok. We also plan to update the game with some cutout content (music, particle effect, AN ENDING STORY). So hope to change your mind by then.