Category Archives: Uncategorized

Goals, Anti-Goals and Multi-player Games

In this article I will try to address Keith Burgun‘s assertion that games should have a single goal and his analysis of certain kinds of goals as trivial or pathological. I will try to demonstrate that multi-player games either reduce to single player games or necessitate multiple goals, some of which are necessarily the sorts of goals which Burgun dismisses as trivial. I’ll try to make the case that such goals are useful ideas for game designers as well as being necessary components of non-trivial multi-player games.

(Note: I find Keith Burgun’s game design work very useful. If you are interested in game design and have the money, I suggest subscribing to his Patreon.)

Notes on Burgun’s Analytical Frame

The Forms

Keith Burgun is a game design philosopher focused on strategy games, which he calls simply games. He divides the world of interactive systems into four useful forms:

  1. toys – an interactive system without goals. Discovery is the primary value of toys.
  2. puzzle – bare interactive system plus a goal. Solving is the primary value of the puzzle.
  3. contests – a toy plus a goal all meant to measure performance.
  4. games – a toy, plus a goal, plus obfuscation of game state. The primary value is in synthesizing decision making heuristics to account for the obfuscation of the game state.

A good, brief, video introduction to the forms is available here. Burgun believes a good way to construct a game is to identify a core mechanism, which is a combination of a core action, a core purpose, and a goal. The action and purpose point together towards the goal. The goal, in turn, gives meaning to the actions the player can take and the states of the interactive system.

On Goals

More should be said on goals, which appear in many of the above definitions. Burgun has a podcast which serves as a good long form explication of many of his ideas. There is an entire episode on goals here. The discussion of goals begins around the fifteen minute mark.

Here Burgun provides a related definition of games: contests of decision making. Goals are prominent in this discussion: the goal gives meaning to actions in the game state.

Burgun raises a critique of games which feature notions of second place. He groups such goals into a category of non-binary goals and gives us an example to clarify the discussion: goals of the form “get the highest score.”

His analysis of the poorness of this goal is that it seems to imply a few strange things:

  1. The player always gets the highest score they are capable of because the universe is deterministic.
  2. These goals imply that the game becomes vague after the previous high score is beaten, since the goal is met and yet the game continues.

The first applies to any interactive system at all, so isn’t a very powerful argument, as I understand it. Take a game with the rules of Tetris except that the board is initialized with a set of blocks already on the board. The player receives a deterministic sequence of blocks and must clear the already present blocks, at which point the game ends. This goal is not of the form “find the highest score” or “survive the longest” but the game’s outcome is already determined by the state of the universe at the beginning of the game. From this analysis we can conclude that if (1) constitutes a downside to the construction of a goal, it doesn’t apply uniquely to “high score” style goals.

(2) is more subtle. While it is true that in the form suggested, these rules leave the player without guidelines after the goal is met, I believe that in many cases a simple rephrasing of the goal in question resolves this problem. Take the goal:

G: Given the rules of Tetris, play for the highest score.

Since Tetris rewards you for clearing more lines at once and since Tetris ends when a block becomes fixed to the board but touches the top of the screen, we can rephrase this goal as:

G': Do not let the blocks reach the top of the screen.

This goal is augmented by secondary goals which enhance play: certain ways of moving away from the negative goal G' are more rewarding than others. Call this secondary goal g: clear lines in the largest groups possible. Call G' and goals like it “anti-goals.”

This terminology implies the definition.

If a goal is a particular game state towards which the player tries to move, an anti-goal is a particular state which the player is trying to avoid. Usually anti-goals are of the form “Do not allow X to occur” Where X is related to a (potentially open ended) goal.

Goals of the “high score” or “survive” variety are (or may be) anti-goals in disguise. Rephrased properly, they can be conceived of in anti-goal language. Of course there are good anti-goals and bad ones, just as there are good goals and bad goals. However, I would argue that the same criteria applies to both types of goals: a good (anti) goal is just one which gives meaning to the actions a person is presented with over an interactive system.

Multi-Player Games and Anti-Goals

I believe anti-goals can be useful game design, even in the single player case. In another essay I may try to make the argument that anti-goals must be augmented with mechanics which tend to move the player towards the anti-goal against which players must do all the sorts of complex decision making which produces value for players.

However, there is a more direct way of demonstrating that anti-goals are unavoidable aspects of games, at least when games are multi-player. This argument also demonstrates that games with multiple goals are in a sense inevitable, at least in the case of multi-player games. First let me describe what I conceive of as a multi-player game.

multi-player game: A game where players interact via an interactive system in order to reach a goal which can only be attained by a single player.

The critical distinction I want to make is that a multi-player game is not just two or more people engaged in separate contests of decision making. If there are not actions mediating the interaction of players via the game state then what is really going on is many players are playing many distinct games. A true multi-player game must allow players to interact (via actions).

In a multi-player game, players are working towards a win state we can call G. However, in the context of the mechanics which allow interaction they are also playing against a (set of) anti-goals {A}, one for each player besides themselves. These goals are of the form “Prevent player X from reaching goal G“. Hence, anti-goals are critical ingredients to successful multi-player game design and are therefore useful ideas for game designers. Therefore, for a game to really be multi-player then there must be actions associated with each anti-goal {A}.

