Statistics + Computers: A Personal Reflection

Statistics + Computers: A Personal Reflection

I’ve recently taken up a new hobby while in Grinnell over the summer: Dungeons and Dragons. When I was approached at the start of the summer to play in a game of D&D, I was naturally a little hesitant – like most people, my knowledge of D&D was limited to what it is normally portrayed as in films/TV. As I got more familiar with the game, though, I realized that there was a much more quantitative side of the game than just wandering around trying to slay beasts.

D&D is, for the most part, fairly simple: you and a group of friends play through a pre-made “adventure” (or the “dungeon”, in some cases, usually designed by a “dungeon master”) in which you solve puzzles, complete tasks, fight monsters/etc., all to reach a certain goal in the end (some form of “winning” or completion). The big question, and what piqued my interested the most, was how success and failure on these quests were determined.

The answer, like in most games, lies in the roll of the dice: for every decision (well, nearly every decision) that is made in the game, dice are rolled to determine success/failure. For example: when attacking, you roll a twenty-sided die and compare that to your target’s armor. If the die roll is higher, you hit, otherwise you miss. It just so happened that an enemy we were fighting tried to attack me and on that twenty-sided die, the enemy rolled a one. Our dungeon master (DM) ruled that, because the enemy got such an awful roll, not only did he miss me, but he hit one of his allies! Of course this doesn’t always happen, but the general idea is there.

Because of the use of dice, statistics play a strong role in D&D. In fact, a basic understanding of statistical principles can make the difference between being properly equipped and being unprepared and out-armed. An example would be weapon selection – one weapon roles a twelve-sided die on an attack, while another rolls two six-sided dice. Do you want higher probability of maximum damage? Do you want higher average damage? Do you want more consistent damage? Depending on the player’s answer to these questions, knowing statistics can make a huge difference in choosing the right or wrong weapon.

What does this have to do with our project, though? Well, during one of our games, we were faced against a gigantic dragon (dragons in D&D are apparently sentient and intelligent, like humans). Having become somewhat familiar with D&D, I knew that the dragon’s hit points were dependent on the rolls of some dice. Instead of just calculating the average hit points it would have, I wanted to know more, so I created a program that simulated the dice rolls and calculated mean and standard deviation. Keeping a tally of how much damage we dealt to it, throughout our encounter I knew how close to being done we were. When the dragon was finally defeated, it didn’t come as a surprise.

My solution to the problem (finding the dragon’s hit points through simulations) might seem straight-forward considering my computer-science background, but in actuality it was in part due to a paper I read by George Cobb: “The Introductory Statistics Course: A Ptolemaic Curriculum?” The article can be found here.

The article is somewhat long, so I’ll try to give a brief summary – Cobb’s basic argument in this article is that introductory statistics courses need to stop focusing on the normal curve so much, and start switching over to an emphasis on inference. Part of the reason, he says, that statistics courses focus so much on the normal curve is that before computers, calculating statistics by hand was somewhat difficult and tedious. With computers, though, these calculations are done in the blink of an eye. One thing he wanted to see replace the normal curve is the use of repeated randomized simulations – have students conduct simulations and see if their results are consistent with hypotheses. This would serve as a replacement to the t-test, which, he argues, isn’t nearly as intuitive as just comparing results from experiments (or simulations).

While the method I used for determining the dragon’s hit points was sound, it proved unnecessary, as our DM used average die rolls instead of actually rolling the dice themselves. Beside that, though, the idea I used was practical and efficient – not only was I able to simulate how much health the dragon had, but I could modify my program to calculate how much damage my sword dealt, or how likely I was to perceive someone sneaking up on me. The possibilities behind these simulations are endless, and the practicality of not having to do the calculations myself is priceless.

Tangrams: Correctness Checking

