• Yes
• No

• I usually research with a team
• I sometimes research with a team
• I occasionally research with a team
• I rarely research with a team

• Designers
• Colleagues in my discipline
• Colleagues from other disciplines
• Software developers
• Content specialists
• Librarians
• Computer Scientists
• Students
• Other (please list)

1. Our first recommendation would be to secure all promised support in writing. Even though a current administrator is well disposed toward your innovation and understands the commitment it requires of all those involved, administrators change. A written commitment will ensure that new incumbents in any office understand that a commitment was made, by their office and not just by the previous occupant, to your ideas, your personnel, and the results you seek to achieve.
2. Develop and articulate terms of evaluation that will enable your administration to see and measure your success. This can result in positive impacts on individual applications for renewal, tenure and promotion, as well as on the innovation itself. It will also provide you with material to convince new students of the value of adding your classes to their timetables.
3. Make explicit your intention to let your innovation wither on the vine if your administration is not willing to commit, in writing, to its continuation beyond an initial trial period (probably that of an initial grant). This way, you do not fail to at least try to innovate, but you also do not commit yourself or your institutional “home” to support that neither you nor they can afford in the absence of administrative responsibility.
4. Those who would get involved in innovation must know explicitly how their involvement will count toward renewal, tenure and promotion. A good model might be one in which key innovators have a written statement from whoever has the authority to offer it indicating that involvement in the innovation will count, for example, as the equivalent of a peer reviewed publication.
5. We found in developing and implementing the multi-disciplinary course we placed at the core of the HHC experience that through administrative and financial imagination it is possible to overcome seemingly insurmountable professional and financial problems. We were able to implement our core course for less than the cost of a single replacement hire on a contractually limited term basis, despite the fact that we had seven university employees from six different campus units involved.
6. Technical support and information literacy are now integral parts of a meaningful humanities experience. By fully integrating technical support and information literacy into our courses, we have been able to offer students marketable computer skills and to incur in them a healthier and more informed attitude to new forms of media production and consumption.
7. Students should be able to see that real scholarship is available to them to produce, and they can become participants in a scholarly field through the production of well-composed and thoroughly researched work. AhHa!, our data management system, made it easy for us to track students’ progress through the “program,” and to let them see how they compared to their peers. The perennially asked “but what do you want?” questions evaporated when students could see how others had addressed themselves to assignments, and in fact the quality of student work improved as subsequent classes could see what had been done before. Students were no longer working in the artificial vacuum of individualistic student-scholarship, where “real” scholarship is defined as that produced by unknown names followed by the three mysterious letters, PhD. Instead, students were able to see that real scholarship was available to them to produce as much as to read, and that they could become participants in a scholarly field not through some unexplained and occult rite that their professors had undergone at some specific place definable only as “not here,” but through the production of well-composed and thoroughly researched work such as that of which they were demonstrably capable.

1. We represent textual variation with the <app> tag and indicate the sequence of the author’s corrections with the varseq attribute;
2. We contain the textual variation within the element <seg type="l">, representing the reconstruction of the verse unit;
3. We avoid the redundancy of empty elements by specifying which unit undergoes textual variation.

1. Who are your collaborators?
   1. What community is your research accountable to beyond your academic community?
   2. How will you demonstrate your desire to be accountable to them?
   3. Are there people you can talk to about the impact of your research beyond the IRB?
2. How does everyone benefit from the research?
   1. What questions does the community want answered?
   2. Can people be compensated in ways that honor their time and skills?

1. What tools and or methods encourage multidirectional collaboration?
   1. What mechanism of accountability can you create?
   2. Are there ways that collaborators can use the research process to their own ends?
2. What kind of process can you create for your research?
   1. Is there room for collaborators to give and rescind consent at different times during the research process?
   2. Does the pace of the project meet your needs and your collaborators needs?

1. How will you take care of yourself in the research process?
   1. What do you and your collaborators need to stay sustained while conducting the research?
   2. What happens after the research product is complete?
2. How will you be transformed?
   1. Will the research strengthen your connection to your collaborators?
   2. Did you and your collaborators come to new understandings?

Apocalyptic: A term that is used almost as loosely within biblical scholarship as outside it; etymologically the word is derived from the Greek for “revelation” or “unveiling” and some scholars would wish to restrict its use to a type of literature in which heavenly secrets are revealed to the seer by a vision, a heavenly journey, or the words of an angel (or some combination of all three). All too often, however, the term is used as if it meant eschatological, and for want of a better term it is often used to describe a particular type of eschatology in which ordinary human history is expected to be interrupted by a catastrophic divine intervention in the near future (the reason being that such eschatology is frequently expressed through the medium of apocalyptic in the first sense).