An argument we might make at this point is that if players are playing for {A} and not explicitly for G then our game is not well designed (for instance, it isn’t elegant or minimal). But I believe any multi-player game where a player can pursue G and not concern herself with {A}, even in the presence of game actions which allow interaction, is a set of single player games in disguise. If we follow our urge to make G the true goal for all players at the expense of {A} then we may as well remove the actions which intermediate between players and then we may as well be designing a single player game whose goal is G.

So, if we admit that multi-player games are worth designing, then we also admit that at least a family of anti-goals are worth considering. Note that we must explicitly design the actions which allow the pursuit of {A} in order to design the game. Ideally these will be related and work in accord with the actions which facilitate G but they cannot be identical to those mechanics without our game collapsing to the single player case. We must consider {A} actions as a separate (though ideally related) design space.

Summary

I’ve tried to demonstrate that in multi-player games especially, anti-goals, which are goals of the for “Avoid some game state”, are necessary, distinct goal forms worth considering by game designers. The argument depends on demonstrating that a multi-player game must contain such anti-goals or collapse to a single player game played by multiple people but otherwise disconnected.

In a broader context, the idea here is to get a foot in the door for anti-goals as rules which can still do the work of a goal, which is to give meaning to choices and actions in an interactive system. An open question is whether such anti-goals are useful for single player games, whether they are useful but only in conjunction with game-terminating goals, or whether, though useful, we can always find a related normal goal which is superior from a design point of view. Hopefully, this essay provides a good jumping off point for those discussions.


Amateur Notes on “Quantum Mechanics as Classical Physics”

I am slow to mature. That is why I squandered myself in graduate school. I could have embraced the opportunity to think critically about the philosophy of physics, in which I was at least up to my knees. I instead glibly dismissed philosophy as secondary to prediction. Quantum Mechanics poses the greatest and most interesting philosophical problems and only now, when graduate school is vanishing on the horizon or, at any rate, eclipsed by towering pragmatics racing towards me (mortgages, careers, children), am I taken, with ever more frequency, by thoughts of the philosophy of physics.

Compensating this lack of remit to study is a comparative freedom of choice about how I study. Reading that would have been deemed frivolous by my graduate adviser I am now free to pursue for pleasure. Hence Charles Sebens’ 2013 paper “Quantum Mechanics as Classical Physics,” which develops a purely classical interpretation of Quantum Mechanics of a novel, Bohmian-flavored variety.

Interested readers should read the version on the Archive. I can’t hope to reproduce anything by a quick and probably inelegant if not misleading summary here, but the basic idea is to create a sort of supererogatory interpretative framework for Quantum Mechanics by adding not a single Bohmian particle, but one for many universes in such a way that the dynamics are preserved and then cleverly realizing that the so-called “Pilot Wave,” which corresponds to the Wave Function in more ordinary interpretations, can be completely removed, replaced instead by a regular Newtonian force between the Bohmian trace particles.

This results in a many-universe interpretation of Quantum Mechanics (with the same predictions as any other interpretation) but without a wave function. I’m interested in what I believe to be one aspect of this interpretation: it seems to be that worldlines never cross in this way of thinking, so that, if we jump up and up and up to slightly absurd questions like “Are there me’s in other universes who have made different decisions than I have?” The answer is “no,” in the following sense: because world lines never cross, there was never a time where two universes (and hence two versions of yourself) shared exactly the same state and then diverged. In other words, in each universe, while there may be many beings who resemble any individual in many respects, none of them share identical pasts. If you resent some decision in the past, as I resent not thinking about philosophy more in graduate school, and torture yourself by imagining some parallel person who made different decisions (with the help of some vague thoughts about the Interpretation of Quantum Mechanics) take heart: there is no such moment in the past where you could have chosen differently. You past is fixed and distinct from all those other versions of yourself, none of which were ever identical to you at any point.

At least that seems to be the case when you think about it this way.

Quick, Probabily Naive Thoughts about Turing Machines and Random Numbers

Here is a fact which is still blowing my mind, albeit quietly, from the horizon.

Turing Machines, the formalism which we use to describe computation, do not, strictly speaking, cover computational processes which have access to random values. When we wish to reason about such machines people typically imagine a Turing Machine with two tapes, one which takes on the typical role and another which contains an infinite string of random numbers which the machine can peel off one at a time.

Screen Shot 2016-05-30 at 9.42.43 AM

I know what you are all thinking: can’t I just write a random number generator and put it someplace on my turing machine’s tape, and use that? Sure, but those numbers aren’t really random, particularly in the sense that a dedicated attacker, having access to the output of your turing machine can in principle detect the difference between your machine and one with bona fide random numbers if it has access to your outputs. And, in fact, the question of whether there exists a random number generator which uses only polynomial time and space such that a polynomial time and space algorithm is unable to detect whether the numbers derive from a real random process or an algorithm is still open.

All that is really an aside. What is truly, profoundly surprising to me is this: a machine which has access to random numbers seems to be more powerful than one without random numbers. In what sense? There are algorithms which are not practical on a normal turing machine which become immanently practical on a turing machine with a random tape as long as we are able to accept a vanishingly small probability that the result is wrong. Algorithms about which we can even do delta/epsilon style reasoning: that is, we can make the probability of error as small as we like by the expedient of repeating the computation with new random numbers and (for instance) using the results as votes to determine the “correct answer.” This expedient does not really modify the big O complexity of algorithms.

