Friday, August 18, 2017

Lloyd's Q Sort Tool: Version 1.0 Just Released

I've been very derelict in providing updates on my project to create a digital tool to allow instructors to use Q sorts in their teaching. I suppose my only excuse is that I've been focused these past three months on actually doing the design work and coding to make it all possible. Well, I'm happy to announce that version 1.0 of the my app - Lloyd's Q Sort Tool - is now available. [Cue the dropping of balloons and confetti.]

Part of the task has been the monumental effort to also create a web portal for instructors to use. Although I had designed the mySQL database carefully over a year ago to allow for instructor accounts, I had never actually created anything more than a crude administrator interface for me to do the behinds-the-scene database tasks to support the field tests I have been running. And yes, this was a very ugly site. So, I've been working on developing an attractive and (hopefully) intuitive web portal for instructors while also making the final revisions of the app. Oh yeah, I was also teaching two courses for the University of Georgia this summer at the same time.

But, I am now ready to make instructor accounts available on a very limited basis. [Cue the triumphant horns.] It is really only the beta of version 1.0 that has been released because I feel it is necessary to do much field testing of the app before I'm confident that I have finally reached a true version 1.0. If you are one of the few who read this blog and one of the very few who might be interested in using Q sorts in your instruction, please feel free to go to my Q sort project's web site to request an account:

Of course, if you are not an instructor, but would like to check out how my Q sort tool works, I invite you to download the app and try one of the public Q sorts I've included on my web site.

Here is a video demonstration of how the app works:

Summary of the Most Significant Revisions to the App

I need to provide separate blog postings to spotlight and explain each of the big revisions to the app, but here is a quick summary of the most significant. Some of these represent true breakthroughs in my design.

Breaking Through the 20 Statement Limit

For the first two years of the project, my design limited all Q sorts to no more than about 20 statements. Although this proved sufficient for all of my field tests, I knew that this limitation had to be overcome at some point. So, this past spring I mounted a design effort to find another approach. The solution came in the form of dynamically collapsing and expanding statements as they were sorted on the grid. This allowed me to switch to a more standard design of the Q sort board which resembled an inverted normal curve. I did keep the sideways orientation to the format of this board, which helped to leave the majority of the screen open for the statements. However, this approach triggered other user experience challenges and it was only through feedback from people who participated in some critical field tests that I was able to find a way for this to work.

Creating a Sorting Sandbox to Encourage Initial Grouping of Statements

It is standard practice within Q methodology to ask participants to first group all statements into three general piles: most agree, least agree, and neutral. Although my first prototypes advised people to do this, it never really worked well given the way the screen was organized. I found a way to persuade users to do this preliminary grouping which provided a solution to the limited screen space. Along the way, I think I found a unique design approach to doing a preliminary grouping. I added three long strips at the top of the screen, marked respectively as high, neutral, and low. Participants are advised to take each statement and do a "gut sorting" of it into one of these three groups. The unique design is that the placement of each statement, from left to right, on each of the three strips, gives a priority ranking to the statements in that strip. I have never seen this added dimension in any of the Q sort designs - paper or digital - that have been developed. I then added a 1-click option for participants to move the statements in any of the three strips into the main area of the screen in an expanded form and in the same order in which they appeared in the strip. The important thing to note about this strategy is that the initial grouping effectively removes all of the statements from the main area of the screen, thus opening this space for the statements to appear when when the 1-click option is used. In this way, the limited screen space is effectively used even if a large number of total statements is used in the Q sort. I also programmed an auto-magnify feature to immediately show the full statement when the participant mouses over any of the statement numbers in the sandbox.

Auto-Numbering of the Statements

I also programmed the list of statements to be auto-numbered. This provides a secondary cue to which statement is which. I combined this with the option to have a pop-up window to list all of the statements. Furthermore, this list can be copied to the clipboard for pasting in another application, such as a word processing document, to allow the participant easy access to all of the statements along with the statement number. This helps participants to cross-reference statements to their numbers.

Improving and Extending the Q Sort Analysis

I made a key decision about a year ago to put the analysis directly into the app itself. Before then, the analysis was done with a separate app I built meant just for the instructor.  This decision put the analysis data directly in the hands of students with real-time access to the data. That is, the student could check to see how many responses had been submitted and run an analysis on the responses submitted so far.

More recently, I extended the analysis by adopting a method very much aligned with Q methodology. Although I have long had an analysis option called "Are You Like Me?" which was based on difference scores calculated between each pairs of people who completed the Q sort, this never proved to be an effective means of getting people to engage with each other. This summer I programmed this option to also provide correlation coefficients along with noting which were statistically significant. Although I have yet to field test this revision, I'm optimistic that it will make people more likely to both talk to those who share their views and talk to those people who do not.

Overview of the Instructor Web Portal

Creating the instructor web portal was a challenge, not so much in terms of programming it, but in designing it to sufficiently explain how everything works to an instructor who has never met me or has never heard of a Q sort. Fortunately, the instructors to whom I've already given our accounts are people who heard me speak at various conferences about this project and asked permission to use the app in their teaching. I had to kindly tell them that the project was not yet "ready for prime time" and that I could not yet honor their requests. But, I added their names to a list of interested folks.

I provide some extensive guidance to instructors on how to use the site. I also created the following video demonstration:

The Difference Between Q Sort Definitions and Q Sort Activities

There are some key concepts that, if not well understood, will make everything else confusing for instructors. The main one is probably the difference between a Q sort definition and Q sort activities. I won't give the long answer here, but the difference has allowed me to take a smart approach to creating Q sorts in a way that should save instructors lots of time. In short, one first creates a definition of a Q sort that contains almost all of the information about the Q sort. Then, one creates one or more activities that are linked, or bound, to that one definition. In this way, one use and reuse a Q sort definition dozens or even hundreds of time without have to go through the time-consuming task of creating yet another Q sort.

