Lloyd's Physics Simulation, Prototype 2: Thread the Needle Game

Zipped Standalone Download: Macintosh | Windows
Download files updated September 13, 2016
HTML5 Version

Over the past week or so, I returned to work on my little physics simulation that I built and wrote about a couple of months ago. This little prototype has constantly been on my mind and I've been playing it rather frequently since I wrote my original post about the prototype on July 4, 2016.

Recall in that post I wondered about a game element that could be added to it: "...I can imagine having targets placed within the area of the line graphs that you have to try to hit with one of the graph lines." Yes, the more I played the simulation, the more I liked this idea. So, I've spent about 6 hours working on the next prototype that includes this gaming feature. I call the game "thread the needle" because that is exactly what it reminds me of - the blue distance graph seems like a piece of thread that I'm trying to maneuver to pierce (thread) the target (eye of the needle). Here's a screen shot of the game:

A Quick Demonstration

Probably the best way to understand how the game works is with a short video demonstration:

Ok, let's explore the game a little further.

Goal and Rules of the Game

The goal of the game is, of course, to learn about the relationship between distance, velocity, and acceleration. But, we should probably keep that a secret because this fact might ruin the game for any elementary, middle, or high school student who plays it. But, as one adds game elements to a simulation that already appropriately models the physics, you have to be careful that the attractiveness of the game doesn't inadvertently detract from the learning of the physics. The physics can be considered the underlying model of the simulation. In a discovery-oriented learning environment, the goal is for the student to "discover" for themselves the rules of this model. If the simulation was sufficiently motivating to explore, no game would be necessary. But, alas, the simulation itself is rather boring for most people who are not already physics geeks. My ambition is to invent a game that turns people who play it into physics geeks. Yes, I dream big. So, let's keep this ambition in mind as I explain how the game works.

I really like how my simulation graphs the quantities of distance (traveled by the marble), the velocity (speed - aka the change in distance - and in what direction) of the marble, and the acceleration (change in velocity and in what direction) of the marble. As I played the simulation, I found myself mostly focusing on the distance graph, while also keeping an eye on the acceleration graph. Interestingly, I pretty much ignored the velocity graph. Not sure why, but that's what I found myself doing. Perhaps your play experience will be different.

Interestingly, I also ignored the numeric readouts just above the graphs. If the graphs are hidden, one could use the numeric readouts to also figure out the location and motion of the marble. But, I must admit I completely ignored this information as well. I find this particularly interesting because I have done research in the past where I compared the use of numeric data, such as these, to visual data in similar physics activities. But, let's not go there right now.

So, I thought my original idea of putting various targets in the graph area to "shoot" with the distance graph would make a rather interesting game. I try to avoid war or violent metaphors if possible, so I'm much happier with the "thread the needle" metaphor, and I think it works quite well. I think the threading metaphor actually describes the experience much better than the concept of shooting.

The Target: The Eye of the Needle

I kept the design of the target simple - a blue circle. I thought it made the most sense to color code the target to match that of the distance graph. Obviously, the larger the target, the easier the task. So, I wrote a script that assigned points to the target that match the size of the target. The size and vertical location of the target are chosen at random. I keep moving the target to the right on the graph area as the graph grows. So, the goal of the game is just to "pierce" the target - thread the needle - with the distance graph. Doing so earns the player the number of points associated with the given target.

Game Elements that Promote Learning

I think the game is pretty good, but I noticed a problem. It becomes pretty easy to hit the target if you press the acceleration buttons with reckless abandon. I think doing so also detracts from the learning of the relationship between distance, velocity, and acceleration. So, I wanted to temper this tendency to just go click happy. Consequently, I added a small penalty each time one of the acceleration buttons is clicked, which I (tentatively) called "maneuvers." The penalty is only 5 points, but this can up quickly if you go click happy. I also reward the player for finishing the graph by awarding some bonus points. This makes one more mindful of the rate of change of the distance graph, which of course is related to the change of velocity, which is what the acceleration buttons control. There is an interesting tension in the game now. One's tendency is to click wildly when you get close to one of the edges, but of course this comes with a penalty. Yet, the bonus points helps to offset that. So, I found myself wanting to absolutely finish a graph, while being careful to use all of my clicks wisely. For now, I don't penalize the player for missing a given target, but that has crossed my mind as another game element to add. I think the loss of points for missing a target is in itself a penalty.