Buridan’s Ass is a paradox in which a hungry donkey sits between two identical bales of hay and dies of hunger, unable to choose which to eat on account of their equal size. There is a strange sort of analogy here: if the Ass has a source of random numbers he can pick one randomly and survive. It is almost as if deterministic, finitist mathematics, in its crystalline precision, encounters and wastes energy on lots of tiny Ass’ Dilemmas which put certain sorts of results practically out of reach, but if we fuzz it up with random numbers, suddenly it is liberated to find much more truth than it was before. At least that is my paltry intuitive understanding.

Duckspeak Vs Smalltalk

The Decline of the Xerox PARC Philosophy at Apple Computers

Malcolm Gladwell’s recent piece, “Creation Myth”, in the New Yorker, about innovation and implementation via Xerox PARC, academia and Apple Computers, tells one interesting story about that surprising time in our modern history. But the story of the tensions and synergies between visionaries and businessmen elides a few interesting details about what was going on, and why, at Xerox PARC at the time. Gladwell’s version of history features a nimble entrepreneur, Steve Jobs, capitalizing on an idea the value of which a monolithic company, Xerox, can’t see. But the story of Apple and Xerox PARC is also that of a design philosophy meant to empower people diverging into one meant to entertain them or to sell them things.

When Steve Jobs visited Xerox PARC and saw the first mouse, the system he was looking at, the Alto, was running a programming environment and language called Smalltalk. While the details of this system are glossed over in the Gladwell piece, they deserve more careful attention. Although The Alto bears a superficial resemblance to modern computers, it differed in one major area: the relationship between software developers and users.

For most people software is a solid edifice – it presents a few modes of interaction to the user, maybe a special panel of customization options somewhere, but is otherwise as opaque and unmodifiable as a modern car. If users bother to think about software at all, they think of it as a product, constructed somewhere by people called “programmers” and distributed to the user. If that software doesn’t do what the user wants, he might send a hopeful technical support email, or he might just shop around for something else.

Of course, there is consumer software that includes more powerful extension features, so that, in principal, the user can add their own functionality, but these features don’t seem to be popularly used. Firefox is an example of user-extensible software, but the vast majority of users don’t use this capacity except to download what a small percentage of computer literate users write.

In other words, it is reasonably safe to say that most people who use computers have never written software.

Why should this be, and what does it have to do with Xerox PARC, Smalltalk and Steve Jobs? Well, an integral part of the Xerox PARC Philosophy was to dismantle the wall between software developers and computer users, to develop systems so easy to program that doing so would be a natural, simple aspect of computer use.

The early years of computing technology naturally produced a division between users and programmers – programming early computers was a highly technical discipline which required specific knowledge of the way the idiosyncratic hardware systems in those days worked. But while computers rapidly increased in power, the tools that programmers used to program them developed relatively conservatively. It is easy to imagine a world where those tools developed along with the computers, until programming itself became so easy that the average user would feel comfortable doing it. After all, the point of any program is to automate or facilitate tedious work, and in this respect programming itself is no different than a word processor.

That wasn’t exactly how things happened, and the reason why is a fascinating and arguably still unresolved story in and of itself. Part of that story takes place at Xerox PARC.

The Xerox PARC Philosophy

I mentioned above that the computer Steve Jobs saw on his visit to to Xerox PARC, the Alto, was running something called a Smalltalk System. Smalltalk is still around, and you can even download a self-contained Smalltalk System called Squeak and play around with one yourself. What you’ll see, if you do, is something which is probably very similar to what Steve Jobs saw on that day – a desktop-ish interface, with dragable windows and clickable buttons. And of course, you interact with the mouse.

Pharo Smalltalk

The Graphical Programming Environment of Pharo Smalltalk.

Both systems also share a fascinating property which “Creation Myth” leaves unmentioned. In Smalltalk, you can, using something called “The Browser,” pull up the “source code” for any object in the system. “Object” in this case means anything in the system whatsoever, including windows, widgets, numbers. “Source code” is the stuff that a compiler translates into machine code so the computer can do something with it. If you want, you can modify that code right there, or copy it and create a new object with user-customized behavior. The entire system is transparent and modifiable.

Most of the programming languages people used in 1979 would have looked very nearly like gibberish to a lay person. Early computers were slow, which meant that compilers took a long time to work unless they were very simple. This meant that most early programming languages were just thin shells on top of the numbers-as-command codes of machine language. Even by 1979, languages hadn’t developed much further in public use – corporate and government users (pretty much the only users before personal computing) were interested in cost-effectiveness and systems their programmers already knew, so language and system design was very conservative. New languages came along, but often they were incremental improvements on previous designs.

The designers of Smalltalk (Alan Kay, Dan Ingalls, and Adele Goldberg principally, and others), given the resources and freedom of Xerox PARC, worked actively to reverse this trend. Whereas a hodgepodge of cultural and technical realities constrained the way most other programming languages looked and felt, both Smalltalk the language and the system were written from the ground up to be so easy that a child could use them (hence the name). It was much more ambitious than just that, however. Kay saw Xerox PARC as being on the vanguard of a real revolution in human/computer interaction. In “The Early History of Smalltalk,” Alan Kay writes of this “Xerox PARC” vision of personal computing:

