Stumbled on a disassembly of the Pac-Man program, with some comments.
Is this what Pac-Man really looks like? What Pac-Man really is? Please discuss.
This is probably the most accessible part of the code:
;; SCORING TABLE 2b17 0100 ; dot 2b19 0500 ; pellet 2b1b 2000 ; ghost 1 2b1d 4000 ; ghost 2 2b1f 8000 ; ghost 3 2b21 6001 ; ghost 4 2b23 1000 ; fruit 2b25 3000 ; fruit 2b27 5000 ; fruit 2b29 7000 ; fruit 2b2b 0001 ; fruit 2b2d 0002 ; fruit 2b2f 0003 ; fruit 2b31 0005 ; fruit
I think this is a great way to frame the question! I submit that the signifier “Pac-Man” actually refers to the practice of performance that occurs in relation to the code, and that the code makes up an (essential) part of that practice–a necessary, but not a sufficient, condition for the occurrence of “Pac-Man.”
Good question, which leads to wonder “what is a game”.
Obviously, any good definition of what is a game (including Jesper’s one in Half-Real) will specify that a game can be viewed from different point of view, such as the actual designed object or the player experience.
Maybe the simplest model we can refer to is the MDA model, which propose three point of views : “Mechanics”, the game as a designed object (i.e. the source code), “Dynamics”, the interaction of a player with the object (what Roger Travis is refering to), and “Aesthetics”, the inner emotions one will feel when playing the game.
To answer the question, the source code is *only* the designed object called “Pac-man”.
Maybe many people will say “the source code is Pacman”, obviously because it’s the only “tangible” part, and maybe the only objective one.
I also bet that loads of game designer tend to consider that the game IS its source code ;)
But without a player, a game is somewhat incomplete, as it is designed to be interactive :).
By the way, speaking of source code, you may enjoy Ben Fry’s graphical interpretation of source code from famous Atari 2600 games :
http://benfry.com/distellamap/
And the “distellamap” created after Pacman source code :
http://benfry.com/distellamap/150dpi/pacman-illus-150dpi.png
3286 32c050 ld (#50c0),a ; Kick the dog
Nick Montfort and I discuss the Pac-Man arcade board and the memory structure of the game a bit in the chapter on Pac-Man in our forthcoming book on the Atari VCS. When understood in terms of the hardware design and the software that accesses it.
http://www.bogost.com/books/video_computer_system.shtml
Ben Fry’s visualizations of assembly game instructions are pretty, and they shed some light on the branching complexity of the code, but they don’t tell us anything meaningful about the relationship between game, code, and hardware. That’s part of what Nick and I are trying to do in the book and with the platform studies series in general.
This is a good example of what I call the game-object as opposed to the game-process. Yet even the game-object can be separated into two: the code, as you pasted here, and then the rules of the game. I’m not entirely convinced that we can say “the rules of the game are in the source code” (I’m not saying anyone does, just thinking out loud), if only for the fact that the code appears to be nontelic. The code says that objects are worth points, that when a joystick is held in a position Pac-Man moves at a certain pace, that when he collides with one of the four moving objects an animated sequence and sound is being played and the board is reloaded. Yet when we talk about the rules of Pac-Man we say that “the goal is to achieve a high score”, or that “you must navigate the maze” (without specifying the speed at which Pac-Man moves, or how collision detection is implemented), etc.
I am willing to say that the game’s rules, goal and general gameplay might be inferred from an extensive study of the source code (after all, there is a specification for what happens when all 2b17 and 2b19 objects have disappeared from the board, and I presume a succession or algorithmic progression of advancing in boards, that would suggest that the goal is indeed to progress; the same with score attribution that implies reaching a high score is desirable, etc.), however I would say that the game’s rules are not simply found in the game’s code, but that they are encrypted in it. It requires a substantial effort to trace the code back to general gameplay rules. The ultimate test would be to post source code and see if people can infer the rules from it.
For an enlightening view on this question, and perhaps hints at some answers, please read “Multiple Views of the World” in Gregory Bateson’s “Mind and Nature,”. Here is a snippet from part 9, “The Case of ‘Description’, ‘Tautology’ and ‘Explanation'”:
QUOTE
A pure description would include all the facts (i.e., all the effective differences) immanent in the phenomena to be described but would indicate no kind of connection among these phenomena that might make them more understandable. For example, a film with sound and perhaps recordings of smell and other sense data might constitute a complete or sufficient description of what happened in front of a battery of cameras at a certain time. But that film will do little to connect the events shown on the screen one with another and will not by itself furnish any explanation. On the other hand, an explanation can be total without being descriptive. “God made everything there is” is totally explanatory, but does not tell you about any of the things or their relations.
UNQUOTE
Bateson’s point is that, only when multiple views of the world are combined (especially into a tautology such as source code + a runtime session) do we get a more than theoretical ‘picture’ or ‘idea’ of the phenomenon in question. The game is not any one game session, neither is it the source code, but those two things combined give us an authentic kind of ‘hologram’ of what Pac Man is.
Brennan, I think that is a nice way of seeing it. Wasn’t Xavier talking about “putting yourself between two descriptions”?
We could also use the term emergence to describe some of these things – the program itself consists of individual instructions that only become Pac-Man when combined; the strategies are emergent; Pac-Man is only played the way it is because humans are not smarter than we are, and so on…
I think that you’ve asked an interesting question Jesper. I’d like to add that the “research object” is especially interesting since Pac-man shows us that video games are different from games in the complexity of the construction of the manifestation of the game. Pac-man was effectively design but the implementation does not match the design (the game breaks at level 256) on several aspects like what is the winning condition, maximum points, safe zones, patterns of the ghosts etc.
What I want to say is that a video game is more than the designed outcome – it is dependent on the implementation, hardware, play testing, players and interaction. It’s almost like it has a life of its own ;-)
And by the way… if there is so much space left (3e5c-3ff9 nop), why didn’t they check for the crash on level 256 or add some other fruits? Strange spaceships do get boring to munch… at least after a while.
The source code is specific to the hardware, or to the emulation software interpreting the code. For this reason, the code is no more tangibly “the game” than the hardware or software is that makes the code runnable. To a greater degree, the programming language’s semantics (this particular variety of assembly) and its relationship to how computer science evolved to manipulate memory to create particular forms of on-screen actions and input reactions are no less what makes the game exist than its source.
But an important point that I haven’t seen made above is that, if the game’s behavior is implemented identically in another programming language – C++ with SDL, C# with Managed DirectX, ActionScript 3, etc. – isn’t it still very much the exact same game as far as we’re concerned as players, critics, or theorists?
If the code is modified to include extra operations that have no effect on the behavior or produced result – say, creating and manipulating variables that aren’t tied to input or graphics – isn’t it the same game?
As soon as we study the game as it relates to the player, the burden is on us to entertain possible differences in the player’s cultural background, values/expectations, familiarity with conventions, etc. To look at its programming implementation (or hardware specifics) seems to be an invitation to complexity from the other extreme, making the questions more about the game’s design genesis and history than the game-in-itself.
The point of argument in this area that I can see as being fuzzy is whether the game is the same “game” when its input mechanism changes, since, for example, a computer mouse behaves much differently than a trackball or Atari paddle. But provided the same type of input device is utilized to produce the same types of interactions with the same events ultimately displayed on screen, it’s not clear to me what there is to gain (besides empathy for development teams) whether what’s making it all work is the original arcade assembly, or an exact port in Java or BASIC, or fairies and wizards. :)
Chris,
Good point about how the execution environment is also part of “the game”, with the footnote that the execution environment mostly not specific to a game.
As for the other point that a specific behavior can be implemented in many different ways, I think you are touching on an unresolved issue in video game theory: It is a common argument that games on a fundamental level consist of their rules, but we don’t seem to be able to figure out where to locate those rules:
1) If we want to argue that the rules of Pac-Man are the high-level behaviors of Pac-Man, the ghosts etc…, then we will find it hard to agree on any specific description of what those rules are. (It’s the same problem as when programming by spec – there is a subjective translation from the spec to the code.)
2) But if we say that the rules are equivalent with the game code, then we get the problem that different pieces of code may result in the same run-time behavior.
Jesper,
Thanks for taking the time to reply! I only realized shortly after posting the comment that it was a 15-month-old entry. Surely the discussion question is no less relevant, and not much more answered from the time between. Though I certainly would have understood if it was no longer what you were interested in thinking about so long later (!).
Having read an Ian Bogost article that led me to this entry has got me oddly wrapped up in this discussion point. In the interest of having a better way to format or fix wording after posting, I have prepared a reply at length regarding this unresolved issue that you have raised in your reply:
http://cdgdl.com/lessons/game-rules.html
Videogames in particular are my field of study, or more explicitly, interactive digital systems (without particular connotation toward entertainment, games, or play), and I’d be very curious if any of the points I’ve pulled together resonate or relate to knowledge from your vantage point as an expert on the end of videogames as games. Likewise, if any of the points seem entirely off-mark from your perspective, I’d be curious to know which thoughts I may be formulating incompletely or communicating weakly.
(Whether or not you have the time to provide feedback though, thanks for excellent the seed question!)
Chris,
Thanks for a detailed position statement!
Let me focus on the game/video game relation and the question of their rules.
Your rules argument makes sense, but I guess I disagree on the premise: Fundamentally, I think that rules (in non-digital games) do more than limit what you can do: the rule of mate in chess is not a limitation, but an affordance. Without the mate rule, you would not have the option of creating a mate. The same thing goes for scoring goals in soccer, getting your achievement recorded in a high jump, etc… These are not limitations, but set up situations where you can do something that you could not do without the rules.
From that perspective, video games are not that different from games. Consider the movement of the chess bishop or the gravity that tucks at a tennis ball. These are pretty comparable regardless of whether you are playing the analog or digital versions of these games. The main difference is who or what handles the movement. In analog chess it is a human, in analog tennis it is gravity. In digital chess and digital tennis, this is done by the computer.
I understand your argument, but it all depends on how you define rules. I argued more extensively for my take on rules here: http://www.jesperjuul.net/text/gameplayerworld/
-Jesper
PS. You may be interested to know that there exists another argument about video games themselves not having rules. Some theorists focusing on the activities of players argue that only players can create rules.
Check the English summary at the end of of Anne Mette Thorhauge’s PhD, she makes the following argument:
“Whereas the programmed system does have rules they should not be confused with the game-rules. The game- rules are conventions of action and communication defined and upheld by the player(s) in the act of playing and the game as a formal system appears as a consequence of this activity.”
http://ncom.nordicom.gu.se/ncom/fbspretrieve/13272/AfhandlingAnneMetteThorhauge2007.pdf