Traditionally there was a big divide between content creators and those who implemented it in the game. You made some sound effects and then a programmer wrote some code to trigger them. You made some animation, and then checked back in a few weeks to see if it worked. However, as the complexity of games increases and the amount of content that you must put into them goes up – there is a need for content creators to have control over implementing their own content.
In my department, I taught my sound designers how to script in Lua and it was a resounding success. We used it to bridge gaps in the toolchain, remove dependencies on programmers to implement content, and most importantly to improve our iteration cycle and drive up quality in the games. For them, it was an empowering experience that not only improved their productivity, but also allowed them to realize their creative goals in a way that would have previously been out of reach for a variety of reasons.
Let’s go over a why, and how you might go about introducing scripting to your content team, and then I’ll share a few of the catalysts that led us down this path.
Why do this?
Quality
Content creators who can trigger their own content, tweak it, tune it, and iterate quickly on this content are empowered to produce higher quality, more polished content. Additionally, programmers are freed up to solve hard problems instead of writing a lot of repetitive trigger code.
Confidence
Giving this ability to content creators provides them with a new level of confidence and ownership of their work, and drives a greater engagement with the product.
Productivity
Removing the communication gap, and communication lag between artist/designer and programmer can drive more iteration, and leave each party open to work at their own pace without dependency, and for them both to be able to focus on what they do best.
Necessity
Content in modern games is so complex that the days where it was acceptable to trigger a simple sound file in reaction to an event are long gone. Things need to dynamically react to an environment, mix seamlessly, and provide greater quality and variation than existed in the past.
You’re doing it anyway
All content comes either with a detailed design that indicates how it should be hooked up, lengthy specs, spreadsheets, or worst case – a long discussion at someone’s desk. Empowering creators to express this as script isn’t as hard as it sounds. Most of the thought process is already covered in the documentation – they just need to learn the syntax.
How do you do it?
Scripting
Scripting languages are common in game engines and provide a good balance between flexible systems that don’t require a custom toolset (a text editor is often enough!) – and a custom configuration editor that is “artist friendly”. Most scripting languages have a straightforward syntax and don’t require the rigid structure that most compiled languages do.
Allowing content-creators to control the relationships between the various values they are used to tweaking, instead of just tweaking the values is an immensely powerful tool.
Babyproof it
Anything your designers are going to touch, you want to make sure that they can call it repeatedly and it won’t risk crashing the game, or otherwise breaking the build. Most things are sandboxed or abstracted away from the core engine so that no sharp objects are available to non-programmers.
Don’t let them manage memory or resources
Anything that requires memory management, disk access, or otherwise managing any of the physical resources of the system is too far to be effective for a wide audience of content creators. It’s also asking for trouble if you let non-programmers delve into these areas – and will require ongoing support. As mentioned above, create bulletproof wrappers that let them load an asset and handle everything you can behind the scenes.
What are they going to want to do?
The main things you end up doing:
- Loading assets
- Triggering assets (ie. animation, audio, etc.)
- Adjusting realtime values (pitch, volume, brightness, etc.)
- Lightweight conditional logic
For us, this came about very much as an evolutionary process based on working with various toolchains, and in a variety of different types of engines, however there were a few key catalysts that spurred us forward to take the plunge:
Technical Gaps
There were gaps in our toolset and pipeline that didn’t allow us the tuning or configuration control we needed to realize our goals. Having a general purpose scripting language allowed us to simply write scripts to bridge those gaps.
Communication Gaps
We have a dual-location studio setup, and all of our sound designers are in one location, and sometimes programmers in another. When a lot of heavy tweaking and tuning is required, it can be utterly painful to do this remotely. Removing the need to have to communicate the exact tuning details to a programmer and putting them in the hands of the designers was a huge success.
Dependency Backlogs
As a central department, we support all the projects ongoing and our ability to work perfectly to a given team’s schedule is very restricted – so there were an increasing number of dependency problems. Removing the necessity of programmers to actually trigger and hook-up assets freed them to work independently on the framework, supporting logic, and event distribution – all with only placeholder assets or none at all. Then at later date, a designer can come in and flesh out all those event handlers with the appropriate content.
Improved productivity and quality were actually (nice) side-effects of trying to solve the above problems.
A few caveats/disclosures:
- Our low-level engine was fairly robust and had pre-existing support for Lua. We didn’t have to build this support in special-case, nor did we have to modify the APIs to support a lot of realtime automation.
- I am a programmer (even if that’s not my job title) and was able to mentor/support/audit the output and development fairly closely without having to draw on an external engineering resource.
- You need to confidence and support of your technical lead to believe that non-programmers will not mangle the build, and that the support will not be higher than just building tuning tools.
- Code reviews are a good idea, especially while learning.
It may not work in all development environments, or for all types of teams, but the growing complexity of content in games, and the desire to deliver highly polished experiences really necessitates that you allow your content creators to script their own content. Making general purpose, or even custom scripting languages available to everyone can really drive forward your team’s productivity and creativity.