Finalizing the game design. Plus PicoES 1.0.0 released!


PicoES 1.0.0

I released a new version of PicoES here. You can see the published npm package as well. At the time of this post, it’s still in alpha. It’s already been integrated into Toroban and is working correctly. Iteration performance has improved with the new world.each() syntax, and systems have been simplified and include automatic dependency injection with world.context().

Toroban updates

Toroban design

Many demo versions were iterated on since the last post. The latest findings from all the feedback was to really nail down the intuitiveness of the game mechanics and visual representation. There were certain behaviors in previous versions that I chose arbitrarily to try and “force” more advanced puzzles, but that’s a really bad idea. It’s much better to just choose a clear representation of something, and only design the logic that would make sense in real life, or at least intuitively in the game. If that logic is too weak, then change the actual objects to be something that produces stronger, deeper logic.

With that said, I’ve made an official GDD, which is super up-to-date, and will eventually contain the final game design. This is a big upgrade from my random notes documents before. This document is getting close enough to completion, to allow working on implementation again.

I’m planning on including some updated variants of good mechanics from previous versions of the game. Most of the logic will be simple and straightforward now, with complexity spread out into more objects instead of compressing the complexity into less. I won’t say much here for now, because the design isn’t 100% final, so you’ll have to wait till the next demo to see what will be included.

No more rule blocks

Rule blocks are being removed. There are many reasons for this.

  1. There’s already a wildly popular game that fully embraces the idea of dynamic rules. In Toroban, the color-based rule blocks only partially explores a similar idea.
  2. By combining the color states with the rules, it limits having simpler color sub-puzzles within more complex levels that make use of rule blocks, because they are too dependent. You can’t change the time travel state of an object without also changing the color, and therefore which areas its allowed to go. There was no benefit of merging the states, other than slightly simpler visual representation, but hidden behind that was complex logic.
  3. Almost every good level required the use of multiple rule blocks, and potentially more unintroduced rule blocks, to hack certain things in to make stuff work in a certain way. This would confuse players even more, by just seeing the existence of weird looking blocks, and noticing that things work differently.

Portal blocks

This is an exciting new addition. A colored block with a portal on one edge. If there’s two of the same color, then objects and lasers can seamlessly pass through these blocks, through the edges. Depending on the direction of the blocks, objects and lasers can change direction when passing through. If there’s three or more, then optional duplication starts to occur. This complements the toroidal world well, and means that world rotation and offset doesn’t have to be completed for things to be offset or rotated.