Automatic manual

December 20th, 2010

One of the goals I have in mind is a learnable programming system that takes advantage of gaming’s greatest strengths. I hinted at these in an earlier discussion of The Incredible Machine. Chief among these strengths is the unique combination of automatically enforced rules and freedom. While you have rules and freedom at play in any design activity, the freedom often comes with a cost (material, risk, etc.), and requires you to enforce the rules yourself. The physical world has some nice rules enforced for you, and indeed much play and games happen there, but often the situations are so complex that the rules boil down to chaos, and the real world carries real risks for experimentation.

But with a video game, you can attempt to do anything, constrained by enforced rules, with no real risk. What’s more, in a good game the rules are designed in such a way that they are apparent. The mechanics of jumping in a platformer are fairly complicated, and no manual will give you all of these details. However, through play, the player finds what is and is not possible, and gets an intuitive feel for how the jumping system works. If the designer has done his job well, this intuition will accurate and useful. Even if one did write out in a game’s manual precisely how jumping works, this would still only be meaningful to a programmer with some physics background, who is skilled in translating between conceptual systems and written procedures. The procedure of jumping is something best communicated by jumping, and a platformer is a game designed to get you to jump in as many different scenarios as possible.

Moreover, a platformer gives you not only opportunities to jump up stairs, over pits, while running full tilt, onto small platforms, onto platforms directly overhead, into bricks, into enemies, and into thin air, but it provides attractions to draw you towards these. The coins in Super Mario Bros individually don’t serve much purpose in gameplay, but they each indicate somewhere you can get to. These provide local goals for you to shoot for, to push you to greater lengths than you would need to progress through the level. And as obvious as it is, the overall structure of the level itself (keep moving right) provides the primary reason to exercise these skills at all. If you just provided a level with no goal, but all the same physics, only the most dedicated would exercise it to its fullest potential. The overarching goal plays a similar role to the game’s laws of physics; it provides a rule which creates a structure to play within.

Once the player has a goal in mind, he attempts to reach it using the skills he has. Perhaps he fails to achieve it. With jumping, it is immediately obvious that the player has failed. What’s more, it is completely obvious how he failed. I jumped too far. I didn’t jump far enough. I hit a block and bounced into the pit. And although this isn’t universally true (video games have a history of masochism back to the arcades), you ought to be able to try again. Ideally you will come to learn the variables that impact performance, and build a set of debugging tools. I didn’t jump far enough: did I jump too soon, or I wasn’t I running fast enough, or did I not hold the button long enough?

Are these benefits necessarily restricted to such simple, “physical” situations? I apologize for using Super Mario Bros. as my one example, but even its impossible physics model is made from cartoonish exaggerations of real physics. The big constants are 2D space, collisions, velocity, and acceleration (including gravity). I suppose these arguments can apply to Sim City, though the written manual is a more important part of the experience there. The more abstract, essentially mathematical worlds of RPGs also exhibit these properties.

Still, the best examples I can think of all involve physical puzzles. Tetris is the prototype, of course, and I have sunk more hours into it than any other 5 games. Braid and Portal are two standouts in recent memory. I am anxiously awaiting Marc ten Bosch’s Miegakure; it promises to do for four dimensional space what Portal did for discontinuous space. In my brief time playing it at PAX East I became convinced that it can use 3D platforming as the wedge to make 4D intuition possible.

Does this indicate that we need to use a physical model of computation? For the advantages I indicate here, we want players to be able to explore a space on their way to a goal we set. The easiest solution is to make the “space” and “goal” physical analogs, to borrow as much from physical intuition as possible.

A model education

December 19th, 2010

Using computers to teach has a long and storied history. The most obvious approach is to use the computer as you would in any other setting, to automate the routine tasks. This is where the venerable Scantron comes into being. A further step is to have the computer administer tests and drills completely automatically. Electronically providing material which would ordinarily be handled in lecture, or in a textbook, is the next step. But while these are all more or less effective ways of replacing parts of the classroom, they do not handle the actual teaching aspect. Spoonfeeding presentations doesn’t suffice, either. The teacher must be able to make good guesses at what is going on in the learner’s head, test these guesses with exercises, and handle questions. This is where artificial intelligence and cognitive science research comes into play, in the form of a field called intelligent tutoring systems. Using models of learning processes, these systems plan lessons and provide interactive exercises tailored to the individual.