Next Steps for the Project

It's been almost two and a half years since I first wrote about my decision to create a digital version of  a Q sort in April 2015. After hundreds of hours of coding and more than a dozen field tests, it feels so good to finally put this project "out there." Yes, I have built it, but will anyone come. To be honest, I only want a small number to request an instructor account so that I can identify and fix errors and problems which are inevitably present.  My hope is that eventually at least a small community of instructors will form who are interested in exploring ways to capitalize on students' subjective perspectives in teaching. I have charted an initial strategy for their use, but I know there are many other creative approaches yet to be identified.

I look forward to seeing how the project unfolds. I plan on presenting this project at upcoming conferences, beginning with the small (but wonderful) IDD@UGA conference on August 19, 2017. But, I will be presenting this project at the upcoming conference of the Association for Educational Communications and Technology (AECT) in Jacksonville, Florida in October. I also have submitted a proposal to present the project at the American Educational Research Association (AERA) in New York in April 2018. I also intend to submit a proposal to the Conference on Higher Education Pedagogy (CHEP) held each February 2018 at Virginia Tech to provide an update of the project.

I have spent a lot of time on this project. I hope it proves to be useful to teachers, instructors, and trainers.

Monday, July 10, 2017

The "Any 3 for 15" Game and the Courage to Start Over

I'm again teaching two courses for the University of Georgia this summer. One is a design course and recently we were talking about accessibility. I've tried to broaden my students' understanding of accessibility. I want them to see accessibility more as a design paradigm rather than a set of mandated technical requirements. That is, instead of seeing accessibility as nuisance for a designer, I want them to see accessibility as an opportunity to improve their designs.

One little activity I've used over the years is a cool little game that demonstrates the power of representation, namely that the way a concept, principle, or procedure is represented can dramatically alter the ease of learning it.

The rules of the game are simple. There are two players and each takes turn picking a number from 1 to 9. Once a number is chosen, it is unavailable to be chosen again. The player with the first hand with any three numbers that equal 15 is the winner. It's a surprisingly challenging game to play. As we play it, people begin to have the feeling that they've played the game before. There is a big reveal at the end. It turns out that this little game is really just tic-tac-toe (also known as naughts and crosses), but in mathematical form. The game is fully revealed when the numbers are shown in this pattern:

This is commonly known as a magic square. Notice how any row, column, or diagonal adds up to 15. Obviously, adults don't play tic-tac-toe any more because once you know the secret to choosing the center square, there is no way you can lose. However, even after the big reveal, the math version of the game is still a challenge to player. The two versions of the game have exactly the same rules, but the representation of each is dramatically different. My hope is that students will take this point to heart and try to find the best representation for their designs.

Creating a Version of the Game with LiveCode

I've had groups play this game for years using PowerPoint. I would just stay in edit mode and manually move the numbers around as the game is played. However, it occurred to me a few hours before class that I could create a quick version in LiveCode that would be easier to manage. Forty-five minutes later, I had a nice working version of the game. I still had to mentally keep checking to see if one of the players had three numbers that added up to 15. After class I thought it be great to program LiveCode to do this checking. Well, that began a design saga that took me over a week to complete.

Identifying All Unique Groups of Three Numbers

The algorithm needs to check all possible combinations of three numbers in the player's hand after each turn. I saw a couple of way to handle this problem. One way is to use a well-known formula to determine the total number of possible combinations, then turn LiveCode loose spitting out random combinations until all of the unique ones were found. Here's the formula:

r is the number of numbers in a given combination, which is always 3 in this case.

n is the total number of numbers in the list, which is the number of numbers a player has drawn up that point.

Obviously, the player has to have at least three numbers before you start calculating. And, the most numbers a player will have is 5 given that the players take turns drawing numbers. The formula above indicates there are only a total of 10 unique combinations of three numbers in a list of 5 numbers. (Order of the numbers obviously does not matter.)

A better strategy - and the one I selected - was to figure out the algorithm first, mapping it out step by step on paper. It's pretty simple:

Take five numbers: 1, 2, 3, 4, 5

The pattern of combinations can be determined as follows:


Yep, there are 10 of them. Do you see the pattern? There are three loops here corresponding to each digit in a row. Believe me, it is very easy to get totally confused in trying to troubleshoot a problem with an algorithm having three interwoven loops - it's like trying to balance three spinning plates on sticks. Once you focus on one, the others are prone to fall.

I spent about two hours on a Sunday afternoon working on this without success. I came back to the problem that evening, only to find myself thoroughly confused. So, I started over.

On the Reluctance to Start Over

I had about three hours invested in an approach that was not working. At times, it appeared I was tantalizingly close, just to have the algorithm fall apart again. The idea of starting over after having invested so much time is a tough pill to swallow. And yes, I think it does take some courage to admit defeat and start from scratch.

I turned to a favorite strategy where I build a new "toy app" from scratch that focuses solely on this one problem. In this virtual sandbox, I find I can focus better on a thorny problem. It really helps to start with a blank canvas and not have all of the other stuff from the bigger project jumbling around in your head. It was a busy week, so it was only Wednesday when I got round to doing this.

Unfortunately, my second approach yielded the same confounding results. And I again decided I needed to start over. Fortunately, all of the code this time was contained in a single button in a very simple stack, so I just moved that button off to the side and made a new button. I worked on this Friday night and some of Saturday. And, I again got myself into a brain splitting knot.

Fourth Time's a Charm

