Announcing the Silo Engine
A 2D focused game engine for shipping games faster.
A game engine is a pretty big piece of software, so I will start by just describing my goals and the basics of the engine in this post. It will take some time to develop a really good message to describe everything, as there are some new ideas in this engine.
Intent: Ship Games Faster
All game engines are made with the intent to make games, but how much they help you get a game into the hands of a player is different for every engine.
I’ve used Unity for 13 years and Unreal for 1.5 years, and both of them are professional engines that provide professional tools to build games. However, their tool chain is fairly disconnected. It takes a long time to do everything, and there are many things that must be done.
In Unreal, it is more streamlined, as the Unreal engine comes from the Unreal series, 1000s of licensed games, and that being the case shipping the game has a lot of tooling.
For Unity, the company itself has never created or shipped a game, and the tooling for shipping is poor because of it. Everyone has to figure out how to get their finalized UI and scenes working. This is a lot of freedom, but the penalty is a lot of time to organize and do it.
More than that, even when you make a library of your UE or Unity workflow, it takes a lot of time and effort to create 2 different games that use them.
Gamedev is slow: Sales are hit and miss
If you spend 12 months on a project, and you make a small portion of what you need to actually live, then gamedev is just unsustainable as a career. I believe this is the biggest problem everyone is facing now.
It takes too long to find out if anyone is interested in your game, and it takes too long to change an unwanted game into a wanted game.
We need to be able to make games faster, and get them to players quicker, so we can become better game developers, and give players better games, which then make it possible to live on game sales.
This is the problem that I am aiming to solve with the Silo Engine.
Integrated Content Pipeline
How will it be faster than Unity, UE, Godot, etc?
Firstly, I am focusing on only 2D content for the Silo Engine. 3D content has a very large content pipeline, and while it is fairly mature, it is still in flux and just makes things too complicated. So for the timebeing, Silo Engine will only focus on 2D content and making 2D games faster.
Having to jump between different tools, deal with file format conversions, image sizing or other matching problems to get content into the engine takes a lot of time.
I have integrated this into the engine to make it very fast. You can import a small games with a content in just a few minutes and have it on the screen.
Not having to leave the engine, not having to mess around with the files yourself or doing conversions, is one step of the end-to-end Content Induction automation.
Integrated Development Environment
The Content Induction pipeline makes it fast to bring in content, but then you have to create logic to manipulate the content.
Silo Engine has an IDE inside it, and the entire process of game development has automation workflow applied to it, so that you need less code, which takes less time.
How can you code less?
The Silo Engine is named after this “Silo” development process which works like this:
Everything is an Entity
On update, all Entities will:
Determine their State using their assigned State Machine
Determine their Animation State using their assigned ASM
Use Utility AI to score all the Behaviors in the Behavior Set for that State
The top selected Behavior is a “Logic Block Stack” which will be executed
Logic Blocks are functions/loops/conditions that modify the Entity data
Prolog is used in place of both conditions and search for most situations
In flow form the Entity update looks like this:
State → Utility AI → Behavior → Logic Block Stack execution
Prolog is used at State, Utility AI and Logic Block levels to remove complex conditions, and use the Prolog system for making advanced inductions, deductions, and logical queries.
What does this give us?
State gives us what this Entity is doing. Are they sitting idle, walking somewhere, in combat? Is this Entity an NPC, or the Player avatar, or a UI item, or the level itself, or a timer? Entities can be anything, whether they have content seen by the player or not.
Having a State Machine to start everything gives us a Life Cycle for every entity. Birth to Death, we know what they are doing.
Using an Animation State Machine for the animations, allows our State to either directly dictate Animation State (Attack → Attack) or maybe it is more complex (Parry → Attack, Attack → Attack).
That allows us to focus on only 1 set of circumstances we need to handle for this Entity.
Similarly, once in the state of “Parry”, maybe there are many behaviors that are possible, so we link State directly to Behavior Set, which is a group of Behaviors.
We use Prolog to determine if a Behavior is valid and what the scoring should be for it. Prolog is a early AI programming language (1971) that never was a commercially viable due to being slow and such, but I have implemented Prolog as lightweight logic tool, that allows us to create some really cool connections. It’s completely deterministic and local, not like an LLM.
The Logic Blocks are based on the Scratch programming language
Scratch uses dragging of blocks, but this is slow and better for children that are learning what the different components are.
I’ve made this fast and error-resistant in that you just enter text or select available options. You can’t program incorrectly in Silo, like Scratch. You may not get what you want, but it will always work. This will also speed up development time.
Batteries Included
1 desktop timer app has been finished, and 1 desktop pet toy is in progress, and I will keep making and shipping larger and more complex games that cover more gameplay genres after those.
The concept is that there are a limited number of functions that all games need, but the list is not small, and there are no published lists of “you can make any game if you have X functions to do it”.
So, I’m going to keep building and releasing different games until we have a comprehensive library of all the required core functions, so that when you do the Logic Block coding, everything is available with a minimum of steps.
Patterns will be worked out and tested, and turned into automated workflow features if they are core, or left as functions if they are optional.
The goal is to allow you to build any type of game in 2D, but not have to create most of the building blocks to do it, because they already exist and were tested on many released games already.
You can’t use the building blocks wrong, because the Silo system doesn’t allow you to write incorrect code, so you only need to mess with the code until you get the results you want.
This should make development faster. Removing the obstactles of compilation. Removing the obstacles of stopping and starting your software, the game is already available to run without any preparation in the IDE. No time delay between making changes and testing them in the game. No separation between Play and Edit besides changing the editor mode, or launching as a game instead of the editor. They are the same executable.
I have a lot to say about how debugging is integrated as a first-class citizen, Silo has a Trace system that captures every output of your code and state and behavior decisions every frame, so you can always see why your program did what it did.
I also keep the last frame’s trace, and I allow you to re-run the same frame again, and Silo has A/B testing for Prolog rules built in. There is a lot of detail in the debugging and introspection system in Silo, too much for this introduction.
What is the Silo Engine written in?
The Silo Engine is written in Zig 0.15.1 and uses Raylib for graphics and media.
It’s written from scratch, and use Sqlite 3 as the database backend, but all the data is loaded into memory with O(1) access.
I use a path based access system to all data, such as: `game.scene.1` which is:
Database: `game`
Table: `scene`
Record ID: 1
This keeps going, so you can reference embedded structs in the records (serialized to JSON in Sqlite):
Actors list: `game.scene.1.data_scene.actors`
Actors 0 name: `game.scene.1.data_scene.actors.0.name`
All data in the DB and structs gets a Property Panel and other things for editing created automatically:
Who is working on it?
My name is Geoffrey Howland and I created the Ludum Dare game jam.
My goal in 2002 was to help people finish games, and make realistic scopes for games, which is why the original competitions were 24 hours, then expanded to 48 hours so people could sleep.
The Silo Engine is another pass at this problem, but working on shipping games to players instead of making fast prototypes.
I wrote Silo over the last 11.5 months, and have the first “game” (desktop timer) ready for testing on Itch.io, as soon as I have finished the second game is ready, so I can test them both in about 2 weeks.
Timelines: It’s early, but my expectation is 1 year of private development with feedback while I ship 10+ games to test different features and expand what it can do easily. After that I will start a private Beta with active community members, before a public Beta.
Current early plans for costs would be free to use, and some similar percentage to other engines after passing the revenue threshold. The goal would be to become a professional game engine focused on 2D games and fast development times, and be funded by games who used this successfully.
How you can help
This was an introduction to the Silo Engine, and my intent with creating it.
I am looking for people interested in this project to point out the 2D features they want in games that exist now, or workflow problems they have had to ensure that Silo has a good solution for them.
Here is the Discord server I’m setting up for discussions.
Come in and tell me what interests you about the project.
What I’m looking for on Discord:
Where is your workflow the slowest?
What do you consider your major blocks to shipping?
How much time does it take to prepare a build and demo when you push a new launch?
What elements of preparing art and getting the art used in your game are obstacles?
Anything else that is slow or an obstacle to your workflow is what I’m looking for to make sure I’m not missing things I should be including in the automation workflow.
Thanks for reading, and I look forward to creating a community around the development and eventually launch.