Game Design Feed

Game Inventories

Game Inventories was a serial in five parts that ran here at ihobo.com from August 31st to September 28th 2016. Within it, pairs of games are examined, and the lineage connections between them are considered, especially in connection with inventory practices. Each of the parts ends with a link to the next one, so to read the entire serial, simply click on the first link below, and then follow the “next” links to read on.

Here are the five parts:

  1. Game Inventories (1): Minecraft and Dungeon Master
  2. Game Inventories (2): The Bard's Tale and Dungeons & Dragons
  3. Game Inventories (3): Diablo and Daggerfall
  4. Game Inventories (4): Resident Evil 4 and X-Com
  5. Game Inventories (5): EverQuest and MUDs

Special thanks to Erlend Grefsrud, Griddle Octopus, Doug Hill, Jacobo Luengo, Sketchwhale, Oscar Strik, VR Sam, Worthless Bums, and José Zagal for contributing to brief discussions on Twitter that helped shape this short serial. Additionally, and this always the case when I talk of the history of games, I am indebted to my friend and colleague Richard Boon. 

If you enjoyed this serial, please leave a comment. Thank you!


Game Inventories (5): EverQuest and MUDs

EverQuest 2 2004One final element of Minecraft’s inventory practices remains unaccounted for: the bar at the bottom that allows rapid access to the contents of the inventory. This is clearly an inventory practice that makes no sense at the tabletop, yet it will hardly be a surprise at this point to demonstrate that it too descends from a lineage that traces its departure point to Dungeons & Dragons. In this case, the pivotal game is Sony Online Entertainment’s EverQuest (1999), which is the first of the ‘graphical MUDs’ – what would become known as a Massively Multiplayer Role-playing Game or MMORPG. Pictured at the top here is an inventory window from EverQuest II (2004), which shows another conventional grid inventory, with the bottom three rows marked with keyboard shortcuts: this is what EverQuest termed a hotbar, and which comes to be known as a quickbar (styled in Minecraft’s case as a quick-bar).

EverQuest Hotbar 1999Tracing the practices of MMOs, or indeed any game that is run as a service, requires significantly greater effort than investigating games that were released as products. Game-as-services means constant changes and updates, and this makes archaeology difficult to adequately perform. Nonetheless, the picture here shows a very early (perhaps the first) form of the hotbar in the original EverQuest. The player is able to customise its contents by placing different actions (at this point primarily described in words e.g. “Melee Attack”) onto the bar, where it can be quickly clicked with the mouse, or activated with a hotkey. The name ‘hotbar’ is clearly a reference to the concept of a ‘hotkey’, which has its origin in the graphical interfaces of computer operating systems.

Dark Age of Camelot Quick Bar 2001 Dark Age of Camelot Quick Bar 2001It appears to be EverQuest’s early competitor Dark Age of Camelot (2001) which coins the term quickbar, and as with all games of this style, the design varies radically throughout its life. The images above depict one of the last versions of the iconography used (top), and the original green and gold iconography (bottom). The functionality, however, remains parallel to the equivalent practices of EverQuest.

Computer RPGs were already moving towards this kind of customisable inventory practice as the available hardware resources increased and games took advantage of this to add more functionality. The action bar at the bottom of the screen in Baldur’s Gate (1998) is a proto-quickbar, even though inventory items are a small part of the space allocated for it. Similarly, Diablo II (2000) offers a quickbar-like system that is presented as being part of the world of the game by linking its functionality to belt items. Each belt provides the capacity to access potions, with different belts having varying capacities. However, by Diablo III, this experiment had merged with the main lineage of quickbar practices, which blossomed in the MMORPGs. To appreciate why, we should examine the two decades before the first MMORPGs, and the lineages of the original multiplayer fictional worlds: MUDs.

 

MUD1 and its Descendants (1978)

When I met Richard Bartle in Dundee this year for the first international joint conference of DiGRA and FDG, where he was giving a keynote, I asked him about the influences that fed into MUD1, the 1978 game that took a simple database, hooked it up with a parser, and connected it to the outside world with BT’s packet switch stream (a precursor to the internet). Bartle was keen to play down the influence of the text adventures, admitting that the parser idea had come from them, but suggesting if it hadn’t been from games like Colossal Cave Adventure (1977) or Zork (1977/1980) it would have come from elsewhere. I’ve already suggested we should set aside such counter-factual reasoning: a history is a narrative that connects the events that occurred, and we should not be too distracted by mere possibilities when constructing one.

Similarly, while Bartle and his co-designer Roy Trubshaw, had played Dungeons & Dragons, which clearly serves as an influence in the trajectory of the MUDs, Bartle was keen to note single-player games of his own devising which were similar in form to early tabletops that had influenced him in making MUD1. This isn’t entirely surprising, since while it was D&D that spread the practices widely by being published, there were numerous proto-RPGs in circulation in the time preceding it. The collision of tabletop player practices with the world practices of novels created unique conditions for the creation of new player practices focussed on narrative play, out of which springs the explosion of inventiveness for which D&D is a key locus of influence.

The early MUDs, however, were much more exercises in world building and community play than adaptations of Dungeons & Dragons. It is the LP MUDs (1989) and especially the DIKU MUDs (1990), originating in Sweden and Denmark respectively, that saw in the MUDs the opportunity to (yet again) adapt D&D for computer form, repeating what had happened back in 1974 on the PLATO educational network. From its first publication through to the early 1990s, wherever there was an opportunity to adapt the various player practices of D&D into a computerised form, it was taken.

The inventory systems of all these games remains resolutely in the style of the early text adventures, and thus in the form of D&D: a list of words. A text command ‘inventory’, often available as just ‘i’, would list all the items that the player was carrying in a simple linear list. Each item was specified in the design of the game, either as a unique object (in most adventure games) or as a class to be instanced (in computer RPGs and MUDs). As long as these games were represented in text, there was no possibility of it being otherwise.

