This going to be the first of a number of articles sharing a rundown of our tools and frameworks, both from the Unity asset store and from our own original toolbox, and all the ways they're contributing to the production of StarCaster. In the instance of asset store tools I'll also be sharing the tweaks and additions that I usually make in order to tailor them to my needs. I've made projects like this often enough to have a lot of go-tos for both getting projects like this up and running quickly as well as looking ahead at making the pipeline easy to work with for future content.
Reinventing the Wheel and When Not to Do It
Before we get into specific toolsets, I'd like to take a bit of time to unpack when it's a good idea to engineer something yourself versus when you should pick tools off the shelf.
My MO for building games is that content should be fast and fun to build above all else. Avoiding reinventing the wheel is a big part of ensuring that's the case, and in a lot of instances the Unity Asset Store has tools and frameworks that are far and away more polished and better supported than what I could hope to build from scratch. This doesn't make game-specific logic or the interactions between all these frameworks any less work for me to do, mind, but it definitely makes it smoother and makes it so that I'm able to focus more on the game rather than on tools that aren't useful outside that one project.
Basically, think about the number of hours you're going to spend getting a tool to the level of polish of an equivalent from the Asset Store. On a live production it's not unusual for a programmer to take ownership of an entire tool or sub-system and devote hours per day to adding features, troubleshooting with other team members, and otherwise just performing maintenance on this one thing in the game throughout the entire production. Servicing something like a dialogue system can quite literally become your full-time job, and a little bit of time each day will trickle into something like an audio pooler or the music playing system.
Looking at it from a dollars and cents point of view probably clarifies it a lot more. Something like Master Audio might cost $40 per seat on the Asset Store... but you'd spend around $15,000 worth of programming man-hours re-creating your own version of it and still wind up with something buggier, less flexible, and less polished. Even supposing you have a team of 30 people and have to buy a license for every single one of them, it still costs better than 10x less to just buy the pre-packaged tool for all of them and integrate it into your pipeline. This isn't to say that off-the-shelf is always the correct solution; if you've got a really, really clear handle on your game's specific needs with a given system and they aren't especially broad then you can cut a lot of unnecessary performance overhead and create sort of a "fast lane" for your project's content, especially if the execution of your game is going to be rigidly consistent. But, especially for the most general, basic, and adaptable tools, even for tools that cost in excess of $100 per seat, it's often way more economical by a huge margin.
Mainstays of the Asset Store
Here, then, are a handful of what for me are some of the must-haves from the Unity Asset Store. I'll share some more remarkable ones with more complex integrations at a later date, but for right now these are all tools that are neatly compartmentalized, speak for themselves right out of the box, and cover incredibly essential basics of game development that really should be part of the engine.
ProBuilder is now a part of Unity, but originated as one of the most popular Asset Store frameworks. It's a geometry-building system specially suited for level design, not that dissimilar from how you'd build geometry in Hammer or the Quake engine. While not necessarily ideal for final ingame art, it can block out a functional gameplay environment very, very quickly. This is a process that's referred to as white-boxing or grey-boxing.
The alternative is modeling prototype environments inside Maya or Blender, which can lead to much more efficient or optimized environments owing to draw call reduction, but it also yields a lot less immediate/hands-on capability to do level prototyping and a lot less capability to edit during live gameplay. To get the best of both worlds ProBuilder has a feature that can export level geometry so that you can use it as a base inside a program like Maya, thus allowing users to move from a simple ProBuilder grey-box environment to an optimized and beautiful-looking finalazed environment.
It's a tool whose utility rather speaks for itself, and has become a staple of 3D Unity game developers for an obvious reason.
This is a tool that really should be a part of Unity. DOTween is a tweening library full of extension methods for easing values of all types, be they transform variables like position and rotation or be they more abstract values as part of code. Any number-based value can be tweened, and since most functions return the resulting Tween, many commands can be chained together in order to script complex pre-programmed behaviors, including events that fire off on Tween end and changes to the easing curves used by specific Tweens.
Provided that there's nothing that would cause an object's trajectory to change, it's an extremely useful tool for a huge number of applications, including UI transitions and pre-scripted ingame motion. It's not a hard type of system to build for yourself, but Demigant's offering is definitely one of the most robust and clean.
To finish off today's round-up, at least until the next one, I'll cap off with a system so basic and fundamental it's hard to believe that Unity doesn't fully address it themselves.
Basically, Unity has the ability to play sounds through Audio Source objects, but there can only ever be one sound per audio source at a time. In Unity 5 they added a few quality-of-life utilities that make the overall management of sound effects and their data a lot easier, but handling playback and allocation of audio sources is still a very involved process with a lot of manual rigmarole. To address this, Master Audio consists of a number of sound buses with a finite pool of "voice" objects that can play back sounds. Instead of spawning a sound effect, think of it like having a pre-set number of audio players in a scene that move around from place to place as playback commands are given to Master Audio, with different "categories" of these voice objects set aside for different sub-sets of sounds.
This is known as object pooling, and it's not dissimilar to how Mega Man's three-shots-onscreen limit works; it just happens that this is a convenient model for managing sound effects too. While you could theoretically spawn-and-destroy them, the frequency at which this happens would cause a lot of undesirable memory fragmentation and bog the game down with a flood of garbage collection, so pre-allocating sound players like this tends to lead to much more stable performance. Aside from that, having a hard limit to how many sounds can play over each other at a time is just terrific from a quality of life standpoint. With the different sound buses for voices established, playback is just a matter of picking what sound you want to play and where you want to put it, then letting the system sort out allocating a voice. It's such a natural evolution for an audio system that, in the past when I've tried to make my own, something I realized after getting through a few iterations of it was that I was basically moving towards something nearly identical to Master Audio anyway.
To top this off there's a bevvy of useful tools for managing both playback and the memory footprint of sound. The system configures sounds via what are called Sound Groups, which are essentially sets of audio files and playback/modulation settings. Within a Sound Group you can collect a variety of different clips that represent the same sound, make the system choose which one to play back randomly, then randomize their pitch and volume for an additional layer of variation. For things like gunshots, footsteps, punches, hits, animal calls, and other ingame sound effects this is invaluable for keeping sound feeling fresh. Sound Groups can be embedded into the Master Audio prefab itself for the most frequently-used sound effects, or they can be created through Dynamic Sound Group Creators, which load their audio files into Master Audio on Start or Enable and unload them on Destroy or Disable. This means that sounds are only loaded when the objects to which they're relevant are in the game. Meanwhile for music there's a separate sub-system called the Playlist Controller, which provides a lot of fine control for playback and transitions between music tracks. In addition to all else it's got a lot of options describing how sounds are loaded, whether it's pre-loaded into memory or whether it streams from the hard disc. With voice and music tracks especially that can mean a lot for optimization's sake.
What few embellishments I have to make with this system typically revolve around an Audio Manager that interacts with both Master Audio and Unity mixer groups, enabling the saving/loading of master sound levels per the ingame options menu. If nothing else with the giant pile of parameters that Master Audio passes in and out can be a little overwhelming and it helps to make alias functions that shorthand the most common use-cases with less room for error. Apart from this, though, Master Audio is in itself basically a fully-featured audio manager right out of the box and is a perfect example of a great tool that stands on its own.
This round-up mainly consisted of tools that don't need a lot of work to be integrated into a game project, their utility being obvious regardless of what type of game you're working on. For the next round-up we'll go into some tools whose utility is much more specific, and how they apply to our exact genre as a traditional RPG.