#summary The requirements and specifications for the software-side of the Super Street Fire project.

= Requirements =

  * There are two sequential sets of flame effects hardware:
    ** Each set has eight flame effects (for a total of 16 flame effects)
    ** The number of flame effects on each set will always be consistent but that number is flexible and should therefore be adjustable.
    ** Each flame effect also has two associated colour sprays (each corresponding to a player)
    ** Flames and colour sprays need to be turned on/off by software
    ** All flame and colour control will be done wirelessly

  * WHAT ARE THE GAME STATES? (e.g., RoundStartState, RoundInPlayState, CalibrationState?)
  * There are two general types of player actions: attacks and blocks
  * When a round is being played, flames represent either a block action or an attack action
  * 


  * There are two players at any given time:
    ** Each player is wearing two gloves (one on each hand), which capture inertial measurements (velocity, gravitational forces, orientation)
    ** Each player is wearing a headset that records brain activity via Electroencephalography
    ** The gloves and headset for each player will wirelessly transmit data

  * There may be other 'peripherals' (score boards, lights, ?) <-- needs elucidation!!
  * The game must run in real-time (i.e., updates should occur at or above 60 Hz)

  * A (polished, user-friendly) Graphical User Interface (GUI) is required:
    ** The interface must be able to operate on an Android tablet/device (mobile?)  and will communicate wirelessly via WiFi
    ** The GUI should display information pertaining to the current state of the simulation and game state (this requires elucidation)
    ** The GUI should refresh information as soon as possible, in real-time (i.e., updates occur at or above 60 Hz)
    ** The GUI should be easy to use and understandable to a non-developer
    ** Only one network GUI can be actively supported at any given time (?)


= Specifications =

  * Protocol for Server-Glove and Server-Headset Communication (One-way communication from gloves/headsets to server)
  * Protocol for Server-GUI Communication
  * Other protocols for data to any other peripherals ...
  * Android program for GUI that can run on a tablet
  

== High-level Software Modules ==

Think Model-View-Controller paradigm:
  * The model is the Game Module
  * The views are...
    ** The Server Module for sending/receiving information which is relayed from/to the Game Module and where events are further broadcasted via the various protocols/packages used for communicating with remote peripherals and GUIs
    ** Any developer-specific GUIs on the server machine (used for debugging/introspective purposes)
  * The controller is the combination of glove and headset hardware and embedded software along with the communications to send the data from that hardware to the server and then parse it and understand it via the Gesture Recognition Module

=== Server (Network Receiver/Sender) Module ===
  * Receives incoming packages from peripherals and interprets the packages into application level objects that can be used by other modules (e.g., glove data is parsed/'unbinarized' and turned into a 'GloveData' object so that it can be passed to the gesture recognition module)
  * Sends packages to peripherals from the ongoing simulation when certain game events occur (e.g., Player 1's life changes from 100% to 80% which raises a life changed event from the game module, the sever module is a listener for such events, it takes the event and builds the appropriate outgoing packages for sending to peripherals such as the score board client).
  * Sends GUI protocol packages over the network via TCP/IP (port TBA)  when events occur in the simulation
  * Receives GUI protocol packages from networked GUI, which can change the state of the simulation (we need to enumerate all of the actions that can take place in the protocol...)

=== Game (Model and Logic) Module ===
  * Tracks information and holds data structures for representing players (e.g., life percentages, names, character type)
  * Tracks state of the game, each state tracks its corresponding game information (e.g., "RoundInPlayState" would track which round it is, how much time is left in that round, how many rounds have been won/lost by what players)
  * Contains data structures for representing blocks, attacks, damage of attacks, routines/functions for executing attacks and dealing with player damage
  * Contains code to signify when certain game events occur and execute the appropriate event callbacks on all listeners to the game model
  * Coordinates blocks and attacks with the flame effect simulation module to ensure the correct flame effects are turning on/off based on the gestures being registered while the game is being played
  

=== Flame Effect Simulation Module ===

=== Gesture Recognition Module ===


=== Android GUI Module ===


=== Debugging/Developer GUI Module ===