Interactive Prototype-Group:BuTtErFlY

From CS 160 Fall 2008

Team

Name	Contribution
Gary Wu	Worked on world map, battle windows, presentation slides
Mike Kendall	Worked on code to get meditate working. Overview, tasks and revised interface design.
Mohammed Ali	Worked on meditate functions.
Hao Luo	Wrote Prototype Overview.
Jordan Berk	Dungeon design, general non-scripting gameplay design (characters, enemies/battles, skills, puzzles, game dialogue), screen shots

Interactive Prototype Links

Problem and Solution Overview

Young students often lack the motivation for learning math. The main problem with math is that it isn't really regarded as fun by most kids (in retrospect, were any subjects "fun" in elementary school?).

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.

Tasks

Easy

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 joystick) 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.

Medium

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 player will have to interpret the puzzle as it is presented (which should be obvious), do some mathematical analysis on it and then somehow give the answer back to the game. In our prototype, our puzzle is very simple, but the method for inputing 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 if they wanted to play this on a gamepad or other input device, this method will still work.

Hard

Our combat system throws a twist at the player 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.

Revised Interface Design

A number of the changes that were made from the lo-fi prototype to the interactive prototype were so that we could use an already existing RPG creation tool. This would allow us to concentrate on making a game that would weave mathematics into the RPG experience rather than being bothered with the huge task of finding art and integrating it into the game. The first such change was from a “click to move there” interface to a more traditional “use arrows to move in that direction” scheme. In addition to allowing us to use RPG Maker XP, this method of movement input is the more traditional one, lending to more recognition by players. Screenshots are below.

A number of things are still unimplemented. First, a real elements-based magic system doesn't exist yet, but that is also a consequence of not having a huge dungeon in which to run around. When there are more than three enemies, then you can have elements that you will use on those enemies. Next, the meditate skill currently pulls from a small number of hard coded problems. We eventually want these problems to be randomly generated so that the player can practice as much as he needs to without getting the problems right out of memory/recognition and without getting bored of seeing the same 10 problems. The meditate skill also needs to be modified so that when you get the question right, you are given another question until you get one wrong. The problem with this was that RPG Maker XP's battle system is strictly split up into phases. First, actions are given, then actions happen in an order dependent on the character's speeds.

The way that Mohammed got the meditate function working was through changing the defend function to a copy of the skills menu, then changing the skill names to be answers to a math question. The wrong answers are dummy skills that don't do anything and the correct answer restores 100 SP. Another problem with this formulation is that the intelligent user will realize that he can hit cancel and go back to the first menu if he doesn't like the math question he is faced with. When he hits the meditate function again, the question is randomly chosen.

The last difference from our low-fidelity prototype is that there is almost no information given to the player about the monster's status. Originally we wanted there to be some kind of feedback that the enemy was dying... Something really obvious like a life bar (a la pokemon) but that priority fell by the wayside. The life bar in pokemon mostly exists to facilitate catching of monsters, rather than giving feedback. We have been very satisfied with the large damage numbers that pop up with each attack thus far.

Prototype Overview

Our prototype can be roughly split up into three sections. There is the world map, dungeon map, and battle screen. The player traverses the world map to enter different dungeons, and within each dungeon are monsters to fight and puzzles to solve. There is also a boss in each dungeon that will unlock the next dungeon on the world map.

World Map:

The world map follows a linear path, from the first dungeon to the last. The player starts with the addition dungeon. Once the boss in the addition dungeon is defeated, the subtraction dungeon will appear on the world map and the player can then explore this new dungeon. The same pattern is followed for subsequent dungeons. The world map is very straightforward because it is simply a navigation tool and not the meat of the game. We don't want the player to get confused before even playing the game. The player can also visit dungeons they have already beaten as once you unlock a dungeon on the world map it will permanently stay on the world map. The harder dungeons that you unlock later are farther along on the world map, which hints to players which dungeons are easier and which dungeons are more difficult.

Dungeon Map:

The dungeon map is more complicated than the world map because it is an open space with monsters, puzzles, and sometimes a boss. The paths are not as clear-cut as the world map because we encourage the player to explore all the open space in the dungeon, to battle more and practice more math problems. Once the player encounters a monster in the dungeon he will engage in battle and the game shifts to the battle screen. Once the monster is defeated, it will disappear from the dungeon map. Sometimes we will have a monster block the path (see subtraction dungeon screenshot) as to force the player to at least engage in some battle and practice math problems. Beating the monster removes it from the dungeon map and allows the player to move on. We also added puzzles blocking the player's path in a similar fashion to mix it up and teach math in a more creative manner. In the puzzle screenshot we can see that the puzzle is about the Fibonacci Sequence. Generally the puzzles are not the standard "addition, subtraction, etc." problems that the player usually encounters.

In the subtraction dungeon in our prototype, there is gray ground that the player can walk on and red lava which the player cannot. Therefore our design hints to the player as to where the paths in the dungeons are and where you can and cannot walk to.

There is a boss at the end of each dungeon that is much more powerful than normal monsters. The player must defeat this boss to go on to the next dungeon. The game is designed so that the player must have already participated in battles and gotten stronger in order to beat the boss. In this way, the boss ensures that the player has sufficiently practiced enough math to move on to the next topic (dungeon). In our screenshot the boss in the subtraction dungeon is a large troll, and he is much stronger than the gargoyle encountered earlier. Once the player has beaten the boss, he also gains access to a new skill. Generally the skills the player learns are more powerful but also take more SP.

Battle Screen:

When engaging monsters in battle, the player can attack or use a skill (magic). Attacks do little damage, and we do not encourage the player to use attacks unless they want a break from doing math problems or are about to finish a monster off (if a health bar is implemented). Skills are much more powerful but cost SP (spell points). In order to keep using skills the player needs to replenish SP by using meditate. Meditate is an option that lets the player recover SP after solving a math problem. In our screenshot against the boss troll you can see that using the skill "addition attack" costs 100 SP and after our character runs out of SP, he must use meditate to get more SP. In our screenshot the player must solve the problem "21 - 7 = ?" to get more SP, and our questions are multiple choice, so the player selects from four possible answers. We have scripted a number of problems into the game and one is randomly chosen for the player. Of course, the type of the problem is dependent on the dungeon the player is currently in. Thus, our screenshot taking place in the subtraction dungeon, has a subtraction question in it. Ideally we would like to be able to randomly generate questions but at this point it has not been determined whether or not that will be implemented.

Beyond these three main screens, there are also other situations that don't come up as often. For example, we have items in our game and there is a screenshot at the end. The items included in the game generally restores HP. We'd like our players to use meditate and answer math questions to restore SP and having items that restore SP defeats that purpose. Another screen is the puzzle screen. This will vary from puzzle to puzzle. In our prototype, the puzzle is crossing the bridge so we simply zoom in on the bridge.

One key feature we left out of our prototype is the ability to meditate more than once per turn. In fact, we designed meditate such that it does not take a turn unless you answered the question wrong. Therefore, the player should theoretically be able to answer as many math questions as he wants in order to restore SP until he answers a question wrong. This was hard to implement because RPG maker's script is based on having both the player and the enemy choose one command and then resolving it, and does not handle looping.

The scripts for RPG Maker is done in Ruby. Although the program itself provides a very comprehensive toolset for implementing our prototype we nevertheless wrote/modified some scripts in Ruby in order to implement our design better. For example, we wrote some scripts that enabled the feature meditate. Other scripts included math problems for meditate. Outside of that there was a lot of drawing up the dungeons, creating monsters, setting up stats for our characters and various monsters in the dungeon, and some tinkering/adjusting along the way.