Learning to Code with a Boardgame

markmcb writes "While some of us cling tight to our memories of Apple-filled classrooms playing The Oregon Trail and driving our Turtle around in Logo, children today have many other ways to learn about the inner-working of computers and the code that drives them. Wired.com is running an interesting article about a boardgame in which players must use simple logic similar to that used in programming to get their skier down the mountain. From the article: 'Using basic math, players have to figure out which paths are open to them and then decide the fastest way to the finish line. The trick, however, is learning which paths are open to you using only programmer jargon like 'if (X==1)' then you can take the green path or 'while (X4) you can take the orange path,' where X is the roll of the die.'"

Comments

Bad Design

[jmlsteele]

I was told to never use a goto...

Re:Bad Design

[TheRaven64]

Those who don't get taught GOSUB have to invent it themselves. I wasn't taught about GOSUB when I first learned to program, so I ended up writing my own. Every time you called GOTO, you wrote your line number into an array and then incremented a variable. When you returned, you copied that line number into a variable, wrote a return value over it, decremented the stack counter and jumped back. Due to the limitations of the language (and, perhaps, my understanding of the language aged 7) you could only store one integer (the return value) on the `stack', and it could only be a maximum of 255 calls deep, but it was a stack. Like early computer designs which stored the return values in the base of the function (which I didn't learn about until 11 years later), it was not capable of recursion.

Some years later, I implemented a pseudo- virtual memory system using a very primitive analogue of mmap on the Psion Series 3. This allowed for arbitrary-length strings - something not possible in the built-in BASIC-like OPL, which used PASCAL-style strings.

My somewhat rambling point? Sometimes it can be better to learn to program in limited settings. If you don't have the tools you need for writing good code, but do have a Turing-complete language, then you end up inventing the tools yourself - and then you understand them much better than anyone who learned simply by being told that they exist.

Re:Bad Design

[elronxenu]

No they won't. You're proposing that people with no formal training and no reference material will independently redevelop recognised programming techniques.

The largest number of people will invent nothing new; they'll just program within the limitations of what they were taught.

A smaller number of people will invent something new, but it will be some kind of kludge. They'll use it everywhere they can. It will be inefficient or inelegant, but they won't notice that.

A very small number of people will invent something new which works well, is efficient and elegant.

My opinion is that if you teach 100 people how to program in BASIC without any mention of GOSUB, then have them solve problems by writing programs, and after a while you check what techniques they use, you will find that 90% of those people are writing spaghetti code with no discernable structure (or maybe only WHILE loops), 8% have implemented the idea of the subroutine by supplying a return address in a fixed location (so recursion is not possible) and the remaining 2% have implemented their own stack and use it to simulate proper recursive subroutines.

There has been much more bad design in the history of computer science than good design. I don't see why the situation we see in the large should not apply to individuals too. Just look at language design. Some recognised (nay, famous) programming languages are awful. You think the people who designed those languages weren't smart?

Just look at Niklaus Wirth - and the botch he made of Pascal's string handling, data structures and control structures. This was a guy who studied and taught computer science.

Take a look at COBOL, if you can stand to. Clearly botched in a number of areas, at least in the 1985 revision which is when I last had to look at it. In areas such as conditional handling, data structures, dynamic memory allocation. COBOL had one good idea, namely statically defining the allowable contents of various data areas, and that's about it.

I can only argue that students should be taught best practices from day one, on the basis that they will most likely never invent those best practices for themselves (98% chance) and could develop bad habits as a result of their stunted education (90% chance).

Case in point - a schoolfriend of mine. He liked to program but he didn't study programming. He came to me once so proud of his invention of a sorting function in BASIC. I checked it out and it was a Bubblesort. I don't recall whether I had the heart to inform him that the bubblesort is possibly the slowest recognised sort algorithm.

Teaching programming to kids is a different kettle of fish. Depending on the age of the kids, introducing subroutines and stacks and recursive data structures may be well beyond their capacity to understand. So for kids, start simple: top to bottom execution, arithmetic, strings, conditionals, while loops. When they're ready for it start to introduce subroutines, data structures, recursion, pre- and post-conditions, invariants, objects, interfaces, inheritance, polymorphism.

Robo Rally

[Speare]

Also try Robo Rally. Of course, this deals with how to program a computer with a VERY limited instruction set, and with damaged hardware. :)

Re:Robo Rally

[jscharla]

With the Armed and Dangerous expansion there are a couple of upgrades that let you do limited run-time branching.

My vote goes with Robo-Rally too. A great game. Total mayhem.

engineering application

[millahtime]

This could have good implications on future engineers. Where I read that the US is falling behind, this could help teach the logic engineers, especially electrical and computer engineers, need to use regularly.

Actual squares from the game

[Radres]

"Job outsourced to India! Go directly to trade school, do not buy a house, do not get laid."

"High school reunion time! The same guy who kicked your ass every day in high school and barely passed wood shop laughs at you because he makes more than you as a plumber while you wasted 4 years at college. Go back 3 spaces."

Why not build a robot??

[technoextreme]

There are fifty differnt robot kits floating about. They are much more entertaining and probably can help people program just as much as a boring board game.

Rules.

[coolGuyZak]

Here are the rules, in case people want to check the game out further.

SkiFree!

[sonixtwo]

Maybe some kid will figure out how to finally get past that damn monster!!

This really is only dimly connected with programs

[UserGoogol]

This is really more of a math game than a programming game per se. Yes, it teaches the concept of conditional branching, but that's not especially new to the world of board games. Also, "x" isn't really a variable, but instead represents the number you rolled, which is different from how programming actually works. (Which is potentially confusing, because c-jump otherwise uses a fairly C-like syntax, with == instead of = and everything.)

Not to say that this isn't a potentially educational game, but this is really more a way to practice doing simple arithematic and logic instead of anything specific to programming itself. (Although arithematic and logic is certainly worth learning.) It would probably lose absolutely nothing in playability or educational value if they removed all C stuff from it and just made it into a silly little math game.

I liked the concept

[leighklotz]

One of my favorite early computer toys was the CARDIAC, the Bell Labs "Cardboard Aid to Computation," and I was hoping that this board game might re-create some of that excitement for today's kids. I liked the concept, but was a little dismayed by the attention to syntax. I'm more of the "Syntactic sugar leads to cancer of the semicolon" school of thought.

I worked on the Logo implementations for the Apple ][ at the MIT Logo lab, and at Terrapin did the Commodore 64 (and other ill-fated Commodore computers), Macintosh. (I also various implementations and translations for Japan, Spain, France, and Germany.)

Looks boring

[LordNimon]

I tried reading the rules, but they're hard to understand just by reading the web page (and yes, I'm a programmer). From what I gather, there are no real decisions that the player makes. That is, you roll the dice and your move is based solely on that dice roll and whatever square you happen to be on.

What would be cooler is if while playing the game, you had to build a "program" of sorts, and you can't win the game until your program produces a specific output. You could then compete against other players for resources needed to finish your program. This would allow you multiple ways to win based mostly on your ability to understand programming concepts.

I see this game as a cool idea, but it's really just a first step.

Robot Odyssey

[willy_me]

This was a great little Apple IIe style game that I enjoyed in elementary school. Looking back, I now see that it taught basic electronics and logic. It was lots of fun at the time. More info can be found here.

It's been done before: PLATO IV

[sakusha]

I remember seeing a similar theme a long LONG time ago, back when I was a little kid about 12 years old, when I wheedled access to the local university PLATO IV terminal.

The scenario was a little oval track with a train that went around and around, the computer randomly generated 3 numbers, and you would type in an algebraic expression to get the number of spaces you would move. You could go for the longest distance, or you could try to hit special squares, like bonus multiplers, or you could try to land on the computer opponent's train which would send him backwards. I was a pretty young kid back then, but I do recall it really made me think hard about algebra, and it was a lot of fun.

PLATO IV had another educational game I really liked, I think it was MoonWars or something like that. You could play live against online opponents too. You had a screen with a random placement of circles (representing craters, I guess). Then you and your opponent were placed on the playing field. You played in alternating turns, you could either shoot a laser at your opponent, or move. The laser would bounce off the sides of the screen, only stopping when it hit the opponent or a crater. Sometimes if you had a clear field, you could use angles really close to perpendicular or horizontal, yielding crazy shots that went back and forth dozens of times. But mostly you just tried to bank shots off the sides, trying to home in to the opponent until they chickened out and moved. The educational content was pretty good, obviously you learned that angle of incidence = angle of reflection, but it also allowed you to input your shot's angle in algebraic notation, in degrees or radians. I immediately realized it was a lot faster to do algebraic notations in radians.

PLATO IV really was a groundbreaking platform for educational games, someone ought to revive some of their old classics. I made a couple of feeble attempts to write a MoonWars clone but I never got anywhere.

Games that teach computer logic

[g_adams27]

For learning the basics of AND, OR, XOR and NOT logic, along with building basic circuits, you just can't do any better than Robot Odyssey. This is probably the greatest educational game I ever played as a young teenager. I trace my interest in studying, and then making a career out of computer science largely back to this game.

For slightly younger people, there's Rocky's Boots made by the same people (The Learning Company). It teaches a lot of the same things, but in an easier (and cuter) style.

All you need is an Apple II emulator like AppleWin and you're all set!

Re:Games that teach computer logic

[Jim Hall]

You may also be interested in GNU Robots. I wrote this several years ago, but stopped working on it in 2000 (it was complete, though.) The GNU Savannah site still lists me as project owner, but zeenix now does the development. He last checked in changes 2 weeks ago, so looks like it's still active.

I wrote GNU Robots because I had fond memories of the old Mac game, Chipwits. In Chipwits, you construct a "program" for a simple robot by setting down "tiles" or "chips" in a grid, where each "chip" contained a single action (check the space ahead of you, pick up an object, turn, move forward, etc.) There were T/F "chips" to make checks. Each "chip" was wired to the chips around it. This was a gentle introduction to the concepts of computer programming. I was already a programmer of sorts, but I found the game fascinating.

GNU Robots is a much simpler version of that, but (in theory) should be extensible to something like Chipwits. A robot program is written in Scheme, where you have functions available to make the robot turn, move, etc. You might be able to construct a programmer's GUI to set up a "tile" for each action, where each "tile" can be represented by Scheme code. And the wired connections to each "tile" can be represented by tail-recursion. I lacked the GUI programming knowledge to create this at the time, which is why I left it as a simple Scheme program. (If anyone out there is interested in doing this, many people will thank you for it.)

FYI: the Chipwits home page shows it as "coming soon" since 1999. So there's no hope in a return of the original.

Fun Game - ACTUAL PROGRAMMING

[Jack9]

Changed a bit since it was being beta tested in 1996 and even more difficult getting 3 other programmer kids to play...

http://www.sierramadregames.com/smg/robotanks.html

They're reissuing it [O frabjous day!]

[Dr. Photo]

I thought of (and googled for) Robo Rally too when I saw the article, and it appears that they've reissued the game, which had been most lamentably out of print for 4 or 5 years.

Still costs around 50 bucks, but IMO definitely worth it.

http://www.wizards.com/roborally/