Most traditional game workflows look like this:
Programmers build the bare-bones gameplay logic for a new feature.
Artists replace the programmers’ placeholder art with stuff that actually looks good!
Thus, the classic production problem emerges: the artists can’t implement their visual effects until programmers build the systems that trigger them. Artists can always work on individual effects like particles in isolation, but there's no replacement for seeing what everything looks like together.
But what if the order didn’t matter? If we can define the exact places the artists’ and programmers’ work needs to connect ahead of time, then either party can start their half and the other can meet them in the middle. Our VR Game ElemenTerra was developed on a tight schedule with little room for bottlenecks, and so we designed an approach that enables just that using Model-View architecture (MV*).
Case Study: Icon
Let’s consider ElemenTerra’s “Icon” object, which represents a power the player can select using one of their VR controllers. The icon has several inputs:
Whether the icon is Focused (VR Controller is overlapping)
Whether the icon is Engaged (being clicked on)
Whether the icon’s associated power is Equipped
Whether the menu tray (“Palette”) that owns the icon is open
Whether the icon’s associated power has been unlocked
These inputs represent the object’s state, the logic that defines how it interacts with other objects. When state changes it triggers feedback, cosmetic audio-visual effects that communicate the new state to the player. On ElemenTerra, the state logic was defined by programmers in C# ¹ and C++, while that state’s feedback was authored by artists using Unreal’s Blueprints Visual Scripting.
Between the button state machine, unlock system, and menu tray dependencies, it will take our programmers considerable time before they have a working icon. So rather than having to wait for one, what if an artist could implement all their feedback events in isolation? The programmer could then attach their state logic to the artists’ feedback events once they finished their code. Enter: the Workshop Level.
¹ That’s right, C# in Unreal Engine! Read about how we did it here.
The Workshop Level
The first step of creating a new ElemenTerra object is to make a Workshop level with a UI widget that defines each input:
We then create an Unreal Blueprint for the object that has a placeholder event for each possible state change:
Finally, we script the widget Blueprint so that each UI element calls the appropriate event. And with that, our artists have everything they need to make the icons work! They can add a mesh, fire particle effects, drive material parameters, or trigger scale tweens, all using node-based visual scripting. As they work, the Workshop UI lets them simulate different states and test their feedback in all gameplay contexts.
Later on our programmers can code the gameplay logic imitated by the Workshop UI -- the button functionality, tool unlock system, and the Icon’s menu tray -- and hook them all up to the Blueprint events the artists created. Now the icon will work in the game as well as the Workshop level.
This handoff can just as easily work in the other direction, from programmers to artists, and the two can even work simultaneously! With the programmers working in pure-logic code and the artists working in the Blueprint asset, neither group has their hands on the other’s source control assets as long as the event interface has been established beforehand.
There are cases like in/out tweens where the logic depends on how the feedback is implemented, but these are easily handled by adding callback functions to the interface that let feedback tell logic when a tween is done.
MV*
If this sounds familiar, that’s because our workflow is an implementation of MV*, a family of patterns which are all about about separating backend state (the “Model”) from the user feedback (the “View”) that illustrates that state.² Because these are separated by an unchanging interface, programmers can work on the Model simultaneously with artists authoring the View.
Beyond bottleneck reduction, there are other advantages to this pattern:
By definition, MV* patterns result in nicely decoupled code. Each side can be analyzed, debugged, and profiled in isolation.
Implementing features around the Workshop UI makes them easy to test. Using the game controls to contrive edge cases can be time-intensive and inaccurate, but with this method artists can easily simulate all sorts of strange permutations.
² The most well-known MV* pattern is Model-View-Controller (MVC), but because we lack a true controller we use the M-V-asterisk term that encompasses MVC, MVW, MVA, MVP, MVVM, and a tangy soup of too many other acronyms.
Production vs. Entropy
When I read about strict development workflows, a voice in the back of my head always says “no way they stuck with that all the way through development.” Best practices always start off manageable, but gamedev is messy and eventually it becomes necessary to break the rules. So, how did our MV* workflow hold up over time?
As it turns out, pretty well! Some of the artists’ Blueprint feedback did affect gameplay logic (e.g. collider placement) and feedback that got too complex for Blueprints would occasionally need to be moved to C# or C++, but these were infrequent exceptions. Overall our codebase remained fiercely decoupled throughout all of development.
Where the workflow did break down was when redesigned features needed new inputs and thus new Workshop UIs. Towards the end of development we didn’t have time to maintain our Workshops, and many fell by the wayside. But if a test speeds up early development and needs to be trashed later on, that’s still a win! We’re shipping a game, not an Unreal project, and test levels are merely tools to that end.
Genie out of the Bottle
Addressing production bottlenecks isn’t just about increasing productivity: it’s about respecting people’s time. Both parties suffer when a block occurs; the blocker feels put-upon, the blockee feels helpless, and both have the cadence of their day interrupted. This is why it’s important to take the design of your pipeline seriously! With the techniques described in this article, we spare our teammates from unnecessary stress and leave everyone feeling empowered.
If you liked what you read here and would like to bring the benefits of MV* to your own production process, you can get in touch with Freeform Labs here. Until next time!
