Toroban: Update #37
Added pause functionality for the new player. New player color/control block ideas.
Updates
The player with followed entities can now be paused. Fixed more issues with Create/Destroy entity actions.
Player Colors
The player entities can be initialized to a color, set on level creation. This color will be preserved when eating food, splitting, etc.
Color Control Block
This is a new, optional block type, that can dynamically enable/disable movement controls for certain colors of players. Depending on the color of light this block receives, determines which group(s) of players get controlled. This follows a common theme that works similar to goal blocks/color walls/color food. All edge cases should already be worked out:
- No control blocks
- All players are controlled
- One control block
- Only players of this one color are controlled
- Many control blocks
- The common set of current control block colors are controlled
- Example: Blue, Red, Blue blocks - only Red and Blue players are controlled
Merging
Some possible merging rules:
- Don’t allow merging of different colors or time immune states
- Fixes many potential issues and keeps things simple and constrained
- Allow merging all players
- Mix colors
- This would be interesting, but should act similar with pause state to “mix” pause bit using OR logic
- Inherit colors from front-most player “head”
- Consistent with inheriting pause state from player head
- Mix colors
At first: Sticking with rule to not allow any different things to merge. Later, once things are stable, I could try adding inheritance or mixing logic, and see which one produces the most interesting levels.
Color Walls
To keep consistent with the colored food constraint, the same constraint can be applied to the player. This would mean there could not exist any segments of a particular color, as well as any food, and any existing goal blocks of that color would have to be solved, for that color wall to be solved. This creates a dynamic where not only do you have to eat all the food, but you also have to kill off any players of that color. Since the player color is not controlled by the food - only by the level - it should not cause a chain of steps that must be executed often. Only if a level was initialized with the same color player as a color wall, would that player group have to be killed off - doesn’t matter how big it gets with any food type. There could be many different style levels that make use of this constraint.
Next Tasks
Merging segments and camera positioning are top priority. Merging should allow the possibility of initial player chains without food. Camera positioning should allow better usability, as it is currently locked to the center of each level.