1 / 27

Pencilvania: Architecture Review

Pencilvania: Architecture Review. Presenters: Christopher Buska (Art Director) Michael Gourlay (Developer) Alfred Sterphone, III (Project Manager) Special Guest: Marshall Powers (Lead Architect). Purpose & MOV.

evers
Download Presentation

Pencilvania: Architecture Review

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. Pencilvania:Architecture Review Presenters: Christopher Buska (Art Director) Michael Gourlay (Developer) Alfred Sterphone, III (Project Manager) Special Guest: Marshall Powers (Lead Architect)

  2. Purpose & MOV • Purpose – To create an enjoyable gaming experience that anyone can pick up and play. • MOV – 5000+ unique downloads.

  3. QFD

  4. QFD

  5. QFD

  6. QFD

  7. QFD

  8. ICED-T • Intuitive – 4 • Ease of use • Learning Curve of controls and game rules • Simplicity of the user interface • Consistent – 3 • Game play remains consistent throughout levels • Graphical and musical style • Menu System • Efficient – 3.5 • Game response time to user input

  9. ICED-T • Durable – 3.5 • Game does not crash, handles errors gracefully • Game will play the same on faster systems released in the future • Thoughtful – 3.375 • Easy maintenance of code • Addition of new levels is simple • Is the game fun to play?

  10. Gantt Chart

  11. Function Points & COCOMO • Function Points and COCOMO must be recalculated due to very recent architectural changes. • In summation, however, complexity will be drastically reduced from previous estimates.

  12. 4+1 Architecture • Logical View – Internal communication across modules • Process View – Process in terms of player perspective; what happens • Development View – Development environment and tools • Physical View – Operating platform • Use Cases – Game play and other scenarios

  13. Logical View Sound Module Loads and plays sounds Control Module Takes keyboard/ mouse/gamepad input and translates into events Game Engine Module A “Switchboard” module which mediates communication between the other modules Display Module Abstracts the display Game Implementation Module Contains the game state data structure Handles the game physics UI Module Controls main screen and menus

  14. Process View

  15. Development View

  16. Development Tools • NUnit – C# unit testing module. • SubVersion (SVN) – Source control. • Mantis – Online bug-tracking database • Visual Studio 2005 – IDE • TikiWiki – Project portal

  17. Physical View

  18. Use Cases • Installing the Game • Un-installing the Game • Selecting a Profile • Playing the Game • Starting or continuing a game • Making progress in the game • Adjusting Settings

  19. Performance • At least 30 frames per second • In-game responsiveness • Imperceptible response time • “No delay” between input and feedback • Quick load times • Minimum Specs • Windows XP • .NET 2.0 • Computers that meet our minimum specifications will not have any foreseeable difficulty in running our software.

  20. Trustworthiness: Safe • What is “safe” in a game? • This game will NOT kill you. • Critical errors will not corrupt your computer. • Game errors will not crash Windows XP.

  21. Trustworthiness: Reliable • Our game piggybacks on SDL, a very mature open source project. • Unit testing ensures that modules and their member functions operate appropriately without testers interacting with the actual game environment. • Test driven development forces the programmers to think logically about what each function accomplishes before writing actual code.

  22. Trustworthiness: Secure • Level editor • Loading stock or custom levels will simply fail if unrecognized syntax is inserted into them. • User input • Unmapped input is dropped/ignored • Currently pursuing an open source solution for product key implementation.

  23. Operations and Administration • Run executable. • Play game (controlled with keyboard or gamepad). • Create levels for game use. • Game installation. • Player Administration (creation, modification, deletion). • Upgrading game. • Patching game. • Un-installation of the game.

  24. Error Recovery • Game errors will not crash Windows. • Game errors will not crash the game without informing the user of the error that occurred. • No unhandled exceptions. • All game inputs will be checked before use. • Reinstallation of game will not clear user files. • The player will be able to continue where they left off.

  25. Error Recovery: Unrecoverable • Corrupted executable • Corrupted level files • Disk Error (disk full, access errors) • We attempt to write to the drive before starting the game as an attempt to determine if there will be any access errors. • Video hardware error • SDL library corruption or SDL not found • Need to reinstall SDL

  26. Error Recovery: Recoverable • Corrupted music / sound effect files • Inform player and continue without sound • Sound hardware error • Inform player and continue without sound • Corrupted user data • Inform user that a new profile must be made

  27. Any questions? Thank you for your time!

More Related