I (Zack) finally implemented my EnergyTransfer? (also called Incredible Machine) use case. I played my game, and dragging and dropping pieces works, as does testing whether or not the piece configuration represents a valid transfer of energy from the source to the door activation. As we outlined in our test plan, we can't really automate the tests for our game because all objects are GameObjects? whose only output is graphics on the screen. There isn't enough actual logic in the game to test functionality, other than to just play the game, and see if it works as intended.
I implemented the game with two main superclasses, the "Piece" super class, which is just the superclass for any draggable object that can be placed to transfer energy from the starting form to the final form. I also have a "Slot" superclass which can be any source of energy, the door, or any slot for a Piece (these are subclassed as ConnectableSlots?). Every slot has an "In" and an "Out" which is used to make sure that future slots both take in the energy that is being emitted, and the animation proceeds correctly upon hitting the "Check" button. Overall, this framework makes it very easy for me to add new pieces and energy types.
I (John) implemented wave games in 1D and 2D. The wave equation simulators are still highly unstable for unknown reasons, so a small constant is added to the theoretically correct equation in order to stabilize everything. The 1D version is very simple, so it's all in Wave1D. It follows the same format as most of the other minigames. Because solving the 2D wave equation is computationally expensive, the 2D solver was implemented in HLSL, Microsoft's graphics language (Wave.fx). Wave_Sketch contains the C# code which updates everything and wraps the HLSL code. Sketch, the base class of Wave_Sketch, handles drawing walls. Finally, Wave2D holds the game parts of the minigame (directions, 'Try' button, etc). The results, for both 1D and 2D, are very pretty.