We decided several months ago to implement Tangrams as one of our StatsGames. As the primary dependent variable in most experiments involving Tangrams is the time the subject took to complete the puzzle, Tangrams lends itself well to computerization, as time is easy for a computer to measure objectively. A completely computerized implementation would also greatly reduce the risk of observer-expectancy effect (the risk of an experimenter unknowingly biasing subjects), as the experimenter would have little interaction with the subjects.

However, in implementing this puzzle, we have discovered that, while implementing a timer is relatively easy, it is more difficult to verify that a puzzle is correct, especially when working within the limits of Flash’s ActionScript programming language. After extensively searching the Internet, Andy and I found several well-implemented Tangrams puzzles written in Flash, but none of these puzzles share their strategy for verifying correctness. In this post, I will explain some of the methods we have tried and their shortcomings.

Our initial idea was to use a method that Flash calls “hit testing”. If you read the documentation for Flash’s DisplayObject class, it has a method called hitTestObject, which purports to tell you if two objects are overlapping. Unfortunately, this method has a crippling deficiency: it only tests if the rectangular bounding boxes are overlapping. For rectangular objects, this works well, but when either of the two objects are not rectangular, you quickly run into problems. For example, see these two triangles? According to their bounding boxes, they’re almost completely overlapping. Since many, if not most, tangram puzzles contain such arrangements, this is clearly not a workable solution.

The next idea we had was much more promising, and indeed works well. We can test every point on the screen to see how many, and which, objects are underneath it. Since we can determine the difference between the movable piece objects and the stationary object that represents the puzzle template beneath it, we can quickly determine if an individual point is “correct”: If there is a template object over the point, ensure that there is exactly one piece object at that point. If not, make sure the point has no objects over it. If a high enough percentage of the points are in the “correct” state, the user wins!

The problem with this method is speed. Checking every point in a roughly 600×400 grid takes several seconds, even on the fast computers we use for development. So we made several adjustments to the algorithm. First, we only test every tenth pixel in both directions, which decreases the workload by a factor of 100, making it much more manageable. Next, we programmed the pieces to snap together if they are close enough, which greatly reduces the number of errors that a user can make.

However, we still don’t think this method is good enough. On slower computers, it lags enough to make the game slightly annoying to play. Since one of our goals is to make games that will be fun to play, even outside of a classroom setting, we are working on a better method. Nevertheless, if you’re ever writing a Flash version of Tangrams and wondering, “How do I check correctness?”, here’s an answer.

Some Game Paper Reviews

These are just a couple reviews of papers I did at the beginning of the summer which were saved on google docs.

Citation: Jenkins, Henry. (2005).  Getting Into the Game.  Educational Leadership. pp. 48-51.

Summary:
This article focuses on the question, why is homework bad when it is hard but games are bad when they are easy?  Jenkins claims that kids will stay up until dawn to try to beat a challenging level but will give up on a difficult homework problem after only a short time.  This phenomenon can be ascribed to intrinsic motivation.  Intrinsic or self motivation refers to activities a person chooses to do which is not for external reward.  Jenkins sites a few reasons kids are intrinsically motivated to play games.  Games offer no fear of failure, if the player messes up and loses a game it is very easy to reboot and try again, with most games this just requires one click of the mouse.  Secondly, games offer an immersive environment which allows kids to feel a personal connection to the concepts they are learning, where as textbooks present information in a remote and abstract way.  Another encouraging trait of games is that well designed games offer a sequence of challenges and rewards.  The early challenges should be easy so the play gains some confidence that they can succeed and so will feel more inclined to take on the more difficult challenges.  Games make information seem important by requiring the player to use what they have learned to accomplish goals.  Games are multimodal, so people can play at their own pace and their own way.  Lastly games support early steps into new areas of knowledge by providing early success.  The piqued interest inspires students to explore further in a given body of knowledge.  Jenkins concludes by saying that games are not a replacement for good teaching but good teachers can learn to incorporate games into their teaching methods.

Quotes:
“Games motivate learning by setting clear goals or allowing players to set their own goals” (Jenkins 50).