… the user interface would have to become a learning environment along the lines of Montessori and Bruner; and [the] needs for large scope, reduction in complexity, and end-user literacy would require that data and control structures be done away with in favor of a more biological scheme of protected universal cells interacting only through messages that could mimic desired behavior.
… we were actually trying for a for a qualitative paradigm shift in belief structures — a new Kuhnian paradigm in the same spirit as the invention of the printing press…

It is obvious from the “The Early History of Smalltalk” that Alan Kay has a direct, emotional involvement in his subject matter (he says so in fact). What is equally obvious is that Kay’s retrospective must be bittersweet at best. Smalltalk and the Alto were, at the time, the avatar of “The Xerox PARC Design Philosophy”. The systems Apple went on to produce would imperfectly capture this philosophy, and arguably, later, jettison it altogether.

In one anecdote, Kay relates showing a custom system (built in Smalltalk) meant to facilitate non-expert “programming,” to executives from Xerox PARC. This system was a kind of highly advanced programming language meant to make human-machine interaction at a very high level intuitive for non-expert users. At one point during a demonstration, a vice president, after an hour of working with the system, realized he was programming. What they accomplished, then, was a keystone for a software system which Kay felt bridged the gap between the numbers coursing through a CPU somewhere, and human intuitive reasoning.

Kay viewed programming as a natural aspect of human computer interaction, and he designed his systems to make programming the computer as easy and intuitive as creating a new Word Document or browsing the web is on modern computers. When Steve Jobs visited Xerox PARC and saw the Alto, he brought more than just the user interface to Apple Computers, he brought an entire philosophy of personal computing.

HyperCard

The Xerox PARC philosophy can be seen in a variety of technological lineages still discernible in the Apple universe. Objective C, a variant of the Smallktalk language, though without its attendant environment (the SmallTalk system), is still in use. Kay himself is quick to point out HyperCard, an early and still incredibly popular application environment, which encouraged user extension and programmability in a language called “HyperTalk,” which was inspired by Smalltalk and the Alto, was a good realization of the Xeroc PARC philosophy on the Mac.

Hypercard  Screenshot

A screenshot of Hypercard in action. Linked from here.

HyperCard, like much of the work from this period, defies comparison to modern software. Although often described as a kind of hypertexual rolodex, its “cards” could contain more than static information – they could also contain user-created multimedia and interactive components. Users would begin by adding cards for various pieces of information, but then, say as a card representing sales data grew to require a calculator, an interactive component for that purpose could be added. These components were themselves added interactively from within HyperCard.

HyperCard, and the people using it, organically grew many applications which left a permanent mark on computer history. A particularly telling fact is that the original version of the game Myst, a fantasy adventure game, was a HyperCard App. On the other side of the Atlantic, figuratively and literally, Renault, a french car manufacturer, used HyperCard to maintain its business inventory. HyperCard became the program its users needed it to be because it was open, extensible and encouraged user programming and interaction as a fundamental use-case. Even modern extensible software like Firefox tends to separate use from extension development – the average user might have no idea that Firefox supports user extension. In Hypercard, these features were “on the surface” of the design.

HyperCard also illustrates some of the difficulties that might be responsible for the gradual shift away from Xerox PARC-like open models of personal computing. According to rumor, the developer of HyperCard, Bill Atkinson, allegedly1 gave the product to Apple in 1987, with the understanding that it would be distributed for free with each Mac. The program was an immediate success. HyperCard produced a tremendous amount of feedback from the community, but since it was a free product, Apple wasn’t sure how much internal resources should be devoted to handling HyperCard development.

Perhaps seeking a way of turning the HyperCard phenomenon into a revenue stream, Apple eventually transferred HyperCard development to a subsidiary company, which attempted to transform it into a profitable business model. HyperCard was no longer released for free, but a locked down version, capable of playing, but not developing, HyperCard Applications was freely available. The “developer’s edition,” recognizable as just Hypercard, was available for purchase. In an effort to make HyperCard into a business model, Apple inadvertantly had separated users into “developers” and “users.” This, combined with the development of work-alikes with more features, seemed to destroy HyperCard’s momentum, and, despite later attempts at revival at Apple, the system fell out of use2.

Waiting for the Dynabook

Alan Kay invented the laptop computer – at least he developed a concept computer called The Dynabook which for all intents and purposes was a modern laptop and more. He envisioned that such a system, directed mostly at children (but usable by adults) would run Smalltalk, and while its possible to build the conceptual system Kay imagined in 1968 today, he still believes that the Dynabook doesn’t exist. Although tablet computers resemble the Dynabook superficially, and the One Laptop Per Child project comes close, Kay believes that his essential vision is unfulfilled. Kay points out, when asked about this, that the necessary technologies for a Dynabook device are quite old, but that corporate and cultural practices simply haven’t caught up to using them appropriately.

The Dynabook

Sketch of the Dynabook design (from Wikipedia.)

