Bringing Unity to Cloth Cat – Games Development in Action!
Hello! I’m Shane Skuse, the Senior Developer at Cloth Cat Games, where I develop everything games and interactive, mainly using the Unity Engine.
My background is in Animation, where I worked on many children’s series. I became interested in creating rich interactive experiences using my visual skills. At first I used Macromedia Flash, remember that? Now it’s known as Adobe Animate but back then it was the engine of choice for 2D games. Sadly Flash wasn’t well optimised for devices and tended to drain the devices battery. Coupled with the need to have the Flash plugin installed and the emergence of HTML5, Flash went the way of the dodo, and so I had to find a new alternative.
After a couple of years, and a few HTML5 games later, I picked up Unity. It was a 3D only engine at the time but, with the help of a few 3rd party plugins, could create 2D games. It became an early replacement for Flash and was able to deploy to various platforms such as iOS and Android. Now Unity has native support for 2D and with its full shader pipeline and 3D engine I can create far more than I could in Flash, and deploy them to various platforms, including HTML5.
During my time at Cloth Cat Games, I have made many interactive projects in both 2D and 3D, creating games for our clients on various platforms, for televised game shows and second screen experiences.
In the early days, we tended to support the animation team at Cloth Cat by creating web games and apps for the animation series they were producing. These were mainly 2D projects and, whilst 2D is easier in terms of math and mesh calculations, it’s more difficult to create rasterised content at a high enough resolution for the retina screens of today. 2D Animation that needed to be imported into our games via Cloth Cat’s production pipeline came from rendered sequences from the show in the form of sprite sheets, large bitmap files with every frame for a character laid out in a grid.
This was not optimal as it created large downloads and required lots of VRAM, so a new solution was needed. We started to rig our character inside Unity and animated them using the tools Unity had to offer. However Unity is not a character animation tool and became cumbersome when dealing with more detailed models. As a result, when Spine2D came to the market – it’s an animation software that outputs a low transform data file with a parts only spritesheet that can be re-assembled and run inside Unity – it quickly replaced our Unity animation pipeline.
Today we tend to build more 3D games using Unity’s Probuilder for white boxing with final bespoke assets made via Blender, and have started to develop our own games which is a very fun process! We feel like we’re able to build anything we need, and are often required to think outside the box due to high ambition and budget limitations.
Our Unity Framework
In the past, Unity was unable to serve all our needs so we had other frameworks in place to build content. We had a large HTML library we used to build WebGl games with for example. However, as Unity grew and added more platform support we felt we could drop those frameworks and adopt Unity as the one place we could build games and interactive experiences in and consolidate our code base.
For this we’ve created a large C# framework that lets us build games quickly. This framework manages all the Unity scenes, loading sequences, registering active core game controllers while making sure any dependencies are loaded and injected to the correct places at the correct time.
We also have a large UI library that extends the Unity naive library. This library allows us to quickly create any menu panels, popup or user interface a game might need, whilst also allowing us to load a menu in its own scene allowing for collaborative work and testing as we make sure the menu scenes can run independently without the rest of the game. We’ve made sure that this framework is scalable. Every part of the framework acts as a wrapper system, so what’s inside can easily be changed if required from project to project.
A good example for this would be our save system. A central system with various api calls for saving and loading. By default the system just serializes the data to be saved via Unity PlayerPrefs. However the inner module can be updated to save another way.
This framework has not only helped us build games faster. It also gives us a common code base. I’ve often found myself having to pull down a project that’s a few years old, and whilst it might use an older version of the framework it has a familiar pattern so I know what’s where. Coupled with good comments and documentation it’s easy to jump back into something and get project momentum.
Case Study
Transport for Wales came to us just before we broke up for Christmas and requested a quote for a game. This had to be a quick turn around as it had to coincide with the launch of their new fleet of trains. So as a team we had a quick ideas session and a one page pitch was sent.
The next year after the Christmas break we found out we won the bid and we started laying out the foundations of the game, Route Wrangler. A 12-level HTML5 puzzle game that needed to be played on school computers, mainly Chromebooks.
In the first stage, we started by white boxing one level – this level should have all the modules we would require – a spline based train system, a dynamic track system that the player could manipulate and a scoring system.
With those parts in place, we white boxed up a few more levels to make sure the kit of parts could be reused in other situations. When we were happy we laid out the other levels in a simple ‘white box’ form.
We could then move on to the second phase and task our asset developer to create the final track parts and the train model. While that was being done the levels were getting tweaked and balanced, code was refactored and the landscape around the track was built in-engine, using Unity’s Probuilder.
Once the basic assets were finished and implemented, we could move onto the third phase, where our asset developer could move on to making cosmetic items, such as buildings and trees, while the development team could switch to the other aspects of the game such as, train customizer, level select, home and results screen, creating more placeholder assets for future development.
Using the new assets as a kit of parts, the development team could populate the terrain with all the trees and buildings whilst adding lighting and postprocessing effects to each level. During this process, the UI team started to design the screens using the developers placeholder screens as a guide.
With UI designed and exported the team moved onto the fourth phase, replacing the placeholder UI and implementing anything new that was required, such as language switching and a high score table.
Once happy with the final game and look, we moved on to the fifth phase, an optimisation pass, to make sure it ran at a decent frame rate on the targeted devices. Sound was developed and implemented into the game. We tend to do sound last as we like to know what the final game looks like and match our sounds accordingly. That being said some placeholder sounds might be used if we feel they are already good enough!
After, all that was needed was to create a custom HTML5 template with a branded loader for the game to be served on, with another round of testing.
Using our framework to get us started, this whole process took around six weeks of time with the client updated at each stage and was very happy with the final result.
Hints and Tips
In conclusion, I thought I would share a few tips that I’ve picked up over the years, hoping it will help anyone building a game, solo or part of a small team. Good luck.
Invest in Tools (But only when necessary)
Creating some tools can help avoid user error and speed up development. It’s important to note that tools should only be created for anything that involves lots of manual steps, make sure you really need the tool and if it’s going to save you time. You might also be able to find a tool on the asset store that does what you need.
One small example of a tool we built, was one that used Unity Asset Importer to detect when a new character rig was imported. It then created the ragdoll system, set up the animation system and created player and menu prefabs. This was a great use of time because I was constantly updating the characters and importing new ones. The use of the asset importer was great too, because we didn’t need to build any editor controls for the tool; it was just automatic.
Never Optimise Too Early
It can be tempting to start optimising your code and assets from the start. I’ve always tried to avoid this unless there were some obvious ones I could quickly do. Optimising too early can create complicated code that you and the rest of the team might find hard to adapt/grow as your project does and I’ve seen/done very complex setups that don’t tend to increase performance at all or, was just overkill! Instead, wait until various test bench marks and only refactor the things that spike during performance monitoring. This not only gives you the before and after results build, it also allows you to develop/change systems quickly and recognise if they are integral to your final game.
Asset Size
Watch out for large assets in your project. Make sure the assets in your game are the biggest size you will ever require. Unity does have ways to downsample per build target, however, never put files in your game that are larger than your highest target and never have construction files in your project like PSDs or Blender files. Large assets in the project can bloat the Unity Editor and make it slow when switching platforms, importing or building and also remember your source controls storage and download costs!
Compartmentalise Assets
Find ways to separate your project up as much as possible. Unity has various ways to achieve this, using scenes, prefabs, timelines and scriptable objects. Making things granular can help split up a development team, each working on their own assigned assets. This helps avoid overriding others’ work or merge issues when dealing with source control. It’s also good practice to do this when working as a solo developer as it keeps things organised and allows you to scale your team later.
Use Source Control
Even when working alone, I would recommend using some form of source control. There are plenty of free tier accounts, Bitbucket, Git and Unity have their own. The use of source control allows you to roll back changes to files, debug issues by allowing you to see what’s different between two versions. When working as a team, it allows you to sync all team members’ versions with the latest changes and tracks what developers did.
Rapidly White Box
Try and build as much of your game as possible with basic assets. This could be simple primitive shapes, or brought assets. Unity does have a Probuilder that allows you to build some basic geometry. White boxing as much as possible allows you to highlight areas of the game that will require more bespoke assets or systems, and reduce your development costs as you won’t be wasting time developing/creating things you don’t require.
Cloud Build
Try to set up some kind of cloud builder. Cloud builders offload large builds to another machine, freeing up your development machines. They also allow your other team members to submit build requests for the platforms your cloud supports. IOS development is a great example, not all your developers will be able to build as it requires a mac. We tend to use Unity’s Cloud but there are other services, most cloud services will pull your project via your source control.