1. CMPT371 – Team 1 Luminance

2. Project – Luminance  Puzzle game  Guide a beam of light using a limited set of tools to certain goals avoiding obstacles along the way  Previous milestone  Majority of work has been developing the different components of the game  Current milestone  Creating core gameplay-related functionality and updating the system to support it

3. Current State  Resource Manager  Fully functional  Input  Touch, drag, pinch  GUI  Menu state functional  Level Loader  XML, fully functional  Graphics  Enhanced from last milestone (sphere, box, etc.)  Game  Renders level, able to play

4. CPM Diagram

5. New Development  Toolbelt  Creates the on-screen toolbelt  User can interact with it and place objects on the grid  GUI  Onscreen widgets  Menu works, though not integrated  Light  Interacts with tools placed on the grid  Detects winning condition properly

6. New Development  Assets  Nicer graphics  Theme of game developing ▪Images for textures and icons  Playable Level  Level loader is functional  Loads a simple level that can actually be played!!

7. Luminance – Screen shot

8. Testing  Smoke Test  Unit tests  Coverage Testing – EMMA  Produces a lot of useful information  Example  Stress Test  Use Monkey Runner  Frame period normal 0.05, peak 10  GUI Testing  What we have, works  Unable to complete for milestone  Mock Testing  Integrated mock testing into unit testing  Use Case  Expanded, created test cases  Structured test classes based on test cases

9. Risk – Vague feature description  Description  Avoid vague descriptions for implementation of new features  Probability: Medium  Severity: High  Plan:  Formalize a design of the new components before implementation  Design lead will clarify any issues that should arise  Status: Not yet realized

10. Risk – Due date?  Description  Ensure all group members are aware of impending due dates  Probability: Medium  Severity: High  Plan:  Project manager informs group of correct date  If individuals are not responsive to this, intervene on an individual level  Status: Occurred, solved (and handed in on time!)

11. Code Reviews  Code Reviews  Done individually  Code written by other group member  Record findings in a communal place  Peer Reviews  Done with most of group present  Look through code together and discuss possible changes or defects

12. Formal Inspection  Resource Manager class  Moderator: Martina  Author: Zenja  Reader: Zenja  Inspectors: Martina, Zenja, Jonny, Kum  Recorder: Steven  Planning and Overview  Martina planned meeting and booked breakroom  Informed members what package we were inspecting

13. Formal Inspection  Inspection Meeting  Found 8 defects  Minor changes  Rework  Zenja fixed the defects we decided as a group that needed to be fixed  Follow-up  Zenja documented the changes he made  Martina verified the changes did not break anything

14. Updated Project Plan  Milestone 4  Prototype and implement new in game puzzle tools and mechanics  Outline and design user manual  Run user evaluation  Robotium test suite  Add sound and special effects for all actions  Implement random level generator  Updated smoke test based on source code changes  Complete Beta version of the game  Milestone 5  Status Clear out all known bugs  Play test  Prepare for code Freeze  Release version of game  Post Mort-um document  Push game through Q&A process

15. Questions?  The end!