Where, then, is the connection to the highly customisable quickbar? Players of MUDs often found that there were actions (or clusters of actions) that they needed to perform frequently, and swiftly hit upon a solution via running additional software in parallel to the MUD supporting macros. A macro was simply a script of text actions coupled to a key press to trigger it, typically (but not exclusively) the function keys (F1-F12), which were ideally suited for such purposes. Later client software for MUDs began to build these macro systems in automatically, because the player practices had become dependent upon the macro concept for smooth play. Note also that it was the players who added this element to the MUDs, with no involvement from the game developers.

Because the developers of EverQuest were MUD players, they appear to have been drawn to providing customisable interface elements like the hotbar, and thus accelerating the development of what would become called the quickbar: they were (on this reading) a graphical substitute for macros, a customisable element that could tailor to the individual player’s practices. MUDs required more actions in part because they brought together multiple players, which necessitated communication and performance irrelevant in a single player game. MMORPGs inherited this requirement, and developed the quickbar practices to deal with it.

Here, in this final element of Minecraft’s inventory design, is an example of why examining the history of games as player practices can reveal aspects that are invisible if they are examined solely as artefacts, since it is only through the actions of the players that the practices of games are sustained. The design of every game is conditioned by the conservation of player practices, which sustains those practices that are effective at satisfying the visceral or imaginative needs of players. Every example within this serial serves to elucidate this point, and to show how games are never isolated objects: they are always embedded in the manifold of player practices responsible for their creation, and which they then contribute to maintaining.

The player is the heart of the game, and game design conserves player practices because designers are also players. We can trace lineages not because successful games are the rare exception that borrow their practices from earlier games, but because games that borrow the majority of their practices from earlier games are best positioned to be successful – especially if they can manage to bring something new to the table in the process. Notch probably did not play tabletop Dungeons & Dragons, or The Bard’s Tale, or Dungeon Master, or UFO: Enemy Unknown, or EverQuest, but the inventory practices of Minecraft nonetheless inherits the successful variations that these games introduced upon a bedrock of established player practices.

With thanks to Erlend Grefsrud, Griddle Octopus, Doug Hill, Jacobo Luengo, Sketchwhale, Oscar Strik, VR Sam, Worthless Bums, José Zagal and, always when I talk of the history of games, to my friend and colleague Richard Boon.


Game Inventories (4): Resident Evil 4 and X-Com

Resident Evil 4 2005The Attaché Case inventory in Resident Evil 4 (2005) feels like a logical next step from Diablo II’s grid inventory three years earlier. Both involve positioning multi-cell objects in a fixed size grid, with weapons varying in size. Resident Evil 4, however, takes the idea one step further, allowing the player to rotate the items, and providing a ‘swapping space’ to store items temporarily while the player fiddles with the layout. It’s an ingenious and absorbing design that most players loved, although a few complained about the way it broke them out of the world of the game (the aesthetic flaw I have called rupture).

Yet if we examine this game from the perspective of player practices then what we are dealing with is not a progression from Diablo II at all – for that particular game was never released in Japan, and is vanishingly unlikely to have been an influence upon the design of Resident Evil 4. Indeed, the player practices that condition the creation of this particular post-survival horror game are primarily those of the Resident Evil franchise itself, which represents an entirely parallel development of the grid inventory concept from largely different influences. I’ve warned previously about the danger of bringing in counter-factuals to examine the history of game design – but when it comes to this instance, we get an alternative history of a single design element because its actual history was different.

We do not, however, cast aside the influence of Dungeons & Dragons in this version of events, even though the game never had a serious following in Japan. Rather, it was once again Wizardry that took the design of the original tabletop RPG and brought its influence to Japan – firstly, as Henk Rogers’ Black Onyx (1984), which was Japan’s first computer RPG, and soon after as Dragon Quest (1986), and from there into the Japanese RPG lineage, a complete analysis of which would be a major project in itself. (Henk Rogers, incidentally, was a D&D player at the University of Hawaii, where he was studying business – and immediately saw how Wizardry’s adaptation of the tabletop RPG practices was a way to make money; he just had to bring it somewhere new…)

The original Resident Evil back in 1996 (Biohazard in Japan) has two key points of influence. From a technical standpoint, it is clearly inspired by Alone in the Dark (1992), which in turn was inspired by the hugely influential tabletop RPG Call of Cthulhu (1981), written by Sandy Peterson (who would go on to be a level designer for id Software, bringing Lovecraft’s Cthulhu mythos into their games). From a player practice perspective, however, it does not seem that Capcom’s team was coming from Alone in the Dark at all, but rather from an obscure Japanese RPG entitled Sweet Home (1989), itself adapted from a Japanese horror movie with the same name. This is hardly a secret: Tokuro Fujiwara, who made Sweet Home, was one of the two key people responsible for directing Capcom’s first Resident Evil game, and it is relatively clear that Sweet Home provides the rough draft of Resident Evil’s inventory practices – including the idea of limiting space in the inventory, the use of save rooms to store items, and individual character items like the lockpick and lighter.

The player practices of the survival horror genre are centred around the inventory, and the limitations therein that Sweet Home pioneered. Having rendered the inventory as a grid for the first game, director Shinji Mikami went on in Resident Evil 2 (1998) to make some weapons take up two spaces in the inventory, adding to the difficult decisions that had to be made. While reviewers complained about the limitations of the inventory, and the surreal quality of the Item Box that shares items between all save rooms, when Capcom eventually removed these in their final survival horror game, Resident Evil Zero (2002), the inventory system unravelled completely. Players were forced to choose a room to layout all of their belongings, which was even more surreal than the Item Boxes!

