My roles throughout developement: Gameplay Developer, Level Designer, Artist, Publisher
After implementing the whole mixing color system, I needed something that makes use having different colors available. My first idea was a classic button and door system that is present in most modern Sokoban games. The twist here in VoidHue is that the different buttons and boxes that are required to activate them would appear in different colors and could be colored as well. White buttons would activate regardless of the color of the object on top. A colored button however would only activate if the color of the object on top matches with the color of the button. This allows for puzzles where the player needs to color boxes to match with buttons or deliberately color the button in a different color to avoid activating them.
The biggest addition to the game that further deepened the concepts of VoidHue was the introduction of the capacitor, a similar object to the button, that could also activate power doors. The key difference is that the capacitor needs an active light source in their vicinity to turn on. Players need to actively decide if they want to use an light source to color various objects or rather use them to power a capacitor. Capacitors have a required color that the light source needs to match with. It instantly became clear what kind of puzzle game VoidHue would be: Solving puzzles with light-proximity activating mechanisms that would require a (often times already mixed) matching color.
Later developed new mechanics only reinforced this idea further. Glass could refract light, allowing light to travel further along the edges of the glass. Multiple glass blocks could be pushed together to act as a light bridge or could be used to connect two separate light sources into one. On the opposite side, light-blocking smoke was introduced. This smoke prevents light from coming in, keeping objects within safe from being colored from the outside, and also kept light from within from shining out. Allowing the player to experiment with those mechanics really shed light on what makes VoidHue such an interesting puzzle game.
The biggest challenge while developing VoidHue was writing the code for the refracting glass and debugging it afterwards. The glass GameObject is split into multiple smaller tiles, building together a large combined glass entity that moves as a whole. If a light source comes in contact with a glass tile, it would send a signal to every neighboring glass tile that a new light source is close and should be refracted along. This process also checks at the same time if a glass tile is in smoke and would therefore stop their refracting process. This ensures that glass tiles that are in the open would not refract light to glass tiles that lie in smoke. Everything works so far in the intended way.
The problem arose when a light source gets pushed away from a glass tile. The glass was suppose to lose their light around their edges and reset into a neutral state until a new light source comes into proximity. Problem is, there were many buggy edge cases were a glass tile would not reset into a neutral state. Some of these were: What would happen if multiple light sources are in proximity to the glass, how to check what light to refract afterwards? What would happen if another glass tile refracts light into the glass and then gets pushed away, how does the glass tile get the information to reset? How can I prevent having an infinite unintented feedback loop of glass tiles refracting each other?
The solution was quite simple. Every GameObject that could receive light would have an interface (IColorable) attached to them. Would a light source enter the proximity of a glass tile, it would be saved to a list where every neighboring light source is marked down in a network of glass tiles. If a light source or a glass tile gets pushed away, every IColorable that was in this network would synchronize to reset at the same time and recalculate their refraction and current color with remaining light sources. The calculation would also include objects like capacitors, that would also lose their color if a light source steps out of range, and sending them a signal to check for light sources as well. This approach ensures a CPU-light calculation and prevents most edge cases.
