On Doors in Games

It’s been a while since I’ve written about games here. This is a draft post from a few years ago; on rereading I think it’s worthwhile.

Doors in Penumbra: Overture

Some time ago, I started playing Penumbra: Overture, the debut first-person horror-adventure title from Frictional Games. I never finished the game or ever played very far in, but I wanted to comment on a satisfying mechanic seen early in the game: manual manipulation of objects — but particularly hinged, swinging doors.

Yes, I’m going to talk about doors in a video game, but I’m certainly not the first.

A little background on the game. Penumbra: Overture shares the perspective and control scheme of first-person shooters (WASD keys and a mouse), and although one combats enemies, this is not a first-person shooter. Your avatar, one Philip stuck in an abandoned mine, has panic attacks when he confronts enemies: breathing contracts, vision is marred, and Philip may stand and reveal himself in a nervous outbreak. Combat is similarly frantic and amateurish. Outside of doors, a player can manually slide, slam, stack, etc., various objects in the game by clicking and holding them, and then moving them onscreen with the mouse. This leads to some physics-based puzzles and object manipulation, and provides a strong sense of analog mechanics at work in the world.

Doors in First-Person Shooters

Let’s return to the operation of doors in the game. It makes design sense that so few (if any) first-person shooters contain hinged doors opened by degrees with a mouse. If the central activity is gunplay or melee, operating a door is a distraction.

Apart from gameplay, it is computationally much more expedient to implement a simple sliding or pocket door. This door will use the same animation every time, and if the game runs a genuine 3D engine, it may remove the need for on-the-fly numbers crunching. In a pseudo-3D system such as seen in the original Wolfenstein 3D, implementing a hinged door would be absurdly difficult and perhaps technically impossible. Thus the player is confronted with the same door sliding door for the entirety of the game and its sequel, from the opening jailbreak setting to officers’ quarters, secret labs and bunkers. Whatever the fiction of the setting, the door never changes.

Going back to gameplay however, a sliding or pocket door features only two states for the player: open or closed. Instead of the player encountering a panel on hinges which he or she must manipulate by degrees to pass through, the player encounters a flat, essentially 2D barrier (even in the case of more modern titles like Halo) that only needs a single button press (if that) to open. The player passes through such doors completely or not at all. Even when it is opening and visually between open and closed, it is functionally closed; when it is seen to be closing it is still absolutely closed and impassable. Many games that feature hinged doors use a preset animation, or use it as a loading screen (Resident Evil). In all cases, doors are a binary gate.

And this is acceptable. It is of course the point of doors, to let something in or out, or keep it in or out. We didn’t make doors for them to be halfway open, although as it happens many are.

Doors of this type are found in numerous older first-person shooters: Blake Stone, Doom, Duke Nukem 3D, Rise of the Triad. Even a modern title like the aforementioned Halo, which could easily implement a hinged door, has no need to do so. Esoteric or exotic settings have their clear attractions as game worlds for players, but they arguably have equally if not more compelling attractions for programmers, developers and designers. Automatic, two-state doors are infinitely easier to implement than a board that swings, by degrees, on hinges, and it’s reasonable to expect to find such doors in science fiction or otherwise futuristic settings. By that time superior door-tech  would have eliminated any instances of halfway open doors.

(This of course goes into the long tradition of technical constraints informing a game’s fiction. I have a growing mental catalog, from Mario’s design to the preponderance of bald space marines.)

Immersion and a Hinged Door

So Penumbra: Overture‘s doors can be neither entirely open nor entirely closed. Why is that so interesting?

I’m sure some of my interest has to do with how such creaky, realistically old doors contribute to the atmosphere of the game. But it’s also jarring to see something in a middle state, a state that’s not precisely describable. I could say the door is open just a crack, or mostly open, or even halfway open, but these are not absolutes like open and closed. I can have any number of different views into the next room depending on these highly adjustable degrees, as I try to imagine what is still obscured by the door panel.

It is the mundanity of operating the door, and of noticing the space it occupies, which is so compelling. Taking the time to operate the door feels slightly unreal – I’ve never had to think about opening a door in a game, and I mean really think about moving the hinged board over. Each door is opened differently, depending on my angle to it and the position of my mouse. Having to concentrate on this, however briefly, immerses one into the game unexpectedly, and reifies the world suggested onscreen.

