Week 3: Readings

GDW Chapter 8: Digital Prototyping: Effective Interface Design (p258—260)

In this chapter, the author talk about how to create an effective interface design for our games. The interface of the game should be designed in a way that is as clear and easy to understand for the players as possible. It should makes sense to the player and to their expectations, but also make sense to the game's context. The author also advised that, the best approach to an effective interface design is to design the interface after the game, to let the interface "evolve from the necessities mandated by the function of the game." (p. 258) This means that the form of the interface should follow the function of the game to be easily understandable. The interface should be metaphorical in the way that allows that player to understand an unfamiliar system of the digital game "because it helps users contextualize the experience of working with various objects on the computer in a way that is familiar." (p. 258) Note that, metaphors could also make the interface more obscure to the players, since each objects may have different metaphors according to different player's perspectives. Moreover, the visual of the interface should makes sense even at a glance, especially for when the players are playing the game, and the interface should be grouped together in a way that makes sense and not move around the screen in a way that would be unexpected to the players. Lastly,  the feedbacks, whether it is the aural or visual feedback, should be responsive to the player's action, as well as communicating clearly the information the players need. Depending on what is happening in the game, aural or visual feedbacks might be more understandable to the players.

I think that there's almost never too much feedbacks within games, and it is always better to make sure the players know what's exactly is going on in the game rather than hinting about the feedbacks in which the players may or may not understand. Moreover, the combination of aural and visual feedbacks can be extremely responsive and doesn't distract the players from their actions in the game. At the same time, there can be too much interface on the screen, since this could distract the players from the gameplay or simply being too much visually. I think that it is important to prioritize which resources should be show to the players on screen, and what can be kept hidden away during the gameplay. Also, the representation of the resources on the interface should be easy to understand and fit with the context of the game, like simple numbers might fit better as a bullet counter than putting tons of bullet sprites on screen, while a few heart sprites might represent the limited amount of lives the player have better than a number that's counting down since the hearts would be able to should the visual feedback upon receiving the attack as well.

GDW Chapter 8: Sidebar: Using Software Prototypes in Game Design by Nik Mikros (p242—245)

This sidebar's focus is how to create an effective software prototype. While paper prototypes could be make for digtal games, which sometimes allow easier iteration and took less resources, paper prototypes for some games that are heavily reliant on mathematical calculation may actually cost more time and resources than a software prototype that can calculate in a matter of seconds. The author also mentioned that we should create a software prototype in a language that we are comfortable in. This allows easy iteration thorughout the process of prototyping. Additionally, make as many things in the prototype variables as much as possible, so that it will be easy to come back to and change it later. Most importantly, the prototype should solve the problems that we were trying to solve as fast and effective as possible, while at the same time, we should be prepared to let go of the parts that didn't work to be able to fix the problems that needed to be addressed. I think that the ability to let go of ideas that may seem interesting, but is redundant, is a really important skill in order to have an effective working process. Holding on to the unnecessary ideas will not only multiplies the workload, but also obscures the game from its main theme and decreases its impact on the audience.

One of the advise that I found very helpful is to always keep in mind that "the goal in building a software prototype should always be to create a tool to help in your game design efforts, not to show off fancy graphics or elegant software architecture," (p. 242) since it is easy to get lost in continuing to program thge software prototype into something fancy that would be difficult to iterate later on. However, I do think that having a clear idea or goal as to what the final prototype can be would really help in creating the first software prototype. This is because I can visually determine whether or not the theme and the aesthetic I chose to work with would work with the mechanic of the game. As a result, I think that having a sketch accompanying a software prototype can help in the prototyping and iteration process of the game, since the sketch(drawn with paper and pencil) and the software prototype(written in the language I'm most comfortable with) are as equally easy to fix.

GDW Chapter 8: Sidebar: Prototyping for Game Feel by Steve Swink (p246—248)

In this sidebar, a good 'game feel' is described as how the controls of the game can make the game itself pleasurable to play. The author divided the different aspects that needed to be addressed to achieve a good game feel into these categories: input, response, context, polish, metaphor, and rules. Although there are no set rules for the best way to construct the input, it should be clear to the player about how the way their interact with the console would effect the player's charcater movement/action inside the game. As for the response, this doesn't refer to only the sensitivity of the console itself, but the feeling of responsiveness given to the player by the feedbacks of their actions. With effective response, the gameplay should feel fluid to the players. I think that the feedbacks, once lined up perfectly with the game controls, can really improve the player's experience on the game. However, it's never easy to create the right amount of responsiveness and create a fluidity within the game. I found that it's best to give a sound effect as one of the first feedback, then fix the movement according to how the sound feels. As for the controls, I found that the best way to understand and polish the fluidity was to playtest, and playtest a lot, with different players. Although usually it would be better to playtest with people outside of the game community to gain more insight and feedbacks, I found that, by playtesting for game feel with fellow game designers, I can receive not only the feedbacks about the feel of the game but also the technical feedbacks and what I could do to further fix and improve the game. 

Next, the placement of different objects on the game can create a context in which the player can understand what they are supposed to do, even without being told directly with words. For example, a floating platform may indicate how high a character can jump, therefore creating a motion context of what the character is able to do. Giving constraints, like walls or cliffs, to the game can also create motion context as well as a more interesting gameplay. The player will know where they can or cannot go, or what they have to go in order to reach the objectives of the game and stragtegize accordingly with the help of the context. This made me think of Super Mario Bros., where the platforms implied how high Mario can jump, and the clouds and bushed, using the same shape, implicitly showed what objects in the game are interactable and what isn't. This was all conveyed to the player within the first level of playing the game, without any written information given. Therefore, it proves the point of how the placement of objects can provide motion context to the players.