Byte Code: The name often given to the intermediate product of compilation; a byte code file can typically be run on an interpreter or virtual machine rather than directly by a computer’s operating system.

Code: Without further qualification this normally refers to “Source Code”, the set of instructions the author/programmer writes in whichever programming language he or she is writing to tell his or her program (in this case, work of IF) how to behave.

Compiler: A piece of software to translate human readable source code into machine readable form. Compilation may be to a native executable (a file that can be executed by a particular operating system without further ado) or, more usually with Interactive Fiction, to some intermediate (byte code) form that can be run by different interpreters on different operating systems.

Containment Hierarchy: The system of containment that determines which objects are within which other objects. In this context “within” includes inside, on top of, underneath or behind. At the top of the containment hierarchy stand the rooms; rooms are regarded as not being contained by anything but as directly or indirectly containing everything else (except for objects temporarily out of play and so outside the map althogether).

Debugger: A tool which helps a programmer (or in this case, game author) track down programming errors or “bugs”. For example TADS 3 Workbench for Windows incorporates a highly sophisticated debugger that allows the programmer to step through his code line by line to see what it is doing each step of the way (and so determine where something is going wrong if it is going wrong).

Domain-Specific Language: A computer programming language (such as Inform or TADS) specifically tailored to a particular type of task (such as writing Interactive Fiction).

Eschatology: Anything that deals with the last things, the end of the age or the consummation of history (from the Greek eschatos, meaning “last”). In Christian theology eschatology traditionally deals with matters such as Heaven, Hell, the Second Coming and the Last Judgement; in a first-century context it is better thought of in terms of the coming of the kingdom of God, the age to come in which the evils of the present age would be overcome.

IDE (Integrated Development Environment): A single piece of software containing all (or at least) most of the tools a game author needs in order to write a game, including an editor, a compiler, a debugger and an interpreter on which the game may be tested.

Inform: The most popular language/system for authoring Interactive Fiction, written and maintained by Graham Nelson. Two versions of Inform are currently in use. Inform 6 (the older version) resembles a conventional programming language. Inform 7 adopts a more “natural language” style of programming with the aim of making the process of writing Interactive Fiction more like writing prose and less like conventional programming.

Implicit Action: An action automatically carried out by the parser in order to facilitate the command the player actually typed; for example if the player types GO THROUGH RED DOOR when the red door is locked but the player has the key, a well-behaved parser would carry out implicit UNLOCK RED DOOR and OPEN RED DOOR actions rather than forcing the player to type these commands explicitly.

Inventory: The items currently carried by the Player Character.

Interpreter: A piece of software that (typically) implements a Virtual Machine and so allows a game compiled to byte code to be run on the player’s computer; one generally needs an interpreter to run a work of Interactive Fiction in the same way that would need a copy of MS-Word to read a Word file, or a program such as Windows Media Player to watch a DVD on a computer. The advantage is that an interpreter needs to be written only once for each operating system (Windows, MAC-OS, Linux, etc.) and can then play all the games written for that interpreter.

Library: A set of supporting routines supplied with an IF authoring system such as TADS or Inform that handles most of the tasks common to most works of Interactive Fiction; a library will typically implement a parser and at least a basic world model, and will generally be written in the same language as that supplied with the authoring system to allow ready customization by game authors.

Map: The totality of rooms within a particular work of Interactive Fiction, together with the interconnections between them.

Menu: A set of options presented to a computer user from which he or she is meant to select one.

Non Player Character (or NPC): Any animate character (human, animal, alien or robotic) that appears in a work of Interactive Fiction apart from the Player Character; characters whose actions are not controlled by the Player Character. Usually, the term is restricted to characters who are actually implemented and can be interacted with rather than characters who are only mentioned or who never remain on stage long enough for the Player Character to interact with.

Object: Something physical that the Player Character can interact with (or at least examine) in the course of the game, such as a table, chair, pen, or book (or, indeed, another character). Some objects may be quasi-physical (such as smoke or sunlight). In many IF authoring systems based on OOP (object-oriented programming) design, “object” may also refer to a programming object; in such systems a game object (in the first sense) will usually be represented by a programming object (the second sense), but programming objects may also be used for other purposes (if you don’t know anything about OOP, this second sense of “object” is probably irrelevant to you).

Parser: That part of the software in a work in the Interactive Fiction that interprets the player’s command and translates it into an action that the program can perform (or else complain if translation is impossible or ambiguous).

