Hi! I’m A. Beauchesne, a game engineer at Filament currently working on RoboCo. I’d like to talk a bit about how we implement RoboCo’s levels. Along the way we’ll discuss some of the level design challenges we’ve faced, why programmer time is a precious resource, and RuleScript, our scripting solution.

Introducing RuleScript

RoboCo’s levels are developed using RuleScript, our custom scripting tool. It’s an event-driven system that allows designers to define level objectives and script object behavior in a flexible way while minimizing the need for a programmer during level implementation.

RuleScript is broadly composed of two parts: entities and rules.

Entities are objects within a scene. The system doesn’t impose restrictions on what can be an entity, only that it is an object in the level. Crates are entities. So are robots, logs, sawblades, and dust clumps. But entities aren’t just physical objects. Invisible collision zones are entities, as are timers, counters, and the level objectives. An entity’s behavior is defined, in part, by the components attached to it. Components are intentionally kept small, reusable, and maintainable.

Rules define both procedural and reactive behavior for entities. When an event occurs on the entity, known as a trigger, the rule defines both the actions to take and an optional list of conditions under which that set of actions will be taken. If written out as a statement, a rule says, “IF [a] occurs, AND [b] is true, THEN do [x y z]”, or, if there are no conditions, “IF [a] occurs, THEN do [x y z]”.

Some examples of rules would be:

“IF a candle enters this zone, AND the candle is lit, THEN complete the candle placement objective”

“IF the crate enters the pit, THEN move the crate back to the top of the conveyor belt and randomize its size”

“IF the level starts, THEN wait 5 seconds to move the door into the open position”

Let’s look at what it takes to implement a portion of the Bistro Challenge in RuleScript. The primary objective for the player is to bring the sandwich to the table. Using a collision zone, we can detect when the sandwich enters the zone around the table. With a rule on that volume, we can respond to that and set the objective as complete. When the sandwich exits the zone, we can similarly respond and reset the objective.

In the RuleScript system, objectives are intentionally independent from the conditions required to activate them. We don’t hardcode objective types based on what needs to activate it – we don’t have Move Object Objectives, Break Object Objectives, and Ignite Object Objectives as separate types – and that allows us to be exceptionally flexible with what completes an objective and when.

But why do we need such flexibility? There are a lot of different ways to design an objective system – why this one? Great question, hypothetical question asker! For that, I’m first going to step back a few months to when I joined the team and provide some context.

The Challenge of Designing Challenges

RoboCo is a game about designing, building, and controlling robots to accomplish a variety of objectives for humans. We’ve already got a robust (and ever-improving) toolset for building robots, as well as a flexible control scheme for moving them around, so let’s talk about the other two parts, designing the robots and completing objectives.

Keeping RoboCo engaging requires we give players objectives that make them design robots with different engineering challenges in mind. If all those objectives could be completed with the same basic robot design, we wouldn’t be asking players for a lot of critical thinking.

This means that for our levels:

Players must be challenged to build different types of robots

Therefore, players need to think about different types of problems for each objective

Therefore, objectives must be different enough to present a variety of engineering challenges







Level design for this game also presents some unique challenges in the form of player verbs. In general, good level design starts with an understanding of the player’s verbs and limitations. How can they interact with the world? How can’t they interact with the world? What can I, as a level designer, build around those restrictions that presents a unique challenge for the player? But those rules are not as well-defined for RoboCo. Character-driven games often have clear verbs and limitations – for example, in the recently-released Untitled Goose Game, players can drag things and make noise, but their size and strength as a goose is limited. Games centered around automation also have verbs – for example, in Opus Magnum, players can put together parts with predefined functions and script their actions on a timeline, but those actions are predictable and constrained to the kinds of puzzles the player will encounter. But for RoboCo? We have two sets of verbs to contend with: those involved with construction and those the player defines for themselves through that construction. While we know how players can build robots, there are far fewer assumptions we can make about what actions those robots can take.

All put together, our levels must satisfy some difficult constraints:

Objectives must require different kinds of engineering thinking in the design phase

Objectives must be varied enough when controlling the robot to avoid being repetitive

Levels must not overly restrict the player’s robot designs

Levels must not make overly restrictive assumptions about robot actions

Not an easy set of constraints to get right! There’s a long road from the basic concept to the fleshed-out level that satisfies those goals. Those concepts require lots of iteration, and some just don’t work out. That’s why prototyping those ideas is an important part of our process.

Prototyping, or: Programmer Time is Expensive!

When I came onto the project, our level prototyping tools were limited. Our designers working on challenges at this time weren’t necessarily prevented from building levels if the game didn’t support a particular type of objective. As long as they kept track of those objectives themselves and acted as the judge for whether they were completed, it was certainly possible to test out ideas. But it was more difficult to gather feedback on those concepts without either trusting the player to judge the objective for themselves or hovering over the player’s shoulder. If a level required more complicated interactions – timed events, buttons that interact with the environment, reactions from the in-game humans – then the designers were left to either modify the scene directly while playing, which is time-consuming and error-prone, or to ask for assistance from a programmer.

As a general rule: programming time is expensive. RoboCo is a game that requires a very robust toolset for players, and some things you might take for granted, like an undo function, are actually quite complicated to implement well. If our prototyping process requires significant programmer support, then that detracts from time spent implementing our sandbox features as well as introduces a frequent blocker for our designers early on in our level pipeline. We’re a small team with limited resources, and an inefficient pipeline like this is a major obstacle.

We needed tools that our designers could use to quickly prototype levels without programmer intervention. They should be able to test all kinds of new objectives without needing to go to a programmer and asking them to implement a new kind of objective archetype. They should be able to make the environment respond to the player and create simple scripted sequences. They needed a scripting system…

RuleScript: A Long-Term Investment

…which brings us back to RuleScript! This was the most logical and time-effective approach we found for giving prototyping power back to designers. While a hardcoded approach for scripting would be faster in the very short term, the quality of the project would suffer over time. Off-the-shelf solutions like Playmaker or Bolt – both popular visual scripting packages for Unity – were certainly options, but since their tools are built for the Unity editor, those would limit us in the future should we decide to open level scripting up to users. And of the two major options we weighed – node-based scripting and rule table-based scripting – node-based scripting required more work, more onboarding, and more maintenance.

We chose to invest in a long-term solution with RuleScript. While this required some up-front engineering effort to develop the system, along with some additional onboarding to help designers understand how to use it, it’s already demonstrated its worth. Since it was made available to the team, we’ve had significantly more prototypes with higher quality interactions than ever before on this project. Several of them are very exciting, and we hope to bring you all a more detailed breakdown at a later date.