Alas, the decision to give up on the player practices of the survival horror game had already been made by the time Resident Evil Zero shipped: Mikami-san had been ordered to make an action game, which is where Resident Evil 4 came from. On the foundations of their own inventory practices, the ‘perfect’ grid inventory of Resident Evil 4 was born. But having traded survival horror for action, the stop-and-start inventory ultimately had to go to make room for multiplayer, and the perfection of the grid inventory in Japan was ultimately a dead end.

 

UFO: Enemy Unknown AKA X-Com (1994)

UFO 1994The connection between the inventory in UFO: Enemy Unknown and that of Diablo that it inspired is readily apparent: here, for the first time anywhere in the world, is a grid inventory where the equipment items take up variable cells of the grid, creating interesting decisions when equipping character. This game, known as X-Com: UFO Defense in the United States where it enjoyed tremendous commercial success, was to found a hugely successful strategy franchise, yet its influence is nowhere more apparent than its provision of the multi-cell grid inventory practices to Diablo.

Just as the case of Resident Evil 4 depended upon a contiguous set of player practices from one linear sequence of games, so the influence that led to Diablo’s grid inventory came from a contiguous sequence of games, in this case those of the British programmer and game designer Julian Gollop. From the age of 14, Gollop was playing Dungeons & Dragons and the strategy boardgames of Avalon Hill that had inspired it. Unlike everyone else considered in this serial, Gollop was strongly influenced by the design of strategic boardgames, and began creating games on 8-bit home computers that adapted the player practices of these games.

Rebelstar Raiders 1984Rebelstar Raiders (1984), pictured right, was one of Gollop’s first experiments with putting a strategy boardgame onto a computer, in this case the ZX Spectrum. With no AI at all, the game could only be played with two players, a limitation that was fixed with the sequels Rebelstar (1986) and Rebelstar II (1988). While the latter two games did allow for changes in weaponry, none of these titles featured an inventory system, which is not surprising since the strategy boardgame practices they had adapted never used an inventory concept either. This was the invention of D&D and the tabletop precursors that inspired it.

Laser Squad 1988It is with Laser Squad (1988), pictured left, that Gollop begins to combine D&D style differential characters – and thus inventories – with the player practices he had developed across his Rebelstar games, the last of which had been released earlier in the same year. As the screenshot makes clear, each member of the player’s squad has a name and an inventory of weaponry, shown with small icons. The more equipment a squad member carries, the more rapidly they run out of action points, and thus tire. The player practices of X-Com descend directly from Laser Squad – indeed, it was originally conceived as Laser Squad II, and both games combine an RPG-like differentiation of characters with the practices of a strategy wargame.

The step up to the full grid inventory with multi-cell weapons in X-Com feels like a substantial progression from Laser Squad, and six years separate the two games (although the last edition of Laser Squad, for PC, wasn’t released until 1992). It seems likely that in the intervening period, Gollop encountered Dungeon Master, and hence the grid inventory. However, the effect of multi-cell items on the grid inventory concept results in a substantial shift in the player practices, as Diablo made clear. I speculate that the influence here might have come from Steve Jackson’s classic tabletop autoduellist wargame Car Wars (1981), for which allocating weaponry to the limited spaces available in the chassis was a major element. Since Gollop worked upon the 8-bit videogame for Games Workshop’s 1983 dodgy knock off, Battlecars, it seems likely he was exposed to Car Wars player practices. But perhaps, like Resident Evil’s parallel lineage of grid inventories, Gollop just hit upon the idea on his own as he continued to develop his own unique lineage of strategic videogames.

Next week, the final part: EverQuest and MUDs


Game Inventories (3): Diablo and Daggerfall

Diablo II Horadric Cube 2002One key aspect of Minecraft’s inventory practices is absent from all of the examples previously examined: crafting. Indeed, crafting formed no part of Dungeons & Dragons player practices until the 3rd edition in 2000, and none of the early computer role-playing games descending from it feature this concept. The means of creating magical items that tabletop D&D offered has next to no influence, however. It seems to be Diablo II (2002) that largely establishes the player practice of crafting through the introduction of the Horadric Cube (pictured left), a secondary grid inventory of 3x4 spaces that includes a button to transmute its contents into a new magical item. This provided a means for players to create endgame items beyond waiting for them to drop, and although its function was considered fairly arcane, it was nonetheless a central part of many players’ experiences of this game.

That the crafting box in Minecraft resembles that of the Horadric Cube is not coincidental: Diablo (1996) and Diablo II (2002) were so commercially successful that it is these games (and those of the Elder Scrolls series, discussed below), that anchor the conservation of player practices in Western-style computer role-playing games from this point onward. The Japanese computer RPG lineage, which also traces its heritage back to D&D via The Black Onyx (1984) and Wizardry (1980) before it, would tell a different story, and one that exceeds the scope of this serial to adequately trace. Again, as I pointed out last week, we can tell whatever counter-factual stories we like about the ways things could have gone, but they cannot nullify the influences upon the actual history of games.

A less influential aspect of Diablo II’s crafting practices are items with sockets, which can be fitted with gems in order to power-up the item in question. Like the Horadric Cube, sockets attempt to make the overflowing treasure tables of Diablo something other than a demand to go to the shop and dump the junk. Ernest Adams has joked that computer role-playing games make their players into “itinerant second-hand arms dealers” – the practices added to Diablo II attempt (rather unsuccessfully, as it happens) to offset the root causes of this, and crafting ever since has built upon this idea. The only other major contributor to early crafting practices other than Diablo II appears to be Daggerfall, discussed below.

The original Diablo is one of the games that synthesises influences both from tabletop Dungeons & Dragons, and its computer game inheritors. Co-creators Erich and Max Schaefer had played in the kind of mindless dungeon bash style of D&D that was common (but by no means universal) in the early days of the hobby:

We wanted to do an RPG how we’d played Dungeons & Dragons as kids: hit monsters and gain loot. Our mission was that we wanted the minimum amount of time between when you started the game up to when you were clubbing a skeleton.

