Archives

SPECIFICATION DOCUMENT: IVANHOE NOTES

Game Notes | Technical Notes | Timeline Projection Notes | Glossary | Return to Main Documents Page

GAME NOTES - 5.29.2001

General Game Outline

The Ivanhoe "Game" is a critical exercise engaged in by multiple individuals (not teams) within the discursive space of a single integral text/media unit. This text source might be a novel or poem or other literary (or visual/aural) work. The game is played

[in turns?] as a series of critical moves. Moves take the form of lexias of indeterminant length, and are added to/inserted into the text source at a juncture or junctures (see move multiplicity) chosen by the player. The move-lexia itself may in turn contain embedded hypertext links to other points in the text source or to other move-lexias (made by any player). Players make moves under the aegis of a role, or mask, of the players' choosing -- a role might be a character from the novel but may also come from other sources, and a player can construct an indeterminate number

[true?] of roles. Any and all texts relating to the text source are in play for the purposes of the game, including extratextual(letters), paratextual(notes, indices), and metatextual (introduction) sources.

The goal of any single move in the Ivanhoe "Game"

[this, of course, deserves more/better explication than I give it] is to allude to or circumscribe a number of other moves or portions of the text source, either through embedded links to those texts or as a result of the meaning of the content of the move-lexia itself. However, whether played competitively for points (allotted by computer algorithm or the more subjective calculation of the players themselves), or played in a less competitive spirit, Ivanhoe always has as its primary goal the exercise of the imagination and the improvement of the analytical and critical thinking abilities of the players.

Defining and Rendering the Text Source

[Two primary issues regarding the rendering of the text source are as yet unresolved, though Jerry has expressed his general inclinations to me regarding these issues.

First, defining what constitutes the text source.

Question one: Are groups of texts candidates for game play? For example, could one play within the space of all of Herbert Spenser's poetry? Jerry's answer for now seems to be, "probably not". If this were possible, it would affect the system infrastructure quite dramatically, as we would have to develop means of relating the texts structurally on the back end and also means of showing relationships between them in the interface. In other words, it would complicate things. Confining text source candidates to single integral narrative units would simplify things.

Question two: Do paratextual/metatextual materials by the author count as a part of the text source proper? Today Jerry was inclined toward "yes". So an introduction and notes by the author do not reside in the notes space, where, for example, move-lexias contributing new notes from sources other than the author would go. Also, insertions into the author's own notes and introductory material would count as additions to the original text source, rather than taking place in the meta/paratextual space. Does this make sense to everyone?

Second set of issues: rendering the text. How will new moves affect the appearrance of the text source? Jerry has said that he believes moves could be displayed inline with the text source, provided there is some means of setting it off from the original (variant typeface, use of color, etc.). Other possibilities: there could simply be an embedded link to a move at the appropriate juncture in the text source, or we could leave out any indication of the existence of moves relating to the passage. Other ideas?]

Player Files

In a player file, a player documents her critical strategies for a particular move. A single player-file entry corresponds to a single move-lexia, and a player creates a player file during the same session in which she creates a move. If a gamesmaster were employed in the game - a designee whose responsibility it might be to assign points for "high-level" merits (i.e. merits determined by non-machine, or non-algorithmic criteria) - then the player file could be taken into account in determining how many points to mete out for a particular move. The player file should be viewable only by the player who authored it and the gamesmaster. The other players are not allowed to see the player file of the authoring player until the game has concluded.

Roles

A role is a fictional identity assumed by a player for the purposes of a particular move. A role might be a character from the text source or a "character" outside of the text source. For example, a player could assume the role of an editor of a critical edition of the text-source published fifty years after the author's death.

[Questions about roles:

Can a player assume more than one role within the space of a single move?

Is the default role the narrator? In other words, if a player makes a move without specifying a role, a move which inserts data into the text source, is it assumed that the voice is that of the narrator? Must a move always be made through a role? Can we imagine a situation in which this would not be desirable?]

In the first two rounds of the Ivanhoe Game, played simply with a weblog engine, players exchanged roles for points or even gave roles away, and players invested points in roles in order to instantiate them. If possible, this function should also be integrated into the game.

Indices

The indices would facilitate navigation through the text source, creating a map of hypertext links to various points in the narrative. These links would need to be facilitated by mark-up embedded in the text-source before gameplay.

Chapters: Chapter units would provide a standard means of navigating through large chunks of the text-source.
Characters: Character links could provide quick access to those points in the narrative in which a particular character speaks, appears, or is referred to by other characters. Providing this level of detailed mark-up may prove an arduous task.
Events: Event links could provide an index of the major plot points in a particular narrative.
Move-Lexias: Links to move-lexias would allow players to jump to points in the text-source in which new material is added. Such lists of links could be filtered by player, by chapter, by role, etc.
Places: Place links could provide an index to the different locations in the narrative, marking changes of scene.

[Please let me know if my general assumptions about the purpose of the above 'indices' is correct.]

Discourse Field

The discourse field for a particular round of the Ivanhoe Game is determined before the game begins. Generally speaking, the discourse field for the round will be a particular edition of the text source, including all heading and trailing material composed by the author. From then on the following discursive spaces are legal for making new moves:

Text Source

The chosen edition for the round and all materials therein composed by the author

Metatext

Example: An introduction not composed by the author

Paratext

Examples: notes, bibliography, appendices, indices

Extratext

Examples: letters, diaries

Game Play Diagram

REFERENCED IMAGES: gamePlay_5-29-01.gif

