Week 4: Readings

GDW Chapter 4: Working with Dramatic Elements (pages 97—102)

In this chapter, the author explains how the dramatic elements in game can provide a context to the game and "engage the players emotionally with the game experience and invest them in its outcome." (p. 97) Some of the more common dramatic elements are challenge and play, while there are also the more abstract ones like story and premise as well. 

As for the challenge, it should be a task that is satisfying upon completion, but also not too difficult that it seems impossible to win or too easy that it provides no thrill. The example of the flow diagram that showed Csikszentmihalyi's theory of flow shows how the balance of the challenge vs the player's ability can keep the game enjoyable to play. If the challenge rises, the player's abilities should rise too. 

In addtion, the player should be able to see the feedbacks, whether visual or sound, when they do something. This is so that they know the their actions are working and will drive them towards completing the challenge. The player should be able to feel a sense of control whilst playing the game. If they feel that they have no control, then there would be no point in playing. Yet, if they have complete control over the game, then that would lead towards the boredom side of the flow chart.

When I read about the challenges within games that are satisfying to complete, I thought of those Soulsbourne games (Dark souls series, Bloodborne, Sekiro: Shadows die twice) which is known to be difficult to beat. I feel the the challenges that these games provide are almost identical to the challenges in sports, in which the best way to overcome them is to practice over and over again. The players will fail a lot, but also learn a bit more everytime they fail and gain more skills accordingly. Once they trained enough, their works will paid off and they will be able to defeat the challenge. This gives immense satisfaction to the players and encourage them to play more to look for that experience again. This also shows that the players know that they more work they put into it, the closer they get to triumping over that challenge. This reminds me of a playtest I once did at Playtech, where I had my platformer game put out for playtesters. I thought that I had made the last level a bit too difficult, and I had one playtester playing the level for an unexpectedly long time. When I asked the playtester why he kept replaying after failing over and over again, he replied that if "the game is made, then it can be beaten. And I feel like I almost got it." This suggests that, with a sense of control and practice, the players can also get a sense of being closer to completing the challenge, and that beating the game is never impossible. 

GDW Chapter 8: Digital Prototyping (pages 235—269)

In this chapter, the author describes how digital prototypes can help in testing out the mechanics quickly before the refining process. These prototypes should be quick to make and easily changable. They should also be focused on answering a specific question rather than the whole gameplay. There are 4 areas that a digital prototype could be made for: Game Mechanics, Kinesthetics "feel", Technology, and aesthetics. 

When making the SCHMUP project, I did made serveral digital prototypes before proceeding to create the whole game. As for the game mechanics, I had several prototypes to test out how the player and the enemies would behave. The first one that I made was a prototype of how the player can move around the scene and either shoot 1-way or 2-ways in opposite directions. This kind of link into the kinesthetics prototype as I had to test and see which movement felt better as well as worked better for the game. Another mechanic prototype was how I could make the enemy shoot in different directions with several bullets and how that felt against the player. I had made most of the code for the prototypes changable variables so it was easy to go back and forth between tweaking the numbers and playtesting the mechanic.

As for the technology prototype, I had s prototype in which to test how the programming for the player's followers would work, as well as two more prototypes in regards to the enemies behavior. For the followers prototype, I was trying to find out how the code could pass on a variable from one scene to another and effect the other objects within the scenes. The code gave serveral bugs within the prototype and was a bit more complicated to figure them out. However, it was better to find out this bug when prototyping rather than when creating the final version. As for the enemies technical prototypes, I had one prototype testing out how to create waves pattern, and another one to test out how the boss can change its state. Just like the followers prototype, there were several bugs and errors within the prototypes, in which I had to fix before moving on to creating the final version.

For the aesthetics prototype, I only had one prototype since I spent too much time fixing the mechanics and the technology part of the game. However, I was able to put in some sprites and visual feedbacks during the later part of the process and recieve some feedbacks on them. I was trying to find out whether the character designs were clear enough to indicate what they are and gives the context to the player. In addition, I had put in particle systems in prototype in order to mimic the charactera exploding on death. As a result, I could see how the visul feedback felt, and whether or not it was effective enough to the players. I found out that making explosion size correlates to the character size provided a pretty clear feedback to the players.