CS160: Interactive Prototype Gary Wu - Jordan Berk - Mike Kendall - Mohammed Ali - Hao Luo

 Introduction  Overall Problem  Representative Tasks  User Interface Design + Live Demo  Summary  Questions

 Problem?

 Students often lack the motivation of learning math. They often shy away from learning math because they simply find it to be useless in everyday life.

 Problem?  Students often lack the motivation of learning math. They often shy away from learning math because they simply find it to be useless in everyday life.  Solution?

 Problem?  Students often lack the motivation of learning math. They often shy away from learning math because they simply find it to be useless in everyday life.  Solution?  Our solution is to integrate math questions with an RPG world in which progress is made by upgrading your character, defeating enemies and advancing levels.

EASY TASK: NAVIGATING THE WORLD MAP

FREE-ROAMING PATH VS. LINEAR PATH

MEDIUM TASK: SOLVING PUZZLES

HARD TASK: BATTLING MONSTERS

 Navigation: World Map  Inputs are mapped to the keyboard  Directional arrows are used to move  “Esc” is the designated Cancel button as well as the Status Menu toggler  “Enter” is the designated Action button

 Navigation: Dungeon Map  Portals are used to designate dungeon entrances  A helpful sign post alerts the user of the particular dungeon  User moves to the portal and hits the Action button (Enter) to enter the chosen dungeon

 Navigation: Dungeon Maps  Helpful hints, puzzles, and monsters are found in dungeons  Each dungeon is themed with a particular mathematical subject, such as addition or subtraction  At the end of each dungeon, the user must defeat a boss to advance

 Battling: Monsters  To engage a monster, the user must walk up and touch the monster. The Action key is not needed to initiate combat.  Players have 4 main options available to them: Attack, use a Skill, Meditate, use an Item. Battles are turn-based systems.  UI draws heavily from Final Fantasy and other popular RPGs, such as Pokemon. Usability relies heavily on user’s familiarity with such products.

 Puzzles  Puzzles are events that are triggered by player touch. Puzzles will take forms of various mathematical patterns, theories, and puzzles. These questions are harder than the typical battle math questions, but the rewards are generous.  Puzzles are geared towards helping the user think more abstractly about math, in general  Technique of choice here is a simple input box for users to answer the puzzle.  Changed from initial low-fidelity test. Reason? GUI of puzzle system made the puzzle even more confusing. Also, scripting limitations played a role as well.

 Battling: Bosses  Meditate restores a player’s SP meter so skills can be used. However, in order to do so, the user must correctly answer math questions. These questions are based on the dungeon type.  Using skills will be the best strategy used against boss monsters. That means the user will have to meditate a lot more during these battles. This means more practice with more math problems. Meditate is designed to get the player to answer math questions quickly and efficiently.  The UI design of choice here is a multiple-choice layout menu system. If correctly answered, the player’s SP is replenished. If incorrect, the player loses a turn and nothing happens.  This was changed since the low-fidelity prototype. Reason? User feedback suggested that choosing an answer was faster and more fluid than inputting one. Historically, RPGs of the past followed this same theme, as well.

 Battling: Bosses (cont.)  Skills follow the familiar menu layout of Final Fantasy and Pokemon battle systems.  After a boss has been conquered, the next dungeon is unlocked. Furthermore, the user receives a new, stronger skill for use in the subsequent dungeon.

 Status Menu: Using Items  Items are usable during battles as well as on the world/dungeon maps  Pressing the ‘Esc’ key in the world/dungeon maps will toggle the Status Menu. The status menu displays information about the game to the player  The layout of choice here was derived from typical Final Fantasy layouts. Once again, user familiarity plays a huge role of usability here.

 Scripting Language  The underlying language used in our game is Ruby  Reason? All the benefits of OOP and tons of support from the online community.

 With our Math RPG, we hope to get kids to learn, practice, and use math in a fun yet educational environment. Optimally, the game will be able to get kids who have little interest in math to practice and improve their knowledge.