1. Luminance

2.  Major group refactoring.  Development Lead: Stephen Damm.  Project Manager: Martina Nagy.  Test team member: Chet Collins.  A lot of effort and cooperation to get new team configuration organized.  Met with professor.  Talked through it as a group.  But we’re still developing strong.

3.  Puzzle game  Guide a beam of light using a limited set of tools to certain goals avoiding obstacles along the way.  Previous milestone  Focused on setup/research  Examining the previous system  Current milestone  Focused on development  Majority of work has been developing the different components of the game

4.  Resource Manager  Textures, Sounds, Music  Input  Touch, Drag  GUI  Menu primitives  Level Loader  XML  Graphics  Basic primitives (sphere, box, etc.)  Game  Renders grid, background, game objects

7.  Strategy for testing  When dev’s commit code stubs, inform test team  Gone to external sources for advice  Ant scripts vs. IDE  Results so far  Continuous integration working.  Game State testing – assume OpenGL is correct.  Use case scenarios – GUI Tests.  User Evaluation plan.

8.  ResourceManager.  jUnit.  Use case testing.  GUI.  Black box.  For every class in the system.  Smoke test  Guarantees repository has run able code

9.  Description  General communication issues amongst the sub groups.  Probability: Low  Severity: High  Plan:  Adjust roles to be clear and precise.  Additional weekly meetings dedicated to sub groups sharing their progress.  Status: Occurred, solved.

10.  Description  Losing a team member.  Probability: Low  Severity: Low  Plan:  Shuffle around people to fill the lost roles.  Status: Occurred, solved.

11.  Description  The game we envision cannot achieve the performance required.  Probability: Medium  Severity: High  Plan:  Lower texture quality, reduce special effects, smaller levels.  Explore any android specific optimizations.  Profile our code for hot spots.  Status: NULL.

12.  Code Reviews  Individual  Peer  Smoke Test  Guarantees run able game  Build master  Ensures code quality  Reviews days work

13.  Android/Java Caveats  No abusing memory allocations ▪ Memory limit: 24MB ▪ Avoid ‘new’ anywhere in update() or draw() code paths  Turning off the garbage collector ▪ Call manually as we see fit ▪ Cannot let it run wild  Java loves threads: ▪ main thread, event thread, android thread ▪ OpenGL context only valid and accessible in android thread

14.  Version Control Strategy.  Essentially remained the same. ▪ TeamCity + Google Code.  Developers commit stubbed classes. ▪ Including pre-conditions, post-conditions, parameter explanations, etc.  Test team is able to start writing unit tests on this stubbed out code.  End result:  Software development process more efficient.

15.  Enhanced communication.  Discuss as a group what changes are going to be made.  Enhanced collaboration.  Separate team meetings for specific discussions, then regroup.  Improved division of labour.  No longer relying on one person to do it all.

16.  Improved chain of command.  More defined developer lead position and project manager positions.  Enforcing group understanding of system.  OpenGL tutorial conducted by Stephen.  Game oriented testing.  Challenges of game testing.  Focus is on black box / play testing.  Tests written as code stubs are created.

17.  Milestone 3:  Game level editor.  GUI Test suite.  Design user evaluation questionnaire.  Finalize the in game object models.  Implement special effects, sound effects.  Milestone 4:  Discuss changes to game based on evaluation.  Prototype and implement new in game puzzle tools and game puzzle mechanics.  Outline and design user manual.  Implement random level generator.  Beta version of the game.  Milestone 5:  Clear out all known bugs.  Play test.  Release version of game.  Post Mort-um document.  Push game through Q&A process.

18.  The end!