Indirect influences came in via the other co-creator, David Breivik, who had played Moria (1975/8) and Angband (1990), two early roguelike games descended ultimately from the unimaginatively titled dnd (1974) on the PLATO educational computer network, written in the same year that tabletop D&D appeared.

Diablo 1996The inventory in Diablo has another key point of influence, however, namely Julian Gollop’s X-Com: UFO Defense (1994), originally entitled UFO: Enemy Unknown. The influence here was in the idea of breaking out of the original grid inventory concept, which allocated one square to an item, by having items take up multiple spaces. As the crop of Diablo’s inventory screen to the right shows, weapons take up between three and six spaces in the grid, in various configurations, an inventory practice established by and descending from X-Com, which all three of the Diablo creators mentioned above point to as their inspiration for the interface design. This thread will be picked up next week.

 

Daggerfall (1996)

Daggerfall InventoryThe same year that Diablo was released, Bethesda were working on a follow up to their first Elder Scrolls game, Arena (1994). Just as Condor (later, Blizzard North) had been engaged in player practices from both the tabletop and from computer RPGs, Bethesda’s influences came from both lineages, with Ultima Underworld: The Stygian Abyss (1992) mentioned as informing the design of Arena. But Bethesda were deeply involved with the narrative practices of tabletop role-playing, and were far more interested in role play than the simple kill-and-level rule play that inspired Diablo. Daggerfall marks the point that their influences change from Dungeons & Dragons to later tabletop role-playing systems, particularly Steve Jackson Games’ GURPS (1986).

An interview on Gamespy with designer Ted Peterson (archived in this forum discussion) makes the connection explicit when discussing Daggerfall’s character creation system:

Julian [LeFay] and I had decided to go with a skill-based advancement system rather than Arena’s kill-the-monster-and-advance system, so each of the classes had been assigned different skill sets. Given that, it made sense to allow players to create their own classes assigning their own skills. Then, thinking about GURPS, we added additional bonuses and special abilities and disabilities that the player could assign. I’ve always enjoyed character creation systems in games of all kinds. I don't like playing Gamma World, but even now when I'm bored, I'll sometimes roll the dice and see what kind of mutations my character would develop if I actually wanted to play the game.

The move here is towards the second generation of tabletop role-playing games, like GURPS, with their emphasis on putting the player in charge of character creation and away form dice-rolling practices, like Gamma World (which was TSR’s post-apocalyptic game, using rules very close to D&D). White Wolf’s Vampire: The Masquerade (1991) has also been mentioned as feeding into the world of Daggerfall, with clans of vampires added into Tamriel for this iteration of the Elder Scrolls franchise.

A striking aspect of the inventory screen in Daggerfall is its division into categories like Weapons & Armour, Magic Items, Clothing & Misc, and Ingredients. As noted last week, this was a common aspect of Dungeons & Dragons character sheets, but it hadn’t been used much in computer RPGs. The influence of tabletop practices is also felt in Bethesda’s crafting systems. Arena had a spell creation system that was clearly a modular version of D&D’s fixed-definition spells. Daggerfall, on the other hand, has a more detailed spell and weapon enchantment system, drawing very clearly from the GURPS concepts of Advantages and Disadvantages, that would go on to influence Fallout (1997).

Daggerfall 1996As noted in respect of Diablo, tabletop RPGs hadn’t had a motive to include crafting systems, but the excessive volumes of loot earned in computer RPGs (a product, in part, of much faster paced play) created a need to find other things to do with items other than just sell them. For Daggerfall, the system that most resembles future crafting practices is the Potion Maker, pictured above. Certain items in the game were characterised as Ingredients and could be combined in a Mixing Cauldron, accessed from Temples or the Assassins’ Guild. Mixing could be done freely, or recipes (acquired as treasure drops) could be used to operate the Mixing Cauldron automatically.

Although Daggerfall’s Mixing Cauldron is narrower in scope than Diablo II’s Horaldric Cube, both are initiating the same kind of player practice: one where the inventory is not just a source of equipment for immediate use (as in Dungeons & Dragons), or simply fodder for sale (as in most computer RPGs prior to the 90s), but a set of active elements that can be combined in different patterns to get better equipment. These player practices made no sense at the tabletop, where complex look-up tables would be required. But on the computer, the availability of automation within the game systems kicked off experimentation with crafting as soon as there was sufficient memory space for such luxuries. It was thus the widespread adoption of the CD drive around 1993 that opened the door to crafting practices, which have thrived ever since.

Finders Keepers 1985That technological limitations play a role in delaying the onset of crafting can be seen by considering one of the few examples of crafting prior to the 90s: David Jones’ Finder’s Keepers (1985). This budget gem (Mastertronic sold it in the UK for £2, one fifth of the price of most games at that time) had a five slot inventory of the style we have already seen in The Bard’s Tale. The twist was that certain items would automatically react in the player’s inventory to form new items e.g. Bar of Lead and the Philosopher’s Stone would switch to Bar of Gold, while Sulphur, Saltpetre, and Charcoal would produce Gunpowder – used to escape the castle in the ZX Spectrum version, and resulting in the player blowing up (Game Over!) on the Commodore 64. But unlike Diablo and Daggerfall, this game failed to influence even its own sequels, which never again experimented with crafting. The 8-bit era does, however, have an important part of the story of game inventories, which we will turn to next week.

Next week: Resident Evil 4 and X-Com


Game Inventories (2): The Bard's Tale and Dungeons & Dragons

Bards Tale 1985

