Color-Shifting Tile-Based Puzzle Game
Chameleon Code is an innovative tile-based puzzle game built around a color-changing mechanic inspired by Color Symphony 2. The core gameplay loop challenges players to strategically shift their color to deactivate matching barriers, blend into environments, and manipulate colored boxes to solve increasingly complex spatial puzzles.
The project was developed as an exploration of interconnected Blueprint systems using a tile-based architecture. Players navigate grid-based levels where color tiles change the hue of both the player character and pushable boxes. Color-coded detection lights act as gates or valves, opening pathways when the player matches the required color or stripping away the player's color entirely to create backtracking challenges.
Each level introduces a new mechanic following the Introduce, Practice, Master progression model. Early puzzles teach basic color-switching and barrier navigation, while later challenges layer in pressure plates that require color-matched boxes, bridge tiles that activate only when receiving boxes of the correct color, and teleportation mechanics that add spatial complexity. The win condition is simple but satisfying: reach the goal tile and hear children cheer your success.
Originally inspired by a concept for a 3D box character escaping a city using environmental camouflage, Chameleon Code distills those stealth and color-shifting ideas into focused puzzle design. The tile-based constraint forced creative solutions around actor referencing and Blueprint communication, resulting in a system where every object is either a Tile or an Entity with clear interaction rules.
The design philosophy behind Chameleon Code centers on depth through constraint. By limiting player actions to movement and color-changing, every decision becomes meaningful. The color system is not just a visual gimmick but a core mechanic that gates progression, creates risk-reward scenarios, and forces strategic planning.
Color detectors function as more than gates, they act as valves that strip the player's color away entirely. This design choice transforms backtracking from a simple path reversal into a puzzle element requiring alternate routes or secondary color changes. Players cannot simply retrace their steps; they must think ahead about color sequences and commit to paths.
The pressure plate mechanic emphasizes that boxes are not just obstacles to push aside but tools to manipulate. By requiring color-matched boxes to hold down plates, the design creates spatial puzzles where placement order matters. Players must visualize the sequence: push box A to color tile B, then position it on plate C while ensuring they can still reach the goal tile.
Bridge tiles elevate this further by catching only color-matched boxes and transforming empty space into traversable paths. This mechanic rewards careful planning and punishes hasty moves, as a miscolored box falling into a bridge slot can block progress entirely. The interconnected nature of these systems creates emergent complexity without requiring complicated individual mechanics.
Color tiles change player and box colors using enumerator-based material swapping, creating strategic color-matching puzzles
Detection lights validate player color to open barriers or strip color away, creating valve mechanics that prevent simple backtracking
Pushable boxes interact with color tiles, pressure plates, and bridge tiles to create layered spatial challenges
Empty tiles catch color-matched boxes to form traversable bridges, rewarding strategic box placement and color planning
The project began with a tile-based framework assignment to learn level construction. After researching games that used color-changing mechanics, I chose Color Symphony 2 as primary inspiration for its approach to color-based collision and object detection. The goal was to translate side-scrolling color manipulation into top-down tile-based puzzle design.
Built the foundational color-changing system using Blueprint enumerators to define color codes. Color tiles detect player or box overlap and swap their material based on the enumerator value. This created immediate visual feedback but lacked gameplay consequence, the color changed but nothing responded to it yet.
Developed color detectors that validate player color and open corresponding barriers. Extended this into valve mechanics where detectors strip the player's color back to default white after passing through. This design choice transformed simple gates into strategic decision points, forcing players to plan color sequences rather than backtrack freely.
Expanded box functionality beyond simple pushing to include pressure plate activation. Implemented color-coded plates that verify the exact color of entities holding them down, creating puzzles where box color matters as much as box position. Players can trigger plates temporarily but need correctly colored boxes to keep doors open while progressing.
Incorporated Jessica Ogden's bridge creation mechanic by designing empty tiles that validate box color and transform into traversable bridges when boxes land on them. This added vertical thinking to the puzzle design, players must consider not just where boxes go but how they create pathways across gaps.
Transitioned from fixed camera positioning to a player-attached camera system to support larger level designs. Implemented camera blend views and managers to handle smooth transitions. Removed rotation orientation on yaw to prevent disorienting control changes, ensuring directional inputs remained consistent regardless of player rotation.
Built levels following the Introduce, Practice, Master model, scaling complexity gradually. Early levels teach individual mechanics in isolation, while later puzzles combine color valves, pressure plates, bridge tiles, and teleportation into multi-step challenges. Focused on gameplay depth rather than visual polish, prioritizing puzzle design over graphics within the one-month timeline.
As the number of color-coded tiles, detectors, and pressure plates increased across multiple levels, tracking which objects responded to which colors became mentally overwhelming. Level design slowed down because I had to constantly playtest to remember what colors triggered specific mechanics, breaking design flow.
Implemented Construction Scripts that provide real-time visual feedback in the editor. Color tiles, detectors, pressure plates, and bridges now display their color coding directly in the level viewport without requiring play mode. This editor-time visualization transformed level design from trial-and-error iteration into intentional spatial planning, drastically improving workflow efficiency.
The teleportation system required players to step onto the tile, wait a frame, and then teleport, creating frustrating stuttering during what should be seamless travel. This made the teleportation puzzle level annoying to play, reminiscent of the frustrating tile-based teleport mazes in Pokemon Generation 1's Saffron City Gym and Silph Co.
Discovered the issue stemmed from entity verification and Blueprint execution order. The system was trying to validate the player's identity before allowing teleportation, causing the delay. By implementing an IsValid node that checks for the Entity Class rather than registering the specific player instance, the system bypassed unnecessary verification and enabled instant teleportation. This fixed the mechanical issue, though the puzzle level remains intentionally challenging as a homage to those classic Pokemon teleportation mazes.
Transitioning from a fixed camera to a player-attached camera initially created disorienting control problems. The camera rotated with the player, causing directional inputs to change meaning based on player rotation. Pressing W would move forward relative to player facing, meaning it might move left, right, or backward relative to the world depending on rotation.
Tackled this challenge in two phases. First, learned about camera blend views and camera managers to implement smooth camera following. Second, removed rotation orientation on the player's yaw axis so directional inputs remained consistent with world space rather than character space. W always moves up on screen, A always moves left, regardless of which way the character model faces. This preserved intuitive top-down controls while enabling the freedom of larger level designs.
Chameleon Code provided intensive hands-on experience with Blueprint interconnectivity and actor referencing systems. The constraint against using collision detection forced me to architect everything around tile-based detection, where every object functions as either a Tile or an Entity with specific interaction rules. This binary classification system created clean separation of concerns and made debugging significantly easier than overlapping collision-based approaches.
Working with enumerators for color coding taught me how to create scalable systems that remain readable at scale. Rather than hardcoding individual color checks throughout dozens of Blueprints, the enumerator approach centralized color logic and made adding new colors trivial. This architectural decision paid dividends when implementing later mechanics like bridge tiles and pressure plates, which leveraged the same color validation system without requiring new infrastructure.
The Construction Script implementation was a breakthrough moment for editor workflow. Before discovering this technique, level design required constant playtesting to visualize color-coded relationships. After implementing real-time visual feedback in the editor, design iteration speed increased dramatically. This experience reinforced that tools development is as important as gameplay development, investing time in editor quality of life improvements pays back multiplied efficiency.
Camera systems proved more complex than anticipated. Understanding the relationship between camera managers, blend views, and player rotation control revealed how much invisible infrastructure supports basic functionality players take for granted. The disorienting control issue taught me that maintaining consistent player mental models matters more than technical correctness, world-space controls felt better than character-relative controls even though the latter is more technically accurate.
The one-month timeline forced prioritization decisions that clarified my design values. Choosing gameplay depth over visual polish was the right call for a puzzle game, the mechanics carry the experience more than graphics. This project validated that strong core systems enable compelling gameplay even with minimal art resources. Polish can always be added later, but foundational design must be solid from the start.
Finally, this project reinforced the importance of constraint-driven design. The tile-based architecture, limited player actions, and focus on a single core mechanic (color-changing) created more interesting puzzles than if I had unlimited freedom. Working within boundaries forces creative problem-solving and produces more focused, coherent experiences than kitchen-sink design approaches.
The next major expansion for Chameleon Code would introduce mobile color detector robots that patrol levels. These enemies would function as moving detection lights, adding timing elements and stealth pressure to the existing puzzle design. Players would need to match or avoid colors dynamically rather than solving static spatial puzzles, creating tension between planning optimal paths and reacting to patrol patterns.
Mobile color detectors with patrol routes that add timing challenges and stealth elements to puzzle-solving
Ability to store one color for later use, enabling new puzzle types that require color swapping without returning to color tiles
Expanded level roster with more complex mechanical combinations before potential GitHub release
Return to the original inspiration with a 3D platformer mode featuring environmental camouflage and box character movement
The color storage mechanic would add strategic depth by allowing players to bank one color for later use. This creates puzzles where players must decide: do I use my stored red now to activate this pressure plate, or save it for the bridge tile three moves ahead? The single-color limitation prevents hoarding and maintains puzzle difficulty while enabling new solution paths that require color management across multiple rooms.
Robot enemies would patrol set routes, scanning for specific colors. Getting caught would reset the puzzle segment, adding consequence to poor planning. These enemies could interact with existing mechanics: a red robot might ignore you when you're red but chase when you're blue, creating scenarios where you must change colors mid-level while avoiding detection. This transforms static puzzles into dynamic stealth-puzzle hybrids.
Before releasing on GitHub, I want to expand the level count significantly. The current build demonstrates all core mechanics but needs more content that explores their combinations. Levels that require storing colors while avoiding patrol robots, or bridge-building under time pressure, would showcase the system's full potential. Additional polish passes on existing levels would also improve pacing and difficulty curves.
The long-term vision circles back to the original 3D city escape concept that inspired this project. Translating the color-changing stealth mechanics into a 3D platformer with environmental camouflage would be the natural evolution. Players controlling a box character navigating a city, blending into the environment by matching building colors, avoiding security cameras, and using parkour-style movement to traverse rooftops. Chameleon Code serves as the proof of concept for those core mechanics in a more accessible 2D format.
Check out my other work to see different aspects of my game development skills, from horror level design to collaborative team projects.