The programmer of Xonix obviously forgot his Shakespeare:

"Cowards die many times before their death, the valiant never taste of death but once"

It's possible for the hero in Xonix to die twice during one 'step' in the game, if two fatal events occur during that step: e.g. being run into by one of the baddies, and having a path he is making be hit by another baddie. The code at the end of the step just checks if the number of lives left is equal to zero, so the following correction should help:

Xonix>>heroDied

self livesHolder value: self livesHolder value - 1.

self livesHolder value <= 0 ifTrue: [self gameOver]

Comment by anonymous

Weird... I posted the above correction, and either the BottomFeeder comment tool or the Silt server has swapped the last two lines of the method. I still have the comment window open, so I can see that for sure. The ifTrue: block has also lost its square brackets, but that's more understandable: square brackets are the way to denote links, so either the client or server interpreted them as markup. -Steve

Comment by anonymous

The code I wrote is of course complete rubbish: game over would have happened on the first death of that step anyway. Motto of the day: don't cut code when your blood sugar's low. Boy do I wish I'd remained anonymous :-). I actually can't see how your daughter got Xonix into that state - unless of course she chooses "Execute Smalltalk code" and enters "Xonix someInstance livesHolder value: -1". In which case my correction wouldn't be so stupid after all... But as I'm still waiting for the lamb to come out of the oven, my blood sugar's even worse than before, so this is probably wrong too :-).

Lives decrement code in XonixPlugin uses #uiEvent to run the #heartbeat in response to a timeout interrupt (the "real" Xonix uses #uiEventNow). If a game step takes too long, it is possible for another timer tick to happen before the step is over. The rest depends on how window event processing is scheduled by the system. What we see suggests that a newer event may somehow preempt the one currently in progress. If that happened between the two lines of #heroDied, we would indeed see lives drop below zero without triggering the end game.

The good robust fix would be rewriting the heartbeat code to ensure #step isn't reentrant. Since the valiant never taste of death but once, changing instead = to <= in #heroDied seems inelegant.

And of course, the right thing for Jim and his daughter to do when this happened was to go and buy a lottery ticket. Too late now, I'm afraid.