I again decided to start over. Although I had basically the right idea behind the loops, my approach to ending one loop and starting the next was flawed. The week's efforts convinced me that I needed to focus on the most concrete representation of the problem I could muster. So, instead of working with ever growing looping lists within variables, I used fields as containers. This gave me a visual form to seeing how the algorithm worked, not unlike the tic-tac-toe example.

I don't think I can sufficiently or succinctly explain my solution here, but suffice it to say it was a joyous moment when my program finally worked.

The lesson to take away here is sometimes the wisest way to solve a problem is to abandon an approach -- regardless of the amount of time already invested in it -- and start over.  Knowing when to throw in the towel is tricky, but I guess that's where the wisdom comes in.

Play the "Any 3 for 15" Game

(Alert! Depending on your Internet speed, this can take a full minute to download.)

And yes, the game title definitely needs work. Right now, it sounds like a selfish version of the Three Musketeers motto (i.e. "All for one and one for all").

A Final Note: Computing Factorials with LiveCode

I mentioned that I flirted with the idea first of using the formula above as my starting point for my solution to this problem. I spent about 15 minutes trying to program LiveCode to compute the factorial of a given number. I would have eventually figured it out, but fortunately,I stopped and did a google search and found a very elegant solution:

The example comes from this web page:

To quote from that page:

"A function can call itself. The following example calls itself to compute the factorial of an integer:"

 function factorial theNumber  
 if theNumber <= 1 then return 1  
 else return theNumber * factorial(theNumber -1)  
 end factorial  

My solution would have been quite convoluted in comparison. And, I learned something new about LiveCode as a result.

Thursday, April 27, 2017

Creating an Instructor Version of my Q Sort App

I am again attending the annual conference of the American Educational Research Association. This year it is located in San Antonio, Texas. I will be presenting a poster session about my research on instructional applications of Q Methodology. I think I have finally found a suitable title for this research:
Embracing Student Subjectivity: Using Q Sorts in the Classroom
I think this is more accurate - and more interesting - than titles I've used in the past (e.g. "Adapting the Q Sort Research Methodology for Instructional Purposes"). I'm also quite proud of my poster if only because I managed to build an interactive component into it, something I've yet to see in an AERA poster.

I'll have pizza statements that people can move around the Q sort board in the lower left-hand corner of the poster.

I also just realized this is my first blog post for 2017 - quite a long hiatus. However, this does not represent my LiveCode work over the past four months. I've been involved in many LiveCode projects, including updating my video analysis tool and building an agricultural education prototype. So, there is lots to write about in the coming weeks and months.

The topic of this post is about some of my latest Q sort app development work. I've field tested my Q sort app and emerging instructional strategy many times over the past few months, most notably in an undergraduate course in environmental health. Here's a quick reminder of what the app's home screen looks like:

The app and my approach have worked very well. But, one thing I have found myself needing is an instructor version of the app to be able to do the following things:

  • Demonstrate for students how a Q sort works, but not have the data for that demonstration uploaded to the server.
  • Analyze any given Q sort without actually completing the sorting activity myself.
At first, I just made some quick hacks in a copy of my "regular" Q sort app. However, I came to the conclusion I needed to devote some serious time to creating a viable instructor version. One other good reason to do so is that I'm very close to entering the next phase of this research and development activity, namely giving other instructors their own accounts in order to use my Q sort app as they wish.

A Key Variable: varInstructor_version

Rather than create a truly separate app just for the instructor, I figured the smartest thing to do was simply to build into the existing app a way to quickly allow it to be transformed into the instructor app. That way, I don't have to keep up with two apps. Remember, the current app is still very much a prototype. I'm sure lots of revisions and enhancements will be made over the coming months. So, I created a global variable "varInstructor_version" that is set to either true or false. If false, the app works as the student version. When true, it works as the instructor version. All I need to do is set the variable, then create a standalone for whichever version I want at the time. When set to true, the home page will show one small, but significant checkbox:

If the instructor leaves the box unchecked, the app works just like the student version. If checked, another variable - varInstructor_mode - is set to true. Two things then happen. First, another button appears titled "Analyze a Q Sort":

Clicking this button will give the instructor a pop-up window to enter any Q sort code. The app jumps immediately to the card showing the list of people who have completed the Q sort along with buttons to do the analysis.

Second, all data upload scripts are disabled within the app. That way, the instructor can enter the Q sort code in the regular input box (the same one the students would use), then go through a complete demonstration of how to complete the Q sort. The following message is shown in the final screen that says the data are being uploaded:

The phrase "not really" cues the instructor that their data really has not been uploaded.

Final Thoughts

I'm very excited by the prospect of soon giving other instructors the option to try out my Q sort app with their students. I gave a presentation about my work with Q sorts at the annual Conference on Higher Education Pedagogy at Virginia Tech back in February. The turnout was good and the main question I received afterwards was "Can I use it with my students?" I promised everyone that I was working on it. Likewise, I hope my Q sort work is as well received by folks who come to my poster session at AERA. However, AERA usually brings a much tougher crowd to sessions. Fortunately, I walk by the Alamo each morning on the way to the conference, so I'm inspired to be "armed and ready" to defend my work. Of course, despite the heroics of Davy Crockett, James Bowie, and Colonel William Travis the Texans lost the battle. Very reassuring.

Monday, December 26, 2016

Hard Coding with an Eight Foot Piece of Pine Lumber

