Wanted to share the development process of a Flash game utilizing the Model-View-Controller design pattern.
The game is called “dum-de-dum Drum”, which can be found at www.dewmocracy.com starting 11/30/2007. It is the third game in the Forest Chamber (green chamber). It is a 3-level game, each level is similar to a “Simon says” game, with different levels of difficulty.
The very root game class extends a base class, which takes care of the generic screen display/removal, timer, xml loading, show/hide methods, instruction display, game data saving, etc. So what I had to worry about is pure game logic.
I started by analyzing the project from a user experience point of view. The interaction is basically between the user, which is referred to as “USER” below, and the game, being it the model, the view, or the controller, which is referred to as “DRUM” below.
 DRUM generates a random sequence (var gameSequ) of drum beats. Go to .
 DRUM increments the number of beats (var userLength) which it will play. Go to .
 DRUM indicates the start of playback of the sequence. Go to .
 DRUM plays the sequence back with (userLength) number of beats. Go to . ( and  need to be further broken up to a step-to-step process.)
 DRUM highlights the drum(s) which were just beaten. Go to . ( and  need to be further broken up to a step-to-step process.)
 DRUM indicates the playback is done and it is the user’s turn to repeat the sequence. Go to .
 DRUM enables the user interaction. Go to .
 DRUM waits for user interaction. Whenever USER beats a drum, DRUM records the beat (var userBeat). Go to .
 DRUM highlights the drum which was just beaten. Go to .
 DRUM increments where the past beat is located in the current playback sequence (updates both var userBeat and var userBeat). Go to .
 DRUM checks if the beat generated by the user matches the original beat in the sequence (var userBeat == var gameBeat ?). If yes, go to ; if no, go to .
 DRUM checks if the past beat is the last in the playback (var userBeat == var userLength ?). If yes, go to ; if not, go to .
 DRUM disables user interaction. Go to .
 DRUM checks if the number of beats played and matched so far is equal to or greater than the length of the original sequence (var userLength >= var gameSequ?). If yes, go to ; if no, go to .
 DRUM indicates USER has won. Go to .
 DRUM indicates USER has lost. Go to .
 end of game.
Then I separated the responsibilities of game and assigned them to the Model, the View and the Controller.
[Model]: keeps track of the data, including key variables to keep track of:
.. gameSequ –the entire drum beats collection, gets generated once when the game starts, but cannot be updated ever.
.. userLength –the number of beats in an excerpt of the gameSequ, decides the length of demonstration playback, gets incremented when the user has successfully matched all the beats in the last playback.
.. userBeat –the beat the user just made at the current position in the playback, gets updated every time USER beats a drums.
.. gameBeat –the “correct” beat at the current position in the playback, gets updated every time USER beats a drum.
[View]: displays messages and status of drums (beaten status and normal status), based on changes of the Model.
[Controller]: enable/disable user interaction; updates model based on changes of the Model and/or USER interaction.
Then I translated the above English description to core properties/functions that the classes need to be able to keep track/perform.
.. get gameSequ ():Array
.. set gameSequ (Array)
.. get gameBeat ():int
.. set gameBeat (int)
.. get userBeat ():int
.. set userBeat (int)
.. get userLength ():int
.. set userLength (int)
.. playGameSequ ():void
.. playSingleBeat ():void
.. userLengthChangeHandler (Event):void
.. userLengthChangeHandler (Event):void
.. beginUserInput ():void
.. endUserInput ():void
.. gameEnd (Boolean):void
From this point on it is just coding, debugging and perfecting. I am pretty happy with the final result. Gonna practice this design pattern more with games of larger scales.