Silo Execution Overview
In my use, “Silo” means to isolate. Isolation is this case means that everything is done through Entities, and there is a system for how that Entity will update.
When you boil down a game, there are just a bunch of Entities, Actors or Game Objects being initialized and updated which makes the game function.
An Entity is spawned in a position, and then will get an update call to move, animate or interact with other entities. If you’ve made games before, you know there are a lot of cases that have to be handled.
For instance, with a player controllable entity character, you can have them playing the Idle animation. Then the player presses Crouch key, and you change to the Crouch animation, and then while they are holding it, they want to attack.
That’s a lot of state even if that simple case. Can they attack? Are there modifiers from attacking from crouching? As games increase complexity, these conditions grow and become very complex in terms of when things are possible or not possible, and then how they should be altered given the current state of things.
Systems like UE’s Gameplay Ability System help with some of this, making a system to put envelopes for changes over time and gating actions with requirements, and making changes to available resources.
It’s a good system, but it’s just one of many systems to manage modern games, and these many systems require a lot of understanding and coordination, which takes time.
The Silo Execution model was developed to create a pipeline for managing cases, so that at each layer you only pay attention to relevant factors at that layer, and you start with human understandable concepts like a State and a Behavior. “Normal” and “Waiting”. “Normal” and “Moving to Target”. “Combat” and “Attacking”.
Here’s the basic flow:
Everything in the game is an Entity. The level, actors, items, UI: all entities.
Everything in the game is done with an Entity. It’s the only resource.
Each Entity has a State Machine. This is a set of states and transitions. Standard.
All States transition via a set of Prolog Rules. If all the rules match, the transition activates and the state is changed. Transition States like “Normal→Combat” are full states themselves, and work the same way as “Normal” or “Combat” states will in their testing.
For our given State, there is 1 Behavior Set, which has many possibly Behaviors.
The Behaviors are scored using Prolog Rules against the facts of the Entity. The Entity facts contain all required data, such as awareness of other Entities around this Entity, closest Entity, last Entity to attack this Entity, many facts are stored in the Entity and available for Prolog to reason about.
The highest scoring Behavior is selected.
The Behavior maps 1:1 with a Logic Block Stack, which is a series of commands.
Each Logic Block can then do anything to the Entity, or send Envelope information to other Entities (damage/healing/trade), or call any engine function call, or external Logic Block stacks you made.
Logic Blocks have loops and conditions, and can use Prolog Rules as well, and are based on the Scratch programming language. Changed from dragging, to using drop downs as all possible options are already known, and you cannot select an incorrect command or value.
Programs will always work, but may not do what you want.
ex: You can’t crash from a typo, but you could set a duration to -5 and see something strange.
Here’s a flow diagram of what I just described:
The isolation that this causes is:
Every Entity only worries about itself, and has all the data about itself in itself
Prolog Rules work on Entity facts updated every frame, so once you understand Prolog it massively simplifies doing conditions and tests.
You can’t write incorrect syntax. You can’t enter incorrect data.
You could put bad data into text fields, but it’s validated.
Debugging is 1st class, in that every Entity has full trace information for every frame. You can see exactly all the data and decisions and results for every step, because they are put into a struct for live inspection.
Changing the Silo data can happen while the game is running. You can also pause, make changes, and just replay the same frame to see how it would change.
This will create a very different type of development experience from the common game engine and programming language.
Making games will be more like configuration and tuning, as the art assets are all put together and usable before they reach the Entity system, so the Entity system only has to tell the content what animation and direction to use, and it will be animated properly.
The Silo system is simple when you understand the flow, and each step reduces the amount of things you need to be concerned with. Here’s an NPC example:
State: Idle
Idle State behaviors: “Look for Enemies”, “Heal if Damaged”, “Pick Up Loot”
In the Prolog rules for the “Look for Enemies”, there is an enemy actor within distance and in visual cone. This becomes the highest scoring Behavior.
That Behavior has an associated Logic Block that will:
Set that enemy as a Target
Start Pathing to the Target
Position is updated
Direction set to face path direction
Each Logic Block Stack will not need to contain many Logic Blocks (functions/loops), because they are very isolated in terms of what they are dealing with. They don’t need to do many conditional checks in the Logic Block Stack, because the State and the Behavior Set already did that work.
If you needed a new type of action, you wouldn’t make a condition and split the logic, you would create a new Behavior and make the Prolog Rules score that Behavior higher in this situation.
This system will not be for a lot of game developers who want to write code and work in the normal programming flow, but it will be very useful for programmers or designers who want to purely focus on the game, and none of the infrastructure.