No practice in creating game environments has proven as informative to me in design-work as play testing. Even if it’s an author’s first map ever, one that has never actually been tested, there’s a good chance the ideas going into it are based off past experiences in a particular game. What kind of level have players generally disapproved of, and what kind of flow of navigation felt intuitive or “right”? Perhaps there was some sort of imbalance rooted to the structure of the environment, and regardless of when a map takes form it’s important to recognize what recreated a certain situation, successful or not, and what that might mean later if reestablished in a new map. Are new ones required to innovate a design, and if so how long might that take to construct and resolve via technical skills? Levels take a lot of time to develop. Good-levels take a lot of time to let others actually try them out.
I was asked the other week whether my thesis project was more relevant to technical skills or the user experience, to which I replied, “The user experience.” Ultimately, this is what is relevant to the player – yet it only comes as readily as our knowledge of the tools to create a space for that relevance. Surely I’ve learned over four years what it means to appreciate the craft of something, especially in digital media. Things either work or don’t work, and suddenly the only willingness that tends to matter is the kind that seeks and applies information. When a level is being constructed, behaviors within that environment begin to exist as well. These behaviors are another kind of information, another source of data to be mindful of as iterations surface. Ultimately, I’ve made Arc Mountain for others to play and if no one ends up wanting to play it then I’d like to know why. The least an author can do is sit some people down, peers most likely, establish a LAN (Local Area Network) or a remote server with the map available, and recognize what they appreciate and/or what they could do without.