Posted by on 11 Dec, 2015 in Fragmental

Something beginning with F

As Billy explained in an earlier post, Fragmental is the product of a new experiment here at Ruffian; a small, multidisciplinary team working on developing our own IP using a rapid prototyping process. On paper it was an awesome proposition, but from a code perspective it presented an interesting challenge. While traditionally the projects we’ve worked on in the studio have been larger in scope, they’ve also been accompanied by larger teams working on them. In practice, this meant that there were always enough engineers to provide enough support for the art, animation and design teams to function efficiently. The question we now faced was what technology could we utilise to ensure our work flow remained as efficient with the move to a smaller scale team?

Over the last number of years we’ve worked with a variety of engines across previous projects, from our own internal tech which powered Crackdown 2 to more established third party engines such as CryEngine and, more recently, Unity. While these engines offered much of what we were looking for, they still required significant code support for each of the other disciplines to get their content into the game. In short, they weren’t what we were looking for this time around.

 

Powered by Unreal Engine

With some of the team having worked with the latest iteration of Epic’s engine previously on both personal projects and as part of some external pitch work, evaluation was completed swiftly. From full source access and multi-platform support to its powerful Editor and Blueprint system, it was felt that it would be perfect for what we were attempting with Fragmental. The Blueprint system in particular was flagged as something which had the potential to really free up the designers to try out new ideas without requiring much in the way of code support. With the decision made, a secondary objective of sorts was also soon set, just how much of the game can we build from Blueprints? The answer, as it turns out, was quite a lot.

The approach taken for the initial prototype was simple. On the code side, we pulled in various assets from the UE4 Third Person Example, grabbed the Character from the Shooter Example, tweaked movement to allow for our top down perspective and then hacked in support for four players. Over on the design side, Dave set about putting together a test level with a fixed camera over the arena so we could start testing basic gameplay mechanics. Looking back through the Perforce logs, it took thirteen check-ins before a single code file was added to the project. Not a bad start.

For those of you wondering what the first code file added was for, well if you’ve taken one look at our trailer or checked out the Steam Greenlight page during our recent campaign, you may be able to make a fairly educated guess. Yep, weapons.

 

boom

 

The Simple Art of Murder

Once we had multiple characters running around a level, the next step was to enable them to murder each other. Obviously. The goal with our weapons system at the time was, to quote Barry – former Ruffian Technical Director – make it modular enough that a designer can create a gun which can fire anything, even chairs if he wants to, with no requirement for code support.

I won’t go too deep into the technical side of the project just yet but, in the context of our above goal, the weapons system worked as follows. The base weapon class was written in C++ and contained the various meshes used to render the object in-game, base functions to control equipping, firing and swapping out the weapon and a variety of structures to hold projectile and gun configuration data. This data would be exposed in the Editor for the designers to tinker with while the base functionality of the weapon was made accessible to Blueprint so that it could be callable via a weapon reference in other assets such as the Character.

The general idea behind this approach was that this base weapon could then be inherited from by the designers to create new weapons and projectile combinations with ease via Data-Only Blueprints. The end result looked a little something like this.

 

AssaultRifle_BP

Part of the layout of the Assault Rifle Blueprint

 

Once the conventional weapons such as the pistol, shotgun and machine gun were in-game, the design and art team went to work creating new firearms of varying levels of destruction. More conventional weapons such as Rocket Launchers and Sniper Rifles soon followed and as the teams got to grips with the Blueprint system, more interesting creations such as the Disc Gun and Repulsor appeared. When code support was needed for iterations on existing designs such as a Homing Rocket Launcher, we were then able to jump in and quickly add the required functionality with ease. The system was working!

 

The Camping Grounds

As some of the design team worked on expanding and balancing our arsenal of weapons, others started work on a variety of new maps for the game. Watching how they evolved proved to be an interesting example of what can be achieved as Unreal’s Blueprint system is mastered. While the first few maps were largely static affairs with designs concentrating on varying flows to encourage different play styles, as soon as the team started playing with Level Blueprints things started to change dramatically.

With a little help from code, simple moving platforms transformed once static arenas into dynamic battlegrounds where spatial awareness became as much of a necessity as quick reflexes. Falling platforms were used to create frenetically paced homages to a variety of 80s arcade platformers and ultimately, the birth of the well-received Survival map types. Even the falling death spheres that Steve spoke about in a previous article have been re-purposed into massive rolling boulders which dwarf the player and provide additional environmental obstacles in larger scale Thunderdome-esque arenas.

 

Your Blueprints are bad and you should feel bad

Now, while this burst of creativity on the level design side may sound great, it did come with one rather notable caveat. As the Blueprints found in both Actors and Levels became more elaborate, their new-found complexity began to require more traditional coding principles be introduced in order to ensure they were not only more maintainable but that they also didn’t negatively affect performance. In addition to this, while the Level Blueprints allowed easy access to every Actor in the level, it also meant that any functionality implemented in them was unique to that level. This, obviously, wasn’t ideal in a game which was to feature around sixty levels.

These issues were solved by simply sitting down with the designers and showing them more appropriate ways of implementing what they had been doing previously. Chunks of functionality which required reuse led to the concept of Functions being introduced, inter-Blueprint communication required an understanding of Event Handling and liberal use of per-frame Dynamic Instanced Material creation led to equally liberal use of murderous glares from certain coders. Finally, in order to promote reuse of functionality across levels, we began to move the relevant contents of some Level Blueprints into the Actors themselves.

 

Design

This was one of the better ones, spot the problem

Beyond the Support Class

Of course, while providing support for the rest of the team continues to be an incredibly important part of our role on the project, the freedom Unreal has given the content team has meant we have plenty of time to work on other core game features. For instance, the fast level switching required in a game where rounds can last less than 10 seconds required the use of a fairly robust level streaming system, the mesh fragmentation which makes up part of Fragmental’s unique look needed to be implemented across a number of areas both in code and in Blueprint and the dynamic music scene which gives our levels that vibrancy needed to be completely written from scratch along with a custom asset type and Editor Module.

In terms of gameplay work, the feel of both the character movement and weapon handling is extremely important to us with Fragmental so we’ve spent a lot of time ensuring they felt just right. Our animation set-up has continued to improve with both new melee attacks and stun effects being added based on feedback from play-testing and the remainder of the character poses have recently gone in for the respective weapon types adding that level of polish to the look of the character that’s always nice to see when you get out of the prototype stage.

There is unfortunately one major exception to all of this talk about the positives of Unreal, its Blueprint system and how it has lightened the code load – Networking. Duncan – Ruffian Tech Director – has been looking into this rather substantial task and has found the process so far, rather bumpy to say the least. The process and complications encountered merit at least one blog post to cover in any form of reasonable detail, so stay tuned for that in the not so distant future.

As for me, I think I’ve rambled enough for now. Future blog posts from the code team should hopefully deal with more concise technical topics like those mentioned above, but hopefully this post gave you a rough idea of how the project came together from the perspective of the code team.