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.