I began a new project to create a mathematics game for elementary school students to develop estimation skills. The inspiration for this game came a few weeks ago as I was getting ready to teach a class in our doctoral design thinking course. I had dusted off an old Apple IIe computer that I had in my office to show to the class. I thought they might find it interesting to see what was the state-of-the-art technology around 1983 or so.
I had two goals. The first was just to have the class get a good sense of the design of the machine's interface design (e.g., keyboard entry only and no internet) and the state of graphics and text. The second was to show the class some computer games I had designed back when I was an elementary school teacher to see if they agreed that the design of the games - however old - was still good. As I like to say, "good design, like good music, stands the test of time." Back in the early 1980s I taught myself how to program the Apple IIe using the BASIC programming language (which was built-in to the IIe). I had programmed a bunch of games and simulations to help my students learn and enjoy some vexxing ideas, such as fractions - the bane of all 4th or 5th graders. I showed the original version of Mineshaft, a game to learn fractions. Mineshaft remains probably the best educational game I've ever designed.
Another game I demonstrated was one I had forgotten about. It was called "Estimation Baseball." (I had mentioned this game in a post way back in December 2016 when I was taking inventory of my career's design work up to that time.) As the name suggests, the game used a baseball theme for two players. The computer would "pitch" a difficult math problem, such as 983 X 317, and the student had to about 10 seconds to enter their best guess as to the answer. The computer would beep every 3 or so seconds (akin to strikes). If no estimation was entered, the student "struck out." Estimations that were way off resulted in "ground outs" or "fly outs." However, the player could hit singles, doubles, triples, or home runs if their estimation was good - it all depended on how good the estimation was. I don't remember the cut-offs for the estimations, but it was something like 95% accuracy for a home run, 85% for a triple, etc. I remember the students really enjoying the game. Students had no time to to work out the exact answer, so a math problem like 983 X 317 needed to be quickly transformed into something like 1000 X 300, or 300,000, which is about 96% accurate resulting in a home run. I also built different "leagues" into the game for different skill levels, from "little league" to "hall of fame." Estimation games, like this, get away from the stress and drudgery of finding the one and only one correct answer and instead have students really explore and discover mathematics in their own way,
Initial Design of the Race Car Estimation Game
I continue to this day to think that estimation remains a very important math skill. (How quickly can you come up with 20ish% tip on that restaurant bill?) I decided to build a new version of Estimation Baseball using LiveCode. But, instead of baseball I thought I'd use a race car theme for the game. (I've learned that there are a lot of people who really don't care for baseball and don't know the rules.) My idea is two players compete by moving their race cars forward by estimating math problems. The better the estimate, the further the race car will go.
It's been awhile since I last blogged about the development of a LiveCode project over time and I thought this would be a good candidate. So far, I've spent only about two hours on the project. Here's a screen snapshot of the first rough prototype:
The field "data" on the left (labeled as "Testing Data" on the screen) is temporary - it provides me with quick feedback on whether the underlying variables are being computed correctly. The first number in each row shows the horizontal position of the car on the race track, which is numbered from 0-100. The next two numbers show the x,y position of the car on the screen.
The button "Opencard" does just that - it opens the card, which restarts the game from the very beginning.
I actually made a lot of progress in a very short time. So far, only one of the race cars moves, but it does so based on the accuracy of the estimation to a math problem. For testing purposes, I'm using very simple multiplication problems where each number (the "multiplier" and the “multiplicand," to be exact) is a random number between 1 and 10. Actually, I've just been using 10 X 10 for my testing so far to make it easy for me to troubleshoot the algorithms I've programmed.
Looking at the Code
The majority of the code is in the button "Next Lap." However, there is also some code in the card script to initialize the various game variables and empties any fields on the screen:
1: on opencard
2:
3: global varCar1x, varCar2x, varNum1range, varNum2range, varNum1, varNum2, varLap1, varLap2, varLap3
4:
5: put empty into field "percent field"
6: put empty into field "num1 field"
7: put empty into field "num2 field"
8: put empty into field "answer field"
9: put 10 into varNum1range
10: put 10 into varNum2range
11:
12: put 0 into varCar1x
13: put 0 into varCar2x
14:
15: set the location of button "car1" to 100,70
16:
17: put 20 into varLap1
18: put 10 into varLap2
19: put 5 into varLap3
20:
21: put empty into field "data"
22:
23: end opencard
Here's the code in the button "Next Lap:"
1: global varCar1x, varCar2x, varNum1range, varNum2range, varNum1, varNum2, varLap1, varLap2, varLap3
2:
3: on mouseup
4:
5: //reset fields
6: put empty into field "num1 field"
7: put empty into field "num2 field"
8: put empty into field "answer field"
9: put empty into field "percent field"
10:
11: //put random(varNum1range) into varNum1 - I'll activate this after all testing is done
12: //put random(varNum2range) into varNum2 - I'll activate this after all testing is done
13: put 10 into varNum1 //I'll delete this and next line after all testing is done
14: put 10 into varNum2
15:
16: put varNum1 into field "num1 field"
17: put varNum2 into field "num2 field"
18:
19: put varNum1 * varNum2 into varAnswer
20: Ask "what is the answer?"
21: put it into varResponse
22: put varResponse into field "answer field"
23:
24: //compute absolute percentage of correct answer
25: put abs(varAnswer-varResponse) into varDistance
26: put varAnswer-varDistance into varDistance2
27: put round((varDistance2/varAnswer),2) into varPercent
28: put varPercent into field "percent field"
29:
30: //put varCar1x into message
31: if varPercent>=.95 then put varLap1+varCar1x into varCar1x
32: if varPercent>=.80 and varPercent<.95 then put varLap2+varCar1x into varCar1x
33: if varPercent>=.75 and varPercent<.80 then put varLap3+varCar1x into varCar1x
34:
35: //move the race car
36: move button "car1" to ((varCar1x*8)+100),70 in 2 seconds
37:
38: //show the key data to help with troubleshooting (to be deleted later)
39: put varCar1x&comma&location of button "car1"&return after field "data"
40:
41: end mouseup
For now, I'm using the convenient "Ask" command to get the student's estimation answer, shown in line 20. I'll change that later to an input field on the screen.
Lines 31-33 show the code to determine the percentage correct of the student's estimation. For now, I'm using the cutoffs of 95%, 80%, and 75%. These may change as I need to tweak the game play in future versions. Notice lines 17-19 in the card script above. These determine just how far the car will go for each percentage - right now these are 20, 10, and 5. I also expect these to change as the game design progresses.
Final Thoughts
I'm optimistic that elementary school students will find this to be a fun game. I think it's a good example of embedding mathematics into game play, in contrast with the common strategy of sugarcoating mathematics with a game context.
No comments:
Post a Comment