The game play diagram will be a visual representation of game play. Certain details of the way moves will be represented must be worked out, but generally the diagram will display moves across two vectors: real time and the progression of the text source. Another goal is that the game play diagram be able to represent all of the discourse fields available to a player. An initial mock up of the game play diagram can be found here.

[One potential problem with the current game play diagram is that as the game goes on and moves accumulate, it may become unintelligible to those who would make use of it. Compromises will have to be made and questions about our target audience answered. What kind of resolution do we want to support? 640x480? 800x600?

Additional thoughts I had when I looked at this diagram: Do we want to necessarily divide up the game play diagram space with chapters? Do we want to provide for alternate units? Plus, if the game is played in turns, then we should probably represent the real time vector in turns, yes? Also, creating and rendering this diagram on the fly in a reasonable amount of time may become a real problem. We should be ready to make compromises if difficulties arise.]

The arrows on the diagram indicate the "placement" of a move either in the text source or within another move. A given move can only represent an insertion or addition. Moves cannot erase, reorder, or otherwise reconfigure the text, except to the extent that new text can achieve reconfiguration

[correct?].

[Also, do we want to represent the other linked aspect of move-lexias, i.e. embedded links that point to other places in the text?]

Game Log

The game log will comprise a text-based record of game play. This record might contain some or all of the following: time stamp, player, role, part of the discourse-field, chapter. The log may be rendered as a straightforward text document or with links to the stand-alone moves or to moves embedded in the text source.

[QUESTIONS: Is the atomic unit of a log entry a MOVE or a MOVE-LEXIA? In other words, if multiple insertions are allowed in a single move, do we log each insertion separately or as a portion of a MOVE?

Also, do we place links in the log? Where should they go?

Full Game Log: The "Full Game" log is equivalent to the log mentioned above. It would provide a record of all moves made by all players.
Player Log: A "Player" log might simply offer a text view of an individual player's moves, or it might simply comprise one "filter" or "view" of the game log, in which the moves of a single player are viewable.

Rules Engine/Points

Ideas about the assignment of points vary within the group. In the weblog rounds of game play, point assignment was reasonably simple. The points merited by a particular move were more or less determined by the player making the move, with some input from the community at large. If a dispute arose as to the points a player assigned herself for a move, democracatic discussion generally resolved it.

In the new version of Ivanhoe, the way points are assigned will be a delicate issue. On the one hand, some of us feel that the democratic method should be retained. A community process for assigning points and resolving disputes worked well for the players in the past. However, even if the community process is retained, we must determine a process for invoking it. Do all players vote on the number of points merited by a move? Is this done in every case, or only in those cases in which there is a disupte? Is a player initially responsible for determining her own points for a move, or is scoring done as in the olympics, where the other players act as judges, the high and low scores are discarded, and the remaining scores are averaged?

Another possibility for the Ivanhoe infrastructure is to appoint a "gamesmaster". The gamesmaster would be a human participant in the game, one who does not play but nevertheless has an important role. The gamesmaster would be charged with assigning points for a particular move. One advantage of employing a gamesmaster is efficiency. Having one designee calculate points would likely be faster than a voting process. Another advantage would be that the gamesmaster could take the player file into account when determining points. Since theoretically the player file would be hidden from the other players in the game, it would not be possible for them to take the player file into account when scoring.

Yet another issue to be resolved on the scoring front is the decision whether or not to use a "rules engine". A rules engine could assign points on the basis of simple criteria, such as the word count for a particular move, the number of links to a particular move, etc. If such an engine were employed, the question of how to count these programatically generated points arises. Do community/gamesmaster assigned points fall into a whole different category as rules-engine assigned points? Do they have the same value?

Finally, once the decisions are made regarding how to assign and value points, we must also decide what configurations of these criteria will be available. Can a group play the game without points altogether? Can a particular game be played with just a gamesmaster, just a rules engine, or just voting?

Living Theatre

Jerry and Johanna have envisioned the Living Theatre as a real-time MOOSpace in which valid game-moves could be made. Because it has been agreed that the first iteration of Ivanhoe should be web-based, and because such a MOOSpace would be a real-time feature with tight integration into game play, everyone has agreed to table development of the Living Theatre. At some point in the future it may be desirable to integrate the Living Theatre into Ivanhoe as an applet, or possibly to provide the Living Theatre as a part of a version of Ivanhoe written as a stand-alone application.

Café

The Café would be a real-time chat client in which players could discuss game play. This feature has similar benefits and problems to the Living Theatre, and so it also has been tabled for the time being.

Multimedia

The first iteration of the Ivanhoe Game will deal entirely with text. The engine will be geared towards management and presentation of textual discursive spaces. Future iterations, however, may be played with aural or visual materials.

TECHNICAL NOTES - 5.29.2001

Proposed Use of Software

JDK?
MySQL?
Postgres?
XT?
Xalan?
Cocoon?

Proposed Use of Standards

XML
XSLT
HTTP
HTML
Cocoa?

Clients Supported

Hardware Required
Software Required

TIMELINE PROJECTION NOTES - 5.29.2001

At this juncture, priorities are beginning to emerge...

One: The living theatre should be bracketed for later implementation because of the implications it could have for the complexity of system design. The living theatre would be a realtime MOO-space in which valid game moves could take place.

Two: The initial implementation will be text-only. Multimedia integration will take place in a later project phase.

Three: The initial structure (mark-up) of the text-source should be very simple, perhaps implementing simple chapter units.

Four: Primary functionality consists of enabling moves(reference links, placement links), facilitating player sessions, role creation, storage and rendering of text source, game logging, and the game play diagram.

GLOSSARY - 5.29.2001