I will not go into much detail today about specifics, in part because I am not terribly well read on the topic, and also I just finished up my Ludum Dare entry so I’m quite tired. I do want to point out an interesting angle here for programming games. I initially got interested in learning models for the purpose of planning lessons for a game, but I eventually realized that the models themselves are interesting fodder for gameplay. We might present an automated agent, which learns through the mechanisms of an EPAM, SOAR, or Cascade, and require the player to teach the agent to perform some task. This would be accomplished through the creation of lessons and environments for the agent to interact with and learn from. In order to do so, the player would need to be able to deconstruct his own understanding of the task, and think of how to build up an algorithm in the “mind” of the agent.

There are obvious parallels to programming. This method also invites a self-reflective look at the player’s own learning mechanisms, and the process of education in general. The unfortunate truth is, however, that these models can get messy quickly. Perhaps a model designed with less emphasis on descriptive power can provide a clearer tool for learning about learning.

Magical programming

December 18th, 2010

As far back as 2001 I had thought about what it might mean for a game to have a “magic programming” system, where spells would be programs that interact with the world.  I’ve since encountered the concept in many different contexts, a few examples:

  • Rick Cook‘s Wizard’s Bane centers around a systems programmer transported to a fantasy world, who builds up a powerful system for constructing magic spells along the lines of Forth.
  • In True Names, Vernor Vinge builds the predecessor to Gibson’s cyberspace as a fantasy world; in this metaphorical virtual world the closest analog to programming is sorcery.
  • There is precedent in the magic system of true names and words of power which make up Ursula Le Guin’s Earthsea, drawing on older traditions, indeed Vinge credits Le Guin in his introduction.
  • Jack Vance’s Dying Earth treats magic as advanced mathematics, complete with formulas named after their discoverers.
  • The textbook Structure and Interpretation of Computer Programs, as well as the accompanying lectures, refer to computer programs as a kind of magic spell, particularly regarding the mystical connotations of a language that can describe itself.

Although magic is a supernatural and arcane system, we get the feeling that people can bring the structuring power of linguistics, mathematics, and programming to bear in order to bend reality to their will.  In essence this makes for a scientific treatment of a magical world, with the magician’s art akin to engineering. Wizard’s Bane describes the protagonist’s efforts in discovering and building his own magic system. Rather than attempting to master the vast, complicated, and error-prone spells that master wizards spend their lives developing, he convinces a reluctant sorceress to teach him a few trivial but reliable spells. He started with a spell to cause a light puff of air, and caused it to be cast automatically and in parallel, creating a strong wind. While this may seem like an obvious step, the system required to make a spell that “runs itself” drew on his knowledge of programming environments, which was totally alien to the traditional spellcasters.

In the realm of games, the SNES RPG Rudra no Hihou implements magic spells not as items to be bought or picked up, but as words that can be typed in and modified to produce various magical effects.  New “root words” for spells are found in in-game books or notes, or in conversations with NPCs, and various suffixes can make the spell more or less powerful, affect one or all enemies, or even change the behavior entirely.  While this is not quite at the level of programming, it is a kind of language, and it is fundamentally different from the common RPG magic system.  Rather than the knowledge of a spell being a property of a character in the game, as are other traits such as intelligence or strength or proficiency with weapons, it becomes a real piece of knowledge that the player can learn, write down, and discover.

As Raph Koster insists, “with games, learning is the drug.” It is universally the case that the player acquires knowledge to help him progress in the game, because a well-designed game provides ample opportunities for learning and requires learning for progression. On this level, making a magic system part of the player’s knowledge is no different from his memory of the layout of a level, or the peculiar physics of rocket jumping. The difference comes in considering the magic as a language, a system that can be used to construct new and elaborate conceptual structures.

Contrast a magic programming system to the idea of cheat codes, which have a similar “knowledge is power” property. Cheat codes are entered as a series of symbols, so there is a superficial similarity, and they may be discovered in-game. Yet the symbols that make up cheat codes do not make up a language, you cannot write new things with them, and studying them does not reveal a grammar. Cheat codes are not a “productive” system, as described in this passage from Thomas W. Malone’s “What Makes Things Fun to Learn“:

The productive principle suggests that learning is more efficient in environments that are structured in such a way that students can make deductive inferences or probable inferences about parts of the environment that they have not yet observed.  …  the periodic table is a more “productive” way of arranging information about chemical elements than alphabetical order would be, and phonetic alphabets are more “productive” than ideographic writing systems like Chinese. (p 7)

