Gazing at the Star

Just something hilarious I stumbled across.

enum {
NO_CLEANUP,
CLEANUP1,
CLEANUP2,
CLEANUP3
} cleanup_mode = NO_CLEANUP;
bool done = false;
while (!done) {
switch (cleanup_mode) {
case NO_CLEANUP:
// Build Step One
…
if (failure_condition_one) {
cleanup_mode = CLEANUP1;
continue;
}
// Build Step Two
…
if (failure_condition_two) {
cleanup_mode = CLEANUP2;
continue;
}
// Build Step Three
…
if (failure_condition_three) {
cleanup_mode = CLEANUP3;
continue;
}
break;
case CLEANUP3:
…
case CLEANUP2:
…
case CLEANUP1:
…
done = true;
}
}

(and if anyone can tell me how to make the formatting work, it’ll look nicer, too)

Note that I am still looking for a better turn of phrase that is both succinct and easy to say, while still getting the message across without too much additional explanation. It is the additional explanation bit where I feel the current wording is lacking. “What you see is what you get.” See? Needs explanation before you know what it really means.

What I’m trying to say with this law of game design is that if the game looks right, then it is right, and vice versa, regardless of what is going on behind the scenes. It doesn’t matter how closely your physics code matches the real-world equations, if it looks like the ball is falling too fast, then you need to change the code. Conversely, if the game appears to be running correctly, then it doesn’t matter that behind the scenes is a mess of spaghetti, and spending time correcting it, if there is no visible lag or slowdown, is time wasted.