Changing the Game

So, the development of this game was going so fast and smooth and I didn't want to upset that with feature creep.. However, as I made more and more levels I found that with the current mechanics I could solve any puzzle using only one duplicate, unless I get really convoluted with the level design, see level 10. This was really bad as the core idea for my game was to have to make lots of duplicates and to have to avoid them as moving obstacles. In order to require the player to make more duplicates I would have to add in a new mechanic, but I wanted to keep it minimal and not add anything new.

How could I add in something new without adding anything new? Extension, I decided to extend the functionality of the doors and buttons using logic gates. By using logic gate behaviour I could make doors require multiple buttons to be opened. Now that I had a solution it came time to implement it. The trouble was I wasn't sure how.. What logic gates would I use? Do I want just two input logic gates or more? What about buffer gates and not gates? They only have one input. What about outputs? Would I ever want multiple doors to open from one button? How do I connect the gates to the buttons and the doors? The main thing I wanted for connecting the different components is that it's simple to do in the editor. I didn't want to have any two way dependencies and I was also thinking I'd like to still hook up a button to a door without a gate.

At first I thought inheritance, I could make a logic gate script that all other gates inherit from and then the door and buttons could have a logic gate variable, but then I couldn't hook a door to a button and I would need a buffer gate, then I thought maybe I hook up the buttons and doors to the gates, this had the same issue and I wasn't sure how to set up the variables, should the inputs and outputs be lists? The buffer and not gates have only one input and output so that wouldn't make sense to use lists.. and would I ever need multiple outputs?

So I wanted more flexibility and less dependency so I decided to use interfaces, ISender and IReceiver then anything I wanted to hook together I could just implement the interface. This solution seemed good at 1st, but ultimately I found it clunky mainly due to there not being interface support for components and I had to do  little work around to add the interface components and it would be possible to put in objects that did not have the interface.

So think I was scratching my head on how to implement this and make it very flexible and have good separation of the code. Then it hit me what about unity events? I was already using some regular events in the game, but with unity events I could connect the objects/build the circuit in the editor easily and I wouldn't need special classes or rewrite all the code. This solution would allow me to hook a button to a door or a gate or anything else I may add in the future, and I could hook the gate to a door or anything else. It seemed the most flexible, easy to implement, decoupled and extendable solution.

So now I new how to implement it and I started to think more about the gates and how I would use them. The common logic gates are Buffer, NOT, AND, NAND, OR, NOR, XOR and XNOR, but would I need to use them all? So since I can wire a button to a door without a gate then I don't need the buffer gate, and the not gate didn't seem like it would make sense to use for this game. That took away my single input gates, so I would only be using multiple inputs and then I decided to use only a single output because having multiple doors hooked up to the same gates seemed to defeat the purpose of adding in the logic gates. I also decided to drop all the notted logic gates for the same reason as the not gate, which left me with AND, OR and XOR.

Now I had to write the logic for the gates and to that I wrote an abstract method EvaluateSwitches, this method evaluates the the states of all the buttons connected to the logic gate in a loop and counts how many are on, the gates all inherit from a base LogicGate class and each child class overrides the abstract method. For AndGate the count must be equal to the number of inputs, for OrGate the input must be more than 0, for XorGate the count must equal 1.

Now that I have my logic gates I have to redo all the button door connections for my levels and redesign some with added logic gates. This new update will be version 1.2 and will have 10 complete levels. These 1st 10 levels will be part of the free demo version. Now I just need to do more testing, fix any bug and design and build more levels. I'm going to try to push to get a finished game by the end of the month!

I was able to add in more to my game without adding more by extending the functionality of the existing game elements and best of all adding  this new mechanic did not impact the development time much, it only took me a day to create the logic gates and another day to fix all the old levels.