Our team entered Ludum Dare for the first time in October 2019. It was 72 hours, and so with 7-8 hours of sleep each night that came to about 48 hours of work time for our team of two. Having done a bunch of puzzle games before, and games that we knew we could finish on time, we wanted to do something completely different. We decided to go for a simulation game, something both very different and very ambitious for 48 hours.
The focus of the game was to make something that we’d never done before, that really pushed our knowledge and abilities. Even if the game ended up being not very fun, or complete, as long as it did some cool things it would be a success. I think our final result more than satisfied that, we had so many cool features that we tried out and above that people actually enjoyed playing the game.
The design philosophy was to split the “simulation layer” from the “presentation layer”. All of the simulation would happen independent of the gameobjects in the scene, and then those 3D models would just have to replicate the underlying state. This meant that we could simulate as few or as many “simulation ticks” as we wanted per second, allowing for very easy speed control implementation.
Each in GameObject had an attached SimulationElement object. There were a few different types, such as Structure (buildings), Nature (resource collection points) and Actors (element that can think and act). Each simulation tick called an update function on all elements in the scene, this could be done multiple times a frame if necessary, as the presentation was split from the simulation. The 3D objects would then have to catch up with their new state the next frame.
We added a system that we liked from The Sims, with radial menus for actions. When clicking on a SimulationElement, it would give you a list of all possible interactions you could do on it. Adding new interaction was as simple as adding a new item to that list. We actually forgot to take one of the test actions out, so it’s possible to “Chop Down” a mud hut. The mud hut doesn’t have any behaviour for being interacted with a “chop down” action, so it won’t take any damage, but it’s still funny to see.
Towards the end of the first day we started working on the UI for placing buildings. Drawing (heavy) inspiration from the 2013 SimCity game, the aim was to have a system of Asset objects that could be dropped onto buttons and then the UI automatically generated. This would give the ability to add new buildings and new “shelves” without needing to lay out any additional UI or write any extra code. This took a few hours to get right, but when done worked exactly as planned. Ultimately we didn’t get enough 3D models done to fill out all three shelves, but it looked so nice that we left it in anyway.
We relied very heavily on the Unity ScriptableObject system. Instead of defining the properties of our elements on the prefabs or in the scene, we made .asset files that contained this data. Each SimulationElement had a slot for a SimulationProperties, and this would show up on the screen whenever the player asked for “More Info”. This information would be the same across all SimulationElements of the same type, so there was no need to have each instance contain its own values. The most important part was that new .asset files could be made or edited without needing to write any code, or even open a code editor. It could all be done from inside the editor.
The second day was a lot of getting content in, such as the 3D models and animations. We also decided to implement a “rabbit hole” system. This was again borrowed from The Sims, where you could send Sims off to certain locations, and then they would disappear much like a rabbit into a rabbit hole. They’d come out at the end and there would be some text telling you what they did while they were there. This was a very clever way to add variety to the things that happen in game, without actually needing to implement any of those systems or create any of the assets. By telling the player that a villager got lost finding apples and stumbled into a pond, we can add more world building without needing all the content.
On Monday, the unfortunate reality of going back to work kicked in and we were down to just one person. The todo list was already too long to get finished so it became a case of deciding what was going to get cut. The most important part was to get some kind of progression in, so that players have a reason to play. We added a system where the game checks to see if you’ve build certain structures, or collected certain resources, and then unlocks more features for you.
As the deadline came closer, even the essential todo list was too long. Villagers getting hungry, tired, or unhappy had absolutely no effect. There was no reason to collect food, or build houses. We rushed together a half baked system for getting the villagers to fall asleep, or stop working when they get hungry. Unfortunately, this system was so rushed that a lot of times it causes the game to become soft locked. Villagers become so hungry that they refuse to collect anything (including food) and so you’re stuck. Anyone who gets more than a few minutes into the game without securing a large amount of food will end up in this state. This basic AI should’ve been prioritised at the start, but there were so many other exciting features to work on that it ended up last. Something to keep in mind for next time.
All in all, we ended up really happy with what we’d done. It’s very clear that we planned so much more than we were able to achieve, from the hapiness system that has no effect, to the weapons and armour system that openly admits to not being implemented. This was not a failure of planning though, it was always the plan. The plan was to go as ambitious as possible and see how far we can get, so we better understand our limits, rather than playing it too safe and making something less cool. We’ve played it safe enough times already, a GameJam should be about trying new things and pushing those limits.
You can play it for yourself in the browser on itch.io