Posted January 19, 2022 by Kate Killick
I am done with this prototype for now! You can play the final version here on itch in your browser. The proto includes a number of levels which, while they may not be that puzzling, demonstrate each of the mechanics, as well as a sandbox level to experiment with.
I still feel that there's potential for a game here, but it would require a different approach to the interaction (see notes below) - a major change. So I am setting this aside for the time being. It's been a super useful learning project and I've uncovered many of the unknown unknowns involved in building a cog-based game!
A more general learning to come out of this is the value of building a sandbox before anything else. It really helped me early on to think of me-as-designer as the customer of the first deliverable (the sandbox), and use that to prioritise what me-as-the-programmer should implement. It led me to spend more time on functionality that would allow for quick experimentation and iteration at runtime (e.g. being able to clone/edit cogs during play), rather than trying to use specific, paper-designed levels as the starting point. As I'm aiming to explore more system/simulation based games, I'll definitely take this approach forward.
Closing thoughts on the game
There are some big challenges with the current prototype, and before I put it aside I want to summarise what my next steps should be if I return to the idea:
1. Cog placement [UX/tech]
In the early iterations, cogs didn't have to be lined up at the edges - they could overlap any amount and still run. I later restricted this so it makes more sense, but the resulting interaction feels fiddly - it gets in the way of the fun. On top of that, there are some scenarios where cogs have to be placed very specifically to get the desired outcome, in a way that is more of an annoyance than an interesting challenge. For example, most of the time when you place a half-cog, you need it to centrally align on the X or Y axis to the cog it's driving, so the timing of the two cogs' teeth catching syncs up with the rest of the system as desired. Currently it's a pain to do, and if you don't do it right then it's not immediately obvious why.
There may be a grid-snap solution to this, but in general I wonder if a slot-based placement system would be much more effective for the player. For example, each cog has 8 attachment slots around it. As the player drags a new cog into the system, the available slots are highlighted, and when the player drops the cog it will snap if it's in range of a slot.
This would be the first problem to solve. It could also help with...
2. Teeth alignment [tech]
Right now, the teeth of the cogs do not align with each other realistically. The solution might be to auto-rotate cogs as they are placed - but this would have an undesirable impact on the angle of half/partial cogs. No solution in mind currently.
3. Contextualising and/or obscuring the goal [puzzle design]
In the demo, I have a couple of goals that can be applied when designing a level:
I previously wrote about other ideas for how this could be framed - e.g. building a piece of machinery that fills bottles, etc. This could add an interesting element to puzzle solving, as the player has to do more mental maths to work out the target timing/rhythm of the system, and also gives more of a narrative context. On the other hand, it might be a frustrating and unnecessary layer of difficulty. I'd want to explore it and find out.
4. How much freedom? [puzzle design]
Finally, a big unknown for turning this into puzzles is how much freedom to give the player. In the demo levels the player has a very limited number of cogs, with the only challenge being which ones to select and in what order to place them into the system. This is quite limited, and there's wide scope for giving them more freedom, e.g. to change cog sizes, rotate them, clone them, etc, as per the sandbox level.
I'd need to explore how much choice gives the right balance of being challenging without being overwhelming.
That's it!