Attached is the Simple Simon game I showed at the LAVA User Group at NI Week. It employs 'Large Code Architecture' features to demonstrate how even a small application can be written with this structure.
I use what I call a "Mono-Cluster State Machine" where there is only one data shift register which passes a Type Def 'Mono-Cluster'. This allows all cases on the State Machine to have access to all the parameters. It also allows you to write very 'pretty' code in that you can resolve each case into one VI - passing the cluster in & out.
The code is pretty efficient:
1. The sound is generated in only state and is triggered via Queue communication between Simon and the User Console.
2. There is very little usage of local and NO Global variable usage.
Another great strenght of this architecture is you break funtions into logical blocks - making it easier to code (smaller tasks to work on).
>Easier to test - you can pass parameters into it's input cluster.
>Less likely to break other parts of the code when implementing changes- because you be working on a single peice of code not a VI buried in a huge loop.
I simply love the Queue-Driven State Machine. I had a 1 year software development project that near the end the client wanted to control in Visual Basic. We decided to link the code using TCP/IP. It took me about 2+ hours to modify the code to accepts commands and allow full control of the software via TCP/IP - because my architecture was already built on a String based command;argument structure. I dropped an addtional TCP/IP link & poll state in the code and handed him my command manual and voila!
PS: the Simple Simon game was written at the request of a potential client who wanted to see a sample of coding style. It took me about 3+ hours to write and I think it is a marvelous way to assess coding style.
Simon Says Game written in State Machine Architecture
in Application Design & Architecture
Posted
Don,
Attached is the Simple Simon game I showed at the LAVA User Group at NI Week. It employs 'Large Code Architecture' features to demonstrate how even a small application can be written with this structure.
I use what I call a "Mono-Cluster State Machine" where there is only one data shift register which passes a Type Def 'Mono-Cluster'. This allows all cases on the State Machine to have access to all the parameters. It also allows you to write very 'pretty' code in that you can resolve each case into one VI - passing the cluster in & out.
The code is pretty efficient:
1. The sound is generated in only state and is triggered via Queue communication between Simon and the User Console.
2. There is very little usage of local and NO Global variable usage.
Another great strenght of this architecture is you break funtions into logical blocks - making it easier to code (smaller tasks to work on).
>Easier to test - you can pass parameters into it's input cluster.
>Less likely to break other parts of the code when implementing changes- because you be working on a single peice of code not a VI buried in a huge loop.
I simply love the Queue-Driven State Machine. I had a 1 year software development project that near the end the client wanted to control in Visual Basic. We decided to link the code using TCP/IP. It took me about 2+ hours to modify the code to accepts commands and allow full control of the software via TCP/IP - because my architecture was already built on a String based command;argument structure. I dropped an addtional TCP/IP link & poll state in the code and handed him my command manual and voila!
PS: the Simple Simon game was written at the request of a potential client who wanted to see a sample of coding style. It took me about 3+ hours to write and I think it is a marvelous way to assess coding style.
Download File:post-12-1073108130.zip