Final Report-Group:BuTtErFlY

From CS 160 Fall 2008

Contents 1 Team 2 Problem and Solution Overview 3 Target User Group 4 Tasks 5 Design Evolution 5.1 World/Dungeon Map 5.2 Battle System 5.2.1 Battle Screen Layout 5.2.2 Magic Menu 5.2.3 Item Menu 5.2.4 Meditate Menu 5.3 Puzzle 5.4 Choice Evaluation Technique: Interactive Prototype 6 Final Interface 6.1 The Final UI design 6.1.1 Functionality 6.1.2 User Interface Design 6.1.2.1 Save, Continue, and Starting New Games 6.1.2.2 Playing the Game 6.1.2.3 Learning Math 6.1.2.4 Pausing and Quitting 6.1.3 Implementation 6.2 What Was Left Unimplemented 6.2.1 What Was Left Out and Why 6.2.2 Wizard-of-Oz Techniques

Team

Name	Contribution
Gary Wu	Final report
Mike Kendall	Game mechanics and poster.
Mohammed Ali	Presentation slides.
Hao Luo	Final game prototype.
Jordan Berk	Final report - "Implementation"/"What was left out"

Problem and Solution Overview

The importance of having a solid foundation in math at a young age is evident in today's society. The concepts in math sequentially build on others. Each concept builds on the concept that was learned before. Therefore it is vital that a child's basic math skills be adequate so that there is a greater chance for success at the later stages of learning math. Math is like sports, if you want to be good, you have to practice often, and make those mental muscles strong. Children, however, often lack the motivation to practice math.

Our game will help to bring that motivation to learn back to children. With the rise of portable gaming, media, and other forms of entertainment, children in today's world are having a difficult time staying focused with their schoolwork. Therefore, a game that provides a medium of entertainment, while retaining its underlying educational influences will try to combine the best qualities of both worlds.

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. To accomplish these tasks, learning and using math is required, thereby making math problems the driving force of the game. Because performing these tasks is fun and rewarding, the user has motivation to learn and use math.

Target User Group

Our target user group will be students from the 5th to 8th grade range. Since our game incorporates math skills ranging from basic addition to pre-calculus problems, we can efficiently gear our game towards that target user group. Furthermore, our game will not require the user to be sufficiently familiar with the RPG style of gaming, as our tutorial should help users of all game-skill levels. However, for users that regularly play games, they have the option of skipping the tutorial and playing the game as is. Since our game draws heavily on menu layouts and systems of popular RPG games from the past, such as Final Fantasy and Pokemon, experienced users should feel comfortable playing the game without much help.

Tasks

Level	Description
Easy: Navigation	Our interface follows the norm for the Role Playing Game genre. The easy task of moving around and interacting with your world is achieved by using the arrows (or the d-pad, if you use a game controller) and there is one button for “Confirm” and another for “Back/Cancel.” Interacting with elements in the world is as simple as walking up to them and pressing the confirm button, or in some cases, just the former. Reason: Navigating the world map should be an easy task. The basic principle of moving in a game should be almost second nature to any user. Thus, an intuitive design that draws on previous games and familiar real world examples (i.e. a compass, or grids on a real map) would make sense here
Medium: Puzzles	When a puzzle sequence starts, you don't know what the input method is going to be. Maybe you will walk around and press buttons in a specific order, maybe you will input a large number one digit at a time. Either way, the user will have to interpret the puzzle as it is presented, do some mathematical analysis on it and then give the answer back to the game through various interfaces the game presents. In our prototype, our puzzle is very simple, but the method for inputting the numbers comes from standard console input. It's counter-intuitive to make the user use arrows and a confirm button to input a number when they're already using a keyboard, but to keep the game accessible for those playing on a gamepad or other input device, this method is optimal. Reason: Puzzles were deemed a medium task as the interface for solving puzzles is possibly different each time, in addition to the intended difficulty of actually figuring out the math solution.
Hard: Combat	Our combat system throws a twist at the user by making them solve math problems in order to replenish their SP (spell points). This task is harder both because of the problems and because the method of input is slightly different. This is also the same method that is used when you are choosing a skill to use when attacking an enemy, except that in this case when you make the wrong choice, your turn ends and you get attacked without doing anything useful. Reason: This was deemed a hard task as the user has to orient him/herself with the menus, figure out the meaning of certain actions, and strategize the best way of defeating the monster.