The ridiculously over-titled Tales of the Unknown, Volume 1: The Bard’s Tale, was released in 1985, two years before Dungeon Master, which as shown last week innovates the grid inventory practice that persists all the way to the present day. It’s a measure of the influence of The Bard’s Tale (as it came to be known) that the sequel drops the Tales of the Unknown branding and goes for The Bard’s Tale II: The Destiny Knight (1986). It ultimately goes on to complete a trilogy of games that are fondly remembered, despite not ranging very far from the practices that SirTech’s Wizardry: Proving Grounds of the Mad Overlord (1980) established five years earlier in adapting tabletop Dungeons & Dragons (D&D) to the computer.

As the screenshot above shows, each character in the party is allowed eight items in their inventory. The ordering of the items makes no difference, and the distinction between equipped items and unequipped items is marked with an asterisk. The Warrior shown in this picture has a shield, various items of armour, and a halberd to attack with. His appearance in the display window in the top left is utterly unaffected by what is equipped, but unlike Wizardry the images of both party members and monsters that appear in this corner are pleasingly animated, which added to the appeal at the time of its release.

There is one difference between Wizardry’s inventory and that in The Bard’s Tale: the former used a question mark to indicate items that had not been identified, a player practice invented by D&D but largely maintained only in Rogue (1980) and its descendants. The Bard’s Tale eliminates this practice for simplicity, and indeed can be seen as a refinement of its immediate predecessor, Wizardry, knocking out all manner of clunky elements that had either been inherited from its tabletop forebear (like identifying magical items) or thrown in for good measure (such as adding attribute points on top of random base values during character generation).

The true extent of the conservation of player practices between Wizardry and The Bard’s Tale can be felt with the latter’s sequel, The Destiny Knight, which allowed players to import their party of characters not only from The Bard’s Tale but also from Wizardry or Ultima III (1983). This was possible because the player practices that all three games were built upon were all intimately tied to D&D. Wizardry’s attributes of Strength, IQ, Piety, Vitality, Agility, and Luck become Strength, IQ, Constitution, Dexterity and Luck in The Bard’s Tale. It thus reverted Vitality and Agility to D&D’s terms Constitution and Dexterity, maintained Strength (also from D&D), kept Intelligence as IQ, and dropped Wizardry’s Piety, which had been renamed from D&D’s Wisdom. The only thing new in the computer games is Luck, which replaces D&D’s Charisma, since early computer RPGs struggled to implement any kind of character interaction, and The Bard’s Tale takes this attribute directly from Wizardry.

It will thus come as no surprise that Michael Cranford, the game designer and programmer at Interplay who was responsible for almost every aspect of The Bard’s Tale except its art, was not only playing Dungeons & Dragons at the tabletop (frequently as Dungeon Master,)but also playing a great deal of Wizardry. Like the team at FTL responsible for Dungeon Master two years later, Cranford wanted to create a ‘Wizardry Killer’, and with The Bard’s Tale achieved a streamlined perfection of the player practices of that earlier game, as well as bringing in a few of the new player practices TSR had added in Advanced Dungeons & Dragons, such as changing classes – which is precisely where the Bard character class had come from in the first place.

 

Dungeons & Dragons (1974)

Bob-Ruppert-Character-Sheet-1975_thu

It is hopefully clear at this point that for almost twenty years after its original release, TSR’s Dungeons & Dragons was the wellspring from which the player practices of computer role-playing games were established. D&D had many influences from the tabletop scene preceding it, not least of which the wargames of Charles S. Robert’s Avalon Hill, but the sheer degree to which the D&D rules were distributed throughout the US (primarily via college players) – both by purchase and through unlicensed copies – made this the definitive version of tabletop role-playing games player practices that were conserved by the computer variants.

The tabletop successors of D&D become a part of the story only a decade or so later, e.g. Steve Jackson Games’ GURPS (1986), which gives rise to Interplay’s later Fallout (1997). All the way through the 70s and 80s, D&D was feeding its player practices directly or indirectly into computer games. This is particularly clear in terms of the First Person Shooter lineage. As noted last week, the original controls of id software’s games were inherited from the cursor key movement of The Bard’s Tale and Wizardry, not to mention that the developer were avid players of D&D itself, with one campaign specifically inspiring DOOM (1993). Furthermore, the open world genre equally ties back to Dungeons & Dragons via Traveller (1977) and Space Opera (1980), two early tabletop RPGs that were beloved by David Braben and Ian Bell, whose Elite (1984) would be a major influence on Grand Theft Auto (1997).

In terms of inventories, Dungeons & Dragons effectively invents them (although not the name...) or rather, acquires this practice from early non-commercial tabletop role-playing games, and then becomes the locus of the conservation of player practices by being so widely distributed. The core element of the inventory practices is the use of a set for representation instead of mere function. Sets had enjoyed a millennia of productive use in board and tile games before Dungeons & Dragons used them to create a revolutionary new player practice: the character sheet. In collecting together all manner of fields (Name, Class, Attributes, Alignment and so forth) into one set of sets (a superset), D&D was creating a means of representing entities that would be picked up by early videogames and gradually explored over the decades that followed.

Within the superset of data that was the written character sheet, the inventory was nothing more or less than a written list, recording a subset of all of the possible items specified by the written rules. The original white box game of 1974 did not have a pre-designed character sheet, and players recorded all the text and numbers required to specify their characters without any established format. However, there was soon a thriving experimentation in home-printed character sheets, like the one depicted above that was created by Bob Rupport in 1975.

D&D Character Sheet 1980Many other variations followed until TSR established an official printed character record sheet in 1977, a 1980 variation of which appears to the right. In fact, as both these examples attest, the early tabletop RPG inventory was quite frequently multiple written lists: Rupport’s version divides the inventory into sections named Weapons/Armour, Magic Equipment, and Other Equipment, while TSR’s official version provides separate boxes for Magic Items and Normal Items, stressing the importance of Magic Items (acquired as treasure) to character advancement, both in the tabletop game and in its immediate successors. At heart, this choice to list items in two separate sets had no representative force, and it is hardly surprising that Wizardry and The Bard’s Tale didn’t bother to make the distinction. They also limited the size of the list to eight items (the paper sheets having no such limitation) as a practical matter tied to the keyboard: number keys could be used easily to select which item was to be used.

