Archive for December, 2010

Code-worthy gameplay

Tuesday, December 28th, 2010

In 2008, Jonathan Blow, the author of Braid, gave a talk in which he described two “guiding skills”, the latter of which was pushing. This is meant in the sense of pushing a concept to its utmost; given an idea, follow it through to its conclusion. Chris Hecker ranted similarly at GDC 2010. Pushing is what turns Braid’s rewind from a gimmick into a gameplay mechanic. Rewind has the scary outcome that the designer can’t really threaten the player with anything. Rather than shy away from this by limiting rewind, Braid actually illustrates it with the first few levels. World 2 is all about tricky platforming that would be tremendously frustrating to play through flawlessly. Since rewind allows unlimited rapid retries, though, it becomes a much more natural and forgiving problem solving experience.

One conceptual issue for the game I’m trying to design is that computation has a number of similarly “scary” implications that make it difficult to design around. Foremost is something you see frequently in robot-commanding games such as ChipWits: why do I need to write a program to do something that I can very easily do by myself? It can be very frustrating to have to build a program to do something straightforward. As Sid Meier has said, “The player should have the fun, not the designer or the computer.” One of the great joys of games is the direct manipulation of the character, in artificially enforcing a disconnect between the player and character we aren’t playing to the strengths of the medium. This is the complement of Blow’s complaint about Prince of Persia: Sands of Time. PoP was constrained by game convention, so it limited the player’s rewind ability in order to retain a more traditional play experience. With robot programming, we are eschewing good game interactivity practices for the sake of our high concept.

There’s a good reason we’re doing it, though. The programming interface is tremendously more powerful than direct manipulation, that’s why we use it, and we think it will be fun for the player once he gets into it. The silly little intro levels are there for tutorial purposes; if we let the player play through those directly, then he will likely not be prepared for more complex issues later.

There are two approaches we can take to reconcile this, and I think a combination of them would be best.

We can make the tasks to be performed larger, duller, and less interesting to play out manually. For conceptual integrity, we might still allow the player to chip away at them if he so insists, but the tasks will be much better to perform through automation. This provides a motivation for programming in the first place, since this is why we actually bother with machines: to do things we could technically do by hand, but much more quickly and accurately. There is always some danger in intentionally making things dull, however. I consider this similar to the approach taken by Braid: rather than shy away from the difficulty, go ahead and explore it. If making the tasks to achieve dull is what is required to make programming appropriate, then maybe we need to find dull tasks that are nevertheless interesting to code solutions for. At the limit of this approach, you have infinite tasks like I mentioned here.

Another approach is to make the programming activity more game-like, through more responsive, animated visual elements. My old favorite Rocky’s Boots is a good example of this, though clearly limited by technology. Being able to immediately see the results with highly interactive debugging and edit-and-continue features would help. This means that the programming environment must itself be a game world. In the interest of conceptual integrity, wouldn’t it make sense for this to actually be the same game world in which our robots do their work? As I mentioned this briefly in an earlier post, I think there is a lot of potential in the programming system wrapping around to affect itself.


Sunday, December 26th, 2010

While my main intent is to design games that are played by writing programs, I have considered a few game types that illustrate the operation of certain algorithms. Imagine enhancing any existing type of game with a scoring system based on the “originality” of the player’s performance. Concretely, say that you would score fewer points for repeating the same solution every time you encounter a particular type of obstacle. The game could keep track of this by forming a statistical model of what it knows about the player’s play style, and thus at each decision point it would assign a score based on how unexpected the decision was (say, oh, log 1/p). If this sounds like data compression, that’s just what it is.

I imagine the data stream describing the player’s actions showing up at the bottom of the screen, along with its translation into compressed data. Along with the more complex entropy coding mentioned above, simpler things like RLE and LZ77 can be used. A graphical representation of when the game last saw a backreference would be interesting. Watching a Huffman tree get built, or a range coding narrowing down, might be instructional. You might receive a bonus for getting the compressor to exceed the uncompressed data size, if you can generate a pathological dataset. Combining this scoring system with the requirement that you actually complete the level as well could prove interesting.