Citation: Schaller, David.  (2005).  What Makes a Learning Game?  Web Designs for Interactive Learning. pp. 2-6

Summary:
This article analyzes two games according to a set of criteria for a learning game.  The four key characteristics present in a learning game as taken from Malone and Lepper (1987)  are challenge, curiosity, control and fantasy.  Challenge is created by providing goals which promote  a feeling of competence in the player.  Curiosity can be in the form of sensory curiosity which is enhanced by visual and auditory stimulation, or cognitive curiosity which can come from interesting game play and story line.  Control is giving the user feelings of self-determination and choices.   People are more inclined to play games which give them a feeling that they are in control of their world.  Fantasy appeals to the emotional needs of learners, but should also have an integral relationship to the material being taught.  The fantasy world of the game must require the user to understand the material in order to succeed or else the player will not be motivated to learn.  After analyzing two games this paper proposes two additional criteria which are essential to an effective learning game.  Iteration and reflection ingrain concepts and really solidify learning.  Iteration in game design means that the game is intriguing for the user to play multiple times.  Reflection won’t necessarily take place while playing the game, but ideally it should take place during the iterations.  The player should be required to rehash old learning and apply it in a new way in order to achieve concrete learning. The article sums up by saying that the potential of learning throgh games is only being scratched but developers need to pay careful attention to design to unlock the potential for education.

Quotes:
“Without evaluating the learning outcomes, game designers cannot know whether players are learning the intended or inadvertent content” (Schaller 5).

Flash-y or Flex-ible or …

One of the “interesting” questions for the StatsGames team explored at the beginning of the semester was what language to use for building the games.  Our goal now, as in the previous incarnation of the project, is that the games can be easily posted on the Web.  When we built the games three years ago, we followed the lead of the preliminary designers (Henry Walker and Dave Ventresca) and wrote Java applets.  This year’s team wanted to revisit that decision, and to consider whether Flash (well, ActionScript) would be more appropriate.

The team eventually decided that ActionScript was more appropriate.  And there were some clear wins for Flash.  From my perspective, the biggest win was that the development cycle seems a lot faster.  That is, the students are getting working examples up and running much quicker.  (As an example, the rewrite of Perfection took about a week; the original game took maybe half a semester.  Of course, more advanced students are working on it this time, but I still think it’s a good gain.)  A second gain is that we are likely to have wider distribution.  With the Java applets, we found that different versions of Java were installed on different machines, which caused some problems.  More recently, any sensible Mac owners had Java turned off in their browsers, because Apple was about four months behind in getting a security hole in Java patched.  A third gain is that it’s a lot easier to build standalone copies of the games, which can then be used for demos and such.

So, all seems hunky-dory.  Except …

Flash is proprietary.  When the students said that the were going to use Flash, I focused primarily on their use of Actionscript, since the key work should be happening on the programming side.  Since the Flex compiler for ActionScript is available for free (and, I believe, is open-sourced), I wasn’t too worried about the use of ActionScript.  However, the way the students are designing the projects ties them very closely to Flash, which worries me, particularly because I am firmly committed to making the StatsGames open source.  I would much prefer to see them use Flex and stay away from Flash.  Their use of Flash also makes it harder for the supervising faculty to look at their work.

Too much existing ActionScript code is poorly designed.  A lot of the code I see out there is clealry written by people who don’t program for a living or who do program for a living, but wanted to hack something out quickly.  My experience with large projects is that the projects are much more successful if people code carefully and generally, and if they follow some coding standards (including code formatting standards).  There seems to be much less care in the ActionScript community than I see in other language communities (hey, even Perl has coding standards, even if people don’t always follow them), and that concerns me for the long-term maintainability and extensibility of these projects.

