Sunday, July 17, 2011

The Door Contest: "Gravity"

Mapcore hosted a contest from April 29th to May 22nd 2011 where the goal was for the designer to build an interesting puzzle for a player to solve to open a door (Mapcore's Door Challenge Voting). This was the first contest I entered ever. I thought I would share the results and the process I went through building this level.

I was notified of the competition by a co-worker at Raven. He showed me the demo video for the contest (this was not an entry):


As you can see, the idea was to find an interesting and unique puzzle to open the door.

Prototype: I instantly thought a gravity puzzle would be a fun way to challenge a player to complete the level. I began work with UDK because this challenge was primarily a scripting challenge and scripting in UDK is easy.

I spent the majority of the project building a puzzle based off a 3x3x3 room cube, thinking I would model the level after a Rubix cube. The player would have to retrieve an object (powercores) to place into switches that would open the door. I created the puzzle on paper, which placed the door the player would want to enter in the middle of the cube and the gravity path would lead around the center, and began prototyping the puzzle.

I thought of two ways to create and change gravity in the cube, the first was to rotate the level around the player whenever they triggered a gravity change. I did not attempt this because it would require significant alterations in matinee to assets to simulate the rotations, every gravity endstate would have to be able to rotate five different rotations. It would also have to be quick to not allow the player time to take a different path then the intended solution and to allow the gravity switch to come to conclusion before the next switch was hit.

The second was to teleport the player from one instance of the cube to another: from the down cube to the right cube. This would require six separate cube orientations that appeared exactly the same to the player and the gravity switches to be mapped to between the six orientations. This seemed much simpler in thought than in practice.

I also made the environment decision that all inner walls of the cube would be glass except for the center room and the outer walls, which would be a stone of some type. I did this so the player could see two, three moves ahead to formulate a plan to get to the triggers and powercores. 

I created the story along with prototyping the gravity mechanic of a old model robot that was charged with processing himself to "die with honor" so his "recycled children can hear of his... wit". The robot overlord would comment on the player's progress with insults in-line with Portal's Glados. The mission would end with the player entering the goal and dyeing. 

Building: I began to build the level and should have noticed the difficulty it took me to map between the six orientations would be even more difficult for the player to play through. I also ignored the axiom that if a level timeline is x amount of time, the completed prototype should be done by x/3 and testable. While the teleporting gravity worked after day one, the completed level was not completed until one week before the deadline. As for the ending, the player had to jump into a box that would crush the player and end the level.

That Monday I had two people play test the level and found it unplayable: one person solved it by random gravity jumping and the other gave up before they did. It was too complicated, it was disorientating and too long. Players did not orient themselves after a jump and did not plan their next jump like I expected them too and the design failed because of it. One of the playtesters suggested a much simpler design, maybe a 2x2x2 cube where the walls in each direction was a different color to help the player orient themselves after a jump: down was red, right is green.

I began working on a simpler design with three day timeline where I still had to work an eight hour day and leave early on the third day (I had my girlfriend's graduation that weekend and I was flying to Boston for it). The level was much simpler: it consisted of three playable rooms where the player had to manipulate gravity and an additional goal room. Every wall consisted of a different color and textured material.  Otherwise, the basic process for manipulating gravity was the same and the goal was the same: retrieve powercores and place them in switches to open the door. I added one other wrinkle, the powercores were in chargers that the player had to flip the gravity to get the cores out of their boxes. I recorded voices for the dialog also, which was a British robot sounding voice.

***SPOILER*** Instead of crushing the player, I decided it was more appropriate for the player to fall down a long shaft to their death. It fit more with the theme of gravity the puzzle used.

I had a prototype working for the level half-way through the second day, all the detail in by the morning of the third day. I was not able to have anyone play test the level. I submitted the level and handed the level to my friend to record a video for the contest (the reason some textures and voices are missing in the video).





Results: The result was getting three votes (did not vote for myself) and being in a three-way tie for 5th out of 17 competitors.

The voters enjoyed the intuitiveness of the puzzle along with the twist and challenge at the end where the player had to switch gravity to exit the level. They also enjoyed the story of the level and the goal which is contrary to many games (killing oneself).

Retrospective: The original level was too big and is a general problem I'm working on: I tend to think bigger than I should and get too excited about a project without considering time-lines. I feel I have improved on this while working on my newer projects, for instance "Lost Pirates" and "Hotel" which remained small and concentrated, and is the reason why I put off the project "Camping" for now.

For specific things I would change for "Gravity", one would be the way gravity switches were very sudden. The solution would be to implement the rotation model mentioned earlier in the prototype, but a quicker solution may be a simple depression button (a player steps onto a button that waits two seconds to teleport the player).

I would also like to art up the level a little more: the textures I ended up using were ugly and the level visually did not hold together: it did not feel like a robot processing facility. Also, I would have added some assets to the areas in the level, like oil dispensing units and robot charging stations.

I would like if the powercores were physic objects or if they fell into place. Currently, the are placed in position. I think having them fall into place would be something small that would really take the experience of the puzzle to the next level.

Finally, the final room should be more of a funnel to force the player down into the kill-zone. As the viewer can see in the video above, the player can choose not to die, which can be a problem in completing the level.

I would like to implement these changes sometime and possibly expand the play experience. I may switch to using the Prey engine for more complex gravity puzzles since they already have much of the gravity functionality built into the engine, but I would definitely polish the UDK "Gravity" level for my portfolio.

No comments:

Post a Comment