Limited as Rudra no Hihou’s magic system is, it has the fantastic property of allowing you to learn the rules of the system, so as to generate new spells.  Indeed it encourages this in several ways:  As soon as a spell is entered in the spellbook, the game reports what the spell will do.  Tips are given throughout the game in the form of “try adding this suffix”, clarifying how the components fit together.  It does not go quite as far as I would like, however: it tries to keep the magic system somewhat mysterious, magic is but one corner of a much larger game, and it is necessary to write things on paper in order to work out and maintain a large library of spells.

Returning to cheat codes, my analysis above is incomplete, because in certain cases cheat codes are very strongly productive.  If the codes are present as strings in the game’s executable, then searching for one known string may identify other codes stored nearby.  If one is capable of reverse engineering a game to identify a cheat code subsystem, that knowledge can be applied to other games as well.  This is to say nothing of systems such as the Game Genie or Action Replay, wherein the codes do actually function as a language, and they can provide deep insight into the game structure.

Consider a fantasy game in which the game world is written in the language of magic, in an echo of the Earthsea myth.  In accomplishing tasks in the game world, the player learns magic spells.  A productive language allows the player to use this knowledge to deduce new spells, but also to learn more about the structure of the world.  This can allow him to open new paths, and peer into the systems we build for him to explore.

A Symmetriad

December 17th, 2010

The most powerful image which stuck with me from Stanislaw Lem’s Solaris (which I read in Joanna Kilmartin and Steve Cox’s much-maligned translation) was that of the “symmetriad”. Solaris is an extraterrestrial planet covered by what is apparently an intelligent, yet entirely alien, ocean. Many pages are spent discussing the phenomena which the ocean exhibits, and the frustration of earthly science to make any sort of sense of it. Here is an evocative part of the evolution of a symmetriad (pp. 127-128):

The symmetriad now begins to display its most exotic characteristic–the property of ‘illustrating,’ sometimes contradicting, various laws of physics. … The interior of the symmetriad becomes a factory for the production of ‘monumental machines,’ as these constructs are sometimes called, although they resemble no machine which it is within the power of mankind to build: the designation is applied because all this activity has finite ends, and is therefore in some sense ‘mechanical.’ …

It would be only natural, clearly, to suppose that the symmetriad is a ‘computer’ of the living ocean, performing calculations for a purpose that we are not able to grasp. … The hypothesis was a tempting one, but it proved impossible to sustain the concept that the living ocean examined problems of matter, the cosmos and existence through the medium of titanic eruptions, in which every particle had an indispensable function as a controlled element in an analytical system of infinite purity.

Quickly as the book dismisses the concept, I read a lot into it. The way in which the symmetriad is accompanied by “local changes in gravitation”, among other oddities, suggest that through this immensely complicated structure, the ocean is able to manifest physical effects far beyond the symmetriad itself. The “ghosts” which are a major aspect of the story seem to be generated in this way, and the same holds for the impossible orbit that the planet keeps around its binary star. I would like to consider the idea of a “physical” computer in a game, which embodies some aspect of the rules.

Recall that my initial idea was to have the game system written in the same language which the player uses to interact with it. At the time I was thinking of a textual programming language, likely something along the lines of Forth for the benefit of its minimal syntax. But consider if the game has the typical adventure game interface, such as in an early top-down Zelda. The interface there is walking about, which lets the player indicate positions and paths. The game world provides other objects and enemies that also run their own computations according to some program. Now imagine that these programs are represented by physical systems elsewhere in the game world. This could take various forms: it might be somewhere near or distant in the same “physical” world, it may be on some higher plane, or we might have a tower wherein Floor 1 contains mechanisms used on Floor 2 and so on up.

The player might be able to manipulate these physical computers to modify the behavior of various enemies or game systems. He might further be able to create his own programs by placing objects, or moving through mazes, which would manifest as a physical effect elsewhere in the world according to the same system. This somewhat models real world computer systems, where computational devices are built up of intricately arranged physical objects. Decoupling these in space, and allowing physical manifestation, is more of a magical effect.

Unfortunately, as compelling as I find this idea, I have yet to come up with any practical examples.

Victor

December 16th, 2010

This is one of those ideas that is too clever for its own good, but it is at least slightly amusing.

