Product
This week:
- I implemented a system which keeps track of which components have live electricity running through them.
- I spent the majority of my time integrating the event system, a rudimentary scoring system and a state system together.
Process
Power System
Each component in the puzzle must be checked for whether it has live electricity running through it; this has been implemented in the Event System. Through an object hierarchy, if any component can be tracked back to a live source (the cabinet in this scenario), they are considered as powered.
The object hierarchy, in this example, if the cabinet is powered on; all these components are live.
In this hierarchy, even if the cabinet is powered on; the ABC is detached and so is not live.
Integration of Events, Scoring and States
After finishing the event system last week, there needed to be some way to actually track where in the puzzle the user is. I implemented a StateMonitor which takes and compares events to the ideal order of events. This is achieved by splitting the necessary events into two lists. One list tracks the order of events for fixing the components. When all the components are fixed, the next list (the order of reassembling components) is used.
The StateMonitor detects whether a user has made a correct or an incorrect choice, and has the ability to weigh events; so if a user forgets to turn the power off before interacting with live components, this applies a higher penalty than taking cables out in the incorrect order. This information is sent to the ScoringSystem which makes the necessary changes to the users score.
A timer system has also been implemented so when the user finishes the puzzle, a time-based variable will be applied to make their final score.
Flow of determining how user's inputs effect their score