Forensic Friday 72: The Great Data Migration + Cooks!
Hey Readers! #
Welcome to Forensic Friday 72. Hardly ever on a Friday though, unfortunately. This “week” Forensic Friday is going to be rather short as we have been stuck in the weeds with what we are calling (really just me), the “GREAT DATA MIGRATION”. We decided to transfer the entire game’s data from Unity’s in-house solution to a custom XML solution. The reason we did this? You can find out below! But first, we should touch upon some of the features we were working on up until this significant halt.
Cooks #
Over the month I have been working hard on bringing cooks to the game, which is one of the last major features until we enter a feature lock.
This is the general template for a basic kitchen and cafeteria.
Cooks will frantically try their best to cook as many meals as possible during work hours. The behaviour loop looks like this: Cooks will haul uncooked food into the cooler. Cooks will also haul clean plates onto counters in the kitchen. Simultaneously, cooks will try to make meals. The requirements to make meals are clean plates and uncooked food. These items are placed onto hobs and consumed, and then a cook comes over and cooks the meal. This creates a cooked meal item. Cooked meals are hauled to a food bar serving area in a cafeteria region, where they are stored indefinitely. During lunch hours, a cook will come and serve staff at a food bar, where staff will queue up to receive their meals.
Quite a lot of behaviour! The new NPC AI system is really showing its merits, as this would have been nearly impossible with our previous method. Or at least completely over-engineered!
One can imagine various extensions/upgrades to this like automatic hobs, automatic sinks etc which could make kitchens quite interesting to optimise. Further ideas we had to link it to other areas of the game was to have the dirtiness of kitchens affect cooking speed, and also grime on the floor affecting the walking speed of NPCs, which links kitchens quite well to janitors; another upcoming feature.
A kitchen and cafeteria are in use.
Right now NPCs don’t place their meals on the table when eating, but that is just a small area of polish. A bigger issue is our grime system. Currently, every piece of grime in the world is a separate entity, which unsuprisingly, isn’t very sustainable for displaying 10s of thousands of grime in the world. We’ll likely revise this soon, probably using chunked textures, and writing the grime sprites straight to the texture for each chunk.
The Great Data Migration #
We decided to do another refactor! Hopefully the last major one, but it is looking like it. Years ago, when we started this project haphazardly jumping into the deep end, we ran into a question of how to store and load data for the game. We looked through all our options and naively went for the easiest solution: Unity scriptable objects. Turns out, this was a big mistake, which took quite some time to boil up the the surface. This limitation was brought to light when we added mod support, scriptable objects and mod support are like oil and water. This brought our attention to other limitations that scriptable objects bring. The biggest one is the requirement to rebuild the entire game just to change data. We want our game to be completely decoupled from the build as so to make our mod support as good as possible. So we had to abandon scriptable objects. But what is the alternative? XML is!
Now the entire game uses XML to define and load data, and amongst a host of internal tooling I developed, it’s become pretty easy for us to define and edit data. It just took a whole month to get there! It has also introduced a lot of bugs! Which is both good and bad. Good in the sense that it brings us back to test old features which may very well have been bugged anyway. And it seems, for the most part, the majority of bugs we find were not caused by the refactor!
This refactor consumed my life for quite a few weeks, but it’s over. The diagram above should illustrate where we see ourselves. We just have a small mountain of bugs to fix, and then a handful of features to add. After that, we lock the features in and go through the process of tweaking the game design (with playtesting of course) which should bring the game to the standard we hope for. Exciting!
The next month will definitely push us into the game design territory, which is rather exciting!
Small Tweaks to Tiles Placement #
During this refactor I had a chance to revisit a bit of technical debt we have had for a long time. Since we started the project it has never been possible to place two tiles of the same rotation directly next to each other. But now you can! That’s all, not that exciting really :P
Case Closed #
That’s all folks, time to file this case away. We are rapidly approaching the end of the beginning of Containcorp’s development. In the shadow of the refactor, I have started to implement anomalies, which is quite literally the entire point of the game, so it’s good we finally got there! Next Forensic Friday, expect more news about that! Have a good week or month, the blog is basically monthly now! However, a lot of that was due to the immense amount of work the refactor took!
Case Closed.
The Team
Plasmarc Studios