"Game Design Workshop" Reading Journal #3

Exercise 5.1 & 5.2 & 5.3 & 5.4

Monopoly: 

• Player tokens
  • Color
  • Shape
  • Behavior: 
    • Move according to the dice
    • Move because is attacked/stepped on bad blocks
• Land
  • Position
  • Number
  • Price
  • Color
  • Behavior:
    • Being bought by players and be represented by their tokens
    • Upgraded
    • Being bought again by other players and change the token representation
• Chance Card
  • Effects
  • Behavior:
    • Being drawn by players
• Bank
  • Money
  • Interest
  • Behavior:
    • Lend money to players
    • Get money back with interest
• Relationship:
  • Player's position decides Land's behavior
  • Player's action decides Bank's behavior
  • The number of land a player is having decides Player's behavior and sometimes decides Bank's behavior
  • Chance Card's effect decides Player's position and further action
• I first took away the bank feature and then the Chance card, but the game is still playable without them. Taking away either land or player would be detrimental to the game because land is the goal of the gameplay and player obviously is needed in a multi-player board game.

Exercise 6.2

• Doodle Jump
  • Formal Element: 
    • One player
    • Objective: keep going up and break records
    • Procedure: use finger position to control the position of the character
    • Rules: Enemy and falling kills the character; jump on the platforms
    • Resources: 1 hp up as the power up item
    • Boundary: Screen size; the game needs to be played with the phone in portrait orientation
  • Dramatic Element:
    • Challenge: not to die; constantly react fast
    • Play: compete with oneself/friends/other players
    • Character: cute, doodle style
    • Story: not really a story in the game
  • Dynamic Element:
    • Difficulty of gameplay increases as players play longer

This week's reading did give me some inspirations to the space-shooter game I'm creating. On page 258, the author says that "As a designer, you should play with how to represent the tension of this particular situation, the excitement of it in both the controls and the interface" and that "the interface is coming from the gameplay, not vice versa". This is some thing that I've seen in a lot of games but never really considered this way. I agree that it is a nice idea to incorporate the user interface and the game play and I'm going to do that in this game.

The part where he talks about metaphors also makes me reconsider some part of my game. I am planning to make a game about a cat trying to play with the master instead of playing with lasers and stuff. I was originally thinking of making cat treats as a kind of bullet, but in that case some player would maybe think of them as power-up items. I will need to think of another thing to replace cat treats and maybe actually make the treats into some sort of power-up item.

In the Quake health meter in three states example provided in the book, the character is having different facial expressions in different health condition. Since I do not want the boss to have an hp bar showing the remaining hp, I might make the boss look differently when in low health. I'm also thinking of changing attack-pattern which can also let players learn that they've reduced the boss's health.

In "Using Software Prototypes in Game Design" by Nikita Mikros, he says that "having a solid understanding of how one system interacts with another is essential in writing a comprehensive design document, answering questions from the team about the project, resolving unforeseen problems, and ultimately creating a compelling, balanced game. As games become increasingly complex, it becomes more and more difficult for the game designer to keep a complete image of all the elements or systems of gameplay in his or her mind". I really agree with what he is talking about, especially with my experience from the previous group project. We decided to create a google doc that we are constantly making changes and writing down new things. Every time we play test or get confused by certain rules, we will refer to that and discuss about changes we should make. This really speeds up the design process and helps up keep track of our project. Also since we are keeping all the changes in the google doc, it becomes easy for us to write our development logs.

Mikros also talks about avoid using numerical values in code so that it's easier to make changes and also easier for other people to understand the code. This is also some thing I learned from my experience creating video games last year. In the beginning phase of creating a game, usually I need to make changes to the numbers and even the functions a lot, and it could be really frustrating to keep going back and froth from Unity to Visual Studio.

Towards the end, he says that "if you want to be creative, don't hold on to anything too tightly, don't make anything so precious that you can't see beyond it". This is the one very important thing I learned from the card game project. At the beginning we had a charm point mechanic and all three of us don't want to cut it because we did dedicate a lot of time trying to balance out the mechanic. Unfortunately, most play test responses we got were saying that it kind of slows down the pace of the game. We talked about that for a while and decided to cut that part out of our game. It felt disappointing at the beginning, but when I look back I do think it's a wise decision and our game did become way better from that very first version.