Game Design Lineages: Minecraft's Inventory

Abstract

Game design is conditioned by the practice, both formal and informal, of drawing from previous designs as a source of knowledge and inspiration. Innovation in game design is thus often the result of old ideas recombined in novel ways. We propose the concept of the game design lineage as a framework for tracing, analyzing, understanding, and explaining the historical significance of specific design elements in games. In addition to game design elements, a design lineage should consider a game's socio-cultural context, including the design and player practices of its creators, and the relationship between these and the prevailing player practices of the time. We contrast this with approaches that consider individual games as their unit of analysis-e.g. comparing different games with each other and establishing connections between them without considering the historical context of their player practices. We feel this approach, while insightful for understanding changes between games that are superficially similar, risks implying a strict Linnaean-style inheritance pattern (inheritance by genre), and thus struggle to account for games with a diversity of design elements that originate elsewhere. We argue that the flow of influences in game design is typically fluid and heterogeneous, and not constrained by genre. Key to this concept of a game design lineage is the role of player practices; i.e. how players receive, perceive, and interact with games, and the ways these have shaped the ideas that are then implemented. We illustrate the game design lineage approach with an analysis of Minecraft's inventory system, tracing its different elements across multiple games, genres, designers, and player practices.

Full text

Proceedings of DiGRA UK 2017
© 2017 Authors & Digital Games Research Association DiGRA. Personal and educational classroom use of
this paper is allowed, commercial use requires specific permission from the author.
Game Design Lineages:
Minecraft’s Inventory
Chris Bateman
International Hobo / University of Bolton
spiral@ihobo.com
José P. Zagal
Entertainment Arts & Engineering
University of Utah
jose.zagal@utah.edu
ABSTRACT
Game design is conditioned by the practice, both formal and informal, of drawing from
previous designs as a source of knowledge and inspiration. Innovation in game design is
thus often the result of old ideas recombined in novel ways. We propose the concept of
the game design lineage as a framework for tracing, analyzing, understanding, and
explaining the historical significance of specific design elements in games. In addition to
game design elements, a design lineage should consider a game’s socio-cultural context,
including the design and player practices of its creators, and the relationship between
these and the prevailing player practices of the time. We contrast this with approaches
that consider individual games as their unit of analysis – e.g. comparing different games
with each other and establishing connections between them without considering the
historical context of their player practices. We feel this approach, while insightful for
understanding changes between games that are superficially similar, risks implying a
strict Linnaean-style inheritance pattern (inheritance by genre), and thus struggle to
account for games with a diversity of design elements that originate elsewhere. We argue
that the flow of influences in game design is typically fluid and heterogeneous, and not
constrained by genre. Key to this concept of a game design lineage is the role of player
practices; i.e. how players receive, perceive, and interact with games, and the ways these
have shaped the ideas that are then implemented. We illustrate the game design lineage
approach with an analysis of Minecraft’s inventory system, tracing its different elements
across multiple games, genres, designers, and player practices.
Keywords
Game design lineage, player practice, RPG, Minecraft, D&D, Dungeon Master
INTRODUCTION
How can we articulate the knowledge of game designers? One well-established method
has been to identify and abstract important design ideas, disentangle them from any
specific game, and formulate them as a concept or schemata. The underlying assumption
is that an abstract idea is more easily communicated and also more readily usable by
others who can instantiate that concept in their games. These are approaches that tend to
deconstruct games into their constituent elements e.g. as patterns (Björk & Holopainen
2005), unit operations (Bogost 2006), or ludemes (Parlett 2015).

-- 2 --
It can be productive to decompose otherwise complex systems into constituent
components as a means of analysis. However, there are dangers in treating any such
decomposed element as merely a building block or tool in the design toolbox. These
approaches often isolate game design elements from the social, cultural, technological
and other contexts in which they reside. This makes it harder to understand why certain
elements may have been used, why they might have been popular, who they might have
been popular with, and more besides.
Consider the use of passwords in 8-bit videogames, for example. Outside of the context
of the arcade, which favored short, intense play experiences in order to facilitate coin
drops, games on early home computers, or consoles such as the NES, began to offer
larger worlds and thus longer play experiences. Players of these games needed to record
their progress so that they weren’t always starting from scratch. They needed a ‘save
game’, but the hardware was not yet able to easily support this option. A design solution
was developed that was hardware independent: the password. Upon completing a portion
of a game, an alphanumeric password would be presented to the player that allowed them
to start the game from that point when the password was entered on a later play session.
We argue that it is not possible to fully understand this design element without also
considering the context in which it was developed. Technology to store player data was
prohibitively expensive at the time (the economic context encouraged this interim
solution), player perceptions and interests were drawn towards more involved game
experiences that required many hours to complete (the design trend towards longer games
made ‘banking’ progress necessary to maintain an acceptable player experience) and,
inputting alphanumeric codes in a game was a familiar player practice due to the
existence of ‘cheat codes’ that were used to alter the way a game executed (the solution
was similar to a practice that players accepted and were familiar with).
The combinations of design elements that constitute games are constrained and shaped in
specific ways that go beyond their construction as systems. Human and cultural
influences serve important roles in elucidating practical elements of design, and these are
especially important when reconstructing the historical circumstances behind a design.
The challenge of trying to understand a design element through its historical context is
not novel and has been tackled across design-related disciplines in a variety of ways.
Keller et al (2006) describe how industrial designers collect materials they use for
reference while Brown discusses competitive reviews in web design as a method that
helps designers “find out how other people solved the same design problems” (Brown
2011 p. 255). Similarly, Clark and Pause (2012) argue for the importance of developing
theory with which to design architecture through the analysis of precedents. In fact, the
knowledge acquired from studying precedents is useful across a range of design tasks
(Eilouti 2009) and is often captured via design cases (e.g. Lawson 2014; Boling 2010).
In the context of game studies and game design we feel that little work has been done to
explore how best to provide rich and deep insight such that game design knowledge can
be understood, communicated, and possibly used, without losing the essential
relationships required to make sense of the games in question. We offer the notion of the
game design lineage as a means to partially address this challenge by contextualizing
game systems within the player practices that provided both the environment that guided
their implementation, and the background of understanding against which the game was
encountered by its original players.