Many issues give me pause, however:

  • What kind of data is the algorithm actually dealing with? Is it just the player’s input? Analog or digital? Is it sampled every frame? Is it some higher level representation of a “move”? Perhaps taking into account the level context? Would “useless” movements be filtered out?
  • If there is only a small set of symbols, say the cardinal directions, which would only require 2 bits, then it is unlikely that the game is going to achieve significant compression (at least with Huffman coding’s limitations). But what more could we provide? Will the “words” of stereotyped motions be enough redundancy to give the game a fighting chance?
  • How much data can we fit on the screen at once in a way that can be useful to the player?
  • Should we attempt to describe the algorithms? Just watching them at work may be puzzling.

In keeping with the theme of compression, I leave this post abbreviated.

Shell script of the gods

Saturday, December 25th, 2010

One of the concerns I had with the programming contest problem was deciding what kind of fictional context to use. What kind of scenario could explain the need for a single automated solution to a suite of problems, even those that had already been solved?

The need to expose the player to such a test suite is twofold. We would like to introduce the player to the idea of breaking tasks down into reusable subcomponents. I thought I would give the player some small task to accomplish, thoroughly testing that the automation he produces works in every case, and then giving him access to that solution as a component to solve future problems. In this way, at least as one part of the level progression, we would coerce the player to build up a library of functionality.

The other aspect is the pedagogical model described yesterday. The gist is that a series of specific exercises are used to illuminate a general concept.

So here’s the story: In a pantheon, you are the god of automation, or perhaps ritual. All of the other gods have vanished. While exploring the reason for their disappearance, you enter into their quarters in Olympus and find yourself invoked by their worshipers. When you are summoned in the name of another god, you have the ability to use that god’s power, theoretically in some limited context to placate the supplicants. Initially these powers will be very limited, such as the ability to cause crops to grow or heal cattle.

The pleas of the faithful never cease. If you had no other option, you would be eternally at the whim of these worshipers to do these tasks manually (they are sounding more like demon summoners at this point, you are bound to do a boon) . However, the interesting wrinkle is that as god of automation, you have the power to set up a system to do these things for you, and you can install it in the place of doing the deity work yourself. I don’t yet know precisely how this would manifest, but it would require the summoning to include somehow a symbolic description of how the task is to be accomplished, in fact a program in some specialized ritual language. The scenarios would each be set up so that it is clear what the player needs to do, and thus the task would be two parts:

  1. Figure out how the symbolic representation represents the work that needs to be done (this is the game-supplied program).
  2. Construct a program to do it for you (this is the user-provided interpreter).

This is similar to the decoding game I recently described, and it is possible that these could both be parts of the same game.

Once you have automated a deity correctly you can then summon it yourself to do work for you in other problems. As each deity has its own ritual language, this has the possibility to introduce a whole slew of programming primitives and language types, in addition to the various powers each god commands.

What kind of language does the god of automation himself use? That is, what is our starting point? I think Lisp or something like it is a good candidate, and I will suggest a possible mechanism for importing lambdas and s-expressions into video games in a future post.

Progressive Pathways

Friday, December 24th, 2010

Part of my conviction that games can work well for teaching is a theory of instruction related to the Socratic method. It is the idea of presenting an argument as a series of questions or exercises, first of specific cases, then of generalizations. R. P. Burn’s A pathway into number theory is made up entirely of questions, and explains the approach as follows:

This book on number theory has been put together by keeping a record of how I actually resolved the blocks which I encountered as I read a number of standard texts. Time and again, it was the exploration of special cases which illuminated the generalities for me. This collection of explorations was then organized into a sequence in such a way that the ‘pathway’ would climb towards the standard theorems which occur here as problems for the student at the end of each section.

This “block resolution” approach is interesting; I consider it related to the theory of impasse-driven learning advanced by VanLehn (and previously mentioned towards the end of this post). By combining questions likely to provide impasses with the programmed learning conceit of immediate feedback, the learner’s inductively-developed understanding of the system ought to be improved. I admit that VanLehn’s concept of impasse isn’t quite a perfect match, not to mention relating to much simpler algorithms, but I think there is some resonance between the two.

Daniel P. Friedman’s The Little LISPer is also presented as questions and answers (though much closer together than Pathway gives its answers), in this case as an introduction to Lisp. From the 1974 edition’s introduction:

DO NOT HESITATE TO GUESS. This book is based on intuition, and yours is as good as anyone’s. We expect you to guess. Occasionally we make you guess before giving the answer, either because we do not expect you to know an answer at a particular stage, or because we want you, in case you guessed wrongly, to slow down and look back for what you missed earlier.

Both authors also call out a particular lack of formality, and not just due to each being an introductory text. From the preface to the second edition of Pathway:

The central point of the Pathway is to enable students to participate in the formulation of central mathematical ideas before a formal treatment (which, suitably introduced, they may well be able to provide themselves).

and from LISPer:

No formal definitions are given in this book. We believe that you can form your own definitions and will thus remember them and understand them better than if we had written each one for you.

Sadly I can’t vouch for the effectiveness of either of these books. Despite starting on it several times, Pathway quickly becomes too notation-heavy for my math-weak mind. Running through LISPer without a computer renders it a rather sterile exercise, although the book does not recommend a computer companion (though this may be due to the scarcity of computer resources when it was written). Pathway does recommend a calculator, but my TI-83 hasn’t proven terribly helpful so far. I think that a game can be more successful here, with a more experimentation-friendly interface and better integration between the problems and the rule system (as in my earlier post).

Continuity is my favorite example of using a well-crafted level progression to teach. Levels are made up of a number of sliding tiles (or slides), as in a fifteen puzzle. In one mode you simply slide these tiles around. Pressing the spacebar toggles to another mode, in which you play a platformer set in the level formed by the tiles. It is a very smooth introduction: level 1 doesn’t require the sliding mechanic at all, and level 2 illustrates it in the simplest possible way. Initially it looks like:

But with a single slide, you get:

Once in the latter state, you can toggle to platformer mode and walk the little guy from the left to the right across the gap, to get to the red door which you need to finish the level.

An important complication is that you can only move between tiles when their edges match up completely. This is so important that the game dedicates two early levels to demonstrating it. Here’s level 4, initially:

It looks like the easy solution is to go right and grab the key (which you need to get through the door). If you jump up the stairs, though, you run up against the edge and the game buzzes annoyingly. You must rearrange the tiles so that there is a matching staircase on the other side before you can pass through that edge:

You must make several similar moves to complete this level (note the seemingly uninvolved block at the top of the left two tiles, this must also match to pass those edges). I was struck with the elegance of this approach, however it may be a little too subtle. I watched a few people play the game and some of them didn’t gather that the matching of edges was the important issue; it seemed to them that the restrictions were arbitrary. One way to clear this up might be a better indication of why nonmatching edges don’t match, maybe a highlight of the inequal parts of each.

As well done as this is, and I could spend many posts discussing what I like about Continuity’s design, the game only uses this teaching to lead up to the hard puzzle parts that come later. While the mastery of discontinuous space is interesting, I hope to use similar techniques to explore computational spaces as well. It was a direct inspiration for my own prototype A Change of Plans, and while that doesn’t hit any terribly interesting concepts either, it emphasizes another advantage of games over textbooks using this method: games naturally support a great variety of solutions.

Lost in design space

Thursday, December 23rd, 2010

I have described my game design efforts to many family and friends and coworkers, and one suggestion I have often had is to just pick a programming language and work from that. My response is that a language designed for practical use is not well suited for my learning game purposes. Clearly, rather than working around the limitations and oddities of an existing language, it would be best to develop a language which perfectly fits my needs.

Several times in my notes I have scolded myself for not having a particular end goal in mind for the game to build up to. While I have compiled a few lists, none of the topics I have considered have been a perfect fit. Clearly, as I am not bound to a particular curriculum, I should take advantage of that freedom to hold out for a truly appropriate goal to build to. The primitives I choose to make the game out of, and the game’s fiction, will certainly suggest something.

Besides a few efforts towards Victor and a vaguely related game, I have not attempted to prototype any of the ideas I have toyed with. Clearly I am able to follow them through to their inevitable failings, so there is no point in wasting my time on them. I can use that time to do the abstract planning and research that has given me so much progress already. I have no time constraints of any sort, I am not beholden to anyone who needs to check on my progress, so there is no reason to misspend the coding effort.

Oh, and I need to make a game and not a software toy or a sandbox environment, because it is the restrictions and gameplay goals that I impose that will propel people to the more interesting corners of the space I have set out for them.