Design Evolution

World/Dungeon Map

---

1. Low Fidelity World Map Sketch

2. Interactive Prototype World Map Screenshot

3. Pilot Usability World Map Screenshot

Changes: Instead of having the user click on the screen to walk and interact with the game, we decided to go with the arrow keys/enter (or directional pad/button if the player is using a gamepad) combination. We decided to do this because we wanted the player to have a another degree of freedom when selecting an input device. Furthermore, we also wanted to mimic navigational systems from popular and successful RPG games from the past so that the average player would be familiar with the system.

1. Low Fidelity Dungeon Map Sketch

2. Interactive Prototype Dungeon Map Screenshot

3. Pilot Usability World Dungeon Screenshot 1

4. Pilot Usability World Dungeon Screenshot 2

Changes: Instead of having the user click on an event to interact with, our interactive prototype uses the 'Enter' or action key to interact with items/monsters/events. We also made navigation around the dungeons easier and more aesthetically pleasing from our pilot usability studies. Additionally, between the Interactive Prototype and final version, we added randomly appearing battles to increase the number of battles, and also make the dungeon design less path-oriented.

Battle System

---

Battle Screen Layout

1. Low Fidelity Battle Screen Sketch

2. Interactive Prototype Battle Screen Screenshot

3. Interactive Prototype Battle Screen Screenshot

Changes: We migrated from the original Pokemon-style fighting system, to the more traditional Final Fantasy style battle screens. To the average gamer, this menu layout will seem very familiar and easy to navigate. Our main reason for this change was to promote recognition and familiarity with past RPG battle systems, rather than implementing a new system that the player would have to learn. We also made sure that the inexperienced player will still be able to use this system by incorporating and battle lesson section in our tutorial portion of our game.

Magic Menu

1. Low Fidelity Magic Menu Sketch

2. Interactive Prototype Magic Menu Screenshot

3. Pilot Usability Magic Menu Screenshot

Changes: No real changes here besides the amount of SP that each magic spell takes up. This was determined during our interactive prototyping and pilot usability studies sections.

Item Menu

1. Low Fidelity Item Menu Sketch

2. Interactive Prototype Item Menu Screenshot

3. Pilot Usability Item Menu Screenshot

Changes: We decided to also incorporate an item system on the world/dungeon map so that the player will be able to use items outside of battle. Picture number 3 shows the world/dungeon map way of accessing the item menu while picture number 2 shows the item menu screen that appears when accessing the item menu through battle. There was no real change in the UI of the item menu as it was straightforward.

Meditate Menu

1. Low Fidelity Meditate Menu Sketch

2. Interactive Prototype Meditate Menu Screenshot

3. Pilot Usability Meditate Menu Screenshot 1

4. Pilot Usability Meditate Menu Screenshot 2

Changes: We took out the input-type answer system with the more straightforward and less confusing multiple-choice answer system. We learned during the lo-fi and interactive prototyping sessions that the multiple-choice system was easier to use, faster, and less tedious to use than the input-type system. By using a multiple-choice answer system, it also allows the user to use both the keyboard and gamepad to play the game. Historically, multiple-choice based answer systems were the systems of choice of past RPG games, as well. We also decided to add a status message in our pilot usability studies that alerts the player whether meditation had succeeded or not. Users commented that they were unsure whether meditation worked in our interactive prototypes, so we addressed that change.

Puzzle

---

1. Low Fidelity Puzzle Sketch

2. Interactive Prototype Puzzle Screenshot

Changes: Following along the same lines as the meditation changes, we decided to swap out the free-form puzzle interface with the simple and familiar number-input system that past RPGs have used. Again, we wanted consistency with our design and layouts so we followed to theme of familiarity and recognition. Users from our lo-fo prototyping interviews complained that figuring out exactly how to solve and use the puzzle interface was harder than the puzzle itself. That was our main reason for changing the interface in our interactive prototype. The error rate on the puzzle task was dramatically lower so we felt that this change was spot on. We kept this same system in our pilot usability studies as it drew favorable results.

