Slashdot Mirror

← Back to Stories (view on slashdot.org)

Learning to Code with a Boardgame

Posted by Zonk on from the learn-fun-not-hard dept.

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.'"

13 of 204 comments (clear)

  1. Solitaire Encryption Algorithm by Danta · · Score: 2, Interesting

    If you find this interesting you might be interested in Bruce Schneier's Solitaire Encryption Algorithm, a real encryption algorithm using a deck of cards.

  2. Re:Actual squares from the game by Anonymous Coward · · Score: 1, Interesting

    "makes more than you as a plumber "

    This happened to me in real life. The plumbers and carpenters make 50% more and they get paid overtime. Which of course nobody in IT gets.

  3. Robot Odyssey by willy_me · · Score: 3, Interesting

    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.

    1. Re:Robot Odyssey by moofrank · · Score: 2, Interesting

      Actually, this is how I learned logic fundamentals. The game itself teaches the basics of digital design including the core gates, AND, OR, flip-flops, as well as timing and delay issues. The game is pretty hard considering the intended audience, with some of the final puzzles requiring having three robots zipping around a room, sending signals to each other to keep their moves in sync. Best educational game ever.

    2. Re:Robot Odyssey by Anonymous Coward · · Score: 1, Interesting

      Robot Odyssey was a GREAT game and so educational! And even before I played Robot Odyssey, I played Rocky's Boots. That one was kind of like a MUCH simpler version of R.O. much more focused on basic logic (AND-gates, etc.) than construction, and more younger-kid-oriented.

      It would be great if somebody updated these games into a modern form for kids today. It's hard to keep a modern kid's attention on a 4 color "HGR" screen.

  4. Re:Robo Rally by Yazeran · · Score: 2, Interesting

    Yep.. :-)

    Personally i think that Robo Rally is best with a group ov nerds and a crate of beer, but seriously, I can see that it could actually be used for educational purpose for kids, as there is a degree of exitement in the game (will i get to xxx without getting more shot up so i can repair?).
        At the same time educate something about the strict logical rules of programming (that a computer will do *precicely* what you programmed it to do without any consideration about the surroundings or change in the conditions the programmer did not anticipate) in a fun way (as learning it the hard way in front of a real computer can be quite fustrating as we all know...).

    Yours Yazeran

    Plan: to go to Mars one day with a hammer

  5. It's been done before: PLATO IV by sakusha · · Score: 3, Interesting

    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.

  6. Re:Bad Design by TheRaven64 · · Score: 4, Interesting
    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.

    --
    I am TheRaven on Soylent News
  7. Mindrover by p_conrad · · Score: 2, Interesting

    This looks really basic, and why skiing?

    If you really want a kid to dive into programming, I'd think Mindrover is a better choice. It's got programming, simulated physics, simulated electronics and competition that doesn't involve a roll of the dice.

    I don't see how the c-Jump game would ever teach the trial and error aspects of coding. In Mindrover, you code better to win, and get to see a lot of hilarious faliures as you learn.

  8. This goes back to the PDP-11 or earlier by Urusai · · Score: 2, Interesting

    Stacks were done with something like:
        POP x = *(p++)
        PUSH *(--p) = x
    since stacks grew downward. With this method, p == 0 means empty stack, which is nice.

    The only reason ++x might be faster than x++ is that no "temp" register is needed to store the unincremented original value. The two forms are NOT semantically equivalent, unless you are ignoring the return value. Any half-smart compiler would not allocate a temp register for an unused value.

    And that's all, folks.

  9. Re:Games that teach computer logic by Jim+Hall · · Score: 3, Interesting

    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.

  10. Don't forget ZZT by eieken · · Score: 2, Interesting

    It is a great little adventure game I played when I was a kid that helped me learn programming concepts. You can design your own levels and program little objects to do whatever you say. It was kinda like programmable Rogue. You could use the ZZT programming language to make the little objects do all kinds of neat stuff, very fun to play too. See it here

    --
    Meet new people, and kill them.
  11. Re:Bad Design by elronxenu · · Score: 3, Interesting
    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.