When you first encounter a 2D game, without reading any instructions, there is a potential for ambiguity. Is this a top-down view or a side view? Are these things walls or floors? This stuff looks like dirt, will the game let me dig into it? On a bus ride between Houston and Austin I came up with the idea of allowing these ambiguities to be resolved depending on the first few moves the player makes. If you indicate you want to go “up”, then the game would assume you want a top-down view, since otherwise you couldn’t have moved in that direction (barring ladders or similar). If you just move “right”, you might be either in top-down or side mode. If you press A while you’re running towards what would be a pit from the side view, the context would suggest that you want A to be the jump button, and the game would assume side view physics from then on. If you press A while next to an enemy, though, then A would forever be the attack button. And so on, the engine would try to create a game consistent with what you appear to be trying to do.

Funny as that idea was, I never came up with any interesting scenarios for it. It did, however, morph into the next stage: a game concept I call Victor. The previous idea would attempt to make any initial input valid, and assumed that interesting play would come out of this, especially once contradictions come about. Victor would strive to make absolutely any input result in some kind of progress, automatically generating an insultingly easy game. I’ve described this as “overbearing DDA“, since the game turns a wrong move (indication that the player’s skill is too low) into a right move, but without the corresponding increase in difficulty if everything is going smoothly. Another angle is to have a built-in walkthrough telling you exactly where to go, perhaps through narration, and correcting itself (and the level layout) when you go the wrong way.

That idea was sort of funny, too, as a one-shot joke about games being too easy or bossy. Loved and You Have To Burn The Rope do this much better than I could ever hope to, though, and I’m sure there are other exemplars I haven’t seen. One way of making it more gamelike would be to allow the player to make a mistake and die, but then the level would be rebuilt to make that kind of death impossible. The goal would be to find every possible way to die in a particular stage. I got about one level out of this approach before giving up on it.

While trying to come up with “inverse level design” mechanisms that build the level around the player, I hit on a strange possibility: What if the algorithm that dynamically generates the level has intentional bugs? If you maneuver just right, you could work the engine into a corner, or catch the game in a contradiction. A contrived example: Consider a top-down viewpoint of your character in the middle of a rectangular room, which is so large that the walls are off-screen. The room is designed, for “dramatic” purposes, so that the door will be in the last wall that you encounter. Now suppose that once you have checked two walls you move diagonally, so that you encounter the last two walls simultaneously. A sufficiently buggy algorithm might show you both of these walls as doorless before it decrements its “walls seen” counter. But now the algorithm is stuck; it can’t put a door anywhere because you have already seen all of the walls. The only thing to do is to invoke a deus ex machina: maybe a door magically appears, or a wall blows up. If we are using a narrator, he may become irritated at his character and skip on to the next part of the story. I consider this a way for the game to admit defeat, and thus this is the only way that the player can meaningfully succeed.

I haven’t made this game for a few reasons. First, it doesn’t have quite the same impact if the player expects the game to be doing these manipulations. Most of the reason to play the game is because of this amusing system, but if I can’t talk about it beforehand I’m unlikely to get many to try it. More importantly, the contrived example above is the best idea I’ve had, and it is really lousy. It would pretty much require the player to read the source code or a walkthrough to figure it out. I also prototyped a platformer that starts with a blank screen; if you fall into a blank space, the game places a platform under you, if you otherwise move into a space it is filled in as background. This was sort of fun to poke at but it was far too easy to break. Many other mechanics never made it out of my notes. I don’t see much hope in ever getting this one off the ground, but at least it was a fun design exercise.

The Programming Contest Problem

December 15th, 2010

Throughout my studies at Rutgers, I participated in the ACM International Collegiate Programming Contest (ICPC from here on). As with many other programming contests, an ICPC event is structured as a set of problem statements, which the teams are required to write programs to solve. The problems range from subtle or not-so-subtle cues to use standard algorithms, to puzzles that would be hard to solve in a week, much less the 5 hours allotted for the contest. Choosing which problems to tackle, and parceling them out to the appropriate team members, is itself a strategic challenge.

Someone unfamiliar with software development might wonder how a handful of judges can examine the programs submitted by dozens of teams. This is of course impossible; it is hard to check code by hand at all, and these hastily-written programs with their obtuse and error-prone algorithms are particularly inscrutable. So rather than doing anything directly with the source code, the program is automatically run by the judging system, which checks the behavior of the program in a number of test cases.