Well, the semester ended and the holiday season suddenly emerged around me. Handmade gifts are always the ones I enjoy receiving the most. It doesn't matter the quality of the item, only that the person has invested their time and focus on the receiver's behalf. My daughter, Rebecca, is the one who has given me the most beautiful and precious handmade gifts over the years. She is an accomplished professional artist, but she enjoys dabbling in most every craft. One Christmas she gave me a wonderful set of crocheted Angry Birds, which I proudly display in my UGA office. I still cannot bear to discard even a picture she drew for me when she was in third or fourth grade. I have tried to give some handmade gifts myself over the years, to varying degrees of success. But again, I think the people who receive them appreciate the time and attention they represent and - even if the quality is lacking - my intent.

Okay, you are probably asking yourself what all this has to do with learning LiveCode. Well, I have long felt the same sensation in building something with wood as I do when programming. And the key word here is "build." The part of my brain and psyche that is fulfilled by the act of building something is equally satisfied with wood or software as the finished product. I feel the same sense of euphoria and accomplishment as I build something in either medium. My skill in each medium is quite lacking, but that hasn't deterred me. I've given so much focus on building software over the past few years that it occurred to me that I needed to spend some significant time on a woodworking project. The brief holiday break leading up to Christmas provided a good opportunity.

Build: A Special Word

A little more about the word "build." Many other words are used for the act of actually giving a tangible form to a design. In my field of instructional technology, a favorite is the word "develop." I've never been too fond of this word for some reason. The current interest in MakerSpaces puts the word "make" at the center. I like the word "make." It conjures up the world of crafts and I've come to really appreciate and admire people who are serious in making crafts. For example, I've finally come to see the importance and value of making personal scrapbooks using paper, glue, and scissors. I find it both funny and sad that we all loved working with these materials as children, but somewhere along the way, most of us stopped because we thought them as too childish for adult pursuits. ("Put down" is an apt phrase here for both its meanings.) "Construction" is a word I've favored for almost 30 years. Indeed, I think Seymour Papert was wise to use it to describe his theory and practice of constructionism, which is simply learning by constructing, or - as I liked to describe it - learning by building. The word also conjured up its more serious philosophical cousin - constructivism. Discussing the "N" version vs. the "V" version of the word has filled many hours of my teaching. One thing I like about the word construct is that it is easy to imagine the person using a variety of tools, those both simple and sophisticated, while probably wearing a hard hat.

But, the word build is my favorite because I think of its relationship to working with wood to create projects used in our day-to-day lives. It's easy to imagine a carpenter or cabinet maker building something on a very personal scale. Our kitchens, living rooms, and bedrooms are full of things built with wood by skilled people. And, I've long used carpentry as a favorite analogy to building software projects. Many years ago, I wrote a book titled Getting Interactive with Authorware: Building Simulations and Games.

In the preface, I featured one of my woodworking heroes - Norm Abrams - to explain what a "project approach" was all about using the metaphor of woodworking:
The project approach simply means that one learns through building complete, stand-alone projects that are interesting and have clear goals and expectations. Good projects also have an easy-to-understand structure that makes sense at the start. Games and simulations make for good projects. One might say that this book was written much in the spirit of Norm Abrams on the American public television show “The New Yankee Workshop.” Norm is a master carpenter who shows his TV audience how to build from scratch a piece of furniture or other woodworking project. Norm always starts by carefully choosing a project worthy of the effort, often visiting American colonial sites for inspiration. Once he finds a suitable subject, he then builds the piece twice — once for himself (plus to show the audience at the start what the finished product will look like) and again in front of the camera. The design that Norm follows usually includes many changes from the original, mostly to keep the construction within the reach of the amateur carpenter at home.
Although TNYW is no longer in production, you can find all of the episodes on YouTube - here's a good one:

A Christmas Present for My Wife

My woodworking project was a special Christmas gift for my wife this year. I really wanted to push my current skills and develop some new skills. Most of my efforts over the years have been creating outdoor projects featuring mostly 2X4s. My projects have included a storage shed, a deck, a few picnic tables, several benches, two chicken houses, simple fencing, and some wooden gates thrown in along the way. If the project involved 2X4s with a fairly wide margin of error, I was your man. The challenge I gave myself this time was a piece of indoor furniture that my wife would find useful and beautiful. The margin of error now was very small. Finding the right piece of furniture was key. I checked out a bunch of woodworking books from the library - all included at least one of the words "simple," "easy," or "children." One book I really enjoyed reading was Build It Together: 27 Easy-to-Make Woodworking Projects for Adults and Children by Katie and Gene Hamilton. I loved the concept and especially the simplicity of the projects. (The photos were fun to look at as each featured a child building one of the projects with a parent.) Each of these books - even the simplest - contained knowledge and skills I did not have. So, similar to my learning LiveCode, each helped me to extend my own skills and knowledge just a tiny bit. And over time, it adds up.

Just as time was running out to build something in time for Christmas, I found the perfect project - a hallway bookcase that I found in the book The Complete Guide to Easy Woodworking Projects: 50 Projects You Can Build with Hand Power Tools, published by Black & Decker.

The design has those three essential elements proposed by the architect Vitruvius several thousand years ago - firmness, commodity, and delight. This bookcase is meant for the underutilized space of a hallway with a small footprint that tapers off toward the top, making it less likely to bump an elbow into it. I think the delight comes from the simplicity of the design and its well-balanced, visual form. Here's a photo of the finished piece:

I won't bore you with any more details, other than repeating that I experienced that same wonderful, satisfying feeling of building something special. And yes, it did involve several pieces of eight foot pine lumber - but not one 2X4.

I wish everyone a wonderful, healthy - and peaceful - 2017.

Wednesday, December 14, 2016

Lloyd Taking Inventory: What Have I Actually Designed in the Past 34 Years?

