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

Hi there fellow devs and gamers,

This is the very first blog post of our team - JumpCatStudo - We will go over some topics to talk about the making of our first Unreal Engine game for the 1-week game jam hosted by Epic Games.

This post will go over these topics in order:

• Our context
• Brainstorming, planning, and scoping our project concept
• Organizing team workflow with Source Version Control
• Techniques of our game
• Conclusion

We will write the topics with mixed technical and non-technical discussion. All of the options are our own reflections of our actual experiences after submitting the project for this game jam. We hope to receive some feedback if you enjoy this post. (And sorry if there is any mistake - as English is not our native language)

Our Context:

If you have been catching up with the news around the game industry, Unity (one of the most popular tools for game development), went on to reveal an updated pricing plan that is confusing and can leave a lot of companies in financial trouble, thus damaging the trust and relationship between unity, dev community and partners alike (By the time of this post, Unity has pulled back to a 'better' pricing plan) So the industry, from some established studios and some Indies alike, are on the looking for some alternative solution for game engine.

We want to learn by doing. We want to have practical knowledge and data-driven proof if we ever consider switching our core technology. We also expand our capabilities on the alternatives. However, we have released a commercial project with Cocos Creator, so we were not that worried about a backup solution. 

And this game jam came up in just perfect timing to check our Unreal Engine as one of the most talked about alternatives - business-wise and technical-wise compared to Unity or other engines.

However, this blog post is only about our project in Unreal Engine - a short game titled Predestination

So to give more detailed context, we are professional mobile game developers (working mostly with Unity) and have worked on several major commercial projects. We have not released any commercial game with Unreal Engine, though we have worked on a few Archiviz projects with Unreal 4 for a long while. Going into this jam was very exciting and refreshing for us.

Our team has 3 people - one programmer/designer and 2 artists by trade. We did not spend full-time working on this jam as we had our own unity project to work on. But we try to put in as much time as we can, especially during the last couple of days before the submission deadline.

Brainstorming, planning, and scoping our project

The theme for this game is 'Antiquated Future'. Rising from the bubble of hyper-casual mobile games, releasing an MVP game (minimal viable product) from a week to 1 month is something we are proficient with.

However, there are a lot of factors that we tried to estimate when working with Unreal Engine:

We have not released any UE game, there could be a lot of issues that are not accounted for, besides not working on this full-time. So to make sure that we do not stress ourselves too much on this project, and still release an MVP game ON time (basically it must have a good, self-explanatory playable game loop), we set out additional constraints for our idea, so that we could focus dead-set on ONE most important thing: make sure our intended game mechanics is polished, engaging and will not have any breaking / show-stopping bug.

Read on and you would not believe how bare-bone we set our game to be:

• It must either be a third-person view or a first-person view, without any exception. So that we can directly expand the starter content of UE.
• Contain itself in one single scene/level/ map. There must be no loading, or switching between scenes. Simply because we do not know yet how to handle data persistent between scenes.
• Can be playable without any sound (we did not even have time to implement sfx, or music background in our submission). Music-Rhythm game for example is a no-go, or any sound-based puzzle mechanics, etc.
• Must be below 1 GB for the final shipping version to match with Itch.io requirement. From our experience in mobile games, we would always want to limit download size as well as avoid split downloading packages as much as possible.

In the end, we chose a first-person-view (FPV) type of game, so that we do not have to work on our main character animation.

Back to the game jam theme -'Antiquated Future' - It does sound abstracting to us. We tried to translate it into our native language to find an angle for our brainstorming session but we did not come up with anything outstanding yet. After some searching around, we eventually settled on a simple concept that we could implement quickly - splitting between something old and something new. And time-traveling between two different timelines/dimensions. That definitely doesn't sound simple enough to implement in less than a week.

But we did release a polished gameplay with it called Predestination

 So if you have not played it yet, download it and tell us how you like it (Only for windows platform):

https://jumpcat.itch.io/predestination#download

During the research for how we would implement the time travel mechanics, one certain dev blog video from a very long past came to me like a Predestination. I briefly watched it before. It was from one of my favorite game franchises even:

I, the programmer, have not played Dishonored 2 but Dishonored 1 is definitely one of my top favorite game titles. Now in this video, they explained how they did their time travel mechanics. And we will just say it upfront that we follow their footstep in this direction, with a couple of twists on our own. 

So the main setup for the time travel mechanics breaks down to this:

• There are 2 separate areas for 2 identical locations, with only differences in height (Unreal uses Left handed, Z up for this compared to Unity or any other 3d softwares)

• The traveling part is simply the player teleporting between these 2 locations (more on about this later)
• There is a device that let you view your destination before traveling, so you do not have to travel back and forth continuously to gather information (Unreal lets you do this in less than 5 minute - We describe it right below)

Basically, that is the main mechanics of our gameplay to represent our interpretation of the game jam theme. With both FPV + this type of mechanics, it came to us obviously that we should make an escape room type of game, where the main mechanics is to get the character out of the current entrapped location, by collecting certain items, and solving specific puzzles within the area.

In our game, the player would complete the gameplay loop by collecting all the required items. That's all to it.