Automated testing has its own pile of problems. Programming errors can cause the program to run forever, or consume all the memory on the system. Malicious programs may attempt to damage the judge’s system, or interfere with the running of other programs. But these are all technical issues, and there are standard ways of dealing with them: programs that run too long are terminated and treated as incorrect, using excessive memory or accessing external resources are restricted by the environment.  The interesting problem, which comes up in real world software testing as well, is how to design the test cases.

When the test suite is assembled, programs can be automatically run with each test case in turn. A tricky point is that some problems may have many valid outputs for a given test case input. If this is true, the judge may need to provide a program to check the answers. Even in non-contest scenarios this can be helpful; it is often the case that a program to check an answer is much simpler than one that can generate the answer, although this is far from universally true. Having a program to check the solution can also allow you to automatically generate test cases, which can allow for much more thorough testing than a hand-generated set of tests. In my experience with the ICPC this was generally not the practice; test cases were usually of the form “input” and “expected output”, and meaningful deviation from the expected output is a failure.

Now to the problem, at least as this relates to learning games. In the ICPC, the judging system does not give you any information about which test cases failed, and indeed most of the test cases are kept secret from the contestants. Partly this is because the contest is meant as an assessment, not a learning exercise, so giving useful feedback is not an intended part of the process (in fact incorrect submissions are explicitly penalized). But the more fundamental limitation is that it is possible to create a program that passes all the test cases without being a general solution to the problem. With a small input space all possible inputs can be tested, but it is more common that the set of test cases simply does not completely specify the problem.

It is hard to design test cases that test adequately when you are trying to spot bugs, but a good semi-random spread of test cases and well-chosen special cases has a good chance of catching semi-random errors and common mistakes. People, on the other hand, are very good at picking out patterns in your semi-random data. If the test cases were available, and admit a simpler solution, then corners may be cut to only satisfy the tests. With computer programs this is trivially possible by simply hard coding special cases for each input! Thus the judges choose obscurity: if contestants know not where the tests will fall, they must cover all possibilities suggested by the problem statement. (This is not to say that the problem statement always completely defines the problem! Judges are only human, clarifications are often necessary, and unexpected solutions are occasionally accepted manually.)

It sounds like this is solved, then: simply give the player a clear problem statement and hide the test cases. So why do I call it a problem? If we want to use a “programming contest” arrangement for learning, we absolutely must provide useful feedback. Showing how the test cases fail is essential to this. However, if we show the player the case that doesn’t work, we run the risk of him trying to treat each case specially, ignoring the problem statement (for which I don’t blame him; English problem statements seem completely out of place in games). One solution is to limit the code size, in an attempt to restrict the player to the least code necessary to handle the problem. Limited code space, if it is sufficiently small, also allows us the benefit of exhaustively testing every program possible in that space, to ensure that there is no unexpected solution that misses the point of the problem.

The excessive restrictions needed to make this work suggests a more radical approach, which is nevertheless completely in line with gaming. What if we do away with the tyranny of the problem statement? The player’s pattern-finding ability deserves exercise; if he can find a pattern in the data that allows him to take a shortcut, then bravo, he is playing a more interesting game! A scoring system based on code size could discourage degenerate case-by-case programs without necessarily imposing a hard limit. The problem statement could be treated as a helpful suggestion, possibly not even provided initially if the test cases can be coherently presented. It is interesting to consider the connection between impasse-driven learning and test-driven development; if building programs is like building knowledge then perhaps we can help our players to do both at once.

[update 12/16] I am only just becoming familiar with Kurt VanLehn’s work through his 1988 paper “Toward a Theory of Impasse-Driven Learning”. I linked to an abstract of that paper above, but it would have been better to to refer directly to his repair theory, which is the big idea here.

The One, The Many

December 14th, 2010

As with many who otherwise enjoyed The Matrix, I found the “humans as power source” excuse somewhat disappointing. I have heard that in the graphic novelization (which I have not read), an alternate explanation is provided: humans are connected to the Matrix because the machines use human brains to perform vast computations. This has some compelling implications. For one, if some percentage of the capacity of your brain is being stolen from you, the human mind may have limits far beyond what are normally experienced.  For another, if the Matrix is computed within human brains, the simulation may not have to be generated as direct sensory signals and piped in from the outside. Instead, the ideas of objects and events can be provided as suggestions, and the enslaved mind can be made to fill in detail at any level, as in dreams or True Names. Most importantly for my purposes, if the human brain is being used to compute the Matrix itself, then it gives a natural explanation for the power of The One.