The fall semester at the University of Georgia is coming to a close. I taught two design courses this semester and am hunkered down reviewing student projects. As usual, I'm very impressed by the creative work of our students.  I've encouraged my students to try to think of themselves as designers, so I always try to model being a designer as part of my teaching approach. The great thing about taking on identities such as designer, writer, or even researcher is that you don't have to be great or even good at it. You just have to do it with passion and confidence. Indeed, the current writing on design thinking makes it clear that good or great designs usually only come once in awhile and only in the midst of a slew of other designs that never see the light of day.

With that as the context of this post, I've been trying to remember all of the major design projects I've been involved in during my career as a professional educator. These are the ones that rose to the level of good or useful and took significant time and effort to produce. Put another way, these are the ones that saw the light of day. Also, the only examples I include here are software design projects. So, I don't include the design of any of my classroom instruction or any initiatives in which I've been involved. For example, none of the +-10,000 or so PowerPoint presentations I've created qualifies for this list. As another example, about six years ago I was asked to build an initiative by a former dean of our college of education to try to engage faculty in innovative forms of instruction supported by technology. This was a major design effort on my part, but it is not included here because it was not software design.

Each of the software described below deserves a full and long explanation, but I'll obviously not do that here. My goal is simply to "take inventory" and provide a short description of each.

Serendipity (1982)

This was my first published software. Serendipity consisted of nine games and activities for elementary school children, most targeted at fifth graders, the grade I taught. The story of its creation is far too long to tell here. The short version is simply that I decided to learn Applesoft BASIC programming on my own on the Apple II family of computers. At the same time I was a brand new elementary school teacher. Fortunate for me, right after graduation from the University of Pittsburgh I landed in an elementary school in rural New Mexico who had a progressive principal who saw technology as the future of education. He found in me a willing participant in his vision of technology supporting teaching and learning. It was a wonderful time to be a teacher interested in technology, which I now refer to the romantic period of educational computing. That is, there were no rules, directives, mandates, or restrictions. I was free to experiment.

Of Serendipity's nine activities, here were the ones I was most proud of:

Mineshaft: This remains as probably my most successful game design, as judged by students' level of engagement and learning. It is an educational game for learning fractions through estimation. A miner left his miner's pick down in the mine and it was your job to go and fetch it. You competed against another player. The mine was actually a number line shown in a vertical direction. Each player entered a fraction, then their respective mineshaft elevator would be lowered to that level. The player who came closest to the miner's pick would see the pick get loaded into their elevator, taken back up to the surface and deposited on their side of the screen. The first player to win a certain number of rounds was the winner. The cool thing about this game was that you really didn't need know anything about fractions to enjoy the game. You could learn about fractions through discovery learning. Another cool thing is that you never worried about getting exactly the right answer. In fact, this was almost impossible to do. Instead, the game promoted the important skill of estimation.

Pinpoint: This was another game where the player learned about estimating mathematics. The game was really just a form of the classic guessing game where one person thinks of a number between, say 0 and 100, and the other person has to try to guess what it is. In this game, a picture of a radar screen appeared on screen. The idea was that the mystery number was located at the center of the cross hairs. As you took guesses, your "shot" was shown on the radar screen a certain distance away from the center. The closer to the center, the better your guess. This was another game that my fifth graders really enjoyed.

Waffle: This was a math game for two players that borrowed from the games of bingo and connect four. A 4X4 grid appeared on the screen. At the start of each round, each player would choose a "target number," such as 20. The goal was to take turns choosing to place an integer from 1-9 in one of the squares. If a row or column eventually added up to your target number, you won a bunch of points.

Estimation Baseball: This was another math estimation game for two players. The idea was very simple. Give the player a seemingly tough math problem, such as 439 X 675, with very little time to solve it. Let's imagine giving the student only 15 seconds with a beep every five seconds. Each beep signals a "strike." If you don't enter some answer (i.e. swinging the bat), you strike out. If you enter a number, it all depends on how close you estimate the correct answer of 296,325. Learning to quickly round each number to the nearest hundred would give you a much simpler problem of 400 X 700, which is 28 plus four zeros, or 280,000. This might result in a double or a triple. Get even closer and you hit a home run. But, estimates that are far off the mark result in an out. Shortening or lengthening the time between strikes is an easy to increase or decrease the challenge.

Professional Class Golf (1984)

