Determining viable approaches to in-game challenges is a real bottleneck for programmed games. The GD:T&P example is a pressure-plate mechanism that the player needs to solve. Two system types are compared: Anticipatory and Complex. As the names suggest, the designer attempts to anticipate player actions in the 'Anticipatory System', guessing what objects the player might use to solve the pressure plate requirement. The guessing method is a simpler approach to program than the alternate 'Complex System', where a weight-value is assigned to all objects and forces within the game world that could possibly effect the pressure plate and thus the challenge.
Determining what player solutions are viable is less a problem for human-run RPGs which can start without even Anticipatory plans and still accommodate Complex solutions on the fly. But it is not unknown for players to take unexpected actions, forcing the GM to re-think or interpret on the spot for better or worse. Looking at a created level or scenario with a Complex viewpoint in mind could help prepare the GM and smooth over any surprises.
Emergence is described as Emergent Play that wasn't intended in a game's original design but "comes out" later during game play. The Complex System approach mentioned above to offering Unique Solutions is presented as the best way toward achieving emergent play which Rouse calls a sign of very good game design. The idea borders on "good design by accident", a somewhat ironic idea for a textbook on learning intentional game design.
When Emergence is good, it is really, really good. An imaginative party can energize a table-top RPG in a number of ways. A sideline within a story can be drawn out and magnified with interest, or personal quests can be fused with the existing adventure. A layer of depth can added to a game purely by interaction and foster further creativity.
Emergent Play is not always a good thing, however. Some forms of emergence can be a problem if destructive in nature. Distractions from a table-top adventure at hand leading to a session spiraling out of control is not an unknown occurrence. In on-line play, virtual goods and real-money trading grew into a volatile design challenge.
A related issue for table-top RPG is disallowing solutions considered reasonable by players leading to alienation and a confrontive relationship between GM and players(discussed somewhere on Gamegrene with Whutaguy I thought, but darned if I can find it).
A facet of Storytelling, Nonlinearity also refers to Multiple Paths / Endings in game story lines, Order in which challenges may be completed, and whether Selection of challenges is allowed.
A strictly linear design would offer only one path for the unfolding of a story, to be carried out in a determined sequence with a decided number of challenges to be completed. A fully nonlinear design would allow for the player to choose which challenges to take, the order in which to take the challenges, and offer a different result based on the choices.
Tabletop RPG adventures can come in either variety, either laid out in a roughly linear fashion as part of a story, or presented as independent scenarios. The live play form is very efficient at handling changes back and forth, subject entirely to the GM and players so either approach can allow for fully nonlinear divergences.
For designers however, writing in multiple possibilities for each juncture of the story would entail a huge increase in the amount of design work, just as it does for programmed games. But some degree of nonlinear consideration is better than none. Designs that do not possess much or any of these design considerations ultimately leave the burden to the GM, and set up the unpleasant surprises when player choices go outside a linear track.
The degree of realism is a common design consideration for all types of games. It is a spice which influences gameplay flavor. It can't "make the meal" on its own, but it can spoil one. There is no single recipe. Finding the right balance of reality means the difference between gritty fun and frivolous drudgery.
Teaching the Player
GD:T&P primarily discusses the use of Rewards as opposed to teaching lessons by handing the player repeated defeat as a form of punishment.
Patterns and themes can be used to teach a player or group how to play an adventure, intended or not. Early encounters may show the adventure is pure hack-n-slash or that the players should always look alternate solutions to defeating the boss monster. Are the brave rewarded for charging in or are there nasty surprises which call for cautious investigating first?
Input / Output
Input is how the player acts upon the game world. It can be joysticks and buttons or words and dice rolling. As mentioned here, just switching from dice to a spinner in special cases can provide a different feel to gameplay.
Output is Game-World Feedback, how the game communicates to the players. Sound effects, visual displays, scoring and GM narratives are all parts of the feedback.
Some possible questions for sharing:
Have you encountered instances of emergent play? How did you handle it?
What design could offer more non-linear features to tale-top RPG?
How do you plan for contingencies as a GM?
Is nonlinear game play overrated?
What kind of feedback "gimmicks" do you use / enjoy?
Game Elements in Non-Game Applications
The cover story of Communications of the ACM is on the use of game elements in non-game software applications. It's an interesting issue, but it feels to me that they're taking a fairly narrow view of what constitutes a "game element." The introduction to the section claims that games are engaging because they provide realistic 3D worlds. Well... certainly, realistic 3D worlds are pretty cool, but there are plenty of games that are not simulations, do not provide a 3D experience, and yet are extremely engaging.
What are some more basic ingredients of game design? Not every game has all of them, and the list doesn't span every design, but it still represents a useful toolkit of application properties that both make games engaging and are missing from standard (non-game) software applications.
Conflict. Games, like movies, are about conflict. You, as the game player, are a protagonist, which means that you have a goal to pursue. A nemesis is responsible for blocking your progress towards that goal. This is a more general idea than it might appear: in Tetris, your goal is to keep the well clear, and the blocks are the nemeses. Not quite on the level of Darth Vader, but still. (The flip side is the presence of in-game helpers, like those 4-block long pieces.)
Score. In many games, there's a way to keep score. This is way of providing immediate feedback to the player. How am I doing? How far have I gotten? Am I doing the right thing?
Reward. After you accomplish a task, or enough tasks, you get a prize. This might be going up a level (in the roleplaying sense), or a short movie (like the interscreen animations from Pac-Man), or a power-up, or even just a significant check-off ("You've completed all the quests on Snowy Mountain!"). The payoff is one of the things that make games so addicting, and the bigger the payoff, the stronger the emotional reaction, even if (or maybe especially if) the payoff is rare. (Incidentally, this is one of the reasons that I finally became a re-convert to the idea of level-based roleplaying games rather than strictly skill-based ones.)
Skill Development and Recognition. You actually have to get better at most games to win them; few of us start as skilled at playing Tetris as we eventually become. (Back in the days when you had to buy Tetris, we bought it for a friend of the family. After weeks or even months of playing and loving it, he called us up. "Did you know you could rotate the pieces??") We like this tangible feeling of mastering a skill, and of course this is reflected not only in the progress we can make in the game ("I made it across Fire Canyon!"), but in things like high scores and top ten lists.
This is just a snippet of a list; obviously games have a broad and rich set of designs to draw upon.
The best place to apply these elements is in educational and training software, which are to date embarrasingly unengaging. The state of the art seems to be drill games like Reader Rabbit, Math Blaster, or typing games. Some companies, like Lucas Learning, do seem to be making games that require real cognition to solve, and in principle teach skills like design, but there are few examples with which I'm familiar that teach an actual skill or subject (say, Physics, or Algebra) in a way that's as engaging as a Playstation II game. Why not?
And it's not just for education. Every application designer ought to be considering the list of game design elements as ways to make the experience of using an application richer, more rewarding, more engaging, and more powerful.