Flash does not interact well with source-code control systems, particularly CVS.  Since we expect this project to persevere over time, it makes sense to take advantage of software designed to manage software projects.  But, as far as I can tell, Flash doesn’t nicely support the kinds of components that we normally rely on (e.g., text files for source code, separate files for separate images, etc.).  Flex Builder does a bit better, as we can put just the src directory in the repository.  Flex is fine, since one gets to lay out the project as she wishes.  Still, this makes things more painful.

Do I think we made a mistake switching to ActionScript?  No.  Do I think we made a mistake starting with Flash?  Yes.  Next year, I think I will require students to work with Flex, rather than Flash, as their development environment.  (It’s not clear to me that they get that much benefit from the special features of Flash; often, it seems like their use is simply treating the timeline as their hammer.)

Next Game: Tangrams

Now that Glimperfection has been re-implemented (link here), Alex and I have begun to work on our next game: Tangrams. If you’ve never played Tangrams before, let me tell you – you’re missing out.

Tangrams is a very old puzzle game where the object is to place a set of pieces around each other such that they match a given shape. Since there are many different arrangements for the pieces, there are many different shapes that the player can try to make. The strategy in the game lies in your ability to visualize how the pieces fit together, and with a multitude of possible shapes, Tangrams can be a fun activity for anyone who’s up for a challenge. (for more information, check out the Wikipedia article)

While Tangrams is fun to play, by itself it has very little to do with statistics. Despite this, we’ve decided that it would be a good game to implement –our implementation of Tangrams, like Glimperfection, will record results into a database. Unlike Glimperfection, though, Tangrams has more flexibility for players through the ability to have many distinct puzzles.

Our primary goal for Tangrams is that we make a game that is fun for the player and can be used by students to help conduct experiments. The ability to conduct experiments is essential for students who are trying to learn statistics – by providing students with the ability to record their own data with our game, we will help them to design and implement experiments that will help them understand some of the core concepts of statistics. This fits in with the GAISE Guidelines (link) for helping to teach statistics in that we provide students with the ability to gather their own relevant data and also show how technology can be helpful with statistics.

To help provide variability, our game will have multiple options and provide different fields for other external variables. One of the more interesting features our game will have will be difficulty – we plan on having multiple piece sets (such as 5 pieces for easy, 7 for normal, and 9 for hard) and we might vary how close the player’s design has to be to the one we’ve specified. Additionally, we will present similar time options to those we had in Glimperfection. One more interesting feature we may add is the ability of the game to randomly make challenging shapes – though we’re still working the kinks out in this design.

Overall, Tangrams looks to be a fun game. We’ve started implementing already, and run into some preliminary design problems. Once we have a solid foundation, though, we shouldn’t run into much difficulty. That is, until we have to play the game ourselves!

GlimPond: A new way of looking at Fish Pond

So, we had to take another look at the Fish Pond, because while our plan seemed to effectively teach capture-recapture, it just wasn’t going to be much fun.  Part of the motivation of the StatsGames projects is that we have games that motivates a person that may not necessarily be interested in the underlying topic, to motivate them to learn the topic, by making the game fun.  Yesterday, we came to the conclusion that once the more basic version of the game is done, we make a version that takes the inspiration from the rather successful series of Sim games.  After the idea was given and liked, I thought about how to do this.

The basic ideas behind how I see it is as follows:  The player starts with a completely empty pond, and some cash to adjust situations.  From the empty pond, the player buys fish to add in, has to set a maintenance cost to keep adding in food, and has tools to do the capture-recapture setup.  As the scenario continues, the players can add more and different fish into the pond.  In this model, the players will know the initial number of fish in the pond (since they can control that), but they have limited information(very high, high, medium, low, very low, each representing a range of numbers) on breed rates, death rates, food consumption rates, and how much space that they each need to reasonably survive, creating the incentive to make use of capture-recapture.  The players can also give fishermen permits, and the players get paid by fishermen catching fish.  Each fish has a cost, being more expensive for having really advantageous properties that will let it survive, and being more valuable the more rare they are effectively.  The final variable that can be changed is that the player will be given the option to make the pond bigger/make a second small pond.  As what makes sense, the pond being bigger allows a higher maximum population size (adjusted for not every fish being the same size), while a second small pond may be useful for players trying to analyze new fish that they intend to add in.  The final option is that players will be able to research other fish (that play differently in the environment than the fish that they start with) which may pull from a preset list, or may have an outside game option to allow people to make more fish to go into a database.