The tremendous influence of Dungeons & Dragons, in terms of the use of sets for representation (inventories, character sheets), character progression (experience points, levels), and codifying game worlds (dungeon, village, wilderness) may inevitably invite the retort: if it had not been D&D, it would have been something else. However, this counter-factual argument is not as important as it feels to game designers as they try to shrug off their debts to their direct influences. The 1980 release of Wander (a rival for the first text adventure, but nowhere near as influential as D&D-descended Colossal Cave Adventure) has an inventory command listing the items you are carrying; perhaps this was also in the original 1974 release. But game design ideas do not exist in a Platonic void, where the are magically plucked from. Game designers are players, and they are embedded in the player practices of the games they play. Once this is accepted, the legacy of Dungeons & Dragons is unavoidable and undeniable, and it comes into focus as the most influential game ever published. 

Next week: Diablo and Daggerfall


Game Inventories (1): Minecraft and Dungeon Master

Minecraft 2009

Look at this screenshot from 2009’s Minecraft, one of the most successful games to be built upon the player practices of the role-playing game lineages. What can immediately be seen are a set of armour slots and an image of how they look upon the character, a crafting area, a grid inventory, and a quickbar. There is nothing new in this design, and neither should there be; Minecraft’s innovations are primarily in its customisable regimes of play, not in its interface. What I want to draw attention to here is the way that every single element of Minecraft’s inventory descends directly from a lineage of videogames rooted at its base in the original tabletop role-playing game (RPG), Dungeons & Dragons in 1974. Even its ‘mouselook’ control scheme, which originates in the First Person Shooter (FPS) lineage, has its roots in the RPG lineage.

This serial takes pairs of games in key lineages that descend from Dungeons & Dragons (D&D), either looking at the relationship between a newer game’s design and an older game that developed or popularised the interface practice being examined, or otherwise drawing historical parallels. This first piece looks at the grid inventory of Minecraft and shows how this originates with 1987’s Dungeon Master, itself a direct descendant of D&D. Future pieces cover all the other elements we see here in Minecraft, as well as a few other aspects of inventory practices in games. Alongside this retrospective analysis I will also be espousing a different philosophy for understanding and practicing game design, one that I have been writing and presenting about more or less since I finished writing Imaginary Games. This perspective is focussed upon continuities in the practices of players, which become in turn the practices that inform game designers, who pass those practices onto new players.

The prevailing tendency when examining the design of games is to break down the functional elements of the design as mere atomic entities that can be freely combined. This is how most game designers, myself included, think about the game design process – as selecting options from an imaginary bag of game design elements. Despite its efficacy, my claim here is that this model risks utterly misunderstanding the importance of both history and practice for game design, and only works because the game designer is so deeply embedded in the existing player practices that they knowingly or unknowingly reproduce them. In contrast to the ‘atomic theory’ of game design, I advocate understanding how the conservation of player practices (which are highly variable in commercially unsuccessful games, but not in successful ones) is in itself the key to successful game design.

Understanding games and game design in this way does not entail any dramatic sea change to the way games are made, it only involves foregrounding what is commonly just dismissed: that games are connected by historical lineages that are sustained by common player practices, which is to say, things the player learns to do consistently. The game designer, as a player themselves, recreates the player practices they have learned from other games. When a game designer thinks they are pulling together isolatable atomic elements of a game design, they are simply ignoring the practices those elements belong to. But success at game design is attained most effectively by understanding how player practices function. As I’ve argued before, the tremendous success of Minecraft was not just down to its original elements, which were small but significant. It was largely down to the way that it leveraged well-established player practices.

 

Dungeon Master (1987)

Dungeon Master 1987The grid inventory, so prominent in Minecraft and the backbone of game inventories for nearly thirty years now, is part of a series of player practices that owe their origins to the influential Dungeon Master, by FTL. This remarkable game came about through the co-operation of two designers who were intimately embedded in the player practices of tabletop role-playing games and their early computer descendants – Doug Bell and Andy Jaros. SirTech’s Wizardry had been their direct inspiration; they wanted to make a dungeon crawl in that vein, and set to work on what was then called Crystal Dragon. However, they didn’t have the funds to complete the project alone.

Six letters to software companies in the Los Angeles and San Diego area eventually hooked them up with Wayne Holder, husband of fantasy and horror novelist Nancy Holder. The combination of a pair of designers rooted in the player practices of role playing games, a professional writer, and a business-savvy company owner was to prove immensely productive. Bell and Jaros, like most game designers, enacted the conservation of player practices in their work, but were repeatedly challenged by the Holders to push past the usual assumptions. In particular, Nancy Holder was responsible for contributing one of the first – and greatest – plot twists in any videogame ever written, and Wayne Holder’s outsider perspective on role-playing helped remake the menu systems of the game to bring them up to the standards then coming together in Graphical User Interfaces at the dawn of the WIMP era (Windows Icons Mice Pointers).

The core vision that guided the project was giving the player a powerful sense of immersive presence. Jimmy Maher, in an outstanding summary of the circumstances behind the game, characterises their goal as “an embodied CRPG experience”, and quotes Nancy Holder as asking: “How do you go from being a player to being ‘in’ a game?” Thus the agency practices of Dungeon Master involved breaking down the sense of separation between the world and the character sheet that earlier games in this lineage had inherited from Dungeons & Dragons. In Dungeon Master (itself obviously named in reference to its tabletop progenitor), the player can find a sword on the floor of the rendered three dimensional dungeon, move their pointer (styled as a hand) and grasp it, delivering it into inventory slots in the grid inventory (Wayne Holder’s WIMP-inspired innovation) or into the ‘paper doll’ slots representing each character’s personal equipment. The widespread deployment of both these practices descend from this game, and they are massively conserved from this point – just compare the screenshot of Minecraft with that of Dungeon Master’s inventory: the key difference is that Minecraft’s is notably more shoddy in terms of presentation values.