Considering again the automatic sliding and pocket doors of first-person shooters: their prime function is to demarcate rooms and divide the player’s challenges appropriately. They reinforce the gameness of the world in that way, in their ability to be completely in the way or completely out of the way. Penumbra: Overture‘s developers do make use of their doors in gameplay. In some cases one needs to block the door from a pursuer. The tension here is that the door returns to its original binary function: it will either be open for the pursuer or closed, and one can watch as the door, by degrees, is forced open. Frequently however the doors are simply wonderfully described objects that exist in the game, outside of your immediate concerns.

This leads me to wonder what other games have used mundane details or provided interactions utterly unrelated to the central gameplay to enhance the realness of the world (and I do not count side quests and such as are found in RPGs: they almost all have very applicable benefits for the player)?

In any case, that lack of a definite state is refreshing, as it happens so little in games. When opponents are felled in a shooter, they are almost always absolutely felled: you do not often maim an opponent with an errant shot and have to deal with his or her suffering. Levels are completely finished, quests are definitely open or closed, achievements are either unlocked or locked, etc. How often can one badly hurt an opponent, and then move on to the next area? If you came back, would it still be there — would you have to hit the opponent a few more times to finish the job? This is the sort unsavory midway point games have dealt so well in discarding, one could argue games have to discard this aspect of our lives to be games at all. In any case, so many games belong in the province of fantasy that dealing in totalities makes thematic (along with the aforementioned technical) sense. Still, it is awfully nice to engage with a world where a few mechanics, at least, are not figured in such absolutes.

Dwarf Fortress Interviews

Dwarf Fortress screen

Before the week is out I wanted to post to the NYT interview with the Adams brothers, who design and build the incredible labor of love that is Dwarf Fortress.

I had the opportunity to interview Tarn Adams (audio and transcript available), who programs the game, for the game preservation project I worked on in school (all interviews are here at the Center for American History). Tarn is a standout guy, who is awfully generous with his time considering the colossal task ahead of he and his brother. He gave a great interview that illuminated important parts of their game-making, which is in kind with the idiosyncratic and singular quality of Dwarf Fortress.

Check out the NYT interview — Tarn has thoughtful and provoking comments on playing games these days.

And, if you haven’t tried Dwarf Fortress, give it a go sometime. I played it for a year on and off – one day I’d like to make a return to it. It’s not as hard as all that, really – although you should have the wiki open as you play.

Complexity and Coupling: Pushmepullyou

As some may know, I have recently been hired at the Mississippi Department of Archives and History. It’s the end of my third week here and it’s been great: great coworkers, interesting materials (I’m working with electronic records in the government section) – and I’ve been able to overhear the back-and-forth on a recently completed project which saw us transitioning from one online catalog to another. It was successful – do not worry.

But for anyone who has worked in IT at all ever, or just had to approach a problematic system and put out the fire may appreciate the elegance of this statement.

Systems that are both tightly coupled and highly complex, Perrow argues in Normal Accidents (1984), are inherently dangerous. Crudely put, high complexity in a system means that if something goes wrong it takes time to work out what has happened and to act appropriately. Tight coupling means that one doesn’t have that time. Moreover, he suggests, a tightly coupled system needs centralised management, but a highly complex system can’t be managed effectively in a centralised way because we simply don’t understand it well enough; therefore its organisation must be decentralised. Systems that combine tight coupling with high complexity are an organisational contradiction, Perrow argues: they are ‘a kind of Pushmepullyou out of the Doctor Dolittle stories (a beast with heads at both ends that wanted to go in both directions at once)’.

That is poetry. From Donald MacKenzie in the London Review of Books (link added). Itself from a post covering Amazon’s April 2011 cloud outage at David Rosenthal’s always-excellent digital preservation blog.

Handling Results in Fedora’s REST API

Lately I’ve been working to put in more development time with the Fedora repository at the Goodwill Computer Museum.

A PHP ingest interface we’ve set up is certainly the most developed of the our repository’s services, but there’s a strong need to relate one object to another as it is being ingested. To do this I want to provide the user with a drop down menu of objects in the repository which fulfill some criteria (say, the object represents a donator or creator). The user can select one during the ingest phase, relating the ingested object to this other object. That relationship would be recorded in the RELS-EXT datastream as RDF/XML, creating a triple. The predicate of that triple will come from either Fedora’s own ontology [RDF schema] or another appropriate namespace.

