Regardless of medium, and beyond the variables presented by production environment, there is one thing that makes a master designer capable of producing masterpieces in said field. Articulation.
In producing our game we had a concept that was very difficult to approach and I believe we did such in an academic fashion that charted a new behavior for everyone involved. That difficult concept was how to maintain articulation within a game environment. While many games may have had more embellished art or more intricate collections of game content, we had the most daunting logical challenge of all to tackle, and it could have been as contorted and out of control as our plant device itself.
The needed articulation calls for a very unique design process. The product needed to be designed for use but also needed to be designed for development. My answer was to approach the game with a design methodology similar to play methodology. Arguing against the process that Nicole Lazzaro and Kevin Keeker propose, I believe that testing processes should be ubiquitous and that poor receptions should kill a process in favor of industrial Darwinism. Separation of designer and developer shields one element from criticism while every element in the process should always be exposed to proper evaluation.
T.L. Taylor describes the organizational effects behind software development and how they impact product. With this I completely agree. However, I find that he is incorrect when he references only technically complicated games. Even simple projects can be elevated through an intuitive trigger system. In doing so, the rhetorical options given to my designers expanded game options in ways that are barely understand on the surface, but become clear and unavoidable upon deeper analysis. Where Taylor would refer to painting a canoe in the water, I wanted to approach the problem differently and find a way to make a pontoon boat. By having choices available such as spawn, approach, state change, remove controller, and add controller, there are some impossible choices that are now available to the designer.
Our game is broken up into four main parts. These parts followed design conventions, but they did so in a very unique way. As developer, I attempted to create a game environment that would have cornerstones from our conceptual design readings as they applied to the designers that contributed to it. This was done by basing having a system of xml files that represent everything from maps to collision boxes. The xml files would load in a bottom first hierarchy, allowing designers to make general specific choices. The primary parts that are represented in the build files are as follows :
Artifacts, these are what normally are regarded as sprites or tiles. They had three different categories, they were the Artifact, the Sprite, and the Doodad. The point behind this part is to be mostly representational. It is primarily based on Norman’s first rule of design convention, association between convention and artifact. Artifacts were usually given not only assets, but also default behaviors (Artifacts were special in that they had no asset but had behavior). The choices with these elements were meant to be as intuitive as possible and this was the entry point for creating a world recognizable object.
Controllers are behaviors, they are meant for Artifacts. They become the life of the elements, giving them complicated behavior and establishing relationship hierarchies. They were the parts that could be encapsulated and extended. The intention behind these was to create scalable actions that could intuitively be applied to their targets. For example, the grow action was the combination of approach light behavior, spawn bud, and spawn leaf behavior. They were deceptively simple and very particular in effectiveness. Their existence was based on Norman’s second rule, logical use of action. In reality, Norman’s rule is meant for effective communication between gamer and developer. In our case, this environment was intended to bridge designer and game environment.
Maps, these are the environment. A map on its own would be completely empty; however, it is an architecture that arranges artifacts into a logical manner. The fabled “environment” (that is so important to the game designers) does not actually exist. Instead, it is entirely conceptual. The designer was capable of making multiple maps within a single game that could overlap, they were not the same as levels or zones, instead they were abstract collections, the designer’s involvement with this part of the engine was based upon metaphorical development. Maps could be ceiling sections as they separated from floor sections. They could be growth sprouts layered onto caverns.
Actions are affects produced by the Maps, they move artifacts from one space to another, they assign controllers, and they bring elements in and push them out. These became the most unique part of our engine and easily the most useful. They require a bit of learning but after some consideration, they become a powerful tool. Following the coherent conceptual model that Norman discusses in point number four of his short on Affordances and Design, I crafted a method for applying abstract actions to abstract organizations of Artifacts. This tool allowed for the most articulate choices but required the most amount of understanding.
Taylor, T.L. (2003). "Intentional Bodies: Virtual Environments and the Designers Who Shape Them." ion 19, no. 1.
Lazarro, N. & Keeker, K. (2004). "What's My Method? A Game Show on Games." In CHI 2004 Conference Proceedings, April 2004. http://www.xeodesign.com/whatsmymethod.pdf
Norman, D.A. (2004). "Affordances and design." http://www.jnd.org/dn.mss/affordances_and.html
Comments