Yay! We know exactly what we would have to implement. Now let's move on to the part where we organize and split the work between our team members.

Organizing team workflow with Source Version Control

The number one priority that we know we have to get through first is Source Version Control (SVC).

On the programming part, I have worked on fairly some complex C++ plugin for Unity and some cool stuff with Cocos JSB (javascript binding to C++), plus using Rider mainly for Unity, with also have excellent support for UE, I have all the confidence and knowledge to know that, I will NOT use C++ for this game jam :)

As we are experienced with Git/Git FLS work flow in all of our Unity projects; however, we want to approach this project with a fresh mind. We just then follow the guide on the game jam page to use a setup with .svn hosted on Assembla  and TortoiseSVN as our client. I spent some good time to read between the different of git and svn, because I have not used svn before. And it definitely was not that pleasant to use it at first (Due to how Centralized vs Decentralized source workflow). Even though the process of setting it up on Assembla and connects it to Unreal is very straight forward and easy.

And while using it, we soon realize that we are trading some downtime for some downtime from Unity vs Unreal (even with Blueprint instant compilation)

In Unity we are always greeting with this.

Now with Unreal using svn, this is what happens almost very frequently.

It checks to see if someone is working on that particular asset, and prevent someone else to check out on it. You will have a warning of locked file. Due to the difficulties to diff what changes in binary/blob file, this is one sure way to avoid merge conflict. It does take awhile to get used to it.

Insane horror story from IT support goes here, it will drive you mad, as it almost did us:

Sometimes, there are some issues with .svn, it will ask you to perform "clean up" so that you can use other command like "commit", "update", etc. The thing is TortoiseSVN uses operation with folder, as in you will right click your folder on your machine to issue a command, instead of having a GUI client like various git softwares.

So to perform a "clean up" or any other command, you just right click on the folder and choose the command, simple enough right?

The thing is, it looks different on Windows 11.

On Windows 11, this is what shows up (on our artists machine, as I still stick to Windows 10)

I legitimately did not know about the feature of "Show more options" of Windows 11. As TortoiseSVN does show limited options here, I thought that because I was the one who created the repo, I have more options/rights to perform with it.

So i went to google for solution how to solve the missing option of clean up command for .svn. Running command line would not seem to work. I was going crazy. But then i was trying to write the .bat file on our artist's machine, then you have to hit the "Show more options" to edit the .bat file with NotePad, and here it is, the fully shown dropout like normal. 

It is solved, phew.

Techniques of our game

With knowing precisely what we were going to make, we went ahead and purchased assets on marketplace, mainly the main scene. Even though we have used UE4 a while ago, this project is in Unreal 5.3. And while there might be not much change from version for this particular small game jam, we would not want any lost time to figure out on the fly how certain things supposed to be set up (materials, lighting, map settings, world settings, etc)

And we bought this package, mainly because it looks decent, does not look too complex for this game jam. The layout is symmetrical, the various content can easily be removed (like the hotel room)

https://www.unrealengine.com/marketplace/en-US/product/modular-futuristic-sci-fi-space-hotel

To stay under 1 GB when shipped, and to fight off against Unreal "Over texture streaming pool limit", we would have to perform a quick and dirty optimization of our assets, mainly from all the 2k, 4k and 8k textures and resize them to 512 or 1024 resolution (not just compress it, or set the max display quality). In Unity, we would just run a tool over the texture folder and call it done. But with Unreal, every asset is packed into .uasset file. Which means we have to export, in our case, all the textures out then relink the source asset folders (because it records the path from the machine of original asset maker), then re-import again. 

There are over 200 textures in our package, that mean we need an automated way for re-linking the assets. 

To do this, i thought i would have to spend some time to work on custom plugin for custom editor solution like Unity, but it turns out, it is quite simple to do it with Unreal. I just create a simple Editor Utility Blueprint. With a bit of learning from simple tutorials, it works out like a charm.

This is a quick work only for texture with .png format. It can be improved further to work on all kind of formats.

https://blueprintue.com/blueprint/znczds9k/

After that, we setup the scene like the following. There are 2 identical environment objects, one is for the 'new' timeline, one is for the old 'timeline'. For the new timeline, we use the original version come with the asset pack with little to no edit, while we work on the old version, making the textures/material looks worn out. This is very convenient to do with Material Instance from UE.

There are two different sky spheres / sky box that wrap around each environment, the purple one contains new environment, the green one contains old environment.

Last but not least, to quickly work on the overall ambient color for both environments, we use local post processing, with is pretty much identical to how it works in Unity. You have a bounding box to define areas that have plenty of graphical settings like color grading, contrast, bloom, etc.

Below you can see if you enter the local area of the local post processing, the overall color is changed.

That is the work on the visual end of the game for now.

Wow, this blog post is longer than expected, and it is the end of part 1. Feel free to comment if you like anything, or have some feedback for us.

 Stay tune for the upcoming of part 2, where we iterate on both game design and programming part to make it fun to play.

And while talking about a fun game to play, if you have not already, the download button for our game - Predestination - is right below this post.

Part 2 link here: 

https://jumpcat.itch.io/predestination/devlog/611488/behind-the-scene-of-predest...