Last semester I was part of a group that worked on video game design for Independent Reading & Research. As we were creating a type of interactive media that drew from several different fields, we were a very mixed group with a variety of inputs. We had several programmers, artists, and musicians - eight people in total – and each member of the group contributed a unique set of knowledge, experience, and skills. Artists were knowledgeable about design, animation, and specific art programs required for the job. Programmers were knowledgeable about programming… etc. We also had a goal of making four games over the course of the semester, and we had four main tools for communication – FtF meetings, Wikidot, email, and IM. We had physical meetings whenever possible but, as there were so many of us and what we were doing was so technical, we often relied on technology for communication.
The interaction process took into account all four types of communication. We had FtF meetings three times a week where we discussed the design and progress of each game. We also had a Wikidot account that served as our group’s main depository. Information about each game and the art/music assets of each game were uploaded here. In addition to this, we had one IM session each week and contacted each other by email frequently.
Our group worked very well with this technology, for the most part, but there were a few issues that arose from proximity. As Kiesler and Cummings describe, “communication in electronically sustained work groups is likely to be somewhat less mutually attentive, less companionable, …etc.” (69) This was very true in the case of one of our IM meetings. Confusion arose between a programmer and the rest of the group over a particular issue of design. The lack of understanding caused the atmosphere become very competitive (instead of cooperative), and an argument dominated the discussion for over an hour. He refused to conform, and the group failed to reach an agreement.
Aside from this, however, our group was very productive. Because our group worked in cycles for each game, we were able to produce new output every three weeks (a game). After each cycle, we also allowed time for a postmortem to address problems within the group. This was very useful because our group was able to stay together until the end of the semester.
Subscribe to:
Post Comments (Atom)
Posts
I am taking this class now, so it is nice to be able to read about someone's experience in the class. The cycles seem to act as a silent enforcer, keeping everyone on track of their goal, which is very important with keeping up group dynamics. The more involved the individual gets into the goals of the group (especially if the completion of a product is the goal of the group), the more involved a person is in the group.
ReplyDeleteIf the confusion of the design issue was brought up through some other mode of communication (CMC to FtF), I wonder how it would have been handled and if the atmosphere would have turn competitive as it did.
I wish I would have taken this class as it seems right up my alley in terms of programming and music composing.
ReplyDeleteI know from a CS standpoint that there was probably a type of source control for the code, but was there anything like this for the entire group? I saw the wiki, but I feel like it would be interesting to see the iterations that everyone made throughout the course.
Would it have been more useful to have been talking in a more conference type style (i.e. Skype) since ideas can be more easily communicated in all mediums over this form. For example, humming a melody or something is much quicker than notating it out and sending it (though that would have had to been done anyway).
Hope the game turned out great!
I can tell your group had a lot of organIzation when it came to communication. Between the once a week instant message meeting, the wikidot, and the the FtF you were always interacting. This is probably the most important thing in measuring your groups sucess.
ReplyDelete