One important key of this game is to give some indication of whether the players are actually learning anything.  At first glance, this seemed like an impossible task, due to the sandbox nature of the Sim series of games, but then it seemed possible.  First off, to check if the player has essentially failed, if you run yourself too low on money, you can’t keep up getting food to the fish, and the fish start dying off, and the system collapses really quickly since no fish = no caught fish = no cash flow = no food.  This may be hard to tell if the player decides to “nuke” the pond and start over with what he has left (which should be a legitimate strategy if the player can tell that things have gotten so far out of control) in comparison to the player has lost control and cannot effectively reset the population. “Winning” is a very hard thing to tell in a sandbox game, because the beauty of them is that you get to set your own kind of goals.  However, we think that there would be a benefit to having a universal scoring system, so here’s what I propose.  As part of the GlimPond interface, the players have the option to at any time call it quits once they think they have the population stable.  When they do so, the simulation runs for another number of iterations, without the player having the option to change any of the variables.  Once this is done, then scoring is based on the idea that the below principles are the most important:

* How many different types of fish are in the largest pond?

* How many total fish are in all of the ponds?

* How much money do you have in hand once the final simulation ends?

* How many cycles did it take before you hit the button?

There may be others that should have effect, but that’s what I see at this point.  Please note that this conception was put together pretty much by myself as a thought experiment, and as such, some of these things may not exist in the final version possibly because [levinnat], [Shonda], or [rebelsky] have some different ideas, or some of these ideas may actually prove to be impractial.

Learning from the Fishes

[levinnat] here.  As [thompson9]  did a good job of describing our current progress on the project in his last post, I’d like to speculate on the effectiveness of the game as a teaching tool.  Statistical concepts such as normal-distribution and standard deviation are currently operating in the background of the game but they aren’ t necessarily visible to the user.  The original goal of the game was to sell fishing permits and buy food, and try to be a successful fish farmer.  Yesterday SamR proposed that the game be more about manipulating variables and maintaining a stable ecosystem.  Played the first way the learning aspect of the game strictly takes place when the user does a capture-recapture to estimate the population of fish in the pond.  Understanding capture-recapture is cool but it seems like a rather small/simple concept to be the entire focus of a game.  I think the goal of the game should be to maintain a stable ecosystem.  I still want to have fishermen and buying food as part of the game, but I think manipulating variables in a system is a great way to learn about those variables.  So, gameplay will consist of deciding how much food to add per day, how many fishermen to allow on the lake, and manipulating variables to build a balanced ecosystem.

The question then becomes why will people want to play this game.  The StatsGames research project is based on the idea that people will learn if they are having fun and externally motivated to learn the concepts.  The game needs to have elements which motivate the player, learning the concepts needs to be essential to correlate to success in the game, and it needs to be fun.  Money is a great motivator.  Of course we can’t offer real cold hard cash, but we can offer in game success and fulfillment.  I think adding a cost for food and for doing capture-recapture, and then paying the player cash after each simulation round based on how well they maintained the ecosystem will provide motivation.  The other motivation could be that if the player can maintain a stable ecosystem at the easiest level for a set number of rounds they unlock the next harder difficulty level, which would add more variables like predator fish, and fishermen.  So the easiest level would just be managing small fish and food.

Game Play:

Round 1: capture-recapture to obtain a population estimate , buy food, buy capture tags, set variables, set food amount per day, set # of fishermen,

