Despite the unfortunate absence from the final presentation, my experience in the project Vision by Proxy is a great one. The game turned out to be a greater game than what I thought it would be when we first start the project. I think the success of the project all own to the diligent work from the members of our small but dynamic team. Our artists are creative and imaginative. Our programmers, which myself is a member of, are diligent and hardworking. Our team manager did a good job in managing the team and guiding it all the way to the finishing line. All in all, we achieved every bit we were set up to achieve and we were even able to do a little bit more. This doesn’t happen quite often in any group projects I have participated in so far.
My role in the group is the “lead programmer.” So in this post I will mostly discuss my experience in the project from a programmer’s perspective. The initial feeling was unease when I was assigned the role. The reason is clear: I had very limited experience with Flash in general. And all previous experience I have with Action Script is with AS2, which, as everybody knows, is dramatically different from the newer, more object-oriented AS3. My programming skill in general is limited to its best. I start to learn programming when I joined DM department as a master student. From any aspect I’m just a rookie programmer. There are many concepts and even programming vocabulary that I still don’t understand. This “confidence” issue plagued me all the way until I guess when we get almost all the mechanism done. I use quotation marks here because I personally don’t think it has much to do with self confidence, although it might appear so. My point is that I’m fully aware of what I’m capable of and where my limitation is when we first start the project. This awareness motivated me to start learning AS3 programming early but on the other hand also limited my way of thinking in terms of originality and creativity. It’s hard to be creative when you have to keep in mind all the technical issues that may come with your or other’s brilliant idea.
Realizing that I have much programming challenge to keep myself busy, I wisely decide to leave the creative part of the project to the artists in the teams and focus my attention on programming almost exclusively (but to my surprise my Playdough eyeball man “prototype” was adopted in the game, So I guess I did my part in the creative aspect of the game as well). While it’s often said that everything is harder at the beginning, in this project it is particularly the case. Following both online and in-class tutorials only get me so far as to implement the basic character movement and collision control. Beyond that it’s all trial and error. I spent many hours solving design issues and. One design issues we had was the key configurations. The original key configuration was tested and then changed several times to follow the conventional usage in flash games. The inclusion of help page further assists players to explore the game more easily. Our interface is simple and easy to understand, and we design it in the way that once the player in the game, he/she need not to spend time learning how to use the interface after reading the help screen. Overall, the interface design follows Norman’s affordance and interface design principles (2004). For the game genre, our game is exploration-oriented with an easy and amusing story line. This is a game intended for everyone to play. As Lazzaro (2005) described the four types of player experience, I believe our game hold the “easy” key that entice the player to linger, and Grab their attention with ambiguity, incompleteness, and details.
The design and debugging process really took some long time. While I realized this is the path and pain that every programmer that has to experienced in a early stage of their career, when looking back, I do hope I began to communicate with other programmers both in and out of the team more often and more earlier. Luckily as I was about to finish my painstaking learning process, the other programmer in the team kicked in with more advanced programming skills. Together we were able to fine tune the codes I wrote earlier, got rid of mistakes and also implement new mechanisms that make the game what it looks like today. From working with other programmer, I was able to learn a lot from someone with much more experience. And the game also becomes better for the implementation of improved code. We actually did a pretty good job of what Zimmerman called the “cyclic process of prototyping, testing, analyzing, and refining a work in progress (2003)”. One regret I have is because I’m a rookie, there is still a little bit of (programming) language barrier between us. This has sometimes caused troubles when we were trying to talk about programming concepts more precisely and effectively. Another regret is I wasn’t able to implement the XML-AS3 scheme that Matt talked about in class. I know this is better way of making a game than what we were doing at the time. But again, I simply didn’t have the time to try on it.
Overall, as I’ve said, this group project turned out to be a valuable game development experience for me. I’m glad to see the end result reached our expectation and everybody is please with the game. Personally I did learn a lot about programming, about flash game development process and team work in general. Some general reflection: start early, don’t wait till the last possible moment; begin to learn what need to be learned early on, keep schedule; meet deadlines, communicate with other members and work really hard.
Reference:
Lazzaro, N. (2004-2005) "Why We Play Games: Four Keys to More Emotion Without Story." Self-published white paper.
Norman, D.A. (2004). "Affordances and Design." http://www.jnd.org/dn.mss/affordances_and.html
Zimmerman, E. (2003). "Play as research: The iterative design process."
http://www.ericzimmerman.com/texts/Iterative_Design.htm
Comments