Does the game ever halt?
What I'm wondering (seeing this is a c-jump game) is if you can smash the stack and bag the game early.
Hopefully you can buffer overrun and cause other players to execute illogical moves.
Great idea, but not well done. Look at the numbers in the if and switch statements here. The first two cases can't be reached. Doh!
X isn't quite a variable. Take a look through the rules.
I suppose it's easier than having (int)(rnd()*6)+1 all the time...
"Skiing and snowboarding is a perfect programming analogy."
Seriously. Everybody knows it's all about rollerblading.
How does "roll a die and do whatever the game tells you to" qualify as a fun game? Didn't we invent the computer because this type of noncreative rote work sucks and we hate it?
so outsource your dice rolls
Evidently, it has been given high cricicism for its irreverence and inconsistencies.
Where's the danger? A game without danger is no fun at all. A race is all well and good, but what players really want is to avoid going to jail or to score the community chest or pwn the most valuabe properties. Introduce some security concepts. Get kids used to the idea of a buffer overrun (skiing off a cliff?), poor input validation (forged ski ticket?), and other things that can screw up their game. And then how to use those things to screw up the other players. At that point, forget the kids: I want to see computerphobic grandma chortle when she starts wailing on everyone else.
Colonel Mustard ... in the living room ... with the free();
THIS Christmas we have Python & Ladders.
And next Christmas we'll have Ruby-Railway.
Although rumours abound of a direct conversion of C-Jump to Thee-Cars (lisp).
Hungry Hungry Haskell never got out of development, sadly, as it essentially comprised everyone shouting "I win" as quickly as possible and was deemed to lack longterm gameplay interest even in this ADD age. Also, it reminded too many people of playground and family arguments and so would face too much environmental competition on Christmas day.