Terminally Trivial

A game about the opportunity costs of using credit cards

Project Role: Designer

Project Responsibilities:

• Took a pitched idea from a course developer and turned it into a fully-fledged game design
• Wrote text and designed interactive elements for a tutorial
• Created and organized flow of game events
• Created AI algorithms to control the actions of computer players
• Balanced certain game values to ensure the proper difficulty and outcomes
• Designed the interface layout
• Worked with artists to have them create new assets, reuse old ones, and create layout mockups
• Worked with subject matter expert to ensure educational value

Design Documents and Other Assets:

• Design document (.doc)
• Flash prototype (developed by me)
• Final Flash game (developed by a co-worker)

Detailed Description and Analysis:
This game was created for a Personal Finance course.  The goal was to teach kids about opportunity cost.  They need to understand that, due to interest, buying something now on credit means that the opportunity to buy something later will be lost.  This game also has a strong emphasis on credit cards and how that spending money on interest reduces one's purchasing power.

The basic gameplay involves buying items during short shopping sprees with either cash or credit.  After a round of shopping, the student looks at some statistics, makes a credit card payment if necessary, and receives an allowance.  The goal is to make more purchases than the opponents without becoming insolvent.

I was given quite a few design constraints to work around.  In particular, I had to:

• Use given dollar amounts and purchases for items
• Ensure values were realistic (i.e. credit card interest couldn't be just anything)
• Could not explain what was in the packages or what the point values of the packages meant
• Display a lot of information to the student both during and between rounds

I really pushed for purchasable items other than packages.  I understood that the goal was to have students buying items not because of what they were but because of their cost and point value, but I felt there were ways around this.  An early idea for the game involved buying diamonds of different colors.  Given that diamonds of different colors have different values, I thought this would have worked pretty well.  Another idea was to have the students buying different amounts or forms of precious metals like silver and gold.  Yet another suggestion was to have the contents of the package revealed after purchasing the item.  All of these ideas were rejected by the course's developer, so I obliged.

For instructional purposes, it was required to present a lot of information between rounds to the student.  I condensed this information down to as few screens and displays as possible.  The most important points that needed to be made were how much money the student is losing due to interest, how the student's spending habits will alter the final point total, and information about the student's credit card balance.  These screens are centered around getting these points across and use graphs where applicable to quickly drive the point home.

The course developer's original idea also required a lot to be displayed on the screen.  The original pitch involved showing the shelves for all three players in addition to all of their stats.  The final game had to be fitted for a 600 pixel by 450 pixel window.  Trust me, that's not a lot of space.

The good news is that the idea of lots of objects on the shopping screen actually fit one of the requirements of the game's design.  In July 2009, I gave a talk at BarCamp Chattanooga about the MDA Game Design Framework that I had recently learned about at GDC 2009.  I used this game as an example as a practical application of it.  During meetings, the course developer told me that the game needed to force students to act without considering the ramifications of spending.  The idea was to trick the student into experimenting with bad decisions.  By the end of the first playthrough, the student should be able to understand the issues with the bad financial decisions they made.  In order to do this, the student needs to feel pressured to make purchases.  This was accomplished by using information overload.  The hope is that the student will see the timer counting down, see their opponents spending quickly, and be unable to process the on-screen information quickly enough to make a smart decision.  I am a little worried that the line between overwhelming and confusing may have been crossed.  I'm still waiting to hear some feedback from the students who have played the game to see if it went too far in this regard.

I was fairly pleased with the way the balancing and the computer AI turned out.  One computer player spends the whole game in debt while the other barely purchases anything.  A student who doesn't spend at all will finish in second place.  A student who actively spends but does so responsibly will win.  Irresponsible spending will lead to, at best, a second-place finish.  I think the game might be a little too easy for the solvent student, but it is better to err on the side of easier rather than harder.  This is especially true since the course is intended for younger high school students.

I'm pleased about being able to tie the game's concepts and values into the fiction of the game and the course.  I was able to structure the game so that receiving money at the beginning of the turn is an allowance, the interest rates are fairly realistic, and frequent shoppers are invited to special sales that take place over the course of  year.  I also managed to get Budget, a dog who is one of the course's main characters, in the game in a starring role as the checkout lady, something that also promoted asset reuse.

The lack of sound (other than optional background music) is a bit disappointing to me, but that was simply a case of having too little time.  The same can be said of my approach to documenting the interface.  I ended up just having meetings with the artist doing the mockups and gave him hand-drawn documents as well as verbal instructions.

One negative aspect of the game that was my fault was the amount of time reading versus the amount of time doing.  This is especially true of the instructions and tutorial.  There is an awful lot of reading to do before getting started.  The reason games are so effective at teaching is that the kids get to do things rather than being engaged passively.  In projects since this one, I've definitely kept that in mind and used shorter, more interactive tutorials and very brief, context-sensitive help.

Since the basic project requirements were met and I learned and used some new design techniques, I consider this project to be a success.

Click here to return to the overview of my games.