Round 2: run simulation while providing visuals for the user, reward the user for how well they managed the pond this round and advance in time

repeat round 1 and round 2   until the user wins by reaching the goal # of rounds, or the user loses by destroying the ponds ecosystem

Creating the Fish pond

The Fish Pond is a Flash applet that I am working with another Grinnell Student (levinnat) to create to show Capture-Recapture.  The idea behind the program is that the players are given a fish farm to manage, where at its most complex has food, a prey fish, a predator fish, and fishermen to interact with each other.  By design, the players will be allowed at a given time increment, to pull a sample, and tag said sample.  The idea behind the Capture-Recapture method is that one grabs a sample, and tags all of the fish involved in the sample.  After a period of time, where the creatures will have the opportunity to spread out within the environment, one pulls another sample, and based on the number of tagged creatures, one can get a rough estimate of the overall population.  A reasonably simple, but more thorough explanation of Capture-Recapture can be found <a href=”http://en.wikipedia.org/wiki/Mark_and_recapture”> here</a>.  What makes this interesting is that the player initially has no idea how things interact, nor what’s in the pond, and has to try to make a stable population by changing the amount of food, and the number of fishermen (so the player can actually buy food).  Through multiple passthroughs, the player gets a better and better idea how things interact, and how many fish are in the pond, and can make better decisions.  Like all of the games that will be made this summer, this will have a path to a database that stores how well the students do at the task of making a stable population.  As we are still trying to implement the game itself, we haven’t thought hard about what information would be useful in a database created by this program.

In this applet, we are also looking at allowing the player to interact with the rates that affect the change of fish within the pond, both allowing for extremely many different environments to run the simulation, and to allow the player to see how the variables interact with each other, and what kind of effects that the changes would have.  Also, given these variables, students may be able to reasonably simulate real species in a simple environment, which with a bit of a stretch of the imagination, could extend past kinds of fish.  This, I hope, will allow this applet to be used outside of Statistics classes.

One of the major problems we have run into at this point is finding a reasonable way to represent the model.  Our first two attempts at this, using a model that turned a probability based system into a static system by creating a change in fish had the problem of doing nothing if the populations got too small.  The second model, the one that is in effect right now, seems to have a problem where even fully sustainable populations will take wild swings either into complete death or massive overcrowding.  The idea behind this model is that we have the probabilities of certain events happening, like a fish breeding.  We then check this probability against every fish, and if it is successful, we add a fish to the pond.  We do this for every variable that could change the number of fish within the pond.  Each time this is called, it’s considered a time period, whether a day or year.  Hopefully, we can find a better model that’s unpredictable, but at the same time, will not fail for sustainable populations and succeed for otherwise unsustainable populations.

Rewriting Glimperfection

Rewriting Glimperfection:  Implementing Piece Shuffling