Consider by contrast any one of Apple’s iDevices. The touch screen, networking capability and user friendly design are reminiscent of the Dynabook, but, whereas on a Smalltalk system one could click on any widget and see and modify the source code, an iPad is essentially completely locked down. Not only does Apple require a license to develop and sell software for the iDevices in their “App Store,” but to even develop, for personal use, software for your own device, a separate “Developer’s Kit” (and the Apple Computer to run it on) must be acquired. Whereas Smalltalk was designed from the bottom up to facilitate programming for young and inexperienced users, the iPad targets its development tools, which are arguably byzantine by the standards of Smalltalk, to a relatively small group of developers. On top of that, software is only distributable after passing through an often arbitrary and, in any case, secretive Apple review process.

While the Dynabook was meant to be a device deeply rooted in the ethos of active education and human enhancement, the iDevices are essentially glorified entertainment and social interaction (and tracking) devices, and Apple controlled revenue stream generators for developers. The entire “App Store” model, then works to divide the world into developers and software users, whereas the Xerox PARC philosophy was for there to be a continuum between these two states. The Dynabook’s design was meant to recruit the user into the system as a fully active participant. The iDevice is meant to show you things, and to accept a limited kind of input – useful for 250 character Tweets and Facebook status updates, all without giving you the power to upset Content Creators, upon whom Apple depends for its business model. Smalltalk was created with the education of adolescents in mind – the iPad thinks of this group as a market segment.

HyperCard was, by comparison, much closer to the Dynabook ethos. In a sense, the iPad is the failed “HyperCard Player” brought to corporate fruition, able to run applications but completely unsuited for developing them, both in its basic design (which prioritizes pointing and clicking as the mechanism of interaction), in the conceptual design of its software, and in the social and legal organization of its software distribution system.

It is interesting that at one point, Jobs (who could not be reached for comment) described his vision of computers as “interpersonal computing,” and by that standard, his machines are a success. It is just a shame that in an effort to make interpersonal engagement over computers easy and ubiquitous, the goal of making the computer itself easily engaging has become obscured. In a world where centralized technology like Google can literally give you a good guess at any piece of human knowledge in milliseconds, its a real tragedy that the immense power of cheap, freely available computational systems remains locked behind opaque interfaces, obscure programming languages, and expensive licensing agreements.

The last 30 years have accustomed us to breakneck advancements in the technology we use every day, and yet at the personal level these advancements have been limited almost exclusively to communication and entertainment – so much so that arguably the public lacks even the the vocabulary to express what it is that modern computing could be doing for them or what they could be doing with modern computing. Spreadsheets are the closest most people get to “computing” with their personal computers. The electronic spreadsheet, which is itself an adaptation of an analog technology, was conceptualized in 1961.

If you ask Alan Kay about personal computing now, he is remarkably upbeat. In his view, the rapid development of technology simply outpaces the ability of corporate and educational systems to adapt, and this leads to a “pop culture” of sorts which dominates the culture of computer use. In other words, the divide between users and programmers, or at least between the truly computer literate and the merely casual computer user, isn’t a top down phenomena imposed upon the people by those in control of technology. It is an inevitable result of the rapid pace of development.

I think one of the main consequences of the inventions of personal computing and the world wide Internet is that everyone gets to be a potential participant, and this means that we now have the entire bell curve of humanity trying to be part of the action. This will dilute good design (almost stamp it out) until mass education can help most people get more savvy about what the new medium is all about. (This is not a fast process). What we have now is not dissimilar to the pop music scene vs the developed music culture (the former has almost driven out the latter — and this is only possible where there is too little knowledge and taste to prevent it). Not a pretty sight.

Alan Kay is still pushing for more symbiotic conceptualization of human/computer interaction, although he describes Smalltalk as part of his “distant past”. He presently heads a non-profit organization he co-founded called “Viewpoints Research Institute,” whose purpose is to continue to consider the questions of educational and personal computing. We’d never have gotten the iPhone if it hadn’t been for his influence at Xerox PARC. Maybe one day we’ll be lucky enough to get the Dynabook.


1 Bill Atkinson is presently a nature photographer and couldn’t be reached for comment.

2 However, HyperCard’s influence is still felt today. Last year, Dale Dougherty, editor of Make Magazine, wrote in wired that the iPad needed a HyperCard-type application. Tilestack, a web based, HyperCard-a-like with a pay-to-distribute model, recently went bust. Squeak Smalltalk includes a “Morph,” a kind of extendable program, which is loosely based on HyperCard. Although from a parallel technological lineage altogether, Emacs, which is still in wide use, and which the author used to write this article, resembles HyperCard in many respects.


Copyright J. Vincent Toups 2011

Slices of Mystery Dungeon 1: Rice Balls

Lately a lot of my free time has been dedicated to the development of a game called The Death Of The Corpse Wizard. The Death Of The Corpse Wizard is a coffee break roguelike which draws significant inspiration from one of my favorite games, Mystery Dungeon: Shiren the Wanderer. I’ve also been playing Peculiar Games’ Voyage To Farland, which is, like Corpse Wizard, inspired by the Mystery Dungeon series. So Mystery Dungeon has been on my mind.

In this series of posts I’ll try to unpack exactly what it is about Shiren that makes it a successful game. To keep the analysis focused, each post will focus on a slice of the gameplay mechanics. Today’s slice begins at the beginning:

Shiren

The sense of adventure that Shiren manages to evoke is a whole other article.