-- 3 --
A game design lineage is rich description of the networks of connections between
common designed elements (in keeping with the notion of decomposing into coherent
units or patterns) that is situated within an understanding of the context that conditioned
the original design decisions that led to them, understood in terms of player practices
(Bateman 2016a, 2016b). This perspective is important not only in terms of more
accurately investigating the historical connectivity of games and their designs, but also
because insights from the past remain useful in the future, and can explain problems that
are currently misunderstood or taken for granted.
GAME DESIGN LINEAGES
Game designer Raph Koster argued that “the evolution of the modern video game can
largely be explained in terms of topology. Each generation of game can be described by a
relatively minute alteration of the play space.” Furthermore, he claimed that “when we
design games, we often start with a previous game and change just one element in it”
(Koster 2004 pp. 78–9). He notes that we can use this to understand relations between
games and how to group them (Koster 2014). For instance, a game with the same rules,
but differences in presentation can be called a ‘reskin’, changing a rule however leads to a
‘variant’. We call a collection of variants a ‘family’. And, if the family becomes large
enough, we end up with a ‘genre’. As a game designer, Koster is concerned with the
design of new games and his perspective offers a heuristic for game design innovation.
Juul built on this idea by organizing ‘matching tile’ games chronologically by year of
release and connecting them with directional arrows that indicated the possibility of
inspiration or the probable perception by players that this was the case (Juul 2008). So, an
arrow from Puzz Loop (1998) to Zuma (2004) meant that the latter was probably inspired
by the former or that players would likely perceive that to be the case.
Suominen (2016) argues that these approaches are genealogical in that they seem
beholden to biology and evolution: a game is presented as a root or source, and from it,
like branches on a tree. Thus, we can reveal connections between games, influences, “and
sources of inspiration of game designers” (Suominen 2016).
This biological metaphor, while at times productive, can be misleading. When designing
games, it is more often the case that elements of multiple games (and other media) serve
as inspiration rather than a single earlier game. Few games have a singular ‘ancestor’
from which they descend (sequels are perhaps the clearest exception). Designers pick and
choose from the buffet of options they are aware of. Following the biological analogy,
game design is akin to selecting genes from the different genomes that are known, and
from these disparate genes assembling a new creation. With apologies to Mary Shelley,
games are Frankenstinian, assembled from a mish-mash of parts and inspirations.
Our concern with genealogical approaches is that they prioritize the game as the unit of
analysis. However, many of the historical and design influences in games result from
design elements having been borrowed from other games, oftentimes outside of genre
conventions. Genealogies and other genre-based taxonomies are ill-equipped to provide
insights into how first-person shooter games such as Battlefield 4’s (EA DICE, 2013)
progression system was influenced by tabletop role-playing games (Zagal & Altizer
2014) or how quick-time events made their way from laser-disc games like Dragon’s
Lair (Cinematronics 1983) to 21st century 3rd-person action games such as God of War
series (e.g. SCE Santa Monica Studio 2005), first-person shooter games such as the Call
of Duty: Modern Warfare series (e.g. Infinity Ward 2009), and sports games like FIFA
2010 World Cup South Africa (EA Canada 2010).

-- 4 --
This genealogical concern also applies to videogames with significant configuration
options and games that are treated by their developers as a service (with frequent updates
and changes) rather than a product (e.g. Duncan 2016). Consider the customization
options allowed in multiplayer games of Halo 2 (Bungie 2004): arguably, these different
modes could be studied as variants (Cheung & Huang 2012). Similarly, the game of
World of Warcraft (Blizzard 2004) that was played when it was released has changed
significantly, in terms of its game design, compared to what is played today. How can we
best articulate what happens to these games in different players’ hands and over time?
Our answer to these challenges is the game design lineage. We present this as a research
method that entails both historical research and careful game analysis. Since this is a first
attempt at a game design lineage, it should not be taken as prescriptive of method but
indicative – our goal is to show how to draw together the decompositional method of
considering game elements that are a part of a game (rather than whole games) with the
compositional method of positioning games within genres and genealogies. We focus on
three contexts: (1) the player practices within which the game was both designed and
first played, (2) the material constraints (both technological and economic) affecting the
game, and (3) the creator vision, that synthesized these in a particular manner.
The method of constructing game design lineages we propose should not be taken to
present definitive histories, if indeed such a thing is possible. While establishing causal
relationships is beneficial to a design lineage, it should not be taken as a goal of the
method. The purpose of a design lineage is not to prove that one situation led to a later
situation, but to illuminate the latter situation in the light of the earlier ones that either
hypothetically, anecdotally, or evidentially provides a relevant context. In this regard,
they resemble ‘thick descriptions’ of game design from anthropology i.e. descriptions that
explain not just a behavior but also the context of that behavior such that even someone
not belonging to the relevant culture can understand it (Geertz 1973).
Player Practices
Player practices are the habits that players have learned from playing games:
“...a ‘player practice’ is anything that a player has learned to do consistently. This
includes, for instance, using the right stick on a controller to move the camera
object, pressing a button to jump, smashing boxes to look for power-ups, and
imagining that moving an animated ‘doll’ in a depicted space entails ‘entering’
the implied fictional world.” (Bateman, 2016a)
It is precisely because player practices are habits – and community habits at that – that
they are important to constructing a historical perspective on the design of specific
games. Constructing a game design lineage necessarily means taking into account what
player assumptions might have been and how they may have shaped the incorporation of
specific design elements. In tracking interface practices for example, it is possible to draw
partial conclusions from default control schemes as to the prevailing player practices
within a particular development culture, or player community (Gkikas et al. 2007).
Player practices can be identified by observation or interrogation of players. When
unavailable, the design of games can be examined to produce hypothetical player practice
claims. In this regard, we see no bar to individual players drawing on their own anecdotal
experiences as evidence, although anecdotal observations of multiple players ought to be
given more weight than purely personal observations.

