In the previous post in this blog series, I discussed the background, software used, and a bit about the Unity version. This time I will focus on the Unreal version. But first, some words about organizing your files.
VERSION CONTROL
As the project is being developed using multiple game engines, on multiple platforms, it becomes especially important to keep your files in order. The easiest way is to use something like Dropbox, that allows you to access files from multiple computers, as well as reverting to previous versions in case some file gets messed up. Though, for game development this is not practical, as files might get updated in the background, clashing with how the game engines keep track of files. So, even for small projects, a proper version control system is needed. Git is very popular among programmers, while Subversion (SVN) is popular among artists.
As games involve both a lot a code, as well as art assets, neither of these are perfectly suited for the task. Many game developers use Perforce (also branded as Helix Core), which is suitable for both code and asset, and is the solution I am using. It takes a little reading of the manual to learn how it works, but once you understand it, it is very easy to use, and has a free cross platform front end application called P4V, so there is no need to purchase something like Cornerstone. You will need a Perforce host server. Assembla provides hosting, but the cost is rather high, so I recommend setting up your own server. For indie developers, Perforce itself is free to use, but larger corporations will have to pay a license fee.
PLUGINS
Also related to organization, this first thing I do when starting a new project is disabling all plugins. Later, when I need I specific feature, I reenable that plugin.
For example, when blocking out a level in Maya, there is no need for Bifrost, MASH, Arnold, xGen etc., and disabling these will make starting up Maya quicker, and the probability of crashes lower. Of course, you might want to use the procedural features of MASH to generate stairs and the like, but in this case I am keeping things light.
In Unity, all built-in plugins (packages) are enabled by default. The image below shows the built in packages I am currently using. I don't target Android, don't use the built in terrain engine, web, VR, AR etc., so there is no reason to keep those around.
Likewise, in Unreal, there are hundreds of built in plugins. Disabling most of these will make the editor start up much quicker. As I am using Perforce, I am keeping that one enabled.
Though, when it comes to Unreal plugins, do be aware that some of them might be needed for the final build to work, even if they are not needed when working in the editor, as explained later in this post.
All this discussion regarding version control and plugins is getting a little long and boring, so let's briefly switch to another topic...
TARGET REACHING
The screenshot below shows the blockout rig and attack animation I made. The target of the attack is part of the rig. The distance between the target and the character is automatically calculated, and exported as a custom animation curve (shown in the graph editor below).
Now, during a battle in the game, the target is moving around, and the distance is changing, and will not match the distance that the animation was authored for. So, the actual distance is compared to the authored distance, and the root motion is scaled so that the attack impact will occur at the correct distance. Without this compensation, the characters would swing their swords into thin air, and look quite silly.
In Unity, I have implemented my own animation system, so cases like this are easy to handle. Though, it is a bit more tricky in the Unreal engine, which leads back to the main topic of this blog post...
UNREAL ENGINE
While the Unity implementation is coded in C Sharp, I wanted to implement the Unreal version using blueprints only. One reason for this choice is that blueprint projects are faster to build, and less prone to cause problems. Let's look at the animation blueprint used to implement the target reaching discussed above. We can access the distance using the Get Curve Value node.
We also need to set the root motion scale. There is a function to do this using C++, but this is not exposed to blueprints. The node Set Anim Rootmotion Translation Scale below does not exist.
One option is to convert the project to a C++ project. Though, I wanted to stick to the original plan of using a blueprint only project. So I had to make a plugin that exposes the required feature to blueprints, making the node above available.
Ok, so to go forward on this art challenge, I first need to make sure I can build the Unreal project on Windows, so that you can experience the final result interactively. While many artists build scenes in Unreal, and take screenshots and record fly-throughs to post on ArtStation, they could just as well have built their scenes and shaders in Maya, and rendered it out with Arnold. The real point of using a game engine is the interactive experience.
The Unreal project I will use as a base is a small subset of the game, with just implements the most basic (but most important) combat mechanics. I developed this on Mac, and to build this on Windows, I first had to check out the project from Perforce. The Mac project could be used as is, with some Windows specific configuration added.
Click build, and all would be done, I thought... but not...
First, I got a popup telling me that Visual Studio is not installed. Though, I had installed this previously. Finally, after installing CLion (an alternative IDE), I was able to build without errors. When running the built game, it crashed on launch, complaining about a missing super-struct. I thought that was caused by my plugin, and tried making my plugin an engine plugin rather than a project plugin. To package the plugin, it now complained that I needed to configure server settings for an iOS build. Though, I had no intention to build for iOS. So, a whitelist had to be added to the plugin settings, specifying that the plugin can only be used for Mac and Windows. And then it complained that the BuildTool could not be built due to a missing dot NET target. Ok, installing dot NET, and finally I could use my plugin as an engine plugin. Good, now let's try again, and... crash. I finally figured out that I needed to enable the built in AISupport plugin, that contains features used by the enemy AI.
While the Unreal engine is artist friendly in many regards, it can be a real pain sometimes. For indie developers, I would strongly recommend sticking to Unity. If using the Unreal engine, I would recommend blueprint only projects, and putting custom implementations into engine plugins.