...
Show More
Do you have a junior high / high school kid that you want to get interested in programming? Yes? Then stop what you’re doing, download GameMaker (for Windows or Mac), and order this book!
My 13 year old son and I have nearly finished working our way through this book over his summer vacation. All of the examples turn into compelling, fully playable games. While the learning curve will appear to stretch to the horizon, it’s a gentle steady slope, with fun and results at each stage. The majority of the book teaches real programming concepts, but without using traditional code. Code is introduced towards the end of the book, and it used throughout the sequel ‘The Game Maker’s Companion’.
While I wanted him to have immediate success, I also wanted him to encounter and learn to track down bugs, since that’s part of the process. He’s certainly made enough bugs of his own, but we only managed to find two in the book itself (in one case, the book is out of date – p12 shows the old way of handling sprite strips, but a quick check on YouTube showed the new way to do it).
Ready? It's time for my “get off my lawn” rant. :)
I’m 42 now. It was 1984 when I was my son’s age, and 8-bit computers had begun to appear in homes. Back then, writing code was a necessary path to having fun with a computer, where as now, it’s (at least initially) a barrier to fun.
In those days, a nation of code-writing kids helped define the next great industry, and it happened when most adults weren't paying much attention. I was one of ~30 million Commodore 64 owners who knew that the future was somehow tied to the glowing screen before me. My dad spent perhaps more money than he thought justified for a computer that he didn't understand. It didn't help that within minutes of unwrapping, each machine presented a child with merely a blinking prompt. Parents didn’t want toys that generated endless questions.
Some kids wanted their new box to play games, but others wanted to understand it and see what they could create. In the early days, many of the programs (games, budgeting, word processors, etc.) couldn't be "downloaded" or purchased in stores, but rather, were found printed in magazines to be manually typed in. What would be unacceptable tedium today set many of us on the path to programming.
A person could write an entire game by himself, including graphics, sound, joystick input, etc. On a C64, the built-in ROM that handled BASIC was, itself, merely an 8K program (written by Bill Gates in his early 20s). Once you learned machine language, you could read the computer's memory to understand it, and then extend and change its behavior.
The modest graphics, sound, and storage were a playground for boundless, creative novelty. The limitations turned to advantage, since anyone could produce passable sound and graphics for their games. Constraints can inspire greater ingenuity – consider how Bach's two part inventions transcended their dyadic restrictions through divine craftsmanship. It is a maximizing of the expression that can be found in the limited and the discretized, so much so that you forget the limitations. Though the computers were simple, in compensation, the software was all the more clever. Today, those who enjoy chess do so for the engaging possibilities contained in its few rules, not because the latest chess boards could be made to talk or blink.
It was an odd feeling to have technical questions about this new toy that no school teacher or parent could answer. In the early days, most local libraries didn't carry relevant books. The world hadn't caught up with its children yet – an unprecedented phenomenon in human history. Much has changed. There is now, of course, no expectation that end users understand how to program. This is good of course, but the audience has dumbed down. The ingenious puzzles found in games of old have long ceased to be marketable to the increasingly average player. I remember the games -- the dark hallways and where they led, the secrets and how they were concealed. These are real places to me, preserved with the dream-like quality that comes with those memories untouched by an adult outlook.
Children using computers today have an entirely different experience. While the creation of as-of-yet undiscovered computing experiences is unbounded, the barrier to entry is much higher. Modern games are not imagined into being by a single individual, but require a huge development/production staff of specialized skills, and tens of millions to get to market. The ever-increasing sophistication in user experience and the increasing distance from code prevents the kinds of exploratory play that bends a computer to the user's will. In its place are packaged, canned entertainments, designed to be linearly consumed. Through no fault of their own, children understand the 'What', but not the 'How', which means they have to wait on adults to create what is to be 'Next'.
That’s where a book like this can roll back the clock, and bring back the magic that happened in the 80s. On the relatively new indy game scene, the tools (i.e. GameMaker) now exist where a single person can once again handle all of the sound, graphics, and programming. In some ways, it’s even better. Want to add background music? Just add it. No more building assembly language interrupt-based music players. Want to rotate a sprite? Just do it. No more drawing every possible rotation ahead of time. Want to port your games to your iphone or droid? Just do it. With the game making tools and languages that are available, you’re not stuck learning the specifics of each computer and OS type. Where I was learning that POKE 646,0 would turn my C64 cursor black, my son is learning about refactoring code using object hierarchies. That’s a huge improvement in abstraction, no matter what nostalgia whispers into my ear.
The authors don’t really dwell on any of these “get off my lawn” rants, except for a paragraph near the very end of the book: They write, “Twenty years ago every self-respecting computer enthusiast owned a collection of books about programming games for the simple computers of the day. These books usually made the reader type in pages of code, which generally contained a generous helping of typing errors and bugs to work around. If you were lucky, then hours of painstaking labor might eventually be rewarded with the chance to control the letter O as it was chased around the screen by a couple of nasty-looking As. Nonetheless, it was books just like these that inspired us to write this one, because they were responsible for starting us down a path that lead to the game-related careers what we have today.”
My 13 year old son and I have nearly finished working our way through this book over his summer vacation. All of the examples turn into compelling, fully playable games. While the learning curve will appear to stretch to the horizon, it’s a gentle steady slope, with fun and results at each stage. The majority of the book teaches real programming concepts, but without using traditional code. Code is introduced towards the end of the book, and it used throughout the sequel ‘The Game Maker’s Companion’.
While I wanted him to have immediate success, I also wanted him to encounter and learn to track down bugs, since that’s part of the process. He’s certainly made enough bugs of his own, but we only managed to find two in the book itself (in one case, the book is out of date – p12 shows the old way of handling sprite strips, but a quick check on YouTube showed the new way to do it).
Ready? It's time for my “get off my lawn” rant. :)
I’m 42 now. It was 1984 when I was my son’s age, and 8-bit computers had begun to appear in homes. Back then, writing code was a necessary path to having fun with a computer, where as now, it’s (at least initially) a barrier to fun.
In those days, a nation of code-writing kids helped define the next great industry, and it happened when most adults weren't paying much attention. I was one of ~30 million Commodore 64 owners who knew that the future was somehow tied to the glowing screen before me. My dad spent perhaps more money than he thought justified for a computer that he didn't understand. It didn't help that within minutes of unwrapping, each machine presented a child with merely a blinking prompt. Parents didn’t want toys that generated endless questions.
Some kids wanted their new box to play games, but others wanted to understand it and see what they could create. In the early days, many of the programs (games, budgeting, word processors, etc.) couldn't be "downloaded" or purchased in stores, but rather, were found printed in magazines to be manually typed in. What would be unacceptable tedium today set many of us on the path to programming.
A person could write an entire game by himself, including graphics, sound, joystick input, etc. On a C64, the built-in ROM that handled BASIC was, itself, merely an 8K program (written by Bill Gates in his early 20s). Once you learned machine language, you could read the computer's memory to understand it, and then extend and change its behavior.
The modest graphics, sound, and storage were a playground for boundless, creative novelty. The limitations turned to advantage, since anyone could produce passable sound and graphics for their games. Constraints can inspire greater ingenuity – consider how Bach's two part inventions transcended their dyadic restrictions through divine craftsmanship. It is a maximizing of the expression that can be found in the limited and the discretized, so much so that you forget the limitations. Though the computers were simple, in compensation, the software was all the more clever. Today, those who enjoy chess do so for the engaging possibilities contained in its few rules, not because the latest chess boards could be made to talk or blink.
It was an odd feeling to have technical questions about this new toy that no school teacher or parent could answer. In the early days, most local libraries didn't carry relevant books. The world hadn't caught up with its children yet – an unprecedented phenomenon in human history. Much has changed. There is now, of course, no expectation that end users understand how to program. This is good of course, but the audience has dumbed down. The ingenious puzzles found in games of old have long ceased to be marketable to the increasingly average player. I remember the games -- the dark hallways and where they led, the secrets and how they were concealed. These are real places to me, preserved with the dream-like quality that comes with those memories untouched by an adult outlook.
Children using computers today have an entirely different experience. While the creation of as-of-yet undiscovered computing experiences is unbounded, the barrier to entry is much higher. Modern games are not imagined into being by a single individual, but require a huge development/production staff of specialized skills, and tens of millions to get to market. The ever-increasing sophistication in user experience and the increasing distance from code prevents the kinds of exploratory play that bends a computer to the user's will. In its place are packaged, canned entertainments, designed to be linearly consumed. Through no fault of their own, children understand the 'What', but not the 'How', which means they have to wait on adults to create what is to be 'Next'.
That’s where a book like this can roll back the clock, and bring back the magic that happened in the 80s. On the relatively new indy game scene, the tools (i.e. GameMaker) now exist where a single person can once again handle all of the sound, graphics, and programming. In some ways, it’s even better. Want to add background music? Just add it. No more building assembly language interrupt-based music players. Want to rotate a sprite? Just do it. No more drawing every possible rotation ahead of time. Want to port your games to your iphone or droid? Just do it. With the game making tools and languages that are available, you’re not stuck learning the specifics of each computer and OS type. Where I was learning that POKE 646,0 would turn my C64 cursor black, my son is learning about refactoring code using object hierarchies. That’s a huge improvement in abstraction, no matter what nostalgia whispers into my ear.
The authors don’t really dwell on any of these “get off my lawn” rants, except for a paragraph near the very end of the book: They write, “Twenty years ago every self-respecting computer enthusiast owned a collection of books about programming games for the simple computers of the day. These books usually made the reader type in pages of code, which generally contained a generous helping of typing errors and bugs to work around. If you were lucky, then hours of painstaking labor might eventually be rewarded with the chance to control the letter O as it was chased around the screen by a couple of nasty-looking As. Nonetheless, it was books just like these that inspired us to write this one, because they were responsible for starting us down a path that lead to the game-related careers what we have today.”
