PDF of Gardner's Scientific American article on HEXAPAWN.
https://people.csail.mit.edu/brooks/idocs/GardnerHexapawn.pd...
Solving a Childhood Mystery: How BASIC Games Learned to Win
21–30 of 30 posts
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#22Ah, the memories of inputting listings from magazines and books like these, only to find that I’d have one character wrong and the whole thing would fail (and I didn’t know enough to fix it). The vibe coding of its day! :D
Using Norton Utilities 1.0's hex editor to read and change save files for Moria :)
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#23Earlier quoted context omitted.
Yeah Scratch has a lot of limitations - but as an introduction to the concepts, it has been amazing. Watching him be able to build a game that he enjoyed on day one, then by maybe 6 lessons later to be using Python - has been great. I'm not a coder so it is not something I could help with (I play with Arduino etc. but I don't know python). But getting the early simple lessons to explain how changing variables affects…
You can learn a lot from Scratch, that's for sure. I'm not saying it's bad , it's actually a decent learning tool. But I think it's a step back from BASIC. You could code a ton of fairly decent games, utilities and even full applications in BASIC. While that's theoretically possible in Scratch, it's a lot more cumbersome. Scratch feels more like a puzzle game than a real programming language. BASIC, especially the la…
Scratch is good for immediate feedback. I mentored some middle school students last year that learned Scratch in elementary. They've graduated to JavaScript and Python now. They built a bunch of simple—and super fun—games for a school project. Notepad.exe and a browser :)
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#24Earlier quoted context omitted.
I would have previously agreed (that there is nothing quite like it these days) - but my son is now part of an online games coding club. They start off assembling ready made 'Scratch' instructions, and playing at tweaking them. In later lessons they then start to write their own Scratch recipes, before moving to Python libraries then writing Python directly. So far I've been really impressed with the materials, then…
Forgive me, but I don't think scratch is all that good - my son did it too. I never liked these super simplified approaches to computing because I don't think they are necessary. Scratch wouldnt be that useful in the 80s. BASIC, despite its flaws, was both simple and powerful. You could code in the same language as many pros from the get go.
Then you should check out Snap!, which is like Scratch without any of the limitations, essentially a visual programming language with the full power of Scheme.
Snap! 5 is here (snap.berkeley.edu):
https://news.ycombinator.com/item?id=20309162
>One of the coolest ways to learn programming I've ever seen is the Snap! visual programming language, which is written in JavaScript and runs in the browser. https://snap.berkeley.edu
>It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.
>Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).
https://news.ycombinator.com/item?id=18497883
>Alan Kay wrote some interesting stuff about some of the inspirations for "Tile-" and "Block-Based Programming", like "Thinkin' Things", in a discussion about the Snap! visual programming language! https://snap.berkeley.edu
>From: Alan Kay Date: Thu, 3 May 2018 07:49:16 +0000 (UTC) Subject: Re: Blocky + Micropolis = Blockropolis! ;)
>Yes, all of these "blocks" editors sprouted from the original one I designed for Etoys* more than 20 years ago now -- most of the followup was by way of Jens Moenig -- who did SNAP. You can see Etoys demoed on the OLPC in my 2007 TED talk.
>I'd advise coming up with a special kid's oriented language for your SimCity/Metropolis system and then render it in "blocks".
>Cheers
>Alan
https://news.ycombinator.com/item?id=38016554
>I'm also a huge fan of Snap!, which has all the advantages of Logo (Lisp without parenthesis) and Scratch / eToys / Squeak / App Inventor family of block based visual programming languages, but all the power of Scheme.
>If you know Scheme, then it's easy to think about Snap!: it's just Scheme with a visual block syntax, but with some functions renamed to make them easier to learn, plus all the stage and turtle graphics stuff from Scratch, running in a web browser!
>I didn't realize until watching in amazement as Jens Mönig used his own creation, that it also has full keyboard support, so you can create and edit programs without using the mouse!
>It's much easier to teach Scheme to kids by teaching them Snap!, because the user interface is so much better than a text editor.
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#25Earlier quoted context omitted.
OK, that makes sense - the game has a better playability if it starts on an average level and "learns" over time.
No, that's not why. The comment you're replying to gave a different reason that it was done that way. That comment explained, twice, that it's not merely, or even primarily, to improve the game's playability; it was to serve as an executable demonstration of the matchbox learning algorithm. The blog post explained that the game derived from Martin Gardner's popularization of Donald Michie's work on the algorithm. The…
> Martin Gardner's popularization of Donald Michie's work on the algorithm.
I remember reading this, but for the life of me I can't recall what the title of the book was. ISTR it also had a chapter exploring multi-dimensional spaces, in particular the problem of packing hyperspheres into hypercubes.
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#26Earlier quoted context omitted.
No, that's not why. The comment you're replying to gave a different reason that it was done that way. That comment explained, twice, that it's not merely, or even primarily, to improve the game's playability; it was to serve as an executable demonstration of the matchbox learning algorithm. The blog post explained that the game derived from Martin Gardner's popularization of Donald Michie's work on the algorithm. The…
> Martin Gardner's popularization of Donald Michie's work on the algorithm. I remember reading this, but for the life of me I can't recall what the title of the book was. ISTR it also had a chapter exploring multi-dimensional spaces, in particular the problem of packing hyperspheres into hypercubes.
I can't keep his book titles straight.
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#27The 1970s saw the birth of many foundational algorithms and concepts in machine learning, with research focusing on decision tree algorithms, clustering, and ensemble methods. I believe one of the first decision tree algorithms was created in 1973, crazy how early it all started!
In the 80's I apprenticed under a greybeard programmer who gave me all the shitty network code to write, while he experimented with neural networks instead of writing "old school" error correction logic for said network code.
I'm grateful for his bikeshedding, because it made me a network programmer and led to a fine career building Internet service providers, but I'll never forget his frustration .. "the computer is simply not big enough, we need to build a bigger computer" .. I wonder where he is these days. Hopefully retired.
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#28this makes me want to rewrite the unbeatable tic tac toe algorithm I wrote back in high school so that instead of starting optimized it just walks through potential game states and eliminates them as it loses.
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#29So basically it has a table of all possible moves, and after losing a game, it deletes a move that led to the defeat? Then why not simply have a smaller table of moves right from the start, with losing moves already removed?
[deleted]
Re: Solving a Childhood Mystery: How BASIC Games Learned to Win
#30Earlier quoted context omitted.
I would have previously agreed (that there is nothing quite like it these days) - but my son is now part of an online games coding club. They start off assembling ready made 'Scratch' instructions, and playing at tweaking them. In later lessons they then start to write their own Scratch recipes, before moving to Python libraries then writing Python directly. So far I've been really impressed with the materials, then…
Forgive me, but I don't think scratch is all that good - my son did it too. I never liked these super simplified approaches to computing because I don't think they are necessary. Scratch wouldnt be that useful in the 80s. BASIC, despite its flaws, was both simple and powerful. You could code in the same language as many pros from the get go.
"You can code in the same language as the pros" is a huge selling point. If you're a kid using a computer, you've seen off-the-shelf software and that's probably your inspiration. You want to be able to make standalone things that look and work like the ones you've used before, not "it only runs in this sandbox" toys. "Use the cool program I wrote, Dad" hits different when he can run it just like Excel and Firefox.