Below is PHP code using the cURL client library to call Fedora’s REST API and get this list of relevant objects. I encountered a few stumbling blocks putting this together, so I thought I’d share in case others were curious or looking at a similar problem.

The first step is to compose your query, and then initiate a cURL session with the query.


<?php
$request = "http://your.address.domain:port/fedora/objects?query=yourQuery&resultFormat=xml";
$session = curl_init($request);

curl_setopt($session, CURLOPT_RETURNTRANSFER, true);

$response = curl_exec($session);
$responseResult = simplexml_load_string($response);
$resultsArray = array();

foreach ($responseResult->{'resultList'} as $result) {
     foreach ($result->{'objectFields'} as $entry) {
          foreach ($entry as $value) {
               $resultsArray[] = $value;
          }
     }
}
curl_close($session);

while (!empty($token)) {
     $nextQuery = "http://your.address.domain:port/fedora/objects?sessionToken=" . urlencode($token) . "&query=yourQuery&resultFormat=xml";
     $nextSession = curl_init($nextQuery);

     curl_setopt($nextSession, CURLOPT_RETURNTRANSFER, true);

     $nextResponse = curl_exec($nextSession);
     $nextResponseResult = simplexml_load_string($nextResponse);

     foreach ($nextResponseResult->{'resultList'} as $result) {
          foreach ($result->{'objectFields'} as $entry) {
               foreach ($entry as $value) {
                    $resultsArray[] = $value;
               }
          }
     $token = $nextResponseResult->{'listSession'}->{'token'};
     print "$token<br />\n";

     curl_close($nextSession);

} //while
?>

On line 2 I’ve specified my query results to be returned as XML and not HTML (resultFormat=xml). This is because I don’t want a simple browser view of the results — I want to work with them some first, so XML is appropriate.

On line 5 the cURL option CURLOPT_RETURNTRANSFER to ‘true’. This directs cURL to deliver the return of its Fedora query as a string return value to the curl_exec() variable, in this case $response.

On line 8 $response, now an XML structure, is loaded into $responseResult as a PHP5 object. The object is a tree structure containing arrays for the result list, the entries, and the entries’ value arrays, all of which we can work through to get to the record values of interest. The specific contents will depend on your query. You can get a good look at the object with print_r():

print_r($responseResult);

The two Fedora REST commands used are findObjects and resumeFindObjects. We need both of these commands because findObjects will not return more than 100 results, regardless the value you set on maxResults.

Instead it returns the results along with a token. This token is a long-ish string you can then supply to resumeFindObjects, which will continue retrieving your results for you. Just like findObjects, resumeFindObjects will never return more than 100 results, instead giving you another unique token. Once again, you can supply that token to a new resumeFindObjects command to continue getting your results.

The two loops for each of these commands should fill resultsArray[] with all the results available in the repository.

You can use this array in a HTML drop down:


<?php
echo "<select name=\"donators\">";
foreach ($responseResult->{'resultList'} as $result) {
	foreach ($result->{'objectFields'} as $entry) {
		$pid    = (string) $entry->pid;
		$title  = (string) $entry->title;
		echo "<option value=\"$pid\">$title</option>";
	}
}
echo "</select>";
?>

Keep in mind that values like $entry->pid and $entry->title are only going to be in the results if those fields have been requested in your queries.

This approach has given me a good understanding of calling and manipulating objects in Fedora through PHP. I have found that setting maxResults to a smaller number (say 5, 10, or 20) is faster than setting it to its maximum 100. And of course, if you are going to be fetching hundreds or thousands of objects, it’s best not to dump them all in a drop down or to fetch them all at once.

Games that Made Me: Microsurgeon

Microsurgeon Banner
Microsugeon

I’ve rediscovered an Intellivision game I played as a kid: Microsurgeon (1982). This was one of the great cooperative console games of my youth, along with General Chaos (Sega Genesis, 1994) and Contra (NES, 1987).

The Intellivision must have been my friend’s father’s — we had both grown up with the NES as the big prize. The console’s controllers each had an analogue directional disc, which struck us as impossibly weird and archaic (but still interesting after too many failed rounds of Sonic the Hedgehog).

The real-world weightiness of the this game made a mark on me. You control a micro-ship inside a human body, where you battle cancer. It was very hard. You could target certain parts of the patient’s body for healing: eyes, brain, lungs, etc. The tumor spread relentlessly and you would find yourself urgently manipulating your directional disc in an effort to hold back advancing grey blocks of cancer cells.

Microsurgeon Medical Chart
Microsurgeon Medical Chart

The challenge was always compelling: you wanted to save this patient.  My most vivid memory though is of the tumor overwhelming whatever organ I was engaged in and the patient dying. Despite the morbid conclusion, the idea of a triumphant heal kept us returning.

Microsurgeon took the mathematical progression of difficulty found in many early arcade games (Space Invaders, Centipede, etc.) and applied it to the body’s battle with disease. I would say it was tragic but my unfamiliarity with Aristotelian tragedy would advise against it. I will just say that it was really sad and a little bit scary to lose. Microsurgeon is still how I visualize cancer doing away with me.

My search phrase (intellivsion health game) also turned up an excerpt from the book Lucky Wander Boy by D.B. Weiss. It’s good read; I look forward to reading more.

The second part of this game I remember so well are the visuals, which were gorgeous and appealingly abstract. The banner graphic above and the medical chart display are taken from user Servo’s contributions to the stock of images at MobyGames. The banner graphic reminds me of Basquiat’s popular painting, Unknown (Skull) (1981):

Basquiat, Unknown (Skull)
Unknown (Skull)

There’s some resemblance, isn’t there? Sure the Intellivision’s representation of the skull is medical and diagrammatic, and Basquiat’s is expressive and descriptive. But both skulls are essentially tackled in pieces.

What Story? Reporting a MUD-Dev Thread from April – May 2000 [re-post]

This is a re-post from my original on the Preserving Games blog, January 23, 2009. I expect to re-post most of these from over time. Looking at this one, I’m struck by how the posters’ concerns are still being considered and played out. In particular, I’m interested in the incidental storytelling notion, in my experience best demonstrated by Dwarf Fortress. A good example of that emergent storytelling is nomad (tim)‘s great illustration of one particular battle.

From August 22, 1996 to the early October of 2004 the MUD-Dev mailing list housed a slew of earnest and lengthy discussions — technical, philosophical, design and otherwise — concerning the development and play of multi-user dungeons (MUDs).

MUDs were developed before graphics-capable computers, originating and remaining entirely text-based. Players type commands, role-play or just socialize through the keyboard. Gameplay ranges from hack and slash to interactive fiction to simple chat, with all sorts of degrees of role-play in between. MUDs are often discussed as the precursors of today’s MMORPGs, and therefore an early index of the concerns and goals of those MMORPGs by at least 10 years. But MUDs are by no means a dead genre. New MUDs, and players for them, are continually coming into play.

The MUD-Dev archive is available at Raph Koster’s site as a bundle of distinct HTMLs, or right here at the School of Information on a single (very) large page with the messages hyperlinked and separated.

I’ve taken a look at the threads “Procedural Storytelling” and “A footnote to Procedural Storytelling”, which had sprung off from an earlier discussion, “Self-Sufficient Worlds”. The topic, broadly, concerns the art of storytelling in MUDs and more typically, how to generate them automatically on a large scale by abstracting them. Instead of doing a play-by-play of the discussion, I thought a report of the salient ideas and contentions would be more digestible.

  • The first idea to be discussed is whether, in the design of MUDs and their story content, “interesting stories” can be computationally generated. It’s posited that interesting stories are not computable and no amount of computation will generate them, at least not consistently enough for actual use. The counter argument believes that it is simply a matter of computational scale.
  • The issue of computational power and its potential for procedural storytelling is complemented a argument: automation and generation is less a problem than a toolset that allows players to interact with a persistent and consequential environment. This idea is revisited a few times throughout the thread. Posters wonder how the history of a world could be more thoroughly fleshed out, if a model could be made to allow future events to reference or be contingent upon past events, and the consequences of a persistent world given the unpredictable nature and large number of player actions any MUD would contain. I think this is an interesting consideration; it well highlights how ahistorical gamers’ interactions are in even very complex worlds. Continue reading “What Story? Reporting a MUD-Dev Thread from April – May 2000 [re-post]”