Planet Ludum

I’ve had the good fortune to be involved with playtesting and contributing to a new game this past month.  While it is played on a computer it is not actually a computer game.  My good friend and fellow game designer Jeremy P. Bushnell has created a new game called Wikipedian Tag.

“It involves using the vast, super-complicated structure of Wikipedia as a play space, an environment through which one player chases another. I like to think of it as a kind of competitive parkour through the architecture of all human knowledge, but calling it “tag” is a little simpler. It’s easy to learn and loads of fun.” – Jeremy

Here is the complete version 1.0 ruleset posted with permission.

WIKIPEDIAN TAG – Version 1.0

OBJECT

Same as regular tag: for one player (”It”) to catch another player.

SETUP

• Find a free block of time. About an hour is good.
• Find at least one other player. The game can be played either in the physical presence of the other player(s), or remotely (I’ve played it a number of times using Gchat).
• Determine one player to be “It” (who I will also refer to as “the chaser”) and one player to be the one who is being chased by it (who I will also refer to as “the runner”)
• Each player privately selects a page in Wikipedia—any page—to be their starting point. Once both players have made their selections, they reveal their starting points, and the game begins.
• The chaser goes first.

GAMEPLAY

• Players take turns.
• On each turn, a player “moves” by following at least one link that leads from a Wikipedia page to another Wikipedia page.
• The chaser is faster than the runner, so on each turn the chaser gets to move twice. For instance, if the chaser was on the page for Brooklyn, they could move to the page for Yiddish and then from there to Aramaic. This would constitute a complete turn for the chaser.
• The runner has the advantage of unpredictable mobility, so s/he is only permitted one move per turn.
• Each player reports their moves as they make them, so that both players know the location of the other player at all times. The runner may look at the page the chaser is on, and the reverse is also true.
• If, at any time, the chaser is on the same page as the runner, the runner is “tagged” and the game ends. (In the above example, if the runner was on the “Aramaic” page, s/he would be tagged.)
• Confused? Check out the sample games below.

A RESTRICTION ON THE RUNNER

• The nimble runner has one restriction upon her or his mobility: s/he may only follow links that are one word. This means, for example, that s/he cannot follow links to the BBC Radiophonic Workshop or the List of fictional games or even Thomas Jefferson.
• Note that some one-word links do direct to pages with multi-word titles; these are fair game for the runner. For instance, the runner could reach the Thomas Jefferson page legally if the link read simply “Jefferson.”
• Acronyms such as IBM count as one word and thus are legal, as do hyphenated words.
• Note that this restriction can occasionally lead the runner onto a page for which there is no legal escape: in this case the runner must use her or his next turn to “backtrack” to the page they s/he was on previously.

A RESTRICTION ON THE CHASER

• The relentless chaser also has one restriction upon her or his mobility: s/he may not reduplicate any exact move made by the runner. S/he must find a creative route to where the runner is rather than simply locking in to an earlier point on the runner’s trail and catching up using the brute force of their superior speed.

RESTRICTIONS ON BOTH PLAYERS

• Neither player may follow a link that will take them outside of Wikipedia. Be especially cautious about accidentally following links that might take you to a Wikipedia “sister project” such as Wiktionary or Wikiquote.
• Neither player may use the links in the left sidebar, including but not limited to the “What links here” tool in the toolbox.
• Players must move: neither player may pass a turn or a portion of their turn.
• While it is legal for players to look at the page their opponent is on, it is considered bad form to look at other pages in Wikipedia during the course of the game, and it is illegal to “peek ahead” to see the content of a page you are thinking about visiting as part of a future move.
• Despite the occasional strong temptation to do so, neither player may do any editing to Wikipedia during the course of the game.

SOME VARIATIONS

• Variations for more than two players are simple: you may play a game where there is one runner being pursued by multiple chasers, or a game where one chaser is pursuing multiple runners. In either of these variants, the players who are “multiplied” in this fashion make their moves concurrently.
• In the basic game, as in real Tag, the game continues until the chaser catches the runner, or until the runner forfeits out of exhaustion. More satisfying end-games can sometimes be generated by an agreement, before starting play, as to how many turns the game will last before the runner will be considered victorious. (I’d recommend 20 turns—20 moves for the runner and 40 for the chaser—although this can be adjusted for the time available or to reflect the relative skills of the players.)

TWO SAMPLE GAMES

GAME ONE
	Chaser	Runner
