1 / 20

Here Be Dragons

Here Be Dragons. Team RPG Paul Maserrat Adam Harlow Jared Strop Ed Larson CSC 4350 Georgia State University  Fall 2010. Introduction. Game Title - "Here Be Dragons" Game Type - Role Playing Game Programming language - Java Abbreviations MP - Mana Points HP - Hit Points

armen
Download Presentation

Here Be Dragons

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. Here Be Dragons Team RPG Paul Maserrat Adam Harlow Jared Strop Ed Larson CSC 4350 Georgia State University  Fall 2010

  2. Introduction • Game Title - "Here Be Dragons" • Game Type - Role Playing Game • Programming language - Java • Abbreviations • MP - Mana Points • HP - Hit Points • EXP - Experience Points • JRE - Java Runtime Environment

  3. Team Roles GUI Programming/Item package  • Adam Harlow Combat Controller/Attributes package  • Jared Strop Backgrounds/Travel package  • Ed Larson Documentation/Shop package  • Paul Maserrat Additional character art provided by Stephanie Harlow

  4. About "Here Be Dragons" • Open-ended, first person Role Playing Game, inspired by the classic PC RPGs and adventure games • Travel to different scenes • Battle enemies in turn-based combat • Gain experience and gold by winning battles • Purchase items, new equipment, and spells • Confront the dragon and save the kingdom

  5. Design Goals • Entertainment • the player should feel satisfaction from winning • Portability • should work on platforms with JRE 1.6 • Stability • exception handling in bounded data structures • Readability • simple on-screen instructions • Control • mouse-triggered events • Challenging • should be hard enough to motivate, but not discourage

  6. Design Criteria • Performance Criteria • Memory • Minimal memory needed • Speed • Quick, no dynamic graphics • Display •  Fixed 640x480 pixels with 256 colors. • User Input • Input through GUI with mouse or keyboard. • Dependability Criteria • Stability • Strict class hierarchy with private and protected member variables • Security • Single player on single PC. No personal Information needed.

  7. Design Criteria (con't) • Cost Criteria • Development Cost • Cost of time spent coding. Software is free. • Deployment Cost • Minimal. Java coding makes it very portable. • Upgrade Cost • No upgrade of a current system. Future upgrade is based on changing the code. Cost is time spent. • Maintenance Criteria • Portability • Adaptability • Strict class hierarchy makes it easy to expand later. • Readability • Very readable. Method calls and class names will correspond to its given name.

  8. Changes We Made • No Databases, used many more classes • Each Item/Spell is its own class • Each type of character and enemy is its own class • More Packages • Attributes package for heroes and enemies • Item Package for items hero can use/purchase • Spell package for spells hero can use/purchase

  9. Proposed System • Use Case Diagram

  10. Proposed System (con't) • Functional Requirements • User • Load new game or saved game • Save current game • Use help instructions • Control User Character • User Character • Acquire Gold • Purchase Items • View Inventory or Map • Fight  & Defeat Enemies • Rest to restore HP and MP

  11. Proposed System (con't) • Non-Functional Requirements • Usability • Reliability • Performance • Supportability • Implementation • Interface

  12. Class Diagram

  13. Classes • Attributes - contains all core statistics for characters (e.g. hit points, mana points, strength, intelligence...) • Hero - has methods to equip items, use items, cast spells, attack, or die. • Enemy - has methods to attack hero, get file name for image, or spawn randomly • Each type of enemy is its own class. • Item, Spell - can be used by heroes and enemies • Each type of item and spell is its own class. • ItemShop, SpellShop - sells specialized stock to hero

  14. Class Inheritance Hierarchy • Attributes • Hero • Warrior, Wizard, Vanguard • Enemy • Goblin, Vampire, Ogre, ... • Item • Potion, Ether, Elixir, ... • Spellbook • Book of Fireball, Book of Earthquake, ... • Equipment • Armor • Iron Armor, Diamond Armor, ... • Weapon • Wand, Wooden Sword, Diamond Sword, ...

  15. GUI Subsystem • Coded in Java using javax.swing.* packages • Consists of the GUI package for GUI components, Images package for graphics • Opens the JFrame which calls the panels from the Interface bar

  16. GUI Components Used • ImageIcon - displays image files in GUI, can be used on JLabels, JButtons, and the content pane. • JLabel - used for displaying ImageIcons, text, or both.  Can also respond to mouse events. • JList - a list which has selectable items it gets from a model

  17. Travel Subsystem • Map package displays current scene and those previously visited • Tracks the number of times that a character visits a scene • Travel package allows navigation up, down, right left

  18. Combat Subsystem • Creating an array of random enemies to fight • Creating a fight between a hero and the enemy array • Controlling the attacks and adjusting the attributes of the hero and each enemy in the enemy array • (HP, MP, Item Inventory, Spell Inventory...) • Ending the fight if any exit conditions are met • (Hero is dead, hero runs away successfully, or all enemies are dead) • Handing out EXP and gold after all enemies are dead while giving out none if the hero runs away or dies. • Testing if the hero has leveled up

  19. Shop Subsystem • Item Shop - sells equipment and items • Potion, Ether, Armor, Sword, ... • Spell Shop - sells spellbooks • Fireball, Earthquake, Boulder, ... • Buying and Selling • The Inn • Rest to regain MP and HP.

  20. Conclusion • What have we learned? • It’s better to collaborate on code than on documents. • Cannot anticipate true complexity in the early stages. • A better understanding of inheritance. • Model-View-Controller architecture and various GUI components. • Combining event-driven programming with procedural programming.

More Related