Every game of Shiren begins in The Canyon Hamlet, which is a medieval Japanese village populated with a cast of characters, many of whom are seasoned wanderers themselves. There is a small restaurant which, if you visit, the bar keep of which will give you a Rice Ball. Rice Balls are food, and they will be the item with which we begin our analysis.

A Digression On Food Clocks

Roguelikes distinguish themselves from other role playing games in their commitment to present the player with mostly meaningful choices. Like traditional RPGs, most roguelikes feature a system of progression whereby the killing of monsters translates into experience points, which themselves translate into improved ability to kill monsters. Numbers, as they say, go up.

However, in most traditional RPGs one is free to wander around indefinitely, killing randomly generated monsters until one’s level is arbitrarily high. Because monsters generally spawn indefinitely, one is free to exchange as much boredom as they can stand now for as much ease as they want later. And because, with each additional level the player gains, all subsequent encounters become easier, this so-called grinding becomes boring very quickly. People play games for all sorts of different reasons, but I advance that “trade boredom for easiness” is not the most compelling of game design principles.

Let’s take it as a given that Roguelikes use RPG-like undermechanics, with statistics mediating encounters, and where leveling up controls those numbers. If the game design is to present interesting choices, then the player must never be far outside of a particular level-range at any given moment; a level range designed to ensure that the player must take care. How does the game designer achieve this balance?

Modern roguelikes are experimenting with a variety of possibilities (The Death Of The Corpse Wizard, for instance, simply doesn’t have levels at all, and the game moves forward whether the player wants it to or not), but Shiren is fairly traditional: it uses what is usually called a “Food Clock,” which just means that Shiren has a timer that slowly ticks down and which, when it reaches zero, kills the player. In order to make the timer go up again, the player must make Shiren eat, which means she must find food, and since items don’t spawn infinitely, or do so with a frequency insufficient to avoid starving to death, she must move Shiren ever forward. By adjusting the food clock, the game designer can change how hard she pushes the player forward, adjusting the difficulty of the game.

So the take away of this digression is that the player needs food. In Shiren, food mostly comes in the form of Rice Balls, almost always either a Small Rice Ball or a Large Rice Ball.

Jars

When the bar man gives you your free Rice Ball, he gives you some advice about the proper care and maintenance of Rice Balls. There is a trap, you see, in Shiren The Wanderer, which will cause your Rice Balls to go bad. A bad Rice Ball only recovers a small amount of hunger and it also usually causes a negative status effect of some kind.

I want to stop and remark upon this, the most basic of mechanics. It would have been easy for the designers to simply destroy your rice balls on certain traps, but instead they transform them into risky items: they might save you from starving to death, but they might also make you fall asleep, and hence be helpless against monsters. The choice to eat a rotten Rice Ball, then, is pretty interesting. You have to think hard about it.

That point aside, you don’t want your Rice Balls to rot. One way of preventing them from rotting is to eat them right away: like a Fremen in a still suit, the best place for nutrition is, after all, in your body. Here Chunsoft again demonstrates an unusually good design instinct: you can only have a maximum satiation of 100%. Big rice balls give you 100%, so the optimal time to eat them in the absence of traps is when your satiation is at zero, but Small Rice Balls give you 50%, so you can eat them at 50% satiation and maximize their utility. So paradoxically, Small Rice Balls are better than big ones, because you can eat them sooner, and hence they have a lower probability of being spoiled. Large Rice Balls, on the other hand, will either waste their satiating ability or risk going bad.

With just two items, a trap and a single mechanic, Chunsoft has created a rich environment to balance risk and reward. That is good design.

And that doesn’t even include what happens when you add jars into the game. For simplicity, let’s assume that there is just one type of jar, the “Jar of Holding.” As the barkeep says, if you put your Rice Balls inside a jar, they won’t go bad, even if you step on a trap. You can eat Rice Balls directly from the jar, without taking a turn to take them out, so if you have a jar, it makes sense to load it up with any Rice Balls you find.

However, there are monsters which steal items in Shiren, and they will occasionally steal one of your jars. If you have put all of your rice balls in a single jar, then you’ll lose all of them if they get stolen.

Note here that, short of recovering your jar, which is possible, but difficult, you lose the Rice Balls. If they rot, they are still semi-valuable. There is not an exact parity between the consequences of carrying your Rice Balls around and the consequences of stashing them in a jar. This is a good game design: you have to choose between similar, but not exactly identical, risk profiles. If you have a leather shield, for instance, which reduces the rate at which you get hungry, it makes more sense to risk letting the Rice Balls rot, because the 30% satiation that a rotten Rice Ball gives you is actually pretty solid, in exchange for the temporary negative side effect. The detailed breakdown is a bit more complicated, but that is the idea.

Conclusions

As we look at the design of Mystery Dungeon: Shiren The Wanderer we’ll see that most of the mechanics in the game are balanced against one another in a way similar to the way Rice Ball rotting traps, jars, thieves and hunger are so balanced. In a turn based game design, where things proceed in a fairly deterministic fashion, the whole richness of the game is in these interacting systems.

As I develop The Death Of The Corpse Wizard, I’ll be trying to invent or steal such mechanisms. Hopefully I will succeed.


Not-so-live Blogging new “Death of the Corpse Wizard” changes

Some updates to “Death of the Corpse Wizard”:

ZAP

ZAP