In setting out to evoke real-time immersive presence, and thus ending the turn-based practices that were both a natural consequence of tabletop practices and a pragmatic option for early computer hardware, Dungeon Master in effect sets up both the shape of forthcoming computer RPGs and heralds the imminent arrival of the First Person Shooter (FPS). Such games are called ‘first person’ in contrast to the arcade shooter, or shoot ‘em up, which was not rendered in 3D, but as a ‘flat’ 2D space. Yet all the dungeon crawl games were in 3D yet did not acquire the appellation ‘first person’. What this term attempts to capture is the very sense of immersive presence that Dungeon Master pioneered; that’s what ‘first person’ is intended to describe. In Maher’s retrospective, he describes this game as “just as obviously a progenitor of Doom as it is a successor to Wizardry.”

Here, we run up against the vagaries of historical research, since while id Software admit to being influenced by dungeon crawl games, no-one will name which. If Dungeon Master were one of them, it would arguably make it the second most influential game after D&D, having set up both the later Western RPG lineage and the FPS lineage. It’s hard to solve this mystery. That Wolfenstein 3D and Doom were both built upon the player practices of computer RPGs is apparent from their interface practices using cursor keys for navigation ('mouselook' emerging only later in Quake, and even then only as an option). But The Bard's Tale (which we’ll look at next week) is an equally plausible point of influence, and there’s a certain sense in which John Carmack’s confidence in the innovation of his first person engine undermines the idea that Dungeon Master was his muse. In an interview for the New York Times he remarked in respect of the sense of fear that the immersive presence of Catacomb 3-D evoked that it was “a reaction that we’d never seen in any other form of video-gaming.” He could not have reasonably have thought that if he’d played Dungeon Master.

Next week: The Bard's Tale and Dungeons & Dragons


Coming Soon: Game Inventories

lolAs part of my work on the lineages of player practices, I’m beavering away on a five part serial looking at game inventories. It was originally going to be just one post entitled The Joy of Sets, but it has predictably spun out of control and has turned into a bigger project. I will be taking pairs of games and looking at the lineage connections between them, which is not simply a matter of saying what influenced what directly. For instance, Notch never played Dungeon Master to my knowledge – but the design of Minecraft inherits almost the entirety of its inventory practices from it. This will be my big serial for this year, and I hope to kick it off soon. Stay tuned!


The Ignorant Dogmatist

Over at Ice Water Games, Kevin Maxon provides another glorious rebuttal to my firestarter. Here’s an extract:

In some sense, ignorance might be an appropriate word for what I’m advocating: for creators to intentionally ignore with greater diligence the pressures to be similar, to follow fashion or money or power, pressures to use objective, scientific methods of art production. And similarly, I think part of what I’m advocating for could be called dogmatism: for creators to hold firm in their values and goals in order to create works that are more distinct, more filled with themselves, more honest and interesting and worth talking about.

Please rush over to his blog to read the entirety of The Ignorant Dogmatist right away!

The original firestarter makes one of its targets the kind of self-focussed indie game design method Kevin defends here. Yet I cannot do anything but respect Kevin’s commitment to exploring his own creative vision in games. For me, what Kevin is doing is making what I call artgames, and the moment you’re committed to art you are no longer practicing a commercial craft. You’ve gone down a marvellous rabbit hole, one where money may be tight but that worthwhile things get made. Almost everything I’ve thought worthwhile in games in the past five years has been an artgame… This is largely what I choose to play these days.

Why sell out artists in The Craft of Game Design Cannot Be Measured By Any Metric, then? When I look at Kevin’s output, which includes Eidolon and The Absence of Is, I see someone pursuing their vision for its own sake, which is the mark of an artist – a way of life I greatly respect, not least because it now feels closed to me. But when I look at the indie market, I see people pursuing a similar kind of self-focussed process and making yet more-of-the-same violent, repetitive ordinariness. Such indies are, I presume, trying to make a living – and they’re doing it badly. It was these indies I wanted to lambast.

If my piece in any way discourages someone from accepting the role of the starving artist, with all that entails, I apologise unreservedly. Art is one of the greatest ways to add value to life beyond money. But most indies aren’t making art. They’re masturbating into a codebase and thinking they’ll hit big doing so. Maybe I should respect that as a kind of art, but I just see it as bad commercial practice.

With my philosopher-hat on (I wear many, conflicting hats), I can only smile with an inner warmth at this line:

I think that often, the non-mechanical components of a game are more important than the mechanical ones, and so I tend to work on visuals and writing at least as early as mechanics.

I wrote Imaginary Games in part to defend this philosophy, and next week I’ll present to a hundred game academics about how games are more than their merely artefactual machinery. Kevin describes himself as willingly ‘ignorant’… his ignorance, though, is closer to the kind praised in Jacques Rancière’s The Ignorant Schoolmaster – it is a freedom from stultifying conformity. I could never oppose this, especially not when it is done in the pursuit of art. Everyone must discover who they are, sometimes over and over again… and never let someone like me tell you otherwise.


Defending Game Metrics

In a comment replying to The Craft of Game Design Cannot Be Measured By Any Metric, game designer and Chief Creative Officer at Spryfox Dan Cook gave such a sterling, thorough rebuttal that I’ve reposted it here in full.

 

Dan CookEmpiricism in Game Design

When I design I have a mental model of how I imagine my game will be played by players. This includes predictions about player emotions, learning, buying behaviors and a dozen other factors necessary to make a self-sustaining game in one of today’s various markets. I also make predictions about how markets will act. Platform desires, player designers, press desires.

Then we build the game, or at least we build an initial version of it.

