Project Kickoff

Prototype goal

My goal for this quarter was to explore simulation games. My first attempt was a plant-themed sim, which I ended up pivoting into a tile placement game. With a few weeks left, I wanted to come back for a second go at a simulation prototype to wrap up this chunk of work.

My last approach was to grind on idea generation, which was draining and not hugely successful. My new approach is to focus instead on giving myself a sandbox to tinker with, which I think might get me further than trying to force upfront system design on paper.

So, my goal was: start building a “blank” sim system. Something that I could experiment with easily and make progress on without getting bogged down in how “good” the final system/idea will be. In fact, I don’t even mind if this project doesn’t turn into a game - it’s a learning process. This would mean going against my old prototyping philosophy of building for a specific purpose as quickly as possible, and putting more care into making my code flexible and stable enough to support experimentation. Balancing these is one of the lessons I’m still very much learning as a programmer!

System concept & first version

I did have a rough picture of the game, though. Using Outlanders as a reference point:

The game will be about harvesting/taking resources, building “converters” to turn them into other resources, using limited labour, working towards the goal(s) of creating x amount of certain outputs. Everything takes time, and time is limited, so the player needs to assign labour accordingly, balancing short term and long term needs/goals.

I started implementing these systems in a theme-agnostic way, and a little further on decided on a vague direction of a cooking theme - ie taking ingredients and processing them into dishes, and possibly having the player juggle a variety of resources and recipes.

Here's the end of week one:

I know visually it doesn't make a lot of sense right now - here's what's going on:

• You have a number of meeple and can hire more (costing money)
• You can assign them to do one of three things:
  • Be at a particular station (“stationed”)
  • Carry resources between stations/storage (“runners” )
  • Build new stations/storage (costing money) (“builders”)
• There are a few types of stations:
  • Spawners (e.g. the chicken coop - produces eggs)
  • Converters (e.g. frying - converts raw eggs to omelettes)
  • Sinks (e.g. the “Food sink” - currently converts omelettes into coins)

When a meeple is at a converter station, they’ll request the inputs they need, and an available runner will try to fetch them. They’ll also require a runner to take away the outputs they’ve created to make room for more. So you always need a good amount of runners available to ferry things about.

A lot of last week was just getting this up and running, making sure these requests are handled, allowing meeple to finish the job they’re doing before moving on, etc. I think that’s now in a stable enough place to move forward.

The data for resources and station types are all defined in scriptable objects and can be added and edited very easily - at the moment, I might still end up totally re-theming the game.

Technical challenges

Building this type of game is a big technical challenge for me - in the past I’ve found myself quickly in a position where it’s hard to make changes or build on the code because of how entangled it is. This time, thinking about it as a “blank” system helped me not go down cul-de-sacs and give more thought to the overall structure beforehand. I tried to keep the systems for game logic and visualisation decoupled, and also relied more on game managers than individual objects to run logic. I’m trying to make good decisions about when to carry on with something I’ve started, and when to actually step back and redo it because I’ve figured out a better approach. I don’t want to burn time unnecessarily, but it’s also proven to be extremely useful for learning and for not painting myself into corners.

There are, though, a couple of ways I have cornered myself, which I may need/want to address at some point:

• The game doesn’t have a concept of individual meeple, only a count of how many meeple are assigned to different places. This probably wasn’t optimal, and will make it fiddler to make them completely persistent (instead of teleporting to where they are needed, as they currently do). I’d like to instead have individual meeple, and then a generic way to handle “pools” of people.
• Similarly, the game doesn’t have a generic way to handle “jobs”, which I think would have been useful, instead of handling “runner” jobs and “conversion” jobs completely differently.
• On the other hand, I think I tried too hard to share code between converter, spawner and storage components, and that’s probably been a hindrance.

System design questions

At the moment, I don’t really know how I want spawners and sinks to work - they are sharing code with converters, and that will need to change. Here, I think I do need to narrow down on the concept a little. For example, if the spawners represent a naturally occurring resource that respawns periodically, the player shouldn’t be able to increase supply by building more (as they currently can), but only increase their rate of harvesting. But then there is the question of how many resource types are in the game - if the idea becomes more that you have many different ingredients and can make different recipes, the source of inputs could be more like a magical fridge that can supply whatever is needed, but again, depending on your capacity for fetching items from it.

A similar question applies to sinks - currently “feeding” an object to the king character just generates money, as I haven’t yet implemented real goals. As you can’t build more sinks, after a while this becomes the blockage in the pipeline. Should sinks be something you have to/can expand the capacity of?  

My next step will be to sketch out a few versions of where this could go, and then choose a first version to try out. This should allow me to get to something resembling gameplay, and start to see where interesting dynamics start emerging.