Taking stock

Here where the prototype is currently:

I have to say I became somewhat fixated on trying to get the system for this game working, and now is definitely time to take a step back and figure out what - if anything - comes next.

I have a bunch of unsolved problems, and I’m not sure whether some of them will end up meaning I can’t take the game further in its current form.

Does the system actually work? (HIGH RISK)

As I mentioned previously, there are a couple of issues with the system that I still don’t know if they are fully solvable, which is frustrating at this point. Plus, I suspect there are a bunch more problems and bugs I haven’t found yet because I haven’t been thorough enough in testing all my changes.

Puzzles? (MEDIUM RISK)

Can I actually make good puzzles with this stuff? I feel fairly confident that I can because of how much I’ve enjoyed messing around with the prototype, but at the same time I still don’t know exactly what the player goal will be, and I may have to remove some features that are causing too many technical/design complications. Either way, it’s not proven yet.

Design questions? 

This week I’ve started to uncover what interaction design problems I’ll need to solve if I were to continue the game:

• Cog placement and animation (HIGH RISK)
  • Currently cogs snap to a grid, but there are some problems - the biggest being that there’s no system to make the teeth of cogs line up visually. This is complicated to solve given that the starting rotation of a partial cog is a key part of the puzzle, so anything enforcing specific positioning or rotation needs to take that into account. I don’t know how to solve this yet.
• Visualising states and goals (LOW RISK)
  • It doesn’t look great in the current version, and will need iterating on to make sure it makes sense to the player
• Editing the system while it’s running (LOW RISK)
  • The optimal UX would not require the player to stop the system from running in order to move cogs around, but I don’t think that’s an option without breaking the purpose of the puzzles. In my mind, it’s similar to a “learn to code” game, where the player has to set it up, then watch it run, then stop/reset it to iterate - but it requires further exploration.

So… what’s next?

At this point, I don’t want to sink more time into changing how the system works and trying to fix the code.  I will create a test scene to try to find where all the problems are and then I would like to spend some time making puzzle levels that use all the mechanics I have so far, even if I have to work around some limitations. 

I will then make a call, probably mid next week, on whether to park this project and move on to something else. I think it’s quite likely that it would be an idea I come back to another time, but with a completely different technical approach.