Choice Evaluation Technique: Interactive Prototype

---

The interactive prototyping interviews was where we found most of our severe and critical incidents. The information gathered during this phase was invaluable and definitely shaped a huge part of our game for the better. Without real users with different gaming, education, and technical backgrounds, we wouldn't have been able to find all of our tweaks and fixes. We can definitely see the importance of the persona in user interfaces. Also, by having a working version of the game, instead of the paper prototyping and wizard-of-oz techniques, flaws and bugs were more easily seen by the group. This meant we could readily fix those glaring errors before having users test out our prototype. To a further extent, we felt that users were more involved in the game/interviews and gave more insightful comments when using a working prototype of the game. We attributed this to the fact that the users could actually play around and explore the system.

Final Interface

The Final UI design

Functionality

• Save, Continue, and Starting New Games
  • Players will be able to save their progress in a certain game and then return to it at a later time
  • Players will also have the option of have multiple save states and thus start new games whenever the player chooses

• Play a Role-Playing Game
  • This involves all the core functionalities of a typical RPG:
    • Learning how to play the game: tutorials
    • Exploring new maps and dungeons
    • Collecting items and resources
    • Following a storyline
    • Battling monsters
    • Leveling
    • Defeating the Boss monster that ends the game and reveals the story
    • Solving puzzles and accomplishing other challenges

• Learn Math
  • Through battling monsters and leveling up, players will need to correctly answer math questions to progress in the game
  • Other challenges, such as puzzles, appear that quizzes and expands the player's understanding on fundamental math concepts
  • The player will be able to hone and learn math skills ranging from addition, subtraction, division, exponents, to pre-calculus

• Pausing and Quitting
  • Players are able to pause and quit the game anytime they so choose

User Interface Design

Save, Continue, and Starting New Games

1. Title Screen

2. Continue Screen

3. Status Screen

• New Game
  • When players start the game, they are greeted with the title screen shown in (1.)
  • By using the arrow keys to move up and down, they can highlight the mode they wish to proceed to
  • By pressing the 'Enter' key, they confirm their selection
  • Highlighting 'New Game' and pressing the 'Enter' key will start the player off in a completely new game

• Continue
  • By highlighting 'Continue' and pressing the 'Enter' key, the player will access the continue menu, pictured at (2.), and will be presented with different saved file states that the player had previously saved
  • Using the arrow keys to move up and down, the player is able to highlight the file of choice
  • Pressing the 'Enter' key will confirm the file selection and start the game wherever the player previously left off

• Save
  • During a game, the player can access the status menu by hitting the 'Esc' key, pictured at (3.)
  • The player can then choose to save the game to a specific slot at the save screen, which looks like picture (2.)

Playing the Game

1. Tutorial Dungeon	2. World Map	3. Addition Dungeon	4. Treasure Box
5. Battle Screen	6. Fight or Escape	7. Skills Menu	8. Meditate Question
9. Meditate Status	10. Puzzle Screen

• Learning how to play the game: tutorials
  • At the start of a new game, there will be a tutorial section that teaches the player the basic mechanics of the game
  • This includes buttons, menu access, using items, and how to use the battle system
  • The tutorial dungeon can be seen at picture (1.)

• Exploring new maps and dungeons
  • By using the arrow keys to move and the 'Enter' key to confirm, players are able to simple, and intuitively navigate the world and dungeon maps
  • Maps were built to be functional, yet aesthetically pleasing
  • In dungeon maps, players are able to battle monsters, pick up treasure, and explore the mathematical land of Addam.
  • On the other hand, world maps are only made for exploring
  • The world map can be seen in picture (2.)
  • A sample dungeon map can be seen in picture (3.)

• Collecting items and resources
  • As pictured in (4.), players will be able to pick up items in dungeon maps from treasure boxes
  • To access a treasure box, the player has to walk next to the box and press the 'Enter' key to open
  • Also, defeating Boss monsters will also give the player additional items