An interesting question when it come to assigning or deducting game points is just how many points to use where and when. This is always a difficult thing to gauge. The goal, of course, is to enhance the game play. The only good way of deciding this is to play the game and to observe other people playing the game. Interestingly, once you find the sweet spot for the first level or round of the game, you can use all these parameters for increasing or decreasing the challenge of the game for subsequent rounds.

Other New Design Elements

As I worked on this second prototype, there were a bunch of other small design features that I included. Here are the most notable:

• I included a way to speed up the game play by allowing the user to change the horizontal step size of the graph. This complements the existing option of changing the default increment of the force of acceleration that I designed in the first prototype. Changing the horizontal step size is a very cool option because it changes the game play quite a bit. There is a faster pace to the game when the step size is increased, which adds to the excitement of the game, but it makes the game more difficult.
• I added simple sound effects at various critical moments: when a target is threaded or missed; when the player completes the graph; or when the marble rolls off the edge before completing the graph.
• When the game begins, I added some scripts to make sure the target was not overlapping the x axis. I wanted to be sure the player had to make some maneuver to begin to earn points. Similarly, I made sure that the target is not initially placed either too high or too low at the start of the round as I thought that would be a cause of frustration.

Next Steps, Though Not Likely

The game only consists of one round. If I continue to work on this simulation/game, an obvious thing to do next would be to add additional rounds with increasing challenges. Another idea is to leave a "ghost" image of all targets on the graph. I think this would be very useful in coming back and debriefing the player's game performance for that round, particularly in a conversation with a "more knowledgeable other" or MKO - to use a famous term by Vygotsky in his social constructionism theory. The teacher is an obvious MKO, but probably a more significant MKO to a player would be a peer who has achieved higher scores (but not too much higher).

But, to be honest, I don't think I'll be working much more on this game as I have achieved my original design goal of creating a simulation/game for use as an example in my teaching of design at the University of Georgia. But, if I can coax some physics teachers in some nearby high schools to use the game in their classrooms, and it proves to be somewhat successful as a learning tool and a fun game, then I might be motivated to continue working on it. I'll bet the students will have all kinds of ideas and recommendations for revising and improving the game. That would definitely "accelerate" my motivation to keep working on the game.

PostScript

I had the students in my doctoral design course download and try out the app. On some of the computers - all Windows I think - the simulation ran incredibly fast, much too fast to play. So, I have modified the option to calibrate the horizontal step size in one tenth increments between .1 and 1. Above 1, I kept the increment in whole numbers. I hope this helps. I've updated the download files accordingly (links are at the very top of this post).

This is an interesting design problem given that the simulation speed is ultimately tied to the processing capabilities of the computer on which it is run.

Update on the PostScript (September 18, 2016)

I submitted this problem to one of the LiveCode forums. With help from more experienced LiveCode programmers, I think I now understand the problem and it is not due to a Mac vs. Windows issue. Instead, it appears the problem is rooted in one of my simulation's scripts. I will post a separate blog post about this after I explore the problem more thoroughly based the advice.

Getting the Word Out: Building an Email Checker App with LiveCode to Remove Multiple or Bad Addresses from a Long List of Emails

For the past three years I've been teaching a MOOC about introductory statistics. In total, about 5800 people have enrolled. I've also been doing some research on MOOCs with this course as well. I'm happy to report that an "early view" of a research article I wrote is now available online through the British Journal of Educational Technology. Here's the link and citation:

http://onlinelibrary.wiley.com/doi/10.1111/bjet.12504/full

Rieber, L. P. (2016). Participation patterns in a massive open online course (MOOC) about statistics. British Journal of Educational Technology. doi:10.1111/bjet.12504