-- 5 --
It is important to recognize that player practices are not automatically reproduced.
Designers often draw from existing player practices (e.g. the use of the right control stick
of a joypad to control a camera object) while also actively subverting prevailing practices
to innovate or meet their own play needs (e.g. Halo’s abandonment of a multiple weapon
inventory for a two-weapon system with streamlined controls and new design choices).
Below are a few questions that can guide the exploration of the player practices context:
• How was this design element related to contemporaneous player practices?
• In what ways was this design element familiar to players?
• How does the design element address a problem related to a player practices?
• How was this design element received by players?
Material Constraints
The technological affordances and limitations that existed when a design element was
developed constitute a major part of the material constraints working upon any particular
game. This includes the platform (i.e. the hardware and software frameworks that support
other programs) and other relevant technologies, e.g. display equipment, input devices,
and internet connectivity. Commercial considerations also form an important aspect of
the material constraints. For example, the design of arcade games was conditioned by the
material constraint of its business model, namely individual coin drops, a situation
revolutionized by Gauntlet (Atari Games 1985), which accepted multiple coin drops in a
single game – an early example of the ‘microtransaction’ business model.
Bogost and Montfort’s platform studies (2007) is a salient example of considering the
relationship, including mutual influences, that the underlying hardware and software can
have with games and their designed elements. Their book on the Atari 2600 demonstrates
how technological constraints can influence and affect game design (Montfort & Bogost
2009). It is important to consider both the constraints and affordances – what a given
technology makes possible – since new technologies (both hardware, e.g. graphics chips,
and software, e.g. game engines) have created novel avenues for design and discovery.
Questions for exploring the material constraints of design elements:
• How did this design element make use of existing technologies or tools?
• In what ways does the underlying technology support the design element?
• What technologies were necessary and how common were they?
• What commercial considerations affected the choices behind this design?
Creator Vision
Examining this context requires understanding how a creator takes their existing habits,
practices, and ‘materials’ and alters them in some way to create something new: their
context, in other words. This may include exploring, when known, what games they
might have played or been influenced by. It may also be necessary to consider other
games made by the same individual or studio. Since design practices are habits, the
culture of design practice at specific companies become important. Thus Bethesda’s
commitment to drawing from the practices and experiences of tabletop role-playing
games (Ramsay 2012) becomes part of the background of understanding for any of their
computer role-playing games in a way that is less significant for, say, Square-Enix, which
has no such vision. Similarly, we can learn about the creators’ context by examining
game design and development artifacts beyond the games including the code, comments
within the code (Sample 2013), game design documents, manuals, and more besides.

-- 6 --
Questions for exploring the context of creator vision:
• What games might the creator know and have been influenced by?
• What tendencies do the creators demonstrate through prior or subsequent work?
• What do we know about the developer’s design process or creative vision?
• What design trends were in vogue when this design element was developed?
CHALLENGES IN CONSTRUCTING GAME DESIGN LINEAGES
Because this research method can never be exhaustively complete, it presents substantial
challenges. The main risk is the creation of deterministic narratives that are overly
simplistic and reductionist. All explanatory narratives run this risk. Since one of the
purposes of a game design lineage is to identify connections between design elements
spanning games and time, there is danger in believing that because a connection exists,
such influence was inevitable (rather than merely fortuitous).
There are also practical challenges. The three distinct contexts articulated above will, in
practice, interrelate in various ways that may not be easy to disentangle. For instance,
game creators often have their own player practices that influence their work and will
deviate in various ways from the community practices, particularly when developers have
access to cutting-edge technology. Creator vision and material constraints combine to
shape player practices, just as player practices shape visions and drive the development of
new technologies, providing new material constraints.
Consider the example of Quake’s control schemes (id Software 1996). This is the point of
origin for the mouselook control mechanism that led to the two-handed FPS control
scheme, but it occurs only as an option in this game. Its standard control scheme uses
arrow keys for movement, a player practice that was well established in the dungeon
crawl games that descended from Dungeons & Dragons (TSR 1974), of which Dungeon
Master (FTL 1987) is a prominent example. Earlier id games such as Wolfenstein 3D (id
Software 1992) and DOOM (id Software 1993) had conserved the player practice of
using cursor keys for navigation, and were in effect dungeon crawlers in all but setting
and pace. Notably, id’s earlier Catacomb 3-D (id Software 1991) is expressly a dungeon
crawler. In this example, a player practice associated with one style of game (arrow key
controls with dungeon crawlers) develops into a new player practice associated with
different a kind of game (mouselook with FPS games) with influence from material
constraints (a new game engine) and creator vision (the faster paced gun play of the FPS).
Since it is hard to know beforehand what role a particular context may have had in
shaping a game design element, this approach may seem daunting. It is also possible that
important information may not known or available, and there are also frequent
inconsistencies even amongst those that were directly involved in the development of a
feature or idea. This means that in creating a game design lineage it is often necessary to
make assumptions based on incomplete or inexistent information when demonstrating the
provenance of a certain game design element is strictly limited by the available sources.
We argue that challenges notwithstanding, this is a fruitful method. It is also increasingly
easier to access the information required for this kind of work. We have seen a rise of
literature on videogames, both new and old. Strategy guides often include designer’s
commentary, game designers are more vocal in the media now than ever before, player
communities exist online in easily accessible places, streaming and media sharing offer
insights into how players play etc. Game reviews are also a source – they illustrate player