• Following a storyline
  • As is true for any fun role-playing game, our game incorporates a compelling storyline that gives the player a reason to fight in the mathematical world of Addam
  • This is represented in the form of dialogue between non-player characters and the user
  • In-game dialogue is represented in the form of text boxes, as does many traditional RPGs

• Battling monsters
  • When engaging a monster, the player has the option of either fighting or escaping. The menu can be seen in picture (6.)
  • If the player chooses to fight, the battle screen appears. The battle menu can be seen in picture (5.)
  • Players are able to choose these actions during battle: Attack, Skill, Meditate, and Item. All of these take 1 turn.
  • Attack performs a simple, physical attack
  • Skill opens up a sub-menu of available skills that take SP to cast. However, these are magic spells that do massive damage. The player should realize that using skills are the most efficient means of battling. A sample skills menu can be pictured at (7.)
  • Meditate provides the player a chance to restore SP during battle. Since skills require SP, meditate provides the means for skills to be cast. If selected, the meditate question screen appears with a math question specific to the particular dungeon. For example, if a player is in the Addition Dungeon, all math questions that appear when using 'Meditate' will be varying forms of addition problems. If the player is in the Subtraction Dungeon, all math questions will be varying forms of subtraction problems. As mentioned before, the meditate question screen consists of a simple multiple-choice based system. If correctly answered, a percentage of the player's SP will be replenished, which in turn allows skills to be cast. If incorrectly answered, a turn is wasted and nothing happens. A status message after choice confirmation alerts the player whether the question has been correctly answered and if any SP has been replenished. A sample meditate sequence can be pictured at (8.) and (9.)
  • Items can also be used during battle. If selected, the item screen appears and the player can choose which item to use.
  • Battling monsters allows the player to become stronger, thus having a better chance at defeating the Boss of each dungeon
  • Strategizing the best method of defeating certain monsters is one of the major challenges the player faces in this game

• Leveling
  • As mentioned before, battling monsters allows the player to become stronger, thus having a better chance at defeating the Boss of each dungeon
  • Experience points are gained with each battle which contributes to the leveling of the character
  • Gold is also acquired through battles, which will aid the player in the acquisition of items at shops

• Defeating the Boss monster that reveals the end story
  • There is a Boss monster at the end of each dungeon. These monsters are quite challenging but provide valuable resources when defeated.
  • There is also the final Boss monster in the last dungeon. Defeating this monster finishes the storyline that the player has been following while playing the game. Since RPGs are usually open-ended games, defeating this final Boss monster will not end the game. It is up to the player to decide whether to continue playing.

• Solving puzzles and accomplishing other challenges
  • Along the way, the player will encounter puzzles and events that challenge the players math prowess
  • Accomplishing these challenges allow the player to proceed with the game and story
  • A sample puzzle screen can be pictured at (10.)
  • A simple input system that can be controlled with just the arrows and 'Enter' key is used
  • Substantial forward progress cannot be made until these challenges are finished

Learning Math

1. Meditate Question

2. Meditate Status

3. Puzzle Screen

• Meditate
  • Meditate provides the player a chance to restore SP during battle. Since skills require SP, meditate provides the means for skills to be cast.
  • If selected, the meditate question screen appears with a math question specific to the particular dungeon. For example, if a player is in the Addition Dungeon, all math questions that appear when using 'Meditate' will be varying forms of addition problems. If the player is in the Subtraction Dungeon, all math questions will be varying forms of subtraction problems.
  • As mentioned before, the meditate question screen consists of a simple multiple-choice based system. If correctly answered, a percentage of the player's SP will be replenished, which in turn allows skills to be cast. If incorrectly answered, a turn is wasted and nothing happens.
  • A status message after choice confirmation alerts the player whether the question has been correctly answered and if any SP has been replenished. A sample meditate sequence can be pictured at (1.) and (2.)
  • As the game progresses, more and more of the battles rely on using the player's acquired skills. This means that 'Meditate' will be used more and more, which in turn means that the player will have to solve more and more math problems. They say practice makes perfect and this method of repitition should help.

