Good news: This is the start of weekly blog posts!

Last week was a lot of going back-and-forth on how the mechanics should work: Having the “small” player only able to push “small” versions of objects, but not big ones, and needing a dedicated vehicle for that. Well, I decided to stick with not deviating too much from the last post, since it felt the most balanced.

Road Map

For the short-term, here’s the plan:

  • Use aseprite for pixel art (and animations in the future)
  • Between each of the following, many test levels will be made
  • Implement new goal block (All sides open, OR logic)
  • Implement life points
  • Implement new vehicle
  • Implement remaining goal blocks and other objects
  • Implement time travel rewind & undo (instead of undo acting like rewind)
  • Implement time immune changers

After this is done, there will be a basic playable demo, that demonstrates all of the newly planned mechanics. Then, for the long-term:

  • Animations
    • Create animations for all the sprites
    • Add animation support to the game
    • Develop a workflow/mechanism for managing all of the animation frames
  • Sound effects
  • Trailer & Marketing
  • More polish
  • Testing on targeted platform(s)
  • Player feedback

The list goes on and on… But, I will take it one step at a time, and post about the progress along the way.

Further Describing Logic

There have been some additions and discoveries from finalizing the design of the mechanics.

Goal Blocks: Logic

Now have the possibility of “logic” operations, with the common early one being OR logic. Can try all of the logic gates, but XOR could be interesting. One that always inverses the input could be useful too, such as NAND/NOR.

Goal Blocks: Loops

Now that lasers can go through blocks, and the blocks contain more advanced logic operations, you can get into scenarios where laser beams loop back to the same block, which keeps changing the colors. There are some solutions to this problem:

  • Have an iteration limit (lame, and wouldn’t make sense because the last iteration wins)
  • Have an array of all seen colors, as the color (would show up striped)
  • Designate a 9th “color” as a “paradox” color, which can be used in the game as a special color

The simplest is the last solution, which is to have a special color whenever loops are detected. The iteration would stop once no more changes are detected. The special color would work like “undefined” or “NaC” (Not A Color) - anytime it is used as an input, the output would always be the special color, to help stop loops. It is possible this does not cover all the cases, so I will find out during testing the prototype if this will be good enough.

Vehicles: Edge Cases

  • Vehicles can now be pushed from any direction, except the direction used for entering/exiting.
  • Entering/exiting is free (produces no pollution). Also, it can be done between two adjacent vehicles with the right position/rotation.
  • Entering a vehicle inside of pollution/lasers is allowed. This is consistent with already being inside of a vehicle and moving to those locations.

Life Points: Collision

Only objects that have life points (the player) can actually enter the location with a life point object. All other objects will be blocked.

Time Immune Changer: Collision

Similar to above, if the object entering is not the opposite time immunity, then its movement is not allowed. This prevents weird visuals of things on top of each other, and may add a tiny bit of logical depth.

Whenever time immunity is changed on an object, its history will be erased. The history of that object’s effects on other objects will remain, however. This prevents a lot of weird bugs, but it’s possible to change in the future.

Time Travel

There are still many edge cases to identify and define logic for with all of the other objects. I am trying to put this off for the last mechanic to integrate. It should be safer to prototype everything else first, to make sure those mechanics are good to use, before spending a lot of time on this.