Won’t get fooled systematically

Wednesday, December 22nd, 2010

I once had an idea for a game about deception. It would be like a tutorial for an ordinary game, but the instructions would be wrong, and the game would berate you for trying to do it the right way. This wouldn’t be too interesting, though, as the instructions would simply become noise, and the player would ignore them. But what if the instructions were needed, somehow, such as to guide your character through an invisible random maze? If the instructions were simply wrong, or intentionally misleading (as fitting the “deception” theme), then the instructions would be totally useless and the game would be impossible. But what if there was a consistent method to the wrongness? Then it becomes a much more interesting exercise.

Consider a game with a top-down view of a standard square grid world. You need to maneuver along a narrow, twisting path over a bottomless pit (or lava). You can easily walk off the path and fall to your doom, but control isn’t hard if you are going in the right direction (a block-at-a-time move system as in early Dragon Quest or Final Fantasy would be best here). While you can easily see your way, the game also gives you directions. The directions are mirrored, however, so north is south, east is west. Because it is easy to see what you actually need to do, the system becomes clear.

In the next phase, you must navigate the same sort of path, but without being able to see where you’re going. Here you need to rely on the “wrong” directions, so you will use the decoding system that you had worked out previously. It should be possible to switch back to the visible maze for more practice if you hadn’t figured it out or memorized it completely. Since it is fairly uninteresting and error-prone to run through the whole maze, we will offer a way to automate it. You can set up a mapping between the “wrong” directions and the correct ones (NORTH => SOUTH, SOUTH => NORTH, etc), and the game will automatically run through the maze, translating the directions as you instructed.

At the next level, we present the same setup again, only this time with a somewhat different mapping, maybe a rotation: NORTH => EAST, EAST => SOUTH. The same game would play out: you need to discover this rotation, then either do it step-by-step or automate it, though the game will ultimately require the automation. A helpful tool might be to build a table showing each “wrong” direction given and the correct direction that the player was able to take, given his knowledge of the context. When setting up the automation, it could indicate which lines of the table the current mapping satisfies. Another form of illustration is to overlay the result of the automation on top of the visible maze. This could show, for instance, that a turn was taken too early or a step was missed; the rest of the path would appear correct, but offset.

Following levels of play will involve increasingly complicated encodings, a few examples:

  • In every other step the rotation reverses, so the first direction maps NORTH=>EAST and EAST=>SOUTH, but the second maps NORTH=>WEST and EAST=>NORTH. To automate this we will need some way to indicate alternation between mappings.
  • At regular intervals a completely bogus direction is given. To automate this we will need a way of counting out the interval and discarding a direction.
  • Pairs of directions need to be taken together to determine the output. To automate this the mapping will need to be 2-to-1, or 2-to-2. Similarly a single direction may always map to a pair of directions, for a 1-to-2 mapping.
  • A particular set of directions indicates a repetition, say the useless series “EAST WEST EAST WEST” actually means “EAST 8 times”. This will require the ability to generate arbitrary numbers of output directions.
  • Directions indicate change of orientation (turn clockwise, turn counterclockwise) and movement in the current direction (go forward, go backwards) rather than absolute headings. This will require the ability to track state, in order to interpret state-dependent commands like “forward”.
  • A set of directions indicates “repeat the previous direction N times”; this is related to run-length encoding (RLE). Automation will require memory of the previous direction, and it also provides an opportunity for introducing a binary or base 4 number system.
  • This is pushing it, but a series of directions may represent a program for generating a whole set of outputs.
  • Other possibilities include more complex compression, encryption, and error correction.

There are a few important points to this progression. First, we attack the idea that the directions are anything but arbitrary symbols. It may be valuable (as I mentioned in this post) to not have them be expressed as “directions” at all, but I think that for a first level it would be good to have the directions say only exactly what they mean, just to introduce the interface. Still, very soon the player finds that these symbols can mean anything. Second, while the encodings become somewhat more complicated, they are not layered in a way such that they are combinations of everything that came before. Thus the RLE mode may have directions that mean exactly what they say, except for certain “escape sequences”. Lastly, the progression is designed around the idea of introducing new mechanisms in the automation toolkit, so we will not provide these mechanisms before they are actually needed.

