Yap, on presentation last Thursday and today mid-term evaluation our team seemed not doing well. In other words, we failed. We couldn't express our game properly during the presentation to the faculties. We also had communication problem between team member and faculty. Each member of the team has different game in their head. The result is everyone thinks that we are circling around during the whole summer and the first half of the semester. To be frank, I didn't quiet see what's the problem but after talking with several team members and the faculty, I see what's the problem.
Since the beginning of Vinyl until earlier of this month, we never really have a goal. The faculties kept mentioning their concern of our game having no goal. They never mentioned it directly to me. I heard rumors that they will fail us if we don't have goal for our game. I didn't quiet see what's the importance of not having a goal. Now that I put things together, I see their point of having a goal. Without a goal, our game is only a toy - an experimental playground - which basically what we did. We added this and that to see if the game is fun without particular purpose. Now that we added a goal, every feature that we added to the game has its own purpose: either to help or to prevent the player achieve the goal. I can totally see that having a goal, we have a better direction in designing the game. So, instead of saying it is a goal, I would rather to say the direction of the game - what we want player to achieve in the end of the song!
The other benefit of having this direction is putting everyone in same page. In addition to Mikeh's one page game design, we get more understanding of what game we are making. I remembered before this all happen, we kind of scattered around about our game. One says it is audio synesthesia game, one audio manipulation and the other one first runner game with audio manipulation as the feedback.
The other thing that makes the team member confused theirself is the bizzare direction of the game design discussion we have as a team. It has already started from last semester when we picked amongst the 4 games. Whenever the team sat together to discuss the game, the game direction went wildly from our original thesis. That's why just before summer break, we pointed Mikeh to be the lead designer. Then during summer Cody kind of becoming the co-designer. It didn't work quiet well. First, some people assumed that whatever we discussed as a team was the game. In fact, the designer team (Mikeh and Cody) filters those input and picked those related to our thesis. Second, some people joined here and there during the game design meeting. As a result of partial information they gathered, the game was completely different from the decision of the meeting. The most important is how the game designer team communicate the meeting decision to the team. Again, now it has been improved with the one-page game design by Mikeh. The way they kept the meeting process from the team also helped prevent the other team member to have wild assumption about our game.
I am glad that our communication problem within the team member gets better. However, one thing that keep bugging me is the communication problem with the faculties. I understand that there were almost no communication between the team and the faculties. As the result, the faculties didn't see our progress at all and worried about us. Brianne is taking care of this and I know she can improve this communication issue.
However, there is one point the faculty mentioned to me that I didn't see the importance. That's to have an executable build. We do have build
No comments:
Post a Comment