, , , ,

Leo and I built a simple but fun and pretty cool math game today in Hopscotch. We called it “Divide It”, and you can play it on the Hopscotch platform here.

The game has two players, and each has 5 keys representing the first 5 primes: 2,3,5,7,11 on opposite sides of the screen. Here’s the layout (we didn’t take enormous care placing things, so it looks slightly random — future detailing):


The number in the middle (28 on this round) is falling slowly — which you can’t see, but below you’ll see it at various states of progress. As the instruction text says: Each time one player or the other clicks on one of their keys, the number in the middle is divided by the number clicked. (The instruction text vanishes after 10 seconds.) Also, the player who clicked the divisor gets 5 points added to his or her score. (The scores, once there are numbers, replace the “Left” and “Right” texts. You’ll see this below.)

In the depicted case, for example, if the left player clicks, say, 2, he (I’ll use he because both Leo and I are guys) will get 5 points added to his score, and the number will be divided by 2, which will make it 14. It continues to fall, and if you were to leave it at 14, when it hits the red target, BOTH players will get 14 subtracted from their scores. But if the players continue to divide the number, say by 7 leaving 2, and then by 2, leaving 1, then the round ends and BOTH players get 50 points.

Here are the game in slightly later stages of a different round. The initial value was 147:


Looks like the left player clicked 7, which divided the number by 7, to make it 21, and the left player got 5 points:


The round would continue, either with a 3 and a 7, in which case both players would get 50 points (and the players who clicked the 3 and 7 would get 5 for each click), or, of they didn’t get it all the way to 1, and it hit the target, they’d both lose 100 points!

Now, you might well ask: What happens if you choose an uneven divisor, like suppose that instead of a 3 or 7, you clicked 5 for 21, which would end up with  21/5, or 4.2?!

For example (this obviously is a much later round):


Okay, so now the players are hosed! There’s no way to get to 1 by dividing a non-integer by integers. When we originally designed the game, we were going to disallow this, and ding a player who tried to do it by some number of points. Unfortunately, this turned out to be extremely hard to program, because Hopscotch doesn’t have a Truncate function, so it’s actually pretty hard to figure out whether one number is a divisor of another. (You would normally just see if Truncate(N/d)=N/d, which is easy, unless you don’t have a Truncate function!)

We tried to find a satisfactory work-around for this. Turns out that you can actually implement Truncate in Hopscotch by successively subtracting 1, until you reach a number less than 1, which must be the decimal part, and then just subtract that from the original number. This actually works, but it’s way too slow to be useful.

So, we gave in to having decimal numbers. But this turned out to be a blessing in disguise, because it makes the game MUCH more interesting. How so? Well, we added a rule that if the number hits the target at less then 1 — which it must do if you keep dividing over and over), for example:


then BOTH players lose 100 points. So it’s really really bad to over-divide. This rule discourages the players from just randomly clicking numbers to try to divide the value down to 1, because if you end up below, you both get docked 100 points! At the same time, if you do end up making a mistake, as in whatever it was that gave them 10.5, above then the way the rules are encourages you to try to divide it out to just over 1.0, but not below, so that you get dinged the minimum. For example, if these players just left the 10.5 to hit the target, they’d get dinged 10.5, but if they did a 7 division, it would go to 10.5/7, which is 1.5, which is a lot less of a ding. But they have to be careful not to go beyond 1.5 to less than 1, nor could they have used 11 from 10.5, because that would have put them at 10.5/11 = 0.954545…, which, being under 1, would have cost them both 100 points!

So by virtue of not having Truncate available, the game actually got to be much more interesting!

A couple of notes about programming. We wanted to make sure that we never ended up at a prime number, either as the original number, or as a factor >11, which the players wouldn’t be able to make into 1 under any circumstances — that is, there would be no solution (although this is actually made moot by the fractional rules described above, since they could just divide it down as closet to, but above, 1 as they could get). So instead of just picking a random number, we did this complex thing, which creates the initial value by multiplication of 2s, 3s, 5s, 7s, and 11s:


The other thing worth a tiny bit of description is the scoring function, which is slightly interesting (to non-programmers) in that it uses a simplifying interim value (delta):


The above sets Delta according to the scoring rules, and then the latter part of the below actually does the score updating:


(The above two pieces of code go together; I just wasn’t able to put them in the same screenshot; Note that they overlap by a few lines of code.)