-- 7 --
practices prevalent at the time of a game’s release and highlight connections between
games and their creators that might not otherwise be known (Zagal et al. 2009).
The remainder of the paper is concerned with providing an illustrative case study before
concluding with a reflection on future directions for this kind of work.
CASE STUDY: MINECRAFT’S INVENTORY
Minecraft is arguably one of the most successful videogames of the 21st century. Its
trajectory from a small independent game to a worldwide phenomenon earned its creators
numerous industry accolades and significant financial success (Duncan 2011). In terms of
its design, Minecraft was not significantly innovative – having been, in fact, described as
a clone of an earlier game (Infiniminer) by its creator Markus “Notch” Persson (Goldberg
& Larsson 2015). That being said, Minecraft was significant in the way it utilized,
recombined, and reimagined game design elements from earlier games.
In the following game design lineage we will discuss and analyze Minecraft’s inventory
system (see Appendix, Figure 1). What can immediately be seen are (1) a grid inventory,
(2) a set of armor slots and an image of how they look upon the character, (3) a crafting
area, and (4) a quickbar. We draw attention to 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 (D&D), the
player practices of which are not overtly on display within Minecraft, but which can be
shown to condition its design through the games that descended from its influence.
Grid Inventories and the Paper Doll
The grid inventory, prominent in Minecraft and the backbone of game inventories for
years now, is part of a series of player practices that owe their origins to the influential
Dungeon Master (FTL 1987). In all grid inventories, equipment is represented by a tile
(often, but not exclusively square) showing an icon of the relevant item, and items are
equipped by dragging these icons into the relevant spaces surrounding a figure
representing the character. Items that are carried but not equipped are stored in
rectangular blocks of empty squares. Every aspect of this design originates with Dungeon
Master, which made a conscious break from the linear text inventories of earlier
computer RPGs (see Appendix, Figure 2).
Dungeon Master 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 (Sir-Tech 1980)
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 (McFerran 2006). They ended up partnering 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.
The core vision guiding the project was providing the player a powerful sense of
immersive presence. Jimmy Maher (2015), in a summary of the circumstances behind the
game, characterizes 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?”. Bell and
Jaros, as game designers caught up in the well-established player practices of Wizardry
and Dungeons & Dragons, were repeatedly challenged by the Holders to push past the

