Collection: Shane Gavin - ICA Portfolio Semester 2


Source Control and UE4

Using Git to track Unreal 4 projects is not the ideal source control workflow. The engine's use of binary files for all assets results in the loss of several key Git features. In particular, the lack of a viable merge conflict resolution strategy, and the loss of file diffing are problematic. The lack of these features also greatly reduces the usefulness of branching. It is beneficial to carefully ration individual file access between team members to avoid the need to manually merge changes. 

Additionally, repository sizes tend to sky-rocket quickly (e.g. ~700MB of project files can easily result in a repository size of >2GB after a release's worth of commits). If working in release iterations, it might be advisable to create new repositories for each release. It is also worth noting that BitBucket imposes a hard limit of 2GB on repositories. If this limit is reached, all features (with the exception of pulling) will be disabled. 

Solution: Use GitLab instead of BitBucket. GitLab has a 10GB "limit" on repositories (and a very shiny, very nice dash board).

If using Git for Unreal 4 projects, it is safe to add the following directories and files to your .gitignore file to reduce repository size:

  • DerivedDataCache
  • Intermediate
  • Saved

If you are using C++ project templates, additional files can be ignored. If you init your Git repository from within the engine, an appropriate .gitignore file will be generated.

Menus / UI in Unreal 4

While it could certainly be argued that menus are not a central component of the games we have created this year, and that "functional" would be a good-enough target to aim for here, I'm a firm believer in the power of first impressions, and of "spit and polish". A menu system is the first thing a player will see in your game, and navigation of this system is the first element they will interact with. A player's experience in a menu system can, in my opinion, have a strong influence on their opinion of the overall game. 

Additional to the above, I believe visually strong menus and UI design add an element of professionalism to games with relatively little investment. Certainly, adding the same level of "finish" with in-game elements can take far more work. 

If a team has the resources to devote to it, it is my personal opinion that menus and UI elements should be worked on from an early stage, and not be added as an after thought. 

For anyone coming to UMG for the first time, I would highly recommend they investigate the animation system as early as possible, as this can be used to add a lot of "flare" to widgets with minimal investment. I ignored animation investigation until we began work on the in-game HUD elements, and once I had seen how easy it was to use, immediately regretted not using it earlier. 

I've also noticed that those new to UMG tend to ignore the "flower" when laying out their widgets. The "flower" is central to creating flexible, scalable layouts and should be investigated as early as possible. 

It's also worth nothing that UMG's graphs can act as very gentle introduction to Blue Print scripting. 

Fuse CC and Mixamo

Fuse Character Creator is an invaluable tool for creating single characters, or creating characters in bulk. At the time of writing, the application is available for free through the Adobe Creative Suite, or as a limited-functionality trial through Steam. 

Used in conjunction with  the Mixamo online services, this workflow can be used to create high quality, animated characters in next to no time. As someone with close-to-no previous character creation experience, I was able to develop, rig, and integrate my first character in approximately 1 hour. Each additional character took about half of that time. 

While I did develop some animations from scratch, the store of free animations on Mixamo allowed us to add a huge amount of variety to the spectators in our game. Without this service, I would have been pushed for time to create the originally planned 6 animations. With the service, I was able to integrate 15 animations (4 developed from scratch) in the planned amount of time.

Without these tools, our spectators would still have been present in the level, but I honestly believe they would have been a weak point, and would have been in development up until the end of the Beta release. Because of Fuse and Mixamo, the spectators ended up being a feature which really add to the overall feel of the game, and help set it apart from competing games which rarely feature non-player characters. 

Using Unreal 4

Unreal 4 is an extremely powerful engine, and the range of tools it offers is excellent. However, the engine is not without its drawbacks. The biggest issue with UE4 is its sheer resource weight--you will need a powerful machine. I've been running the engine on a machine with specs below the recommended minimum, and while the engine does work, it doesn't work very well. Even the college computers, which meet the minimum spec., struggle with simple tasks. 

Not being able to run the project's primary tool properly did limit the sub-systems I was able to work on this year. As example, working on the bike mechanics was never an option, as I was unable to reach an acceptable FPS rate for physics (my machine averages 10 to 12 frames per second for any complex scene). 

Relatively simple tasks also took far more time than they should have. As example, when it came to placing spectators into our level, this task ended up taking over 5 hours. Of those 5 hours, approximately 30 to 45 minutes involved actual work, and the rest of the time was eaten up by building and running the level to test placements and activation timings. By the end stage, my machine struggled so much that I had to ask Brian to test for me. 

Not being able to run the engine efficiently was a constant cause of frustration. That said, with a powerful machine at your disposal, the engine's work flow is fantastic, and you can achieve a lot in a very short amount of time. If you don't have such a machine to work with, you can still get a lot done if you are careful about the sub-systems you work on. UMG is mostly light-weight and should work flawlessly on any system (I ran with a 2Ghz Core i3, 4GB RAM, and integrated intel graphics without any issues). General scripting tasks, too, are usually fine once you're willing to occasionally work blind and rely on others for testing. This is mainly an issue when you need to test features which rely on decent playback performance. 

Scripting with Blue Print

Using BluePrint for visual scripting, in place of writing code, has experience. One upside to the scripting system is that features and nodes are very discoverable within the editor, but it is worth noting that this is no different to having code intelligence in an IDE. Another upside is that many complex tasks have been abstracted into pre-built nodes, and overall integration of the system into all of Unreal's tools is flawless. 

On the downside, there is a severe lack of discoverable documentation, and solution searchability is abysmal. Vast documentation, and solutions to common problems, do exist, but because of BluePrint's visual nature most of this content exists in the form of screen shots, and finding them can be a project in itself. 

More than anything, though, I found BluePrint to be very verbose. As an example, something as simple as an if-multiple-elseif-else structure can take several minutes to construct, and is an absolute mess to look at. To further that point, the general readability of BluePrints is terrible.  

That all said, the major issues I have with the system are all connected to general programming tasks. BluePrint as an interface to existing tools (UMG, Persona, etc.) is a much different (and more pleasant) experience.

For anyone coming to BluePrint for the first time I would highly recommend that you use functions from the start, familiarise yourself with the major BluePrint classes, and in general, realise that BluePrint is just another programming language, use it as such. Avoid adding functionality to Level BPs as much as possible, create custom BPs by extending existing types, use construct and destruct events, break functionality up into...functions, an so on. BluePrint instances are objects, if you need one BP to communicate with another, simply pass a reference through an editable parameter. 

Lastly, take the time to tidy and align your nodes and connections. The extra effort here is well worth it for the gained readability. Also, if you have an inner obsessive, s/he will thank you. 

Team and Project

Working with the other members of Margin of Error has been an absolute pleasure. All team members have shown themselves to be hard-working and dedicated throughout the semester, and I would have absolutely no hesitation in working with the team on other projects. 

The overall project structure for semester 2 was much better than that in previous team projects. The clearly defined releases brought a lot of structure, and the work load was better balanced than in semester 1. If I had one small complaint about the project structure it would be the equal allocation of time to each release. In my opinion, POC and Alpha could have been trimmed, and more time could have been set aside for Beta. In terms of overall workload for the semester, this would have made the final weeks more manageable too. 

In terms of Scrum usage for agile development, the move to estimating in hours was a huge improvement this semester. No matter how many times it's explained to me, I don't think I'll ever agree that there's not a direct correlation between complexity and time, and for me, estimating in hours is more natural. Even in situations where estimates are off, the lessons learned are more tangible. 

One major disappointment I had with the project this year was the theme. Before the year started, I was quite excited about developing around the well-being theme, and the move away from this has probably contributed to my disappointment. Beyond that, though, I just find the virtual tourism idea to be uninspiring and bland. It has lead to a situation where certain members of the review panel are constantly pushing the development of simulations, rather than games, and this often comes across as a belittlement of gaming which is not "serious". From what I've observed, this attitude has stifled creativity and enthusiasm across all teams. 

I also found the communication from the review panel to be frequently confused and inconsistent. Talking to any panel member one-to-one was always beneficial, but the feedback and direction given by different panel members was often conflicting. That said, the prompt feedback on each release was very much appreciated. 

The rushed presentation slots were also a problem. As well as causing issues with set-up and preparation, this has also lead into problems with marking and feedback. As example, for our POC release we received a fairly low mark for our Q&A session. This is despite the fact that we were given no opportunity to engage here, and every time we attempted to respond to a question, we were cut off and told there was only time for quick-fire comments. If the college is still facing the same time constraints in future, I would highly recommend breaking the presentations up over 2 weeks. Once all teams submit at the same time, there is no element of unfairness here. Personally, I would have no problem having to present a week before another team if it meant there was ample time, both to set-up and present.