Expedition 33 is ’95 percent’ made with Blueprints
Much has been made of Clair Obscur: Expedition 33 developer Sandfall Interactive’s production process. As you’ve probably heard by now, the smash hit game was produced by a studio that employs fewer than 40 people, and everyone in the game industry has a hot take about what made that possible (and often ignore the hundreds of other people listed in the game’s credits).
They’ve been so prolific that at a GDC Festival of Gaming talk from Sandfall chief technical officer Tom Guillermin and senior gameplay programmer Florian Torres had an entire slide advising the audience not to use their presentation as a roadmap. “This is not meant to be a tutorial or like a how-to guide on how to make games,” said Guillermin. “It’s a retrospective on how we made Expedition 33.”
But let’s face it, when your studio’s first game is such a highly-polished hit, everyone will obviously be trying to copy your homework. Developers aiming to learn about Sandfal’s process swarmed Moscone West, and let out a collective murmur of shock when Guillermin and Torres described how their small team of programmers supported such an expensive-looking game—they just used a near-vanilla version of Unreal Engine.
And they didn’t use Unreal Engine to write lines and lines and lines of code in C++. Expedition 33 was largely made with Unreal’s Blueprints system.
According to Torres, 95 percent of the game was constructed in Blueprints.
Is it strange for a game like Clair Obscur: Expedition 33 to rely so heavily on Blueprints?
For the uninitiated, Unreal Engine’s Blueprints system is a visual scripting tool that lets developers link “nodes” together to create different gameplay elements. It’s used to define object-oriented objects or classes in the game engine. For laypeople, this mean it lets developers assemble game logic by stringing together nodes of scripting logic without constantly coding in C++.
On Clair Obscur, this meant that Guillermin, Torres, and the rest of the programmers could hand off content and feature development to the studio’s designers and artists, allowing them to produce and test content in the game engine with fewer roadblocks that would rely on a programmer to create code.
Unreal Engine developers use Blueprints to different degrees. The system is deeply tied into Unreal Engine’s natural codebase, and if you need to modify the engine in any way, the system becomes less reliable. In fact Guillermin said that Sandfall has a very “vanilla-first” approach when it comes to using Unreal. “We take all the tools that are natively present and we push them to their to their limits so we don’t have to develop bespoke tools for the features and content of the of the game,” he said.
Photo via the author, slide by Sandfall Interactive
The only “modifications” they used were old-fashioned Unreal plugins like CommonUI, GeometryScripting, ALS (Advanced Locomotion System) and KawaiiPhysics (which one commentator on Bluesky described as “one guy’s freeware project for doing swooshy anime hair physics.”)
This practice isn’t commonplace because many game studios have unique needs for their game that may require them to modify their game engine. And the jaded programmers in the room who’ve spent years fighting with these engines certainly seemed thrown for a loop.
One triple-A programmer we spoke with later told Game Developer Sandfall’s process made sense—but it would be difficult to replicate on larger teams because of version control processes. They said that generally, Blueprints can only be “checked out” in devops tools like Perforce by one person at a time, so if a programmer needs to fix a bug in a Blueprint and someone else is working on it, that bug might not be fixed for several days.
But while the room shook itself out of stunned silence, others asked—is Sandfall’s strategy really that strange?
Clair Obscur’s Blueprints framework is old news for veteran devs
The benefit of live-posting through a GDC session is you get real-time reactions not just from the crowd but from developers at home. “What if I told you this is what usually happens?” posted developer Joe Wintergreen. “Kinda unsurprised over here,” commented UI artist and UX designer Jo Stringer. “You can get excellent results with out-of-the-box tools if you know what you’re doing!”
Some indie devs like Ghost Hunter Simulator co-creator Kim Aucuff Steiner and Age of the Deep developer William Davis even shared that they, like Sandfall, work entirely in Blueprints.
The back-and-forth feels like a small resurrection of developer debates that date back to the early days of visual scripting tools (that predate my time in the industry, to be perfectly clear). Some developers used to debate if the industry should use game engines or stick strictly to language-based frameworks.
Lurking under that debate is a fair concern. Everyone is uncomfortable with the idea of being prescribed a workflow that doesn’t fit their way of working, and everyone is worried about a world where relying on visual scripting tools can mean your company is blindsided by something like the Unity Runtime debacle of 2023.
But before we turn Sandfall Interactive’s choice of game engine and workflow into another round of discourse, let’s recall that Expedition 33 isn’t a magnificent game because of what engine its creators used or how they used said engine. It won over so many hearts and minds because of what the game’s designers, writers, artists, and performers created…using tools made possible by the programming team.
Just like Guillermin said—their experience isn’t a tutorial or a “how-to guide” for anyone making games. It’s just a helpful reference point for those who come after.
First Appeared on
Source link
