Iterations and group workflow

Establishing a team workflow is important with any group project. With this particular one there a couple of factors to consider;

1. There are likely to be a large number of contributors on a relatively small project
2. Due to the timing of the project many of the contributors are likely to have limited time to work on it
3. Not everyone can make every meeting to discuss the project

The simplest solution to tackle these problems is to work in iterations. Each week a number of goals are set to be achieved within a timeframe, upon completion of that time frame the next set of goals are defined. This style of iterative workflow is essentially a casual form of Agile software development popular with development companies today.

Iterative workflow

If every couple of weeks the group sets its next set of goals they can remain realistic and achievable within that timeframe. It is important ensure that the App remains deployable at the end of each iteration because the project may be dropped at any point as pressure from other university work may build.

With this in mind the first iteration was planned out, a stripped down version of the initial plan by Rob and Sam. 

The game was broken down to the 4 critical classes necessary for it to exist. It consists of:

• A graphics handler - charged with drawing the keys, stave and positioning the aliens
• A note alien - a sprite with an x position and a note number
• A keyboard class - whom sends the note numbers to destroy the aliens
• A game engine - to create aliens and move them along

Once these are done the game should work. Everything after that will be a bonus!

Version Control

As a first foray into a team software development project, the group acknowledged the importance of setting up a version control system. The system would have to enable multiple contributors to work on the project in unison whilst minimising the risk of anyone being able to overwrite others work.

A number of version control systems exist, such as Git and SVN, however Git was chosen due to a number of the group being slightly more familiar with it. As a small group project with no experience any advantages/disadvantages of other systems would likely be academic. Sometimes go with what you know is the way!

The project is hosted at https://github.com/jeromegill/StaveInvaders and will remain open source.

The Plan

Ok so me (Sam hunt) and Rob Davidson have sorted out the blog for keeping track of our progress! This blog will be updated weekly and will showcase our work towards the iphone app!

So what will the app be.......

A Musical space invader note reading game.

We did some class prototyping. As follows

AppDelegate (objective c) Launches the app

ViewController (objective c) Controls the contents on the screen

Game Engine (c++) Keeps things moving

Virtual Keyboard (c++) contains co-ordinates for the virtual keyboard

Space Invader (c++) the little note object that moves across the screen

Audio Playback (c++) Plays back audio

Score (c++) Keep track of the Score

Graphics Manager (objective c) Converts any c++ data, objects into objective c objects so they can be draw to the screen.

These are the diagrams we came up with.

The second picture shows the GameViewController storing any input into the GameEngine, The game engine works on a callback loop and will check for any of these events, then work out what position they would be on the VirtualKeyboard, then use the note that it returns to check against the SpaceInvaders, then update the score, then push any display updates into the GraphicsManager, which tells the GameViewController what to draw. The GVC runs on the same loop as the GameEngine so will update when that is called, not whenever the graphics manager tells it something new.