-- 8 --
usual assumptions. As Wayne Holder later remarked, “At the time, most RPGs were
adaptations of board games” and their ambition was to transcend this (Meston & Arnold
1994 p. 131). Nancy Holder’s experience as a horror writer informed the experiential
design, while Wayne Holder’s outsider perspective on role-playing helped remake the
menu systems to bring them up to the standards then coming together in Graphical User
Interfaces at the dawn of the WIMP (Windows/Icons/Menus/Pointer) era (Kovacs 1988).
Thus the creators’ vision for 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 D&D. In Dungeon Master (itself 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 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 conserved from this point, as Holder
himself remarks (Meston & Arnold 1994 p. 132): “We expected to be imitated... but it
was amazing how many things we did that got completely borrowed.” Indeed, comparing
a screenshot of Minecraft’s grid inventory with that of Dungeon Master’s, the key
difference is that Minecraft’s appears shoddier in terms of presentation values.
Crafting and Multi-Celled Inventories
The process of manipulating game items in certain combinations to create new items has
come to be termed ‘crafting’. Minecraft’s inventory screen has a box specifically for this
purpose. Crafting formed no significant part of Dungeons & Dragons player practices
until the 3rd edition in 2000, and none of the notable early computer RPGs descending
from it feature this concept. The means of creating magical items that tabletop D&D
offered has had next to no influence, and while there are earlier examples of item-
combinations such as Ultima IV’s spell creation system (Garriott 1985) or Finders
Keepers (Jones 1985), it appears to be Diablo II (Blizzard North 2002) that largely
establishes the design element and player practice of crafting through the introduction of
the Horadric Cube, a secondary grid inventory of 3x4 spaces that includes a button to
transmute its contents into a new magical item (see Appendix Figure 3). This provided a
means for players to create endgame items beyond waiting for them to drop, and although
its function was considered fairly arcane at the time, 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 (Blizzard North 1996) and Diablo II were so commercially
successful that it is these games (and 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 CRPG lineage, which also traces its heritage back
to D&D via The Black Onyx (Rogers 1984) and Wizardry before it, would tell a different
story, but one that does not bear on the game design lineage of Minecraft’s inventory.
The original Diablo is one of the games that synthesizes 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

-- 9 --
time between when you started the game up to when you were clubbing a
skeleton.” (Edge 2010)
Indirect influences came in via the other co-creator, David Breivik, who had played
Moria (Koeneke & Todd 1983) and Angband (Cutler & Astrand 1990), two early
roguelike games descended ultimately from the unimaginatively titled dnd (Whisenhunt
& Wood 1975) on the PLATO educational computer network, work on which began the
same year that tabletop D&D appeared.
The inventory in Diablo has another key point of influence, however, namely Julian
Gollop’s X-Com: UFO Defense (Gollop 1994), originally entitled UFO: Enemy
Unknown. The influence here was in the idea of modifying original grid inventory
concept, which allocated one square to an item, by having items take up multiple spaces
(see Appending Figure 4). In Diablo’s inventory screen, weapons take up between three
and six spaces in the grid, in various configurations, a design element and player 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 (Edge 2010, Pitts
2006).
The multi-cell grid inventory created by Gollop for X-Com descends from a line of games
the British programmer developed for 8-bit home computers. From the age of 14, Gollop
was playing Dungeons & Dragons and the strategy boardgames of Avalon Hill that had
inspired it (Retro Gamer 2014). Gollop was influenced by the design of strategic
boardgames, as can be seen with Rebelstar Raiders (Gollop 1984) and its sequels,
although it is only with Laser Squad (Target Games 1988) that he began 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. The multi-cell grid inventory arguably has its origin at the tabletop, since
Battlecars (Chalk & Livingstone 1983), which Gollop adapted into a videogame, used a
similar system, and this boardgame descended directly from Steve Jackson’s classic
tabletop autoduellist wargame Car Wars (Jackson 1981), for which allocating weaponry
to the limited spaces available in the chassis was a major aspect of its play.
Another of Jackson’s games, GURPS (Jackson 1986), serves as a more direct connection
between crafting practices in videogames and their tabletop predecessors. While Diablo II
appears to be the game with the most direct influence on Minecraft’s crafting, it is
important to recognize that the Elder Scrolls series is another contributor to the player
practices that sustain crafting in games. 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. It is Daggerfall (Bethesda 1996) that
marks the point that Bethesda’s influences change from D&D to later tabletop role-
playing systems, particularly GURPS (Gamespy 2001 as archived at RPGCodex.net).
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 below,
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 (Bethesda 1994) had a spell creation system that was
a modular version of D&D’s fixed-definition spells. Daggerfall, on the other hand, has a
more detailed spell and weapon enchantment system, where players choose from a set of
effects then modify casting cost and purchase price by altering chance of effect, duration,

-- 10 --
or magnitude. This draws very clearly from the GURPS concepts of Advantages and
Disadvantages that would go on to influence Fallout (Interplay 1997).
Tabletop RPGs hadn’t had a motive to include crafting systems, but the emphasis on
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.
Certain items in the game were characterized 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 the Mixing Cauldron’s scope is narrower than Diablo II’s Horadric Cube, both
develop the same design element: one where the inventory is neither a source of
equipment for immediate use (as in D&D), or simply fodder for sale (e.g. most pre-90’s
CRPGs), but a set of active elements that can be combined in different patterns to get
other equipment. Material constraints are relevant here, since these player practices made
no sense at the tabletop, where complex look-up tables would be required. On computers,
however, the availability of automated game systems kicked off experimentation with
crafting as soon as there was sufficient memory space for such luxuries.
Quickbars
One final element of Minecraft’s inventory remains unaccounted for: the bar at the
bottom that allows rapid access to the contents of the inventory. This 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 tracing its departure point to D&D. Here,
the pivotal game is EverQuest (SOE 1999), which is the first of the 3D ‘graphical MUDs’
– later known as a Massively Multiplayer Role-playing Game (MMORPG).
The earliest MUDs, such as the ground breaking MUD1 (Trubshaw & Bartle 1978) were
much more exercises in world building and community play than adaptations of D&D,
although Bartle notes that he had played the game (Bartle 2016). It is the LP MUDs
(Pensjö 1989) and especially the DikuMUDs (Hammer et al. 1990), originating in
Sweden and Denmark respectively, that saw in the MUDs the opportunity to (yet again)
adapt D&D for computer form (Aarseth 1997 pp. 142–61), 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 computerized form, it was taken.
The inventory systems of all these early online 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
as 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.
The graphical interface of the MMORPG is the material constraint that gives rise to the
quickbar. However, tracing the practices of MMOs, or indeed any game that is run as a
service, requires significantly greater effort than investigating games released as products.
Game-as-services means constant changes and updates, and this makes archaeology

-- 11 --
difficult to adequately perform. Nonetheless, we know of an early (perhaps the first) form
of the hotbar in the original EverQuest. The player was able to customize its contents by
placing different actions (at this point primarily described in words e.g. “Melee Attack”)
onto the bar, where it could be quickly clicked with the mouse, or activated with a
hotkey. The name ‘hotbar’ is a reference to the concept of a ‘hotkey’, which has its origin
in the graphical interfaces of computer operating systems. It appears to be EverQuest’s
early competitor Dark Age of Camelot (Mythic Entertainment 2001) which coins the term
‘quickbar’ (styled in Minecraft’s case as a ‘quick-bar’), and as with all games of this
style, the design varies radically throughout its life. The functionality, however, remained
parallel to the equivalent practices of EverQuest.
CRPGs 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 the officially licensed D&D
computer RPG Baldur’s Gate (BioWare 1998) functions as a proto-quickbar, even
though inventory items are a small part of the space allocated for it. Similarly, Diablo II
offers a quickbar-like system that is presented as being part of the fictional 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 (Blizzard
Entertainment 2012), this experiment had merged with the main lineage of quickbar
practices that had blossomed in the MMORPGs.
There is another potential link between the quickbar and MUDs worth considering. MUD
players 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 that supported macros. A macro was 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 MUD client software began to build-in
these macro systems 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 (Bartle 2003), they appear to
have been drawn to providing customizable interface elements like the hotbar, thus
accelerating the development of what would become called the quickbar: they were (on
this reading) a graphical substitute for macros, a customizable 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 a clear 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 Origins of Game Inventories
For almost twenty years after its original release, TSR’s Dungeons & Dragons was the
wellspring from which many of the player practices and design elements of computer
role-playing games were established and conserved. 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 –

-- 12 --
made this the definitive version of tabletop RPG player practices that were conserved by
the computer variants. All the way through the 70s and 80s, D&D was feeding its player
practices directly or indirectly into computer games, as with the example above of the
influence of early dungeon crawlers on the development of the FPS lineage.
In terms of inventories, Dungeons & Dragons effectively invents them (although it did
not coin this term) 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 key to the inventory is the character sheet, which
collected together all manner of fields (Name, Class, Attributes, Alignment and so forth)
including a list of all items possessed – the prototype of the inventory. D&D’s original
1974 edition did not have a pre-designed character sheet, and players recorded all the text
and numbers required to specify their characters without an established template.
However, experimentation in home-printed character sheets soon appeared, such as the
one created by Bob Rupport in 1975 (Peterson 2013). TSR only established an official
printed character record sheet in 1977. These early examples demonstrate that tabletop
RPG inventories in the early days were 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 provided 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.
When early computer role-playing games took up these practices, there was little sense in
maintaining the distinct segments, with Daggerfall a rare exception. It was the material
qualities of paper and pencils, and the requirements for manual maintenance of lists in
this form, that had made separate boxes useful. The material constraints of computer
games, however, all but dictated a single inventory system accessed with a unified control
mechanism – as can be seen with Wizardry and The Bard’s Tale (Interplay 1985).
In The Bard’s Tale, each character in the party is allowed eight items in their inventory –
a number that facilitated selecting items using a single press of the number keys (the
material constraint that informed this design). Equipped items were marked with an
asterisk, and although an image of party members is shown the choices of items do not
change that appearance (as they do in Minecraft). Despite being five years older,
Wizardry’s inventory is almost identical, the one difference being the use of a question
mark to indicate items that had not been identified, a player practice invented by D&D
but largely maintained only in Rogue (Toy & Wichman 1980) and its descendants.
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 (Crooked Bee 2013). Just as with Bell and Jaros’ Dungeon Master, 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 (Gygax 1978),
such as changing classes – itself a contribution from the player community.
Recognizing Dungeons & Dragons’ role in initiating inventory design elements
underlines the importance of considering player practices for game design lineages. The
tabletop role-playing game had radically different material constraints to early computer
games, and it was the desire to preserve the already established player practices that made

-- 13 --
the inventory systems for Wizardry and The Bard’s Tale what they were – and the desire
to transcend what had gone before which made Dungeon Master such an influential title.
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 here 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.
CONCLUSIONS AND FUTURE DIRECTIONS
The player is the heart of the game, and game design conserves player practices because
designers are also players. We can trace lineages of design elements and their intimately
related player practices 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 bring
something new to the table in the process. Notch may not have played tabletop Dungeons
& Dragons, or The Bard’s Tale, or Dungeon Master, or X-Com, or EverQuest, but the
inventory practices of Minecraft nonetheless inherits the successful variations that these
games introduced upon a bedrock of established player practices.
Understanding games and game design by examining player practices and constructing
game design lineages does not entail any dramatic sea change to the way games are made
or studied, it merely involves foregrounding what is all too commonly dismissed: games
are connected by historical lineages sustained by common player practices, which is to
say, things the player learns to do consistently. The game designer, a player themselves,
recreates the player practices learned from other games, as well as expanding and
intentionally subverting them through the application of new creative visions, conditioned
in part by the affordances offered by new material constraints. Even when a game
designer thinks they are pulling together isolatable atomic elements of a game design,
they may simply be ignoring the practices those elements belong to, and which are
required to make sense of them. The game design lineage method invites both researchers
and game designers to reconsider the role of history and culture in understanding games.
Not only do game design lineages represent a new research tool for understanding the
history of games and the practices of game design, they potentially have significant
relevance for commercial game development. Certain games succeeded commercially
while others did not: the reasons for this are not always (perhaps, not ever) entirely
reducible to the design decisions or the quality of implementation. Sometimes the
prevailing player practices created difficulties within the marketplace because a certain
game did not align with player expectations, while other games with apparently
conservative designs (i.e. designs that did not innovate) enjoyed commercial success
despite the frequent claims of players to prefer originality. We leave open the question of
how these aspects of commercial success could be researched, or even whether definitive
answers are available to researchers. Nonetheless, the preceding discussion makes a case
for the influence of player practices and game design lineages upon the commercial
success of Minecraft that at the very least offers a new perspective that commercial game
designers and game studies scholars may want to seriously consider.
ACKNOWLEDGEMENTS
With thanks to Richard Bartle, Richard Boon, Erlend Grefsrud, Dan Griliopoulos, Jacob
Hartmann, Doug Hill, Jacobo Luengo, Yik-Sian Seow, Oscar Strik, and Samantha Vega.

-- 14 --
Parts of this paper appeared in five parts on http://blog.ihobo.com starting here:
http://blog.ihobo.com/2016/09/index.html
BIBLIOGRAPHY
Aarseth, E. (1997). Cybertext : Perspectives on Ergodic Literature. Baltimore: Johns
Hopkins University Press.
Atari Games. (1985). Gauntlet. Milpitas, CA: Atari Games.
Bartle, R. (2003). Designing Virtual Worlds., 1st edition. New Riders Games.
——. (2016). ‘Personal Communication’.
Bateman, C. (2016a). ‘No-one Plays Alone’. Presented at the First International Joint
Conference of DiGRA and FDG 2016, Dundee, Scotland.
——. (2016b). ‘The Lineages of Play’, Journal of Playwork Practice, 3/2: 95–106.
Bethesda. (1994). The Elder Scrolls Arena. Rockville, MD: Bethesda Softworks.
——. (1996). Daggerfall. Rockville, MD: Bethesda Softworks.
BioWare. (1998). Baldur’s Gate. Irvine, CA: Interplay Entertainment.
Björk, S., & Holopainen, J. (2005). Patterns in Game Design. Game Development Series.
Hingham, Massachusetts: Charles River Media Inc.
Blizzard. (2004). World of Warcraft. Irvine, CA: Blizzard Entertainment.
Blizzard Entertainment. (2012). Diablo III. Irvine, CA: Blizzard Entertainment.
Blizzard North. (1996). Diablo. Irvine, CA: Blizzard Entertainment.
——. (2002). Diablo II. Irvine, CA: Blizzard Entertainment.
Bogost, I., & Montfort, N. (2007). ‘New Media as Material Constraint: An Introduction
to Platform Studies’. Presented at the 1st International HASTAC Conference,
April 19.
Bogost, Ian. (2006). Unit Operations: An Approach to Videogame Criticism. Cambridge:
MIT Press.
Boling, E. (2010). ‘The Need for Design Cases: Disseminating Design Knowledge’,
International Journal of Designs for Learning, 1/1: 1–8.
Brown, D. (2011). Communicating Design 2nd Edition. Berkeley, CA: New Riders.
Bungie. (2004). Halo 2. Redmond, WA: Microsoft Game Studios.
Chalk, G., & Livingstone, I. (1983). Battlecars. Nottingham, UK: Games Workshop.
Cheung, G., & Huang, J. (2012). ‘Remix and Play: Lessons from Rule Variants in Texas
Hold’em and Halo 2’. Proceedings of the ACM 2012 conference on Computer
Supported Cooperative Work, pp. 559–68. Presented at the CSCW ’12, Seattle,
WA: ACM.
Cinematronics. (1983). Dragon’s Lair. El Cajon, CA: Cinematronics.
Clark, R. H., & Pause, M. (2012). Precendents in Architecture, 4th Edition. Hoboken, NJ:
John Wiley & Sons, Inc.
Crooked Bee. (2013). ‘RPG Codex Retrospective Interview: Michael Cranford on Bard’s
Tale, Interplay, and Centauri Alliance’. RPG Codex. Retrieved February 14,
2017, from <http://www.rpgcodex.net/content.php?id=9163>
Cutler, A., & Astrand, A. (1990). Angband.
Duncan, S. C. (2011). ‘Minecraft, Beyond Construction and Survival’, Well Played, 1/1:
1–22.
——. (2016). ‘Mandatory Upgrades: The Evolving Mechanics and Theme of Android
Netrunner’, Analog Game Studies, 3/5.
EA Canada. (2010). 302 FIFA World Cup South Africa. Redwood City, CA: EA Sports.
Edge. (2010). ‘The Making of... Diablo’, Edge Magazine, 210: 104–7.
Eilouti, B. H. (2009). ‘Design knowledge recycling using precedent-based analysis and
synthesis models’, Design Studies, 30/4: 340–68. DOI:
10.1016/j.destud.2009.03.001

-- 15 --
FTL. (1987). Dungeon Master. San Diego, CA: FTL Games.
Gamespy. (2001). ‘Ted Peterson Interview’. Gamespy. Retrieved February 15, 2017,
from <http://www.rpgcodex.net/forums/index.php?threads/im-looking-forward-
to-oblivion.9614/page-4#post-151132>
Garriott, R. (1985). Ultima IV: Quest of the Avatar. Austin, TX: Origin Systems.
Geertz, C. (1973). ‘Thick Description: Toward Interpretive Theory of Culture’. Geertz C.
(ed.) The Interpretation of Cultures: Selected Essays, pp. 37–59. Basic Books:
New York.
Gkikas, K., Nathanael, D., & Marmaras, N. (2007). ‘The evolution of FPS games
controllers: how use progressively shaped their present design’. Presented at the
Panhellenic Conference on Informatics.
Goldberg, D., & Larsson, L. (2015). Minecraft, Second Edition: The Unlikely Tale of
Markus ‘Notch’ Persson and the Game that Changed Everything. Seven Stories
Press.
Gollop, J. (1984). Rebelstar Raiders. London: Red Shift.
——. (1994). X-Com: UFO Defense. Alameda, CA: MicroProse.
Gygax, G. (1978). Advanced Dungeons & Dragons Player’s Handbook. Lake
Geneva:WI: TSR Hobbies Inc.
Hammer, S., Seifert, M., Stærfeldt, H. H., Madsen, T., & Nyboe, K. (1990). DikuMUD.
id Software. (1991). Catacomb 3-D. Shreveport, LA: Softdisk.
——. (1992). Wolfenstein 3D. Garland, TX: Apogee Software.
——. (1993). Doom. Mesquite:TX: id Software.
——. (1996). Quake. New York, NY: GT Interactive.
Infinity Ward. (2009). Call of Duty: Modern Warfare 2. Santa Monica, CA: Activision.
Interplay. (1985). Tales of the Unknown, Volume 1: The Bard’s Tale. Redwood City, CA:
Electronic Arts.
——. (1997). Fallout. Irvine, CA: Interplay Entertainment.
Jackson, S. (1981). Car Wars. Austin, TX: Steve Jackson Games.
——. (1986). GURPS. Austin, TX: Steve Jackson Games.
Jones, D. (1985). Finders Keepers. London: Mastertronic.
Juul, J. (2008). ‘Swap Adjacent Gems to Make Sets of Three: A History of Matching
Tile Games’, Artifact, 2: 205–16.
Keller, A. I., Pasman, G. J., & Stappers, P. J. (2006). ‘Collections designers keep:
collecting visual material for inspiration and reference’, CoDesign, 2/1: 17–33.
Koeneke, R. A., & Todd, J. W. (1983). Moria.
Koster, R. (2004). A Theory of Fun for Game Design. Paraglyph.
——. (2014). ‘When is a Clone’, Raph Koster’s Website.
Kovacs, R. (1988). ‘Interview of Wayne Holder’, ST-Report, 24.
Lawson, B. (2014). ‘Schemata, gambits and precedent: Some factors in design expertise’,
Design Studies, 25/5: 443–57.
Maher, J. (2015). ‘Dungeon Master, Part 1: The Making of’. The Digital Antiquarian.
Retrieved February 14, 2017, from <http://www.filfre.net/2015/12/dungeon-
master-part-1-the-making-of/>
McFerran, D. (2006). ‘The Making of Dungeon Master’, Retro Gamer Magazine, 34: 30–
1.
Meston, Z., & Arnold, J. D. (1994). ‘An Interview with Wayne Holder’. Dungeon Master
II: The Official Strategy Guide, pp. 131–3. Sandwich Islands Publishing:
Lahaina, HI.
Montfort, N., & Bogost, I. (2009). Racing the Beam: The Atari Video Computer System.
Platform Studies. Boston, MA: MIT Press.
Mythic Entertainment. (2001). Dark Age of Camelot. Los Angeles, CA: Vivendi Games.

-- 16 --
Parlett, D. (2015). ‘What’s a Ludeme? – and who really invented it?’, The Incompleat
Gamester.
Pensjö, L. (1989). LPMud.
Peterson, J. (2013). ‘Character Sheets in 1975’. Playing at the World. Retrieved February
14, 2017, from <http://playingattheworld.blogspot.co.uk/2013/07/character-
sheets-in-1975.html>
Pitts, R. (2006). ‘Secret Sauce: The Rise of Blizzard’. The Escapist, no. 48, Retrieved
28th February 2017, from
<http://www.escapistmagazine.com/articles/view/video-
games/issues/issue_48/289-Secret-Sauce-The-Rise-of-Blizzard.3>
Ramsay, M. (2012). ‘Christopher Weaver: Founder, Bethesda Softworks’. Gamers at
Work: Stories Behind the Games People Play. Apress: New York, NY.
Retro Gamer. (2014). ‘Julian Gollop’. Retro Gamer. Retrieved February 15, 2017, from
<http://www.retrogamer.net/profiles/developer/julian-gollop/>
Rogers, H. (1984). The Black Onyx (
ザ・ブラックオニキス
). Yokohama: Bullet-Proof
Software.
Sample, M. (2013). ‘Criminal Code: Procedural Logic and Rhetorical Excess in
Videogames’, Digital Humanities Quarterly, 7/1.
SCE Santa Monica Studio. (2005). God of War. San Mateo, CA: Sony Computer
Entertainment.
Sir-Tech. (1980). Wizardry: Proving Grounds of the Mad Overlord. New York, NY: Sir-
Tech Software.
SOE. (1999). Everquest. San Diego, CA: Sony Online Entertainment.
Suominen, J. (2016). ‘How to Present the History of Digital Games’, Games and Culture.
Target Games. (1988). Laser Squad. London, England: Blade Software.
Toy, M., & Wichman, G. (1980). Rogue.
Trubshaw, R., & Bartle, R. (1978). MUD1.
TSR. (1974). Dungeons & Dragons. Lake Geneva:WI: Tactical Studies Rules.
Whisenhunt, G., & Wood, R. (1975). dnd (PLATO system).
Zagal, José P., & Altizer, R. (2014). ‘Examining “RPG Elements”: Systems of Character
Progression’. Proceedings of the 9th International Conference on the
Foundations of Digital Games. Presented at the Foundations of Digital Games
(FDG) 2014, Society for the Advancement of the Science of Digital Games.
Zagal, Jose P., Ladd, A., & Johnson, T. (2009). ‘Characterizing and Understanding Game
Reviews’. 4th International Conference on the Foundations of Digital Games.
Orlando, FL: ACM.

-- 17 --
APPENDIX
Figure 1: Minecraft Inventory System (sans Quickbar)
Figure 2 Inventory System in Dungeon Master

-- 18 --
Figure 3 Diablo II's Horadric Cube (crafting system interface)
Figure 4 UFO Enemy Unknown