220 likes | 349 Views
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
E N D
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 • EXP - Experience Points • JRE - Java Runtime Environment
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
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
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
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.
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.
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
Proposed System • Use Case Diagram
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
Proposed System (con't) • Non-Functional Requirements • Usability • Reliability • Performance • Supportability • Implementation • Interface
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
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, ...
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
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
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
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
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.
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.