Player: The flesh-and-blood human being typing the commands at a keyboard and reading the game’s responses on screen.

Player Character (or PC): The protagonist of a work of Interactive Fiction, whose actions are controlled (or at least guided) by the player, and through whose eyes and ears the fictional world is described to the player.

Room: A (normally discrete) unit of space within the game’s map. The usual convention is that the Player Character can interact with anything that is in the same room as himself or herself (unless it is deliberately concealed), and so a room is effectively that volume of space that is immediately present to the Player Character. A room may be a room in the ordinary sense of a room within a building, but it may also be a section of space outdoors, such as a meadow, the top of a hill, or a section of street.

Scope: Roughly speaking, the set of objects with which the Player Character can currently interact, given the nature of the action he or she is meant to be carrying out. Normally this will be restricted to the objects the PC can see or touch, but this is not always the case. If the action is conversational, e.g. ASK ACTOR ABOUT TOPIC, then any object (or topic) is potentially in scope. If the author has implemented a GO TO ROOM command to take the Player Character to anywhere on the map, then any (known) room will be in scope.

Spoiler: A piece of information (typically in a review) which reveals too much to someone who has yet to play the game, and so spoils the experience of playing it for the first time.

TADS: An acronym for Text Adventure Development System, one of the two major languages/systems in which amateur Interactive Fiction is currently written. TADS 2 is still in use, but the latest incarnation (in which “All Hope Abandon” was written) is TADS 3. TADS was written by and is maintained by Mike Roberts.

Virtual Machine (or VM): technically, a computing device implemented in software rather than as a piece of hardware (hence “virtual”); a piece of software that can execute byte code written for it, usually implemented as an interpreter for Interactive Fiction.

World Model: That part of a work of an IF that defines the behaviour of the story-world in which the action takes place (such as movement around the map, the containment hierarchy, and some basic physics); typically, much of a game’s world model is supplied by the library of the authoring system used.

Z-Machine: The Virtual Machine for which the Infocom games were written, and to which games written in Inform compile.

Hardware obsolescence: The original console or computing platform used to run the game may cease to be supported or even available in the aftermarket.

Software obsolescence: The original software needed to run the game — operating system, drivers, frameworks — may lose support, cease development, and become incapable of running on future hardware/software configurations.

Scarcity: Some video games are produced in limited quantities, and are subject to the dangers of media decay.[8]

3rd party software dependence: Once a game platform becomes obsolete, emulation may be the best method of providing access. Currently, however, most emulators are developed by the game community and are of questionable legality. They are also typically created without the benefit of the original specifications, and are themselves at risk of becoming obsolete.

Complex, proprietary code and an associated lack of documentation: Videogames are generally released as compiled binaries with no documentation of the compiling process, or even the programming languages used. Not having access to the source code or language specifications makes migrating or emulating software far more difficult. It’s a magnification of the format identification issue for stand-alone, static files.

Authenticity: The elephant in the digital preservation room — proving that a digital object is what it claims to be, free from tampering or corruption. Video games enjoy many versions between the first prototype, the official release (on multiple platforms), and cracked or otherwise altered unauthorized editions. Especially for older games, the only extant copy may exist in a fan-run web repository, making the authenticity impossible to establish.[9]

Intellectual property rights: The game development industry is highly creative and competitive, leading developers to be very jealous of their intellectual property. Most have instituted extremely draconian shrink-wrap licenses reflecting this. And yet, once a game is no longer actively marketable, they are unlikely to respond to inquiries about licensing for it.[10]

Significant properties: What are the significant properties of a game that must be maintained with each transformation/preservation action? How important are font size and color palette? What about the speed of text scrolling or sprite movement? How faithful must we stay to the original code? Is it enough to save a video of gameplay, or must we save the interactivity? Do we need BOTH? These are essential to define, as they play a major role in determining authenticity.[11]

Context: Although this isn’t an immediate threat to the preservation of games, building contextuality is important to creating understanding for future users. This is truer for video games than many other record types because, as technology advances, game players who have only been exposed to the latest and greatest may be apt to play an older game and say, “so what?” even though the game might have been revolutionary for its time.[12]

AEE: 
    1 <$letter#1 a $letter#2> == $letter#1 ē $letter#2      
                         

1. We represent textual variation with the <app> tag and indicate the sequence of the author’s corrections with the varseq attribute;
2. We contain the textual variation within the element <seg type="l">, representing the reconstruction of the verse unit;
3. We avoid the redundancy of empty elements by specifying which unit undergoes textual variation.