Imagine that you notice a train of thought carrying on in your mind, seemingly out of your control, like perpetual motion just out of your field of vision. It doesn’t make any sense, doesn’t form words or images, but it keeps distracting you as you go about your work, do your taxes, and help your landlady carry out her garbage. Eventually you begin to notice patterns, almost premonitions. You cringe in recollection just before a glass breaks in another room. You recognize the feeling of an unexpected guest moments before he rings the doorbell. All the stuff of coincidence, or superstition. But then one day you see it again, the harbinger of smashed china, and you deny it. You master the mental loop that was driving you to distraction, and you find peace. Rather than a smash, there is a shouted obscenity from the other room. You investigate and find your coworker standing staring at the coffee mug he had knocked off his desk. It is now hanging in space several inches from the floor. As the shock hits you, the mug hits the ground and shatters.

“Whoa.”

If you can excuse my attempt at prose, the fascinating idea here is that certain tasks of the world simulation are being delegated to the audience of the simulation. Normally the system is set up so that the tasks are carried out subconsciously, but perhaps there are flaws and certain people at certain times begin to notice. The brain being the powerful pattern recognition engine it is, it may manage to “decode the Matrix”, at least on some intuitive level. Furthermore, some small set of these people may be able to manipulate these alien thoughts to reshape the world as they see fit. It doesn’t perfectly fit with the cinematic fiction, but it provides some interesting possibilities for games about programming.

As an example, any kind of game with a physics system might occasionally interrupt play to ask you to solve a simple math problem. If you can recognize the numbers, say perhaps they are associated with the movement of an enemy you cannot pass, then you might be able to fudge the result to move the enemy in a physically impossible way. You may need to budget such abuses in order to avoid the system noticing and cracking down on you. From the perspective of programming, you may be required to simulate some instructions in your head or on paper, and doing this subtly wrong may likewise give you some advantage. It may be possible, and necessary, to examine the surrounding code (which is executed by other enslaved minds) to see what you can cause to happen indirectly.  You may eventually get the opportunity to create new code and pass it on to others. As in the example above, even simply not executing some code may have powerful effects.

We see a similar thought in Neal Stephenson’s Diamond Age, which describes a vast organic computer formed out of the minds and bodies of a society called The Drummers. The members are under the influence of nanites (nano-scale robots) that cause them to live in a continuous dream state, with frequent orgies for information exchange. This system is apparently used perform the massive computations needed to crack cryptographic protocols. The character John Hackworth unknowingly enters one of these colonies at the behest of the mysterious Doctor X, and something interesting happens when his engineering expertise is added to the mix. Normally someone who joins the colony loses any individuality and becomes just another part of the larger system. Hackworth, on the other hand, is able to take it over from within, and he uses it to work on an extremely complicated machine, though when he emerges he is not consciously aware that he has done so. A spectacularly different outcome of exploiting hive intelligence occurs in Bruce Sterling’s Swarm. What other possibilities might we find in the concept of overcoming our role as just another brick in the wall?

In the beginning

December 12th, 2010

Hello, I’m Adam Gashlin.  I am working to design games that explore powerful ideas in computation and programming.  What exactly does that mean?  That is the topic of this blog.  I hope that by organizing my thoughts into blog-post-sized articles I can make some progress towards concrete designs.

I first started down this path in April 2008.  I had been interested for some time in developing a programming language and environment that could be used on systems with very limited input schemes, such as the digital audio players that Rockbox runs on.  I was calling this LITHIC (Limited Input Toy/Tiny Hardware Instruction Code), but I had not gotten to the point of implementing anything.  I was concerned with finding an efficient means of entering identifiers with so few buttons, though it seemed that a combination of a T9 system and syntax awareness would be helpful.

This collided with a train of thought about video games with magic spells as programs.  I realized that a LITHIC would work well on a video game controller, and that a game would be a fascinating way to teach someone how to use an unusual interface and language.  As I was nearing the end of my undergraduate studies, I had also been thinking about the possibility of teaching Computer Science.  I attended college part time that last semester, and as I was driving home everything came together.  When I got home that night I explained it as follows to friends on IRC:

A game that teaches programming. Written in the same language in which solutions are devised, in later levels finding flaws in the structure of the game itself might become important.

This concept has remained very consistent over the years, though I have questioned every part of it.  Embarrassingly, despite my confidence that games are uniquely well suited to communicating programming concepts, I have not yet implemented a prototype to explore and test these ideas.  Hopefully as I pull things together for this blog I will find the concentration to assemble some demonstrations.