Starting point	Anasazi	Firefly (TV series)
Turn No. 1	»Cowboy Wash »Molecular biology	»Courtesan
Turn No. 2	»Rockefeller Foundation »Alfred Kinsey	»Witchcraft
Turn No. 3	»Homosexuality »Lesbian	»Necromancy
Turn No. 4	»Willow Rosenberg »Druid	»Chaucer
Turn No. 5	»London »History of London	»Pseudepigraphy
Turn No. 6	»Protestantism »Roman Catholic Church	»Tanakh
Turn No. 7	»Old Testament »Tanakh TAG	TAGGED
GAME TWO
	Chaser	Runner
Starting point	Weather	Probability density function
Turn No. 1	»Predictions »Probability	»Kurtosis
Turn No. 2	»Probability theory »List of probability topics	»Parameter
Turn No. 3	»Location parameter »Statistics	»Dag Prawitz
Turn No. 4	»Mathematics »Mathematical proof	»Philosopher
Turn No. 5	»Philosopher TAG	TAGGED

Wikipedian Tag, by Jeremy P. Bushnell is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.

Hey, I guess I should make new posts here sometimes! Here's a Pikachu I did today for the tigforums renditions thread:



Tried a new (for me at least) method of doing shading for this one (using Gimp). In stead of just blobbing everything together in an unholy mess like I usually do, I made a dedicated layer for every color, so eg Pikachu up there has a layer for yellowish, orangeish, brownish, and so on. Each of these color layers are opaque and completely filled with its assigned color. They also have a layer mask where you can do the actual shading, working with opacity in stead of mixing colors.

Masks are greyscale, so all shading is done with just black and white. There's no need to mess with repetitive color picking -- just select the layer mask for the layer with the color you want to modify and draw away, and hit X to switch between black (transparent) and white (opaque). Pressure sensitivity gives you shades of grey for varying degrees of translucency. Also, since every color is kept separate at all times, you can unmix colors, change the effective palette at will (automatically remixing colors!), etc. Color priority is fixed, but you can always have more layers of the same color if that turns out to be a problem.

Anyway, I really like this way of shading. The way Gimp works, or maybe the way I work with Gimp, my old way tended to degenerate into extended periods of, well, pain, because something always got screwed up. This new way is rather the opposite. It's very liberating.

(Also, I've been neglecting the sketchblog.. I'll post something new there soon.)

I started this as a reply to increpare's question: How much do you plan on characterizing each of the playing areas?

I thought it would make a good dev blog post.

Define "Area"

For the purposes of this blog post, I should explain what I mean by "area".

Each "area" is a 50x50 block that you can think of as being closely analogous to a "screen" in non-scrolling games. That is, it normally fits within a greater geography but creates a very concrete sense of location. When the player leaves one area, they hit an edge and the next one loads. It's a somewhat abrupt and very deliberate transition. As a result, the player's sense of location in the game world is discrete: she knows she is on the area (screen) with the waterfall, not just "near to" the waterfall.

In that sense, each area is mainly characterized by it's shape, and it's contents: where are the exits, walls, and what buildings or set pieces are inside of it. I lay trees/rocks out in certain patterns or try to create distinctive points of interest on each area. By the same token, other areas are more anonymous in feel (e.g., somewhere in a forested area); they seem to just be a "forest square". Even so, landmarks such as bends in a river or particularly placed trees are helpful.

Greater Geography

Beyond this the game is broken down into a greater geography. There are "real world" and a "alternate reality" planes which have slightly different color sets and terrain types, as well as completely different trees/rocks/walls/etc. This creates a nice division between the two.

Within each plane, I try to create a sense of location by how I lay out objects and how areas flow into each other. So for instance, certain flowers may be very prominent on the southwest corner of a map, across several areas, but not at all existent on the southeast corner. Other, larger "places" help to define the areas such as a castle, graveyard, or town.

Certain elements also flow between areas; so farms have fields that cross across boundaries and walls which pass through several areas. We have to follow the walls (usually by walking on a path) to a nearby gate to get through (although in many cases there are crumbling sections which not only add interest but prevent you from having to walk all the way around).

Start With Setting

Lastly, or rather, firstly, I start off thinking of setting. The first thing I usually want to create is the setting, and that means mapping. So I draw maps on paper, changing and reorganizing, until they seem to have interest and look natural.

All this, without respect for the gameplay they will later have to support. For the most part, the entire game world was created before I had a good idea as to the specifics of locations, or other functional elements (e.g., crossing a bridge or getting through a certain cave to reach a more advanced area). I think this approach creates a better sense of place, so that you feel the game world is quite logically organized.

I also think this is a more authorly way to work. Do novelists start off by thinking of a story and then construct a setting to fit around it? Of course not. A setting inspires a story and if it's not based on a real place or time on planet earth, then typically requires a lot of imagining on the author's part.

Of course, you make modifications to your setting to fit your story, once you have it in place and realize what you need.

End Result: Believability