It is a hard but fascinating problem to consider how to build visible mazes that explain the encodings to the player. With a narrow path we quite straightforwardly indicate what the result should be in some scenario. We can also provide branches and wider paths where multiple interpretations may be valid; these can either end in a pinch point where we eliminate other possibilities, or the system may admit to multiple solutions. Even in a straight corridor, a useless direction to go backwards might be valid, or it might signal something unusual. One interesting aspect is the overall feel of the maze. The RLE level will likely have a visible maze with an unusual number of long straight corridors; this befits its usefulness as a compression scheme to describe data with long runs of a single value.

We present the player with two related problems. He must figure out how the given representation relates to the real maze he finds in front of him. He does this with the help of an automation system that we also expect him to learn to use. It is interesting to consider that the processing of a data stream is naturally a stream or dataflow programming problem, and as such it lends itself to expression as a flowchart. This suggests a straightforward graphical representation for user programs.

I think that this is considerably more interesting than the common cryptogram puzzle. While these can be somewhat fun, they rely on knowledge of various letter frequencies which have to be known in advance. With an unknown language, it becomes the much more difficult and interesting decipherment problem. The combination of visible mazes and encoded directions form a kind of bilinguis: we know that the directions are somehow indicating how to solve this maze, and we can check how well our attempted translation succeeds at this. Additionally, the encoding is conceptually interesting in its own right, which is valuable here where the thing being described (the maze) is rather dull. Even so, the maze is explicitly designed to help the player figure out the language, so we ought to make it a fun system to learn with.

To choose obfuscation

Tuesday, December 21st, 2010

Salen and Zimmerman’s Rules of Play has a whole chapter dedicated to various definitions of “game”. The most memorable one for me was by Bernard Suits, from his book The Grasshopper: Games, Life, and Utopia:

Playing a game is the voluntary effort to overcome unnecessary obstacles.

Several of my ideas for learning games involve interfaces whose function is deliberately obscure, which only become usable through experimentation. This is common in games such as Myst, which is in essence a series of poorly documented interfaces, but why would I want to do this in a game that is trying to teach something? Wouldn’t I want to make explanations and controls as straightforward and self-explanatory as possible? There are good reasons for explicit or representative explanations, but I think that they are out of place in games, where we have a different set of powerful tools available.

As I’ve discussed briefly before, the skill of extracting meaning from data is an important one. In a game we provide opportunities to discover the meanings of objects and commands, ideally constructed in such a way that incorrect inferences prove untenable.

If one has to work to figure out what something means, it can be more meaningful than simply being told what it means. It is important to make that discovery in a context where that meaning actually means something. Being told that a boomerang stuns an enemy for 5 seconds is much less significant than discovering how fast you need to run to be out of danger when he recovers. My recent post was about the development of this kind of understanding in games.

Relying on a symbol with a readable name like “if”, “then” or “while” brings in all manner of unintended meaning. In “Preprogramming Knowledge” (PDF), Bonar and Soloway call this SSK: Step-by-Step natural language programming Knowledge. Because of the surface similarities between Pascal‘s keywords and English, the wrong meanings can be inferred. For instance, “while” is sometimes thought to describe the “demon control structure”, which continuously tests the condition of the loop (i.e., the body of the loop is only processed while the condition holds). This is a natural thing to assume based on the usage of the English word “while”, but it is quite different from the actual behavior of the Pascal construct.

Using graphical icons, like an arrow pointing up to mean “forward”, is likewise rife with difficulty. If the “forward” arrow is a command for a robot to move forward, what does it mean when the robot is facing in a different direction than the arrow? Even arrows consistently indicating cardinal directions have the overloaded meaning of pointing at things, such as the icons surrounding them.

In psychological research on memorization, it has long been common to use nonsense syllables, in order to avoid triggering associations that might aid memorization. Leaving aside how to define meaningfulness, this allows the syllables to take on meaning only in relation to the environment in which they are presented. In a programming learning environment, when we are trying to introduce complicated concepts and behaviors, I think we would do well to follow this practice. While the inferences initially made may be wrong, they are more likely to be wrong because our presentation hasn’t shown them to be wrong yet, rather than polluted by concepts brought in from outside that we can’t plan for.

Automatic manual

Monday, 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

Sunday, 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

Saturday, 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.