Welcome back Fealtivers! It has been six months since my last update so I have many things to tell you.
Come along as I tell you a story about one approach to make a video game…
First, make a prototype
Making a video game is a much bigger project than you think it is. The game itself only a part of the final product, but the game itself is made up of many parts, and so on. The trick is to know what to do at the right time. In the beginning doing anything is generally helpful, but as the project becomes more complicated it gets easier to do a lot but accomplish little if you get sucked into important but not urgent work.
The first phase of any project is the prototype in which you want to figure out the rough idea of what the hell you are actually making and get a better idea of if you can do it. After a [little bit more than] year of mad-dash development releasing prototype-0.5.1 was important because it validated the lock-step deterministic engine I was creating. However, the dressings had all been piled on - things like buttons, and AI, and game entities/units - haphazardly just to get the damn thing to work. I think this is an important process because part of why assembling something that has many parts is difficult is knowing how those parts interact.
After I released the final prototype I hit upon having to make a critical decision. The code was running but chaotic and making any serious changes to how the game worked required me to go and dabble in that hot mess of code. I knew at some point I wanted to fix that: remove all the very specific bits with more generic bits that could be reused to create many different types of game mechanics. However, there were still many features to add to the game before it could even come close to being playable - without even thinking about the art or UX of the game.
In the end I realized that any new systems I added would, whenever the time came, have to be yanked out (including associated logic and UI stuff - a lot work lost) and replaced along with what I had already written. Beyond the measure of lost work, I also wanted to be able to enable a designer to do all these changes directly without requiring me to write code.
Second, make tools
“Tools” are the software you use to help you make your game. In the process of building the prototype a few people helped out with art and some editing of data files. Two things made the process particularly painful. First, once an artist finished a sprite it took a little bit of effort to put it in the game - so for stretches new art just sat there because I was too busy. Secondly, data files are a pain to edit.
Because the process was painful it was slow and ineffective, so these were two things I wanted to address with our new tools: Foundry and Loom
Foundry is a cloud-based system for managing game Content Packages and Assets. If you are familiar with Unity’s asset bundles its the same thing made out of tin cans and string. Though primitive (it uses Airtable for a front end) it gives content creatores (artists and designers) a place to upload new stuff and make it available immediately in the client.
The Content Package management (not Asset management) is exposed in the client for users to create, publish, download and delete their own packages. Content packages can be viewed and modified in Loom.
Loom is the editor for the game data, as well as the name for the technology that powers the game. All of the mechanics and objects in the game are defined as Loom objects that define data and/or operations. The Unity code implements different ways for Loom data to used and displayed both in the editor and as game UI and visualization (people, buildings, trees, etc).
At the heart of Loom are the object interfaces that define the sort of data the engine understands. These interfaces can then be extended by concrete classes. Not only can you create new logical “bricks” to extend Loom (and the game), but because the game simulation and the UI code are driven by the interfaces (and not the specific concrete classes) this process is simple and doesn’t impact the existing code.
And this is where we are. Working on Loom has broken barriers of what I thought the game would be able to do, and also given me the opportunity to lay a strong foundation for the gamedev work ahead. It has been hard not having a playable game for six months, but the future of the game has never been stronger.
This third phase is going to be about building as much game as we can with the Loom until we hit its limits, stopping to extend them, and rinse and repeat.
Now that the tools are ready to go, I think the game design conversations are going to start flowing again, and I am looking forward to sharing gameplay as it comes together.
Thanks for reading!