This golf game remains my magnus opus. It was also designed for the Apple IIe and was programmed using BASIC. It was my second software package published. Interestingly, the publication of this game coincided with my transition from classroom teacher in New Mexico to doctoral student at Penn State. I have vivid memories of working on it in both places. (Note: I know there are DOS 3.3 emulators out there that will take old software programmed in Applesoft BASIC and allow the software to be played on modern Apple computers. Unfortunately, getting the code from the 5.25" disks to the Internet is a "bridge too far.")

Fig Newton (1985)

This was the software I designed for my dissertation research at Penn State. It involved a fundamental tutorial about Newton's Laws of Motion lasting about 45 minutes. My research topic was learning through visualization, specifically animation. I built a bunch of simple physics animations to accompany my physics narrative. I studied the difference between animated and static images. Fig Newton was designed using SuperPilot for the Apple II family of computers. Few people know about SuperPilot, but it was the preferred authoring choice at Penn State at the time. Despite knowing and greatly preferring Applesoft BASIC, I went with the flow and learned SuperPilot.

Fig Newton Redux 1 (1988)

After I graduated and became an Assistant Professor of Educational Technology at Texas A&M University, I decided to go back to programming with Applesoft BASIC. I reprogrammed my Laws of Motion tutorial in BASIC. I recall one motivation to do so was so that I could begin to include gaming and simulations within the tutorial. Although one could actually program the needed algorithms in SuperPilot, the execution was very, very slow to the point that it was unusable. And, it felt good going back to BASIC. I used variants of this software for my many research projects in the schools for many years.

Space Shuttle Commander (1990)

This was my attempt at putting into practice everything I had learned with my research. Space Shuttle Commander (SSC) included a series of games and simulations in the context of the player commanding the space shuttle. All of the tutorials I had created became available as student resources, creatively rebranded as "flight school." I was very proud of SSC, particularly because NASA agreed to publish it within their Educational Technology division. The software was given away for free to all interested teachers.

Fig Newton Redux 2 (1992)

I'm actually amazed how long the Apple II family of computers remained viable in the schools. But, eventually, the inevitable happened and the Apple II family was replaced with Macintosh or Windows computers. I think it started to happen in earnest around 1991. I had begun learning a new authoring tool called Authorware a few years earlier. Gaming and simulation software created with Authorware in the early years ran very slowly, similar to SuperPilot, but due to advances in the Mac platform eventually the speed became satisfactory and I made the jump from BASIC to Authorware. This happened about the time I moved from Texas A&M University to the University of Georgia in 1993. I again programmed many different variants of my laws of motion tutorial, games, and simulations for use in my research agenda at that time.

The Rogue Refrigerator (1995)

For awhile I focused attention on the relationship between distance, velocity, and acceleration as the learning topic within my research agenda. If you know anything about physics, you know this is among the most fundamental set of principles in physics. Indeed, the history of physics more or less began with these ideas. Some historians point to these principles as the first serious examples that gave rise to the invention of calculus. One example of a game and simulation combination involved an activity in which just the graphics - and hence the context - of the simulation changed. For example, we had the ever-popular spaceship example with an engine accelerating it faster and faster. But, another example used a graphic of a refrigerator being pushed by one or two people (they resembled twins). The idea of a fridge on the loose really struck the fancy of the research participants, though in the end this example produced the least effective learning. But, it was fun to play.

Nowhere Road - The Game (1999)

Our program at the University of Georgia changed the design of our masters curriculum to focus on a studio approach to learning. This included sharing one's design prototypes as they were developed with one's design community for critique, while also journaling about the design. Again, in the spirit of modeling all this I designed Nowhere Road - The Game, which involved the adventures of a mild-mannered professor who bicycled to work most days. Along the way, he had to deal with mean dogs and impatient drivers. The game also tried to teach the benefits of safe cycling. I again used Authorware to design this. Fortunately, the journal I kept is still available.

Project Shop (2000)

Project Shop was a federally funded to help people with mild to moderate intellectual disabilities. Video and interactive software was developed in the context of grocery shopping. The grocery store is an interesting place, both cognitively and socially. There are so many opportunities to build many forms of literacy and to learn socially accepted behaviors. Having a dually-diagnosed son with autism, I learned early how difficult the grocery store was for him to figure out. The grant allowed us to produce some very fun, motivating videos that became "anchors" for a variety of activities found on an accompanying CD. I can claim only a portion of the design effort that went into Project Shop. The credit goes to the entire team, which included Dr. John Langone and Dr. Thomas Clees, special education faculty and colleagues of mine at UGA. We also had some outstanding graduate assistants, included Michael Matzko. Mike was one of the most talented software designers I've ever had the pleasure to work with. The topic of Mike's doctoral dissertation was the design of the Project Shop software. We used Authorware to build the software which, unfortunately, makes all our excellent work inaccessible. Very sad irony.

WWILD Team (2000)

Around 2000 I became very interested in designing online learning environments. I began to learn about how to build databases for use in dynamic web sites. I learned how to program Active Server Pages (ASP) using a simple Microsoft Access backend database. The WWILD team was my first large project. WWILD stands for "World Wide Interactive Learning Design" team. I envisioned the entire world acting together as type of organized design effort. Interestingly, the WWILD team anticipated the rise of learning objects because the site promoted the compilation, curation, and review of interactive learning "modules." Yes, I had high hopes for this site. The site remains active and functional.

Lloyd's Personal Learning Management System (2002)

The early examples of learning management systems (LMSs) were very crude and I was very disappointed in them. So, I decided to make my own custom LMS for various courses I was teaching to use an alternative. I built a rather clever design using ASP and Microsoft Access which allowed me to early create new sections of the course for use with new students in subsequent semesters. It proved popular enough that many of my colleagues at UGA asked to use my system when they were tapped to teach these courses. This online system still works, but I stopped using it about five years ago when UGA finally adopted a more robust LMS.

Graduate Degree Portfolio Management Site (2005)

For many years I was graduate coordinator or department head or program coordinator, or a combination thereof. One of the most confusing tasks was managing graduate student portfolio meetings. Many people have to be consulted just to schedule one. Then, it becomes a game of reminders to make sure everyone shows up at the right time and the right place. So, I solved this problem by building a management site for all of the graduate student portfolios. The site doesn't contain the portfolios themselves, just links to them, along with committee members and room numbers. The web site also manages the approval and completion process as each portfolio undergoes several reviews. This has been one of my most successful projects and in the end saved a lot of people a lot of time, especially me.

In Search of Lost Wisdom (2006)

This was special activity I designed for my online teaching of instructional design to help me teach task analysis. I built this activity because, frankly, I was dissatisfied with my teaching of the task analysis unit. I didn't like teaching it and, not surprisingly, my students didn't like learning it. I had been touting the advantages of game-based learning, so I decided to practice what I had been preaching by designing a game to do the teaching for me. This is now one of my and my students' favorite parts of the course. This was also designed with ASP and was added to my custom-built LMS for the instructional design course. (Note: I also built a public portal for my LMS, which required quite a bit of effort. It's been used by about a dozen or so instructors in the USA. It still works. In fact, I used this portal myself this semester to run the game during one of my courses. It worked great and students seemed to really like it.)