The purpose of this kind of organization is to allow the player to orient themselves within a believable world. We give them enough landmarks and subdivide the world into discrete blogs to give them a very good sense of where they are at all times. At the same time, we have a greater sense of geography that we constructed to be interesting in the first place, before we started to think about gameplay and story. What we end up with is a world that both feels natural and is easy to understand: and hopefully somewhere fun to be!

Persistence is Key, but...

Finishing a game requires a LOT of persistence and a lot of ability to just plough through small details and so forth.

But sometimes you need to recognize when something you're working on should be just dropped. I don't mean a whole game, I mean a feature or an idea. You've already decided to add a certain feature; how do you undecide?

When to Stick To It

You can't just undecide based on difficulty. Some features may be necessary but fairly painful to implement, for example hunting down memory leaks. This could take you a few days but you can't really avoid it. For these, I think you just have to stick to it.

Other features may not be necessary but seem like a good idea. I.e., if you could get this feature in it would fix certain gameplay-related problems. In this situation, I think you normally have to follow through as well. Reason being, if you don't pay attention to certain problems with gameplay, those problems are going to ruin the whole rest of your game.

Sometimes you can comprimise. For instance, a blog post or so ago I talked about NPCs opening doors. "Properly", the NPC should determine that they are in front of a door, stop, open the door, walk through, stop, and close the door. This is a ton of game logic. Instead, I took the middle ground and had them detect when they were already on top of a door, open it (so that technically it opens late) and then once they are off of it, close it. They don't stop, and they technically pass through the door before opening it. But it's a good comprimise. Without this, the game have a rather large gaping "hole": NPCs would pass miraculously through doors. I can't really get away without fixing that.

When to Cut Your Losses

So when do you actually decide to cut your losses and drop a feature altogether?

I would say, you "undecide" when you realize that you made bad decision, and why.

Recently, I decided to clean up the side-to-side area transitions. When you move from areas on the world map, there was a "wiping" transition that sort of wipes the screen to black, then unwipes it. Not really terrible but as someone pointed out, quite jarring. I had stopped seeing it as jarring, but after reading a comment on a video I realized, in fact, it was.

This is probably something I need to fix, one way or another. It breaks continuity in a fairly major way.

But I made a bad decision. I wanted to make the screens "slide". If you've played the original Legend of Zelda, or the SNES version Link to the Past, you know what I mean. I thought this would be a nice retro effect, and provide good transition.

But there were problems with decision:

Problem One: * vs. 1

First, the game engine was built from the very start to assume there is only one "area" live at a time. This was in order to simplify implementing many things and to remove many design decisions that would otherwise have to be made. As well, it gives the player a nice sense of "concreteness"; the game is divided into discrete areas, so they have a good sense of where they are.

Allowing for a slide transition meant I had to jerry rig the engine to have more than one area open or "live" at once. This was problematic, though I eventually did actually get it working. Not a total hack, but far from elegant. And it had (as you may expect) some unforseen consequences that would have required perhaps some painful fixing, for example there were lighting and "noise" seams between areas.

Framerate also dropped off significantly during the slide transition, because we're rendering more than one area at once. This sort of negates the benefits of sliding, since the framerate becomes chop-city.

Problem Two: Coordinates

The other problem had to do with the camera, and coordinate systems. Again, stemming from the fact that I only wanted one area open, everything is coordinated relative to the current area. Changing areas means recoordinating: the camera now needs an offset, we need to know where the player should be relative to each screen, etc. etc. Ugly!

Solution

The first part of the solution was to dump this idea, which I happily did. I needed to recognize why I had made a bad decision, and cut my losses. It's not just that it was difficult. It was difficult BECAUSE it conflicted with other core design decisions made for the game.

The second part is to come up with a replacement that will not be so disrupting. In this case, I need some element to create a sense of continuity. That element, it turns out, will be the sky.

The sky right now during the daytime shows just blue (at nighttime it shows stars, which is good). My plan, not yet implemented, is to have clouds going back and forth on the sky. I will then have a nice faux-reflective effect on water surfaces which shows this sky. The effect is overall somewhat trippy, since the sky is visually "below" you (rendered underneath the terrain, along the edges) but in reality represents something "above" you. It was a cute idea when I had it and a great one.

What I'm going to do is put animated clouds on the sky. These clouds will blow back and forth peacefully creating a nice sense of place. When I transition between areas, I will wipe not the entire screen but just the terrain/area etc, so that the sky shows beneath it. This way, we get a greater feeling of continuity without violating the core mechanic.

Later, I can update it to also show the player (a bit tricky, but it should be possible), and the effect should be complete.

Conclusion

Don't give up on solving problems that need to be solved, but cut your losses when you realize you've made a bad decision.