Posted September 16, 2019 by fungifurball
#Reading Journal
Exercise 5.1 & 5.2 & 5.3 & 5.4
Monopoly:
Exercise 6.2
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.