Programming Sync

Posted on May 8, 2011

Throughout Game Design as a Cultural Practice I have been confronted by new ideas and ways of thinking about games that have subsequently manifested themselves in my semester project: Sync. As a programmer I found that many initial design decisions fell on me while building the first prototypes and, later, while adding features and tools. In the following paragraphs I will discuss how programming and design intertwined during my hours working on Sync throughout the class’s iterative design process.

Early game prototyping is extremely fun. During the Sync team’s first meeting Ben introduced us to a game concept centered on a mimicry mechanic. It met the requirements for the class project, we were all excited about it, and Joe and I immediately set to work building prototypes to demonstrate potential movement paradigms. These first prototypes were set before our team members and, based on their feedback, I jumped into Flixel (our engine of choice) and continued constructing the prototype. At this stage I made several design decisions (fully expecting them to be overwritten later) encompassing colors, screen layout, level design, and player controls. The aesthetic qualities that resulted can appropriately be called “programmer art.” Fortunately, as Eric Zimmerman notes, “initial prototypes are usually quite ugly… they emphasize the game rules.” (Zimmerman) Indeed, early Sync prototypes opened right up to the game screen and presented the tester with a set of yellow squares moving in a circle: that is all that it took to model our core mechanic and springboard the game through an iterative design process.

“Aesthetics,” as I have perhaps improperly referred to them, do play a significant role in the design of a game. It was very obvious that there were no perceived affordances in these first prototypes: interacting with the game relied first on cultural conventions (the correspondence of arrow keys with two-dimensional movement in a flash game, their conventional but not inherent usage) and my instruction. (Norman) Furthermore, the unit art did not lend itself to the primary game mechanics of mimicry and discernment: the impostor was unable to take particular control over one of the units (“Which one am I?”) and the judge was unable to follow through on perceived irregularities in unit movement. The need for distinguishable units was established in these early prototypes and followed several iterations as development continued: yellow squares became colored, colored squares were re-colored to be more easily distinguishable, and finally the squares were replaced with Cameron’s art assets. The result is a much better solution to a requirement established very early on in the process but which also lent itself to other developments along the way. As in Zimmerman’s LOOP, the early implementation of our core mechanic inspired many questions that led to later developments. (Zimmerman)

One of the most significant additions to the game as a result of our play testing was a space for the impostor player to practice moving a unit in the pattern presented and with the appropriate physics. Our basic mechanic was technically sound but the game play was broken: impostors would give themselves away almost immediately, almost every time. In this case, in addition to the need for a practice arena, we did not provide enough affordances to indicate to the impostor that they were taking control of a unit at a certain point in time. As Norman points out, a computer mouse “affords pointing, touching, looking, and clicking on every pixel of the display screen.” Similarly, we chose to utilize the arrow keys’ inherent affordance of being pressed in both responsive and unresponsive ways: making the player aware of when the keys became responsive was critical. Our design allows for the player to “get into sync” with their chosen unit by pressing the buttons as if they are controlling the unit when they are not. This enables a rhythm of sorts to be established before the first player is exposed to the judgment of the second.

To this point I have said little about programming except that my placeholder art was very poor. To switch gears I would like to return to Norman’s perceived affordances and cultural conventions. Although the game has always been about a player mimicking a trivial artificial intelligence, the cultural norms behind the standard controls for a two dimensional Flash game are strongly reflected in Sync’s architecture. The units’ motion is based on four Boolean (true / false) parameters that, for the player, are controlled by the arrow keys. For the AI, these parameters are controlled by rules that, originally, were hard-coded into the game. The iterative design process introduced different ideas for behaviors that we wanted to implement and the notion of a “level” (yet another cultural convention) persisted. The game’s architecture was modified to allow levels to be built with rules in an XML file that ultimately describe which button presses the AI units are simulating. The game’s description implies to the player that he or she should be able to reproduce the movement of the AI units on screen: the actual movement of the units in two dimensional space suggests to the player the button presses required to mimic their behavior. In this sense, the programming behind the artificially controlled units creates a perceived affordance of interactivity to the player.

I really enjoyed programming Sync and I learned a lot from Celia’s lectures, the readings, and especially the chance to design, build, play test, and release this game. I believe our final design and architecture are conceptually solid and I look forward to refining the details of Sync to create an experience that brings people together and leads to even more new ideas of what a video game can be.

Norman, D.A. (2004). “Affordances and design.” http://www.jnd.org/dn.mss/affordances_and.html

Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm