Closing Cog-itations


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:

  • Connect all the driver and target cogs in the system (making sure speeds and directions match)
  • Make all the switches in the level light up simultaneously

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!

Comments

Log in with itch.io to leave a comment.

Seconding that "Cogitations" is a great name for a puzzle game with these cog mechanics.

I'd love to read about your puzzle design process when you do get to it!

Playing with the prototype reminded me of Zachtronics games, and I think a game  in that vein, with these mechanics designed around building machines that accomplish specific real-world(-ish) tasks given a specific set of pieces, would be very interesting. I think the limitations that Zachtronics games tend to set are also informative: everything is on a grid (usually a hex grid), and those pieces that can change size only do so in a small range and in increments that correspond to this grid. This limitation should allow the cogs' teeth to match up, since there would only be a small number of cog sizes and relative positions possible. Early in a Zachtronics game, you start with only a few pieces available with which to solve each puzzle, but as you progress, you earn new pieces required for solutions. You can go back to early puzzles and build potentially smaller (spatially), simpler (fewer pieces), or faster solutions using these new pieces. The games keep track of the complexity of your solutions along several axes and let you save your solutions for each puzzle, encouraging you to try different approaches. For the final few puzzles, you have every piece available and have to show a full understanding of their interactions to solve them.

(+1)

Thanks! I'm not familiar with Zachtronics but I will definitely have to check it out. To be honest I feel like I always struggle to find that spot between too simple and overwhelmingly complex with puzzle mechanics, but I do like the idea of unlocking the pieces as you go. 

Cogitations would be a very good name for this game!

Haha, I will have to come back to this game mechanic, if only so I can use the name!