Week 1: Readings

Reading Response

GDW Foreword / Preface / Introduction:

After reading the first few pages of this book, I got the impression that GDW talks about game design in a very straight-forward tone. loaded with examples. What I didn't expect were the occasional opinions from experiences and encouraging words within the text that made reading the book felt more like a person-to-person teaching rather than just simple reading it, which I assume would continue to be there for the rest of the book.  Some lines caught my attention more than others, one is that the goal to create games is to "To bring magic into the world. To make great games. And to set the world on fire through play," (p. XIV) which really highlighted how games could be played as entertainment, but also so much more; it suggested that games are powerful.  Later in the introduction,  the text states that to make games, it doesn't require you to only know about games, but also culture, to also be the engineer, mathematician, entertainer, and requires more skills that are seemingly unrelated on the surface. It made me realize the skills that I should learn and know in order to be able to create games outside of just the technical stuff, but also that the skills I've already learnt that I thought wouldn't be of any use wouldn't go to waste.

Game Designer (p1—28):

Right at the start of the chapter, it was very nicely summarized into a few words that the role of a game designer is to "plan the structural elements of a system that, when set in motion by the players, creates the interactive experience," (p. 3) so that the player can play the game to "learn new skills, to feel a sense of achievement, to interact with friends and family, and sometimes just to pass the time." Then, it goes on to state that game designers should know how to look at the game from the player's perspective. In order to do that, there are a few things in which allow the desginer to create a solid game that the player would enjoy as a result.  One of the things that I also think is very crucial is having playtesters to play the game, and going back and forth between playtesting and mkae changes according to the feedbacks. I've found have playtesters to be extremely helpful when testing out the mechanic and the rules of the game. Unlike the art aspect that could be commented upon sight, the mechanic and rules required a throughrough playthrough in order to see what's working, what isn't, and whether or not the player is behaving the way you expected the game to make them do. Having a clear goal and set of questions prior to the playtests would also help to stay on track and organize for the next iteration of the game. In addition to talking to playtester, the team should be able to communicate well with each other as well, which would in turn create a good teamwork.  I think that, when working with another person or a group of people, there's bound to be a disagreement, and depending on the group of people, solving the disagreement could take a few minutes to a few days. The solution the text suggested is to be a good listener and a good compromiser. However, I sitll find it a bit tricky occasionally since different people react differently when faced with an idea that they don't agree with., and I think that activites that allow you to know the teammates' personalities more before the actual process of creating the game might help in decreasing the time to solve the disagreement in the future.

GDW Chapter 6: Conceptualization (p165—181):

This chapter started off with how to find ideas and inspirations as a starting point if making the game. One of the advices is to look at your daily activities and interests from a new perspective: looking at the systems and the underlying connections beneath the surface. This was very interesting to me since, when coming up with new ideas, I ususally reach for ideas that I think are 'cool' or potentially 'interesting' rather than something that I usually encounter all the time.  This made me think about finding inspirations in the aspects that  would've usually overlooked, and using further research to improve those ideas. After this, the text goes on to talk about brainstorming in order to flesh out the ideas, espcially when working with a group of people. Usually, I use a list to keep tracks of the ideas while adding on to it and making it longer and longer. On the other hand, mind-mapping, which was mentioned in page 175, is also a very effective ways to develop out the ideas. Since mind-mapping lays out the different ideas in a non-linear way, it is more visual and therefore allow the interesting ideas to stand out more. In addition, it makes it easier to tell which ideas could be developed more since their branch from the mind map would be longer and more branched-out.

GDW Chapter 7: Prototyping (p197—202, 209—212, 224—229):

In this chapter, the main focus is how to make a physical prototype that would allow the problems and bugs to be easily spotted and solve with quick iterations before creating the finalized design. Creating physical prototyping for a board game or a card game were things that I've experienced before, however physical prototyping for digital games that the latter part of the chapter talked about isn't something I'm familiar with at all. An important point that caught my attention as to why we should make physical prototypes to digital games is that, not only are they cheaper and require less time to fix since you only nees basic crafting equipment,  "physical prototyping forces you to think through the design elements and define them." (p. 209) This suggests that physical prototyping really focuses you into thinking about all the details of the mechanic and the system, which would in turn makes the programming later on easier since the programmer would already "be able to grasp your vision of the game... [and ] have something solid to work from." (p. 209) In addition, it is adviced to keep the core rules of the games as simple as possible, to create a structure that you could built and implement on. The text describes creating the structure of the game as "constructing a skeletal structure that can support the rich and varied feature set that will be your finished game," (p. 224) and that it is best to focus on creating a solid set of rules that work because the features can be added later. This makes the brainstorming process important since, later on, the cool ideas that weren't used to flesh out the rules could be used to add interesting features and aesthetics to the game.

GDW Chapter 12: Team Structures, Agile Development (p403-406):

The focus on this chapter is how to communicate and work within a team in an effective and non-disruptive way.  It is highlighted that a successful working team means that each member contributes to the part in which they are responsible for to the best of their ability. An emphasis is put on team building and communicating because these are the crucial points that could create a smooth workflow or disrupt it altogether. Moreover, somtimes it is better to have a person in charge in order to make decision to move forward, or to counduct meetings on certain topics that need to be addressed. Because making games will almost always be collaborative, it is important to know how to behave when working within a team.