1 / 18

CMPT371 – Team 1

The Luminance project aims to develop an engaging puzzle game where players guide a beam of light through a series of challenges. Team 1, led by Stephen Damm and project manager Martina Nagy, is focused on refining game components like resource management, graphics, and user interface. Key milestones include establishing a game level editor, implementing sound effects, and preparing for a beta release. Effective team communication and collaborative efforts remain critical for overcoming challenges and adhering to project timelines.

karena
Télécharger la présentation

CMPT371 – Team 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Luminance CMPT371 – Team 1

  2. But first... • 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. 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 • 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. Current State • 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

  5. Class Diagram

  6. CPM Diagram

  7. Testing • 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. Test Results • ResourceManager. • jUnit. • Use case testing. • GUI. • Black box. • For every class in the system. • Smoke test • Guarantees repository has run able code

  9. Risk – Team Communication • 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. Risk – Losing members • Description • Losing a team member. • Probability: Low • Severity: Low • Plan: • Shuffle around people to fill the lost roles. • Status: Occurred, solved.

  11. Risk – Performance • 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. Software Quality Assurance • Code Reviews • Individual • Peer • Smoke Test • Guarantees run able game • Build master • Ensures code quality • Reviews days work

  13. Software Quality Assurance • 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. Software Quality Assurance • 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. Software Engineering Process • 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. Software Engineering Process • 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. Updated Project Plan • 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. Questions? • The end!

More Related