Project Promote (2006)

One of the cool tools I built for my custom LMS was a question & answer (Q&A) tool to allow all questions asked by students to be archived and then searched later by them or future students. It worked pretty well. I presented this tool to a group of faculty and administrators in the Office of the Vice President for Instruction at UGA and it generated some interest. An interesting design emerged from these conversations to build a Q&A-type tool where assistant professors could ask sensitive questions posed to a group of senior faculty. The VP gave me a little bit of money to hire a graduate student to build this online tool. I thought it was a great idea, however, the tool just never took off. It was that case of "we built it, but they did not come." Too bad.

Catch Sunny (2011)

This was my first serious LiveCode project. I was working on a large grant meant to support people with disabilities transition from school and home into independent living in the community. This app was meant to help the team understand the ability of people in the target audience to use and interact with the small iPhone interface. Sunny is one of my pet dogs. I randomly put a picture of Sunny on the screen and the task was to click on Sunny (i.e. catch him) as quick as you can. If successful, the size of the icon of Sunny was reduced a little bit. If errors began to occur, then the icon's size was enlarged. The app tracked the user's success and error rate. It also tracked where errors were occurring. I also used this project to learn how to build a native iOS app for the iPhone. This was my first app that appeared in the iPhone App Store.

Lunar Hotel Shuttle (2012)

This physics simulation game was the original inspiration to start this blog, so click here to read more about it.

Statistics in Education for Mere Mortals (2013)

I entered the MOOC world in 2013 by proposing, then building a MOOC to help instructional design professional in particular, but really anyone, learn and use fundamental statistics in their work. I've taught this MOOC eight times, with a regular schedule for future offerings (a new section begins every February and July). The fundamental software design for this MOOC is a series of videos that revolve around each participant building their own Excel spreadsheets from scratch. We start with computing the mean and standard deviation, and end by computing an Analysis of Variance (ANOVA). All of the videos used in the MOOC are available on YouTube.

PersuadeMe (2013)

PersuadeMe is an interactive web site that promotes learning how to write evidence-based argumentation. The design of PersuadeMe was a group effort, but I led the design effort and also was the programmer for the team, building the site using HTML, PHP, and MySQL. We received a very small grant of $25,000 to build the prototype, but this funded only a small portion of the time needed to build the site.

Lloyd's Video Analysis Tool (2016)

I've blogged extensively here about the design of this app. Here is a last blog post I published about this app.

Lloyd's Q Sort Tool (2016)

I've also blogged extensively here about the design of this app. Here is a link to my first blog posting about it.

Closing Thoughts

As I wrote in the opening section, most designs never see the light of day. A good example of this is the fact that I have designed and written about 31 unique projects in this blog since I began it in January 2013, almost four years ago. However, of these I include only three in the list above - Lunar Hotel Shuttle, Lloyd's Video Analysis Tool, and Lloyd's Q Sort Tool. But, that's OK because each of the projects contributed in some small way to my overall understanding of LiveCode and consequently to the design of these three projects.

As I reflect on the list above, I wonder about many things. What exactly does this list represent? Although this blog post seems long, one must remember it represents 34 years of my professional life. That fact makes the list seem very, very short to me.

Finally, I keep an old Apple IIe in my office and every now and then I power it up to play some of my older software. Of all the software I programmed for the Apple IIe, the one I play first - and usually the only one play - is Professional Class Golf II Pebble Beach. Even with the old graphics, simple sound effects and keyboard only input, I still think this is a fun game. Good design, like good music, stands the test of time.

Wednesday, November 23, 2016

Giving Thanks to the LiveCode Community For Their Help in Solving a Pending Messages Problem

We Americans are about to enter into the long Thanksgiving holiday weekend, so it is time for me to pause and reflect on all of the reasons I have to be thankful. There is much on a personal level I could mention, but given that this blog centers on my professional life, I wish to give thanks to the wonderful LiveCode community. And, the topic of this post is definitely in the spirit of my blog's title - learning LiveCode.

Recall I had been experiencing a strange speeding up within a little physics simulation/game I had created back in July. This problem baffled me, so I decided to post a note about the problem within the HTML5 LiveCode Forum. Two longtime LiveCode users, Hermann and Bernd, quickly responded. Each immediately zeroed in on the cause of the problem. My looping strategy has a major flaw in it. It creates a build up of pending messages. Each one restarts the loop, resulting in a sort of amplification effect. Instead of only one loop being in control at all times, multiple loops are created with each having an effect on the speed of the simulation. Through their kind assistance, Hermann and Bernd helped me to understand a little better the nuances of the pending messages feature in LiveCode. For more details, I've included below a copy of my post to the LiveCode HTML5 Forum along with the replies from Hermann and Bernd.

My physics simulation now runs great on all platforms, including HTML5. Click here to check it out for yourself. (The download takes awhile, so be patient.)

Knowledge Transfer: Solving a Similar Problem in My Q Sort App

Most of my time over these past two months have been devoted to work on my Q sort app. I will post an update on that project soon, but I believe a problem that only Windows users had been experiencing is also related to this pending messages problem caused by my looping strategy. I haven't been able to test the new version of the Q Sort app thoroughly yet, so I'll withhold judgment until later if this is, in fact, the cause of the problem. But, I definitely was executing the looping strategy incorrectly in the Q sort app, so fixing it can only be a good thing.

This is just a nice example of how increased understanding of a problem in one LiveCode project - even a toy project - can be used to solve a problem in another, more serious, project.

