As lead programmer in my group, my design decisions were slightly limited. I made sure that my input was heard at the earlier meetings and brainstorming sessions, but gradually deferred to other group members as the idea became more concrete. In the end, my thoughts on design were all concerning the affordances and constraints of my engine. I acted as a reference for my group; without me, they would not know what would be possible or practical to implement in the game.
In our brainstorming sessions, my group drew up a giant list of ideas and possibilities. We attempted to be as completely uninhibited as possible early on. Personally, I wanted to move away from more traditional types of games. I was inspired by the New Game, discussed in Sustainable Play, which were not the typical goal-oriented styles of play. These were examples of play for play's sake. Likewise, many of my ideas were based on the idea of playing without a goal or specified task. I also wanted to experiment with some of the conventions of gaming. The goal of the course was to design a game mechanic, not necessarily create a complete game. I feel like some of my strongest ideas were based on simple and well-known gaming conventions. I felt that a mechanic like jumping or running could be changed or used in an unexpected way. Whereas games like Mario and Sonic use running and jumping in a literal sense (as a form of movement), some other meaning could be attached to these actions. I wanted to explore a different reason for running. Mario runs to save the princess. Sonic runs to save the world. Why should our character run?
What our group finally settled on as a mechanic was memory and time. The idea, going through many phases, was that a character would travel through time or memory as she explored a space. We discussed many ways that this could be accomplished. Perspective would play large role in how our game would be received. Again, gaming conventions would play a role. A top-down view is typical to RPGs and exploratory games. Side-scrolling indicates a more action-oriented game. Or we, could implement a 2.5D perspective that would blend both gaming metaphors. We decided on a 2D side-scoller for the art's sake, but that our game would not be action-oriented. The style of the art would be great indicator of the mood in our game. The art, like our character, would change as she moved through time. I suggested that scale could be exaggerated to emphasize the changes in age. Children perceive the world as being larger than adults, and I think it offered an interesting way to paint the world. It was at this point that design choices and I began to part ways. I was fully investing myself into coding a good Engine.
My initial expectations of the game would be that the player moved through a house. As she moved from room to room, she would experience different memories. I likened it to a stream of consciousness novel. Instead of reflecting upon the memories, she would be actively participating in them. Some rooms may have an object the character desires, an obstacle she must overcome, or another character seeking to harm her. And, based on how the player performs in the memory, the outcome of the game would change. These memories would only be played through once, instead of restarted when the player supposedly "fails". For example, suppose there is an item across a large gap. She may obtain it or fall down the gap. Whichever outcome that occurs becomes the memory. The level doesn't reset if she falls down the gap, and she doesn't "win" if she gets the item. Each of these scenes would rely on a single game mechanic, like a mini-game within the story. I thought our game would be comprised of several of these scenarios, each of them altering the story of the character.
The actual game my team produced is slightly different. There is still the notion that the player cannot fail. But the story is a bit more abstract, keying on events that may not take place in the house at all. As it exists now, I do not feel like we produced a core mechanic; it is more of narration method. I feel like we are too attached to an established convention of side-scrolling platformer. I don't think that the notion of time-travel is immediately read by the player. I could be wrong, but I definitely look forward to seeing how the game is received by an outside audience.
During the development process, I voiced my concerns whenever they arose. I mentioned that the art for platforms needed to be distinct from the background images. If a player cannot recognize what he or she can jump on, the play is interrupted and becomes frustrating. Also, a player must become versed in the language of the world gradually. Our game makes use of platforms that disappear after landing on them. Players should come into contact with these platforms before being placed in a "dangerous" situation. That is, the first time the player meets these disappearing platforms, it should be in a setting where they can get acclimated to them. If a player jumps on a platform, not knowing it will disappear, and falls off the screen, he has "failed" by no fault of his own. The player should recognize the challenges presented by the level and how he is expected to overcome those challenges.
Overall, I feel like our team has done very well in producing this game. I think my teammates wanted to create a complete game when they should have focused on the core mechanic a bit more. That's not to say they did anything wrong. I just feel they may have been over-ambitious. I've gained a strong sense of personal gratification from this course. I realized a lot about myself in working on this game. I'm grateful for the chance to sharpen my Flash skills, and for the lessons I learned about the game design cycle. This course offered a load of resources, and I look forward to applying them all in the future.
Comments
You can follow this conversation by subscribing to the comment feed for this post.