Then within the scene that housed the level we would place a puzzle object into the hierarchy. Then within that puzzle we would pass it every piece to track the state of within the scene, so within level 2 we would pass it all four batteries and all three logic gate slots.

The scene would then be loaded upon awake with the game manager and puzzle manager objects as a singleton pattern as they stay consistent between scenes. Upon loading the new scene, the puzzle manager would find the puzzle object for the scene, which then the puzzle object would then pass all puzzle pieces that need to be checked for the puzzle to be complete. With the puzzle manager then storing these objects along with if they fir their own checks for being in a “correct state” for the circuit to be complete.

Each puzzle piece whenever it changes its power output to either off or on, by either being set by the player with the battery or having the correct gate attached to itself would then invoke an event in which it passes itself as a game object to the puzzle object which the puzzle will then use to determine if the piece is in a correct state or not for the circuit to be complete. It will then pass the object along with its current output to the puzzle manager where it will initially compare its output against its acceptable answer (being off or on), with which it will then update its dictionary of the object name and if it’s in the correct state or not for the puzzle to be completed 

The Puzzle manager then checks this dictionary for if each object is in its correct state according to this dictionary and if so, the puzzle is complete and the door object will be told through an event to open its doors. However, for more complex inputs from batteries attached to gates such as OR or XOR in level 2 an additional check will need to be done.

During the puzzle completion check we check for any batteries that have a partnered object. Partner objects are other batteries within the scene that also feed into the gate slot attached to the battery objects within the scene. If a battery has a partner object it will perform a check according to both of their shared acceptable answer. For example, were the batteries to feed into a gate slot of a XOR gate they would check if only one of the two batteries are active.

With the lights or wires also being tracked by the puzzle object within a dictionary, with a parent object where the wire would originate from and one of the connected wires from that object. Whenever the output of that objects power variable would be changed the puzzle object would have an event sent to it where it would look up the object within the dictionary and then pass the wires material to the puzzle manager to update its colour. Since we can change the colour of the material outside of an instance, we could update the material as a whole and update very wire object that shared that same material resulting the whole wire changing colour when power was provided from that object. With each material within that scene being reset upon changing to the next scene or level.

Later, during development I would realise I had made a mistake, as many parts of each level could technically be completed by a different gate. So, for example there are both XOR and OR gates, where both these gates can be placed, these gate slots would both function with either provided gate. Resulting in a change to the system. Within the newer system the piece would have a list of acceptable answers. For example, both batteries and slot gate in the previous mentioned example would have an acceptable answer of either OR or XOR gates. The gate slot would then check the attached gates type against the acceptable answers that would provide am activated power output. Then later in the system the battery would check the type of the attached gate to the gate slot it was providing power to and check for the conditions that would provide that gate power.

The Game manager would then be used to keep track of if the game is changing scenes or if the game had been paused. If the game had been paused an event within a player pauser object attached to the player character would invoke an event to all listening objects which would then stop their updates based off the game has been paused or unpaused. With the game manager receiving this event and setting the game time speed of the project to zero. 

Then whenever the player were to leave the level through a trigger box entering the game manager would inform the puzzle manager and the puzzle object to empty all of their caches to reset for the player replaying the game and transitioning to the next level. So the puzzle manager was ready to receive the new puzzle objects within the new scene form that levels puzzle object.

Then later controller support was implemented through the use of the players actions being controlled through the new unity Input Manager. We would assign a function to both a key and a controller button and perform that function whenever that button was pressed. With the option to perform a small check in the main menu to check for any controllers that were not detected upon start of the game.