• Puzzles
  • Along the way, the player will encounter puzzles and events that challenge the players math prowess
  • Solving these puzzles will teach the player fundamental concepts and theories in math
  • Accomplishing these challenges allow the player to proceed with the game and story
  • A sample puzzle screen can be pictured at (3.)
  • A simple input system that can be controlled with just the arrows and 'Enter' key is used
  • Substantial forward progress cannot be made until these challenges are finished

Pausing and Quitting

1. Status Screen

2. End Game Menu Screen

• Pause
  • During the game, the user can pause the game by pressing the 'Esc' key anytime
  • To resume the game, the user can hit the 'Esc' key again
  • During a battle, pausing the game is equivalent to not doing anything during the user's turn, since battle sequences are turn based

• Quit
  • Users are able to quit the game by hitting the 'Esc' key and accessing the status menu
  • Using the arrow keys, the user can select 'End Game' from the menu and choose whether to completely shut the game down, or return to the title screen
  • The status menu can be pictured at (1.) and the end game menu that appears can be pictured at (2.)

Implementation

To implement the UI described above, we used RPG Maker XP, a Windows-based platform for designing and implementing RPG games. The program includes built-in map elements, animations, characters, enemies, as well as many standard basic RPG functions such as navigation and battling. Using the program interface and the scripting language (Ruby), we expanded upon what the program provides, creating our own title screen, puzzles, storyline, maps, and battle interface following the UI.

The most difficult user interface element to implement was the Meditate function, which is used to restore SP upon the user correctly answering math questions. Because RPG Maker obviously had no built-in platform to create this functionality, we had to edit the underlying scripting code to create it. Our solution essentially tricked the game into thinking that the Meditate skill is equivalent to using a particular item (depending on the correctness of the math answer), which either displays a "Success" text box and restores SP, or displays a "Failure" text box and does not provide any benefit.

What Was Left Unimplemented

What Was Left Out and Why

Scope of Game - Although never planned to be incorporated into our prototype, it should be noted that our final prototype, although a self-contained and complete game, is nowhere near the length necessary to have the user learn the represented math to an appropriate degree. As it is now, the game lasts on the scale of a few hours average, but for it to have actual educational value, it is likely that each dungeon would have to take at least an hour so that the respective math operation is heavily reinforced. This sacrifice was made so that we could concentrate our efforts on user interface design rather that game and map design.

Chained Meditate - Our lo-fi prototype included a feature we called "chained meditate." This feature made it so that instead of the Meditate skill restoring a fixed percentage of total SP (as it is in the interactive/final prototype), the player would have to answer as many math questions as they could in a row, until they got one wrong or maximized their spell points. This was left out of the interactive prototype for time reasons, but based on the results of the pilot usability study, we decided to permanently remove this feature, since users seemed very satisfied with the stability of a fixed SP restore function.

Enemy HP Display - Our lo-fi prototype included a permanent display of enemy HP (hit points) on the standard battle screen. We were unable to include this feature in the interactive and final prototypes due to the limitations of the RPG Maker platform. However, upon comparing the battle strategies used by participants of the lo-fi testing and the pilot usability study, it appears this display does not affect chosen actions significantly. Plus, even if a non-optimal strategy is used (basically the case of using a more powerful attack than necessary to finish off an enemy and therefore using up more SP than required) only encourages more math usage, which is the primary goal of the game anyway.

Enemy Levels - Our lo-fi prototype included a permanent display of enemy 'level' on the standard battle screen as well. This was left out of the interactive prototype simply because it served no function. Knowing the opponents level does not affect battle strategy, we realized, so keeping that information there was simply a waste of space and potentially confusing to an inexperienced RPG player. In fact, enemy levels are not represented at all within the game, so it wasn't just a user interface decision.

Enemy Types - Our original plan, and what we put into the lo-fi prototype, was to include Pokemon-style "types" of enemies, essentially classes with unique strengths and weaknesses. For example, a 'division'-type monster would be extra susceptible to division attacks by the player, but resistant to multiplication attacks. We decided following the lo-fi prototype that this system added unneeded complexity to the game, especially since we switched the combat system from Pokemon-style to Final Fantasy-style.

Wizard-of-Oz Techniques

We are proud to say, none.