Coming into this class I was expecting to work with a bunch of designers to come up with some cool game ideas. I was looking forward to the class, but overall I was worried that my voice would be lost in a crowd. Instead what I got was the opportunity to work with one the best project teams I have ever had.
When we first started brain storming session I had the personal goal of all my proposed ideas being ones that Activision would never produce. Some of the early ideas included a stacking game where you stacked large every day objects (cars, houses, trees, etc.), and who doesn’t like stacking stuff. Another idea involved a ricochet mechanic where the player would have to bounce objects off of themselves and the environment. This idea stayed on the table for quite a while actually, becoming mixed with two of our other platformer ideas. The game eventually transformed into a blob game where the player would be able to stick to the sides and various objects too navigate the world. While all of these ideas had merit we eventually went with our programmer’s idea of interfaced. We all wanted to use this project as an excuse to make the craziest idea we could come up with, without the worry of sales figures and market appeal. It reminds me of a quote from Zimmerman when he says, “While every game embodies some kind of conflict, we were drawn towards modeling a conflict that we hadn’t seen depicted previously in a game,” [1]. From there we went on to designing constraints. From the start I was adamant that the player should not be able to drag the elements. I felt that this could potentially lead to lazy level design where you’re just moving pieces to plug gaps or uncovering elements. Ironically I soon went from saying, “why the hell do you want to move these things”, to, “how the hell are we going to make these levels without being able to move these things”. While I’m still getting a bit lampooned by my team for this reversed position, but in the end I think it was the right decision. Still if we allowed players to move the elements unrestricted or we would have no semblance of puzzles. In the end we decided to constrict the movement of each element individually. To make the inventory useful we had to give it unrestricted movement, but to keep it from breaking the game we made it so that you couldn’t move it when the player is inside. We also made it so the stamina bar could only move left to right so player couldn’t just raise themselves higher. Finally, to balance with the stamina bar we made it so you could move the mini map up and down. Unfortunately this too caused more trouble than it was worth and we ended up fixing it in place.
A game about breaking conventions can be difficult simply because players will expect for conventions to be in place. Sure we have a game where you can jump into the inventory, but how is the player going to know you can do that when all they’ve ever done with an inventory is put loot in it. This presents the unique challenge to the designer of telling players what they can do without breaking the flow of the game. Personally, I hate tutorials were every feature of the game is laid out in front of the player. This robes the player of the satisfaction that comes with discovering the game mechanics for themselves. In my mind I had a grandiose plan for developing amazing levels that cleverly and subtly drove players to use the mechanics that they never new existed. There was just one problem with that clearly ingenious plan...it was really really hard. Near the end of development we realized we needed a simple solution for this problem. To that end we turned to Norman who recommends that you use, “Use words to describe the desired action (e.g., "click here" or use labels in front of perceived objects).” [1]. That’s right with just a few words integrated into the level via sign posts we were able to point players to the mechanics without spelling them out. For example, the first level includes a sign that instructs the player to “run around”. The player now knows the input, but they have to figure out what to do with it. Upon observation the player will notice the stamina bar falling and KABAM, knowledge has been learned.
My main job as development went on was level design. I tried to focus on creating a logical progression, both in terms of difficulty and introducing the elements. For some time I was worried about the difficulty combined with the very unconventional concept leading to frustration. Eventually I decided that as long as the puzzles could be solved by my teammates that the difficult levels would be better than easy levels. As Lazzaro puts it, “a 100% success rate eliminates most of the aspects that make a game fun” [3]. To develop my levels I first drew them all on pieces of graph paper. I then marked out the solutions with dotted lines. This allowed me to develop and refine the levels even before our XML system was in place to build them. I honestly think that our biggest success in this project was the XML interpreter. Not only was I able to easily build and edit levels with out playing with the code, I was able to do so independently of the coders. In other words I was able to build the levels concurrently with the programmers without having to worry about having to heavily edit my syntax. This saved us a lot of time and is the main reason we have so many levels. I would highly recommend that any future class student rely on this system as it allows very rapid level development.
Oh and by the way. Tech just became the ACC champions!!!!! Clemson still can’t stop the perfect option!!! Go Jackets!!!
[1]
Zimmerman, E. (2003). "Play as research: The iterative design process."http://www.ericzimmerman.com/texts/Iterative_Design.htm
[2]
Norman, D.A. (2004). "Affordances and design." http://www.jnd.org/dn.mss/affordances_and.html
[3]
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
Comments