Implemented water/sand, animation engine, new locked player clones, animated overlay, control blocks, smooth camera, discovered new mechanics, and more!
Smooth water and sand
While this works similar to wall rendering, this steps it up a notch by working with diagonals to support large areas of sand and water. Using the old approach for walls, would result in needing 256 full sized sprites. I did some manual deduplication, using 1/4 sized sprites, so that only 18 sprites were needed, plus the 2 for full sand and full water.
The color palettes for the entire game still need work, as well as basically all the sprites. Placeholders are good for now so that I can make sure the logic will work with final sprites in the future.
Added an animation engine to be able to easily play animations in forward & reverse. Animations contain frame metadata, and can be consumed by render methods.
Locked player clones
Implemented new player logic, related to control blocks and overlays below. Now, when there are multiple players, they are moved as a locked group, so if one collides, they all collide.
Players now show an overlay to indicate they are currently controlled. This gif shows the checkerboard pattern for overlay animation direction. It seemed kinda dizzying to have them all turn in the same direction, so this keeps things changed up as you move around.
Demo of new control block mechanic!
Spent a lot of time trying different approaches to have a smooth moving camera that automatically centers on controlled entities. It’s mostly done, but the part that re-calculates could do a better job finding a more appropriate center.
Improved automatic build system, added player exits, added color areas. Color areas only block physical objects currently, but interactions with light are planned as well.
Instead of hard-coding one rule per RGB bit, there can be separate rule blocks, that work similar to goal blocks and control blocks. For example, if a time block is hit with red light, then all entities with the red bit, will be immune to time travel. The old hard-coded system can be easily replicated by setting up a rule block for each RGB bit, on top of a red, green, and blue laser.
There will be the following rule blocks:
- Wall - renamed from “goal”
- Changes up/down state of walls
- Sets which players are controlled
- Pauses matched entities
- Enables matching entities to control world offset by relative movements
- Matched entities will no longer be able to push, and can pull
All of these will work the same with how they interact with colors, see below.
8-color (3-bit) vs 10-color (3-bit + null + all)
Went back and forth on some different color systems like this one:
Decided on using the simplest 3-bit, 3-component system, with 8 output colors:
All the block types will be consistent in using components specifically, instead of unique colors. Example: White is actually just red, green, and blue all at the same time.