Then we playtest the game to see if the my predictions worked out. Most of the time they don’t. In the best cases I’m only off by a factor or two. In the worse cases I’m off by several orders of magnitude. However, I may also find that players behaved in a manner that was actually more interesting than I predicted.

So we build another iteration of the game. Somehow, we need to connect the empirical reality of what the playtest suggests with what we predict will happen. This usually involves updating our models, sometimes radically. Often incrementally.

For some designers, this process can be frustrating. The reality of player behavior imposes constraints on their mostly imaginary vision. But I tend to see constraints as necessary to the process of design. And constraints based off observing real people playing the game tends to more often than not yield opportunities to impact the real shared world of many people vs the isolated imaginary world of a single person. We find new ways of playing that are more vibrant and interesting.

 

How are metrics useful when iterated on a game?

Game designers are information starved. With writing, we have an imperfect but competent mechanism for imagining how someone might feel reading a bit of text. In order to write, you must read. And thus you are forced to process a work in a somewhat similar fashion to how a potential reader might process. Game developers do not have this luxury. We build systems multiple times removed from a player’s experience. Write some code. Do a dozen other steps. Build an executable that someone somewhere runs. Knowing how people with react to what we make is hard.

So we use crutches. We create complex models of how players think. We use ‘proven’ patterns. We watch players and try to imagine what they are feeling. Then we try to backtrack all far removed information to whether or not a number in the bowels of a broken machine should be 2 or 4.

There are certainly classes of information we can extract more easily. Surface player emotions on individual playthroughs. Awesome. We can do that. But human behavior is broad. We see the need to sample behaviors across populations and discover central tendencies or outliers.

So metrics or analytics are that tool. They let us understand statistical patterns of behavior. Do they let us see inside the minds of our players? No. Nothing does yet. Do they replace in person playtests? No. Smart designers use multiple sources of insight.

But metrics do provide an amazing range of insight by allowing us to look at hard problems from a different direction. If players in an MMO are flooding forums with complaints about a change, how many people are impacted? How did playstyles change?

When balancing economies and progression systems, metrics are essential. You can’t do an in-person playtest of someone playing a game for 90 days. The old tools don’t work. And various forms of data collection do.


Maybe all this doesn’t need to be said. Maybe you are worried about something else entirely.

Are you worried about how metrics shines a light on bullshit design? Because a lot of design is unsubstantiated bullshit. We imagine people will play a game a certain way and then they don’t. Such an ego buster. Metrics beat us with bully numbers. They bluntly state our initial idea was flawed. Or even worse, the thing that people have been praising us for years doesn’t actually apply to anyone but some weird elite group of outliers that happens to give out chintzy feel good awards. Reality can be cruel when you live in a fantasy. But it also acts as a constraint that forces us to up our game and make something that works. Versus wandering blindly off a cliff in a feel good haze. Which I’ve done. (Lovely until you fall).

Are you worried that Bad Men use metrics in a reductive fashion to emphasize making money over art? Bad Men have been emphasizing making money over art for a very long time. For any golden era of games there were penny pinchers micromanaging creative decisions at a level that destroyed souls. Might I suggest that a new tool for getting data is not the actual problem. The team sets their goals. The tools just get them there.

Are you worried that we are using Dumb Metrics? That the dumb patterns dumbly followed by dumb practitioners result in dumb ideas and dumb games? Well it is true. And the solution is one that applies to all complex instruments used in the pursuit of art and beauty: Get Good.


I actually see metrics, competent design and building something positive that meets player needs as three complementary pursuits. I’ve asked “Well, what do players want and how does that align with business? And how does that align with art or craft?”

Here’s one answer. Many players want connection with meaning and community. They want mastery and agency. This leads to them enjoying an activity for a long period of time. That results in great retention metrics. And when deep needs are being met, people are willing to spend. Will I spend a buck on Pokemon lures to enhance a relaxing afternoon with my wife at the coffee shop? Yes. It makes for joyful light conversation. The game improves our relationship by creating a shared playful space.

Metrics track and tune all this. Is that evil? Just the opposite. I consider it doing great good for the world through competent design practices.

I have made minor edits to the text to make it read as a standalone post: the original comment is still available under the original post.


The Purpose of Metrics in a Game

Brian Green (AKA Psychochild) has a piece responding to last week’s firestarter and arguing that there is a purpose for metrics in a game. Here’s an extract:

I dislike the absolutist nature of the argument, and prefer the more nuanced version. As a creative person, I still like things like food, a roof, and perhaps air conditioning when the temperature and humidity get high outside. But, I think it is important to realize that there is a decision to be made. One can choose to pure creative energy to create experiences on one extreme, pandering to tastes and maximizing for profit on the other, and a lot of room between the two extremes. And, as much as we might lionize the indie iconoclasts, the reality is that sometimes it takes a lot of work and understanding what people actually want to survive as an indie.

The argument Brian refers to here is art vs. commerce. Personally, I don’t accept a significant divide between art and commerce here… the vast majority of art is commercial in the sense that this term is used today: music recordings and performances are sold, paintings are auctioned, theatre and cinemas charge an entry fee. Knowing that games are artworks doesn’t mean the people who make them don’t deserve to be fed. I absolutely agree with Brian that game developers are no different in this regard: part of my argument in The Craft of Game Design Cannot Be Measured By Any Metric is precisely that indies, in rejecting commercial design considerations, are gambling on their livelihood.

So I accept Brian’s point that metrics can be used responsibly, at least in principle. My argument is only that there is a tension between the craft of game design, and engineering systems for commercial exploitation. Developers who can use metrics to assist their game design practices ought to make clear how this can be achieved without it becoming exploitative. I welcome the discussion here – it is this discourse that I feel is substantially missing.

You can read the entirety of The purpose of metrics in a game over on Psychochild’s Blog – check it out!