Download
cs160 interactive prototype n.
Skip this Video
Loading SlideShow in 5 Seconds..
Team Butterfly PowerPoint Presentation
Download Presentation
Team Butterfly

Team Butterfly

386 Vues Download Presentation
Télécharger la présentation

Team Butterfly

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CS160: Interactive Prototype Team Butterfly Gary Wu - Jordan Berk - Mike Kendall - Mohammed Ali - Hao Luo

  2. Overview • Introduction • Overall Problem • Representative Tasks • User Interface Design + Live Demo • Summary • Questions

  3. Overall Problem • Problem?

  4. Overall Problem • 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.

  5. Overall Problem • 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?

  6. Overall Problem • 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.

  7. Representative Tasks Easy Task: Navigating the World Map

  8. Representative Tasks Free-roaming Path vs. Linear path

  9. Representative Tasks Medium Task: Solving Puzzles

  10. Representative Tasks Hard Task: Battling Monsters

  11. User Interface • 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

  12. User Interface • 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

  13. User Interface • 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

  14. User Interface • 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.

  15. User Interface • 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.

  16. User Interface • 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.

  17. User Interface • 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.

  18. User Interface • 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.

  19. User Interface • 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.

  20. Summary • 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.

  21. Questions?

  22. Appreciation