Skeletons now behave much more intelligently and will try to slowly break walls if they cannot find a path to you.

Brutes do twice the damage they used to the player.

Wizard bolts do not travel through walls.  Using a bolt will cost you one health but give you one health for each monster it hits, so lining monsters up is the best way to gain ground in health/vitality.

Play the game here.

Liveblogging Adding a New Monster Type to “Death of the Corpse Wizard”

Hi folks.  Yesterday I developed a complete, but tiny and probably not fun, game called “Death of the Corpse Wizard”:

Death Screen

Death Screen

 

The point, yesterday, was to get me over the hump of having created my first entirely playable game.  Today I’m going to try to add features to the game which make it more fun.  

I’ll be updating this post as go, as usual.  

Today’s goal is to add a different monster type and to modify the behavior of the Skeletons.  Presently there is but one kind of monster, skeletons: skeletons spawn anywhere on the screen and always move towards the player by selecting the square which is closest to the player’s position.  If the square the want to move onto is blocked by a pillar, which the player is able to create, then they attack the pillar first.

The revisions planned for today will make the Skeletons track a path around the pillars, if they can, while a second, tougher monster type will behave as the skeletons do now.

UPDATE: 1:54pm, Strasbourg Time:

Added the new monster sprite.  Next I am going to integrate pathfinding from an external library.

GIF!

 

UPDATE 4:03PM Strasbourg Time

I’ve added the second monster type with its own unique behavior and modified the Skeletons.  Now the brutes will break your walls as you build them and the skeletons will try to find a path into your fortress if one exists.

Right now they sit around doing nothing if they can’t see one, so I’d like to modify the behavior so that they try to get as close as possible until a wall opens up.

08

 

Check out the new aggressive little guys!

UPDATE 5:46 pm, Strasbourg Time

Now it has some real game elements!
You can zap multiple monsters at a time, which encourages you to construct walls to direct them into lines.  The zap special effect is invisible for now, but I can fix that later.
And there is a second monster type which smashes through walls.  So a nice little game.  I can already see how to balance the game to make it more fun.

 

I’m done for the day, so here is a link to the current version.

Commentary on Mike Bostock’s “Towards Reusable Charts”

A colleague recently asked me to comment on Mike Bostock’s “Towards Reusable Charts” since I have the distinction, at the company, perhaps not entirely deserved, of knowing Javascript and being something of a programming language theory dilettante. The upshot of the article is that we can represent configurable charts using that old PLT observation that there is a close relationship between closures and objects. The ordinary approach, outlined, for instance, in SICP, observes that you can encapsulate your object state and methods inside a closure, and provide an interface to that closure via the function which gives you a handle on it. In scheme:


(define (Point x y)
  (lambda arguments 
	(match arguments ; only barbarians suffer lack of pattern matching
		   ((list 'x) x)
		   ((list 'y) y)
		   ((list 'set 'x value)
			(set! x value) ; or purely (Point value y)
)
		   ((list 'set 'y value)
			(set! y value) ; or purely (Point x value)
))))

(define p1 (Point 0 0)) ; -> #
(p1 'x) ; -> 0
(p1 'set 'x 100)
(p1 'x) ; -> 100
; and so forth

Who cannot look upon this and give a little chuckle? It is a neat little trick about which we can observe a variety of things. First of all, this is admirably encapsulating. There really is no way for a user to get their dirty little fingers into the inner workings of our instance. True to its name and to its mission in life as the fundamental unit of abstraction, our closure is sealed up quite tightly. The second observation is that we are basically implementing message dispatch by hand – a feature usually handled by the implementation language which is a bit smelly, but the sort of thing people do in Scheme all the time. And anyway, the encapsulation might be a bit too heavy handed: how do we debug or interactively play with such objects? This isn’t exactly unsolvable, but it is a downside to the approach.

Bostock presents a slightly modified version of this trick anyway. In Javascript, functions are objects, and as such they may have methods attached to them. Rather than implementing dispatch himself by inspecting the arguments to the returned closure, he attaches methods to the function object. Since they capture the same closure as the returned function, they too can interact with the state of the simulated object. Eg:


function Point(x,y){
  var closure = function(){
    console.log("x:"+x+", y:"+y);
  };
  closure.setX = function(newVal){
     x = newVal;
  }
  closure.setY = function(newVal){
     y = newVal;
  }
}

var p1 = Point(1,2);
p1() // -> prints x:1, y:2
p1.setX(10);
p1() // -> prints x:10, y:2 

So this version of the trick is a bit less encapsulating. There are definite private member variables here, but the methods are accessible to the outside world.

This approach, while superficially clever, leaves some things to be desired, mostly related to integrating into Javascript's admittedly confusing and arguably poorly designed object oriented programming "ecosystem." First and foremost, Javascript instanceof operator will not give you any meaningful information ( Point(1,2) instanceof Function and Point(1,2) instanceof Object will be true, but Point(1,2) instanceof Point will be false). The even less useful, but frequently used, typeof operator will also give you the unhelpful answer "function". Javascript pretty clearly exposes functionality to the user pertaining to object orientation. I would argue it is just bad style to ignore it. On top of that, this technique doesn't have any obvious mechanism for implementing inheritance. While I agree that inheritance hierarchies should be shallow, this pretty much prevents any inheritance at all.

Even if we swallow these peculiarities in favor of the encapsulating that this technique furnishes (its only major benefit besides returning a callable object), we still must observe that there are efficiency concerns operating here: each time we construct a new object we construct a new set of methods because they must access the enclosing object's scope. We can ameliorate the implementation somewhat, but not without making it more peculiar and sacrificing certain things, like callability. I leave how that might work to the reader, in favor of describing the contemporary standard method of implementing object oriented programs in Javascript.

Javascript and Families have a problem in common: resolving inheritance

In Javascript, we generally create objects via an unholy collusion of the new operator and a regular function definition. Eg:

function Point(x,y){
  this.x = x;
  this.y = y;
}

Point
.prototype
.toString = function(){
  return "new Point("+this.x+","+this.y+")";
}

var p = new Point(1,2)
console.log(p.toString()) ; -> new Point(1,2) 

The new operator creates a fresh object for us, set's its `prototype` in such a way that it points to an object at Point.prototype, invokes the function Point in such a way that this is bound to the newly created object, and then finally returns the object, regardless of the return value of Point, though I like to return this from constructors just for the sake of consistency.

One does not access an object's prototype directly, but when a lookup on an object is attempted, the prototype will be checked if the object doesn't have the item, and then the prototype's prototype, etc. This is why we set Point.prototype.toString instead of putting the method directly on the object. This is good organization AND it means the method is only created once. This setting up of the prototype also ensures that when we use instanceof we can find that our objects are indeed instances of Point.

If you know Javascript, all this probably seems uncannily clean. You might be wondering why we'd be tempted to cook up our own mechanisms of object oriented programming, given that this seems to be the way the language intends for us to do it. The rub is what happens when we want to do inheritance. Here is a naive attempt to extend Point, supposing we wish to embed the point in a mathematical Field:

function FieldPoint(x,y){
  Point.call(this,x,y);
  return this;
}
FieldPoint
 .prototype
 .multiply = function(byPt){
  this.x = this.x*byPt.x - this.y*byPt.y;
  this.y = this.x*byPt.y + this.y*byPy.x;
}
FieldPoint
 .prototype
 .add = function(withPt){
   this.x = this.x+withPt.x;
   this.y = this.y+withPt.y;
 }

Astute readers will recognize that these points are like complex numbers, and indeed are a field. So far so good. However, things start going wrong when we experiment with instanceof. For instance

var p = new Point(1,2);
var fp = new FieldPoint(1,2);

console.log("p is instanceof Point: ", p instanceof Point)
console.log("fp is instanceof FieldPoint: ", fp instanceof FieldPoint)
console.log("fp is instance of Point", fp instanceof Point)

gives us:

p is instanceof Point:  true
fp is instanceof FieldPoint:  true
fp is instance of Point false

Once again we are breaking what I take to be a good rule of software engineering, which is to avoid violating expectations implied by some system. In this case, we would expect our subclasses to be instances of their superclass, which they are not. Here is the standard way that people do inheritance in Javascript (put your thinking caps on):

function extend(subClass, superClass){
	var inheritance = (function(){});
	inheritance.prototype = superClass.prototype;
	subClass.prototype = new inheritance();
	subClass.prototype.constructor = subClass;
	subClass.prototype.superConstructor = superClass;
	subClass.superClass = superClass.prototype;
}

function Point(x,y){
	this.x = x;
	this.y = y;
}

Point
	.prototype
	.toString = function(){
		return "new Point("+this.x+","+this.y+")";
	}

function FieldPoint(x,y){
	Point.call(this,x,y);
	return this;
}
FieldPoint
	.prototype
	.multiply = function(byPt){
		this.x = this.x*byPt.x - this.y*byPt.y;
		this.y = this.x*byPt.y + this.y*byPy.x;
	}
FieldPoint
	.prototype
	.add = function(withPt){
		this.x = this.x+withPt.x;
		this.y = this.y+withPt.y;
	}

// FieldPoint extends Point 
extend(FieldPoint, Point);

var pt = new Point(1,2);
var fp = new FieldPoint(1,2);

console.log("pt instanceof Point", pt instanceof Point);
console.log("fp instanceof Point", fp instanceof Point);
console.log("fp instanceof FieldPoint", fp instanceof FieldPoint);

This should result in the following being printed

pt instanceof Point true
fp instanceof Point true
fp instanceof FieldPoint true

As an aside, people usually put extend on the Object object so that you can simply say something like: var newclass = someClass.extend(newConstructor);.

Recapitulation

So, to wrap up, the Bostock model is a variation on the old "use closures as objects" model, with the advantages that the object is callable, and the internal state is completely private. The downsides are that each object so constructed recreates its methods at creation time, which may be burdensome, depending on the use case, that the data is entirely private, that there are no mechanisms for inheritance, and the objects do not behave meaningfully against expectations about how Javascript object oriented programming works.

The standard behavior, more or less outlined above, but present in variations throughout the Javascript world, is idiomatic, behaves meaningfully with respect to `instaceof` and allows inheritance. There is less privacy of internal state, but this is generally not considered to be deeply problematic. In general, without a compelling reason to adopt the technique of punning a closure into an object, I'd favor the more standard approach. It's downside is that, like many things in Javascript, its a bit weird. But at least it is weird with, rather than against the grain.