(After the print version article is published, the citation will change to include the volume/issue and page numbers.)

Yes, this is great news, and my family - usually my only readers - are very proud. (Some people have spread a rumor that I hold nightly, mandatory readings of my research articles in my house. That's simply ridiculous - I stopped doing that years ago.) However, I do want to alert the people who enrolled in my MOOC over these past three about this article because it's really because of their help and support that I was able to do this research. Fortunately, I have all of the emails of every person who ever enrolled in the MOOC. So, I could just put all of these emails into a gigantic list and "bcc" them in an email with the information about the paper. And that is exactly what I will do.

But, although it is true that over 5800 people enrolled at one point or another, a good number of these enrollments were the same people. Some started the MOOC and didn't finish, but came back the next time it was offered to work on it some more. Some did this several times. So, I don't want to send two, three, or more copies of the same email to a person. That's a good way to really get someone angry, and I've spent a lifetime trying to avoid angry people (with only mixed success). Ok, simple enough - just check the list and remove any multiple entries. But, good golly, doing so manually with a list of 5800 would be a tough task and I would likely make many mistakes even if I tried. So, once again it's LiveCode to the rescue. I quickly built a simple app that scans a given list of emails and removes all of the duplicates. I also added the feature to subsequently have it scan a list of "bad email addresses" - those that bounce back for whatever reason. That way, I can refine the list to only those emails that actually work. The result is an edited list of email addresses that I can use - judiciously - to send other announcements to these people that I think are useful and would be warmly received.

The Email Checker App

Here's a snapshot of the ugly, but functional main card:

Yes, pretty ugly. But hey, I built this app quickly - an hour or two at most - for me to do an important job. No need to make it pretty. But, there is usability in the design. The red text are the directions I wrote to remind myself about how the darn thing works. I actually built this app about a year ago and knew at the time I wouldn't need to use it very frequently. Knowing how short my memory is, I was careful to write in the instructions so that any idiot - well, a specific idiot - could know what to do after opening the app. As anticipated, it is only now that I have another email that I think is worth sending to this group. I'm now very grateful to myself that I wrote those "notes to self" - hmm, am I being "self"-ish?  

How the App Works

After pasting in the list of emails into the far left field, there are three simple steps to cleaning the list of duplicates and non-email addresses:

1. Sort the list. This puts exact copies of multiple emails sequentially in the list.
2. Check for duplicates. This simply compares each line in the field with the one after it. If the two are a match, a bell rings and the email is deleted from the field on the left and placed in the field on the far right. I realized that if there are more than two duplicates in the list, then this step would need to repeated until all duplicates were found. I was rather lazy here because yes, I could have programmed the matching algorithm to just keep going if it found a duplicate. That is, if it finds one duplicate on the next line, then it should continue the comparing the next line with the same email. At some point, I may make this modification, but for my purposes, it's easy enough just to run step 2 as often as I need to catch all the duplicates.
3. Check for the @ symbol. Finally, I found the occasional email entry that wasn't actually an email address. So, I added a step that checks each email for the @ symbol. Obviously, without this symbol, the email would not work.

Purging Bad Emails from the List 

After I send the email out, it is inevitable that some addresses won't work. Perhaps the person entered the email address incorrectly when they created their MOOC accounts, or they deleted the email account after the MOOC was over. Either way, I manually keep track of all emails that bounce back to me, then paste that list into the middle field on this card:

The end result is a nice, clean list of working emails.

Final Comments

I take very seriously the responsibility of having such a list of email addresses. I would never, ever consider giving or sharing this list with anyone. I don't know about you, but I am very hesitant of giving out one of my "good emails" to any group or organization because I'm always suspicious that my email will be sold or used for marketing purposes. (And yes, I do have some "throw-away" emails that work, technically, but I never check them. God only knows how much spam they have accumulated over the years.)

So, if you ever join a future section of my MOOC, please know that your email is safe with me. But, I hope you won't mind getting an email two or three times a year from me with information I think you really might want to have.