One of my initial tasks for this project has been to re-write the old Glimperfection game.  Unless you’re an avid Perfection fan, I doubt you’ve heard of the Glimperfection version, so I’ll take a brief minute to explain it (you can find the game itself here:  http://www.cs.grinnell.edu/~lortonel/Glimmer/Perfection/perfection.cgi

Glimperfection is a modification of the game Perfection.  In it, you try to match geometric objects to squares with those objects punched out.  Glimperfection has a few different takes on this original design – users can choose different times to compete against (or no time at all), different number of starting shapes, color settings, piece settings, and some other user-controlled variables.  All of the instances of the game are recorded into a database which anyone can access.  My task for the past couple of weeks has been to completely re-implement Glimperfection in Flash (the old one was in Java), making sure that all of the old features are included.

The new version has been, for the most part, implemented.  Unfortunately, as I’ve gone along coding, I’ve used some confusing algorithms and at first glance my code is a little (and that may be an understatement) hard to understand.  In fact, when going through the code with my partner Alex and Professor Rebelsky, both of them had trouble understanding my implementation of a solution to a seemingly simple problem with Glimperfection:  How do you display the pieces?  My solution, albeit somewhat backwards, did solve this problem, though explaining it was extremely difficult, and I’ve since re-worked how I was going about my answer.  Considering this difficulty, though, I think it’s important that I outline this problem and describe the solution.

For various reasons, I decided that I would hardcode the shapes into Flash.  This way, I was able to label each one of them, which in turn allowed me to move and change them with code.  In doing this, I ended up creating 48 different objects that I would need to display during the course of a game.  This seemed simple, though – all I need to do is make an array of all the holes (the punched out shapes), an array of the pieces, and then iterate through each one setting each object’s visibility field to true.  Testing this out, I had a rudimentary version of Glimperfection up within days.

The next task was shuffling, but this was easy:  just shuffle the arrays.  Using a modified Fischer-Yates algorithm (as suggested by Alex), this was O(n), and the end product was an auto-shuffling set of pieces.

As I worked more I realized this solution didn’t work, though – how do I handle the case where some pieces/holes aren’t displayed?  If I randomly select shapes out of the array and turn them off, there will be holes in odd spots on the game board.  So, from here I realized that my initial, simple solution didn’t work:  in addition to recording the holes and the pieces, I needed to record the x and y coordinates of the locations I wanted to fill and their correct order.

My first remedy for this problem was to create two cumbersome nested arrays – each location in the array contained another array with 3 elements:  the hole/piece stored there, the x coordinate, and the y coordinate (after talking with Professor Rebelsky and Alex, I re-did this obscure design).  Now, I can easily shuffle the pieces (shuffle the 0 indices and then change each object’s x/y coordinates to those in the array).  But how do I select the n pieces out of the array that I want?  If I just take from [0->n], there’s no guarantee I’ll have the right pieces and the right holes.

That’s where I realized that I needed to change the order I did this:  first, select the shapes, and then shuffle.  Selection, I decided, could be done as simply as shuffling:  shuffle the pieces and the holes to the same indices of the main array such that holes[i][0] corresponds to pieces[i][0].  Then, from there, shuffle within the array but use n as the value that I want to stop shuffling at (instead of array.length).  Then I can simply traverse up to n in the array, display those images, and I’ll have an adequately shuffled set of Glimperfection pieces!

Simon, the first StatsGame

Simon (based on the old game of “Simon Says”) is a simple game in which players attempt to repeat longer and longer sequences of actions.  In many versions, the game is played with a circular device with four colored buttons.  The computer (aka “Simon”) shows a sequence and then the player repeats the sequence.  The computer then increases the length of the sequence, and the player repeats the extended sequene.  Game play continues until the player can no longer duplicate the computer’s sequence.

How can this game be used in a statistics class?  In our version of Simon, which the students have called Glimon (Rebelsky’s research lab is “Glimmer Labs”), many aspects of the game are configurable.  One can vary the number of buttons (4 or 8), the coloring of buttons (all buttons the same color or each button a different color), multimodal textual information (text on buttons or no text on buttons), multimodal sound information (buttons accompanied by sound or not), sequence formation (gradual development or new each time), as well as external variables such as major, gender, or number of cups of coffee drunk before playing the game.

In the typical use of Glimon, statistics students make hypotheses about the effects of different settings and then gather data from subjects.  Because all games of Glimon record their data to a common database, when students analyze the data, they have access to not just their own data, but also that from other student experimenters at their school and elsewhere.

Through these deceptively simple experiments, students learn a number of important concepts, including variability (different subjects often have very different maximum sequence lengths, even with the same settings; even the same participant is likely to have different maximum sequence lengths for the same settings), multivariate explanations (while a student may hypothesize that text will make more difference than any other difference, it is often a combination of factors that have the greatest effect on maximum sequence length), and meta-analysis (they quickly learn the benefits of comparing the results of multiple studies).

You can even play Glimon yourself.  (Warning! This link is scheduled to change soon.)