A quick side note: Last week I gave a presentation at the E-Learn 2016 Conference in Alexandria, Virginia, about my Q sort research project. I think it went well. Most satisfying was the fact that no one in the audience had ever heard of the Q methodology. I like being the one to first alert people to this very interesting way to study subjectivity.

Final Thoughts

I like to tell people that Thanksgiving is my most favorite holiday of the year, with July 4th coming in a close second. Thanksgiving is all about family and July 4th is all about community. Also, we have yet to figure out a way to commercialize these two holidays. (Yes, the encroachment of the Christmas buying season on Thanksgiving has been a problem, but even that is finally beginning to be rolled back.) But for academics - faculty and students alike - Thanksgiving also provides a well-timed moment to both catch our breath and catch up. This post is a good case in point. I actually began writing it in mid-September. The past two months have been very busy and hectic. So, it is nice to finally give thanks publicly to Hermann and Bernd.

Finally, take note of the last paragraph by Bernd. He cleverly found a way to "hack" my little game, something I'll be sure to patch up if I continue working on it.


I'm mindful of the fact that the Macy's Thanksgiving Day Parade may be the greatest example of commercialism. But hey, it's an American tradition!

My LiveCode Forum Post

Strange Speeding Up in the Execution of a LiveCode Project

I wasn't sure the best forum to submit this to, but given that the problem I describe below occurs when I export to HTML5, I thought I would start here.

I've created a little physics simulation/game I call "Thread the Needle" to show the relationship between distance, velocity, and acceleration. I'm used LiveCode 8.1 on a Macintosh. It works great when I run it as a standalone for the Mac, but when I export it as a standalone for Windows or HTML5, something odd happens.

Everything starts off fine. The simulation and game work just as expected. But, the program starts to speed up inexplicably with each new game or simulation try. It is important to point out that each new try begins with an "opencard" command. The program only consists of a single card. I put all of the opening scripts on the card script including a bunch of custom functions I created. This includes the main "loop" function that controls the simulation/game:

 on mainEventLoop  
   if varRun is true then  
   end if  
   send mainEventLoop to me in 50 milliseconds  
 end mainEventLoop  

The procedure "mainEventLoop" is originally called in the opencard script.

For the HTML5 version, if I choose to reload the page the program again works fine for the first try, but then it predictably speeds up in each successive try.

The same phenomenon occurs when I run the Windows standalone version. If I quit and relaunch the Windows standalone, it works just fine for the first try, but then the simulation/game gains speed with each successive try. It's as if the computer's processing power magically increases each time. (Given that mainEventLoop calls itself every 50 milliseconds, I would think this would create it's own speed limit.)

But again, all works fine if I stick to the Macintosh. So, this leads me to think the code is working properly, but that there is something uniquely odd with the Windows or HTML5 execution (at least when the program is built on a Macintosh).

If you want to run the program for yourself to see what I mean, here is the link to the HTML5 version of the project:

I also made a video demonstration of the simulation/game for use in my teaching at the University of Georgia, in case you just want to get a sense of how the program works. (This video was made using only a Macintosh, so the problem described above doesn't occur.)

I'm guessing (hoping) that others have experienced this phenomenon also and might be able to share some insights as to what is happening and, more importantly, how to make the problem and to have the simulation/game run smoothly.


Lloyd Rieber

Re: Strange Speeding Up in the Execution of a LiveCode Project

Postby [-hh] » Sat Sep 17, 2016 8:55 pm
Hi Lloyd,

you could try to cancel the current loop before starting a new one.
This should work on each platform and especially in the HTML5 standalone.

   on opencard  
     repeat 2 -- cancel current mainEventLoop  
       repeat for each line L in the pendingMessages  
         if L contains "mainEventLoop" then cancel item 1 of L  
       end repeat  
     end repeat  
   end opencard  

[Probably the Mac IDE holds, without the above cancelling, the additional mainEventLoops in a long row and absorbs them later on because the simulation needs more than the 50 millisecs of the loop's refresh.]


p.s. Great stack!

Re: Strange Speeding Up in the Execution of a LiveCode Project

Postby bn » Sun Sep 18, 2016 4:44 am
Hi Lloyd,

I agree with Hermann that the messaging seems to be the problem.

   on mainEventLoop  
     if varRun is true then  
     end if  
     send mainEventLoop to me in 50 milliseconds  
   end mainEventLoop  

here you send "mainEventLoop" regardless of what happens, whether you show a dialog and so on. That is not necessary and piles up messages.
I tried to fix this by

   on mainEventLoop  
     if varRun is true then  
      lock screen  
      unlock screen  
     end if  
     put the pendingMessages into tMessages  
     repeat for each line aLine in tMessages  
      if item 3 of aLine is "mainEventLoop" then cancel item 1 of aLine  
     end repeat  
     send "mainEventLoop" to me in 50 milliseconds  
   end mainEventLoop  

It effectively keeps the "mainEventloop" messages from piling up and it runs nicer in HTML5.

Note that I put a lock screen/unlock screen pair around checkGame and physicsEngine. You do a lot of screen updates in your handlers like graphics and fields. That is costly and can be avoided by locking the screen.

Furthermore your mainEventLoop does not have to run when the game is not actually running e.g. showing dialogs. I would move " send "mainEventLoop" to me in 50 milliseconds" inside the "if varRun is true" condition.
That needs a little more coding regarding varRun setting to true and false and when setting it to true to start the "mainEventLoop" again but saves a lot of processing cycles and then it does not interfere with the rest of the application.

My strategy to get some points was not to touch the arrowkeys at all. Then at least I did not have a negative score and at times I even hit a marble when it happened to be close enough to the middle line. :)

Kind regards

Sunday, September 11, 2016

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.


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.