Mecha Mercs
Introduction
This was my first experience working as a team on a game at UAT. It was a completely online course, so distance was one big obstacle between the team members. However, we all did very well staying connected to the project...for the most part. My team consisted of: Anna Traynor, Brian Gutscher, John Phillips, Tyler Bason, and myself. We worked on Mecha Mercs for 4 weeks, using Game Maker Studio as our IDE. It was tricky deciding initial roles going into the project, the group consisted of basically all game design majors, and no one was very good at programming. Knowing this, I wanted to make everything as simple as I believed it would be to code or produce using the drag-n-drop system of Game Maker. While my entire group worked very hard and stayed on track of our milestones for the most part, the project reached a bottleneck because of programming.
We produced the majority of what we desired from the game in those 4 weeks, but it ended all for naught. What I felt went right: me acting as a bridge, project documentation, assignment of duties, and communication. What I felt went wrong was: lack of participation from programmer, lack of a working build, and a costly, foolish 'fix' that did nothing.
What Went Right
For this class, everyone put forth a game idea and the instructor chose 2 out of all the students and formed a team around those- one of those game ideas happened to be my own, Mecha Mercs. Going into it, the group was largely comprised of game design majors. This made some of the initial ideas go all over the place. Everyone had a different idea of what they wanted from the gameplay. We all performed extensive research on several games and related works. When we started to seriously decide roles for the team, I requested class works from each one and their personal input to figure out what would work best for the project. I also tried to think realistically about the ideas everyone was coming up with, and what could be done in the short class period. Quarrelling of ideas came to an end when I attempted to synthesize our ideas into a paper-protoype video that served as a sort of 'vertical slice' for the group. Once it was done, we allocated duties and each member was actively involved with their own work, consulting me to see if changes needed to be made. Brian became the writer, Tyler became the tracker(he wrote the documentation), John became the artist, Anna became the programmer, and I stayed a designer as well as being the project manager.
I did what I could with providing enough work to not make my team
members bored, but also not too much to overwhelm them for a week. I
had a very clear idea of where we wanted to be at the end of each week.
I also altered or 'culled' some of the work produced by my members if it
was out of scope or something. For instance, Brian initially came up with
9 different brokers for the game; we had planned for 3 missions per
brokerage, which would have been 27 separate levels to construct. Due
to the gameplay mechanics, this wouldn't be difficult to accomplish, but
it would create additional work for the artist and writer without already
having a stable 'foundation' in place. We settled on 3 brokerages, which
proved to be very do-able in my eyes. We communicaed actively during
our weekly team meetings over Skype, and that also contributed to
everyone being on the same page.
Another thing that was done very well, both through the ease-of-use with Trello, and the ability of my team, was documentation. The class requested a Game Design Document, Technical Design Document, and Art Design Document. Pretty much anytime we had an idea or we put something into the design of the game, it went into one or more of these documents. Since Trello easily stores and shares files, all of my team members would submit files and keep ourselves connected. Tyler stayed on top of updating the documents and this aided in keeping everyone on the same page, design-wise, as well. Brian produced numerous written documents about the narrative, and game world- though many can be difficult to find on the Trello page. We still have many initial sketches as well as final concept art and sprites to be used. Aside from the technical design document, everything was produced, stored, and used to the benefit of all.
The division of duties helped keep each person's task for the week simple, and in an
easily digestible format, while the main project remained large and somewhat-complex.
Trello helped with this process allowing me to flag posts at different levels of importance,
as well as creating a 'task checklist' that would be updated dynamically when others
finished a task. I could easily figure out what each person needed to do in order to reach
the milestone for the end of each week. However, once we got to work and didn't
'brainstorm' as much, Tyler's workload dropped excessively. So, I also asked him to find
sounds and music for the game in the mean time. Brian's work also dropped, so I put him
in charge of writing help text dialogue boxes and item descriptions in addition to the
narrative and story dialogue. I believed what I gave Anna was within scope, but it's
always difficult to predict with programming, especially if it's not your forte.
Encounter Key written by Brian Gutscher,
and edited by Alex Thompson
(left) The original concept art for a Mecha by John Phillips. (right) The in-game sprite version, also created by John Phillips.
Communication, for the most part, was a very high point on the team. I asked for each person's schedule, kept it on the Trello page, and had most of my team members phone numbers, alternate emails, or skype information. If something popped-up that would impact the team as a whole, we would be ready. By staying in-touch, my team members also communicated to me whenever their weekly tasks seemed too big, not enough, or they simply had quesions about it. I also could check-up on their work progress every other day; not too often that it was annoying, but keeping ourselves safe from trying to shove a week's full of work into the last 2 days of the week, either. Talking often also helped to build trust and comradery, I was very concerned about this initially so I made a Trello page essentially to just 'hang out' and talk geeky stuff that we like. For the most par it worked, but I do think how the project ended left a sour taste in the group's mouth. So now, on to what went wrong...
What Went Wrong
Anna was given the task of programming. She missed several meetings and would be difficult to reach at times. I'm not a very good programmer, but I can write code a little bit. So I understand how things can spiral out of control and we have game breaking bugs, etc. The issue is that I had already been helping John to complete the art assets, so on top of everything else I wasn't able to assist Anna as much as I needed to. Anna was very reluctant to giving us the current build of the game; that is, until the final week. She said she was having some issues, but explained that she's working through them just fine. I didn't want to be pushy, especially since I think Anna got pressured into being the group's programmer, so I let her be. If I've learned anything from working on this project it's to take notice when people won't show you work, or do not communicate with the group.
By the time I saw the 'build' it was in shambles. I had no idea how far behind Anna
was, so many things weren't implemented and there were numerous bugs
everywhere. What I quickly learned by trying to assist her for several hours over
Skype is that she was trying to program, but never tested it- which is a combination
for disaster! Not only did she not have really anything working, but she seemed
completely confused about how the game was supposed to play. So I guess she
didn't understand the paper prototype video or the information that Tyler and myself
put into the technical design document. Had she been working on the art, and I on
the programming, perhaps we would have had a working game.
One of the reoccuring issues that Anna was having had to do with the free version of Game Maker. It put a limit of how many objects you can have on the screen a a time. At least, this is what she told me. To 'fix' this, I went ahead and purchased the Standard version for her, since I already had it, and let her get back to programming. I did this without consulting or notifying the rest of my team. As it turned out, Brian was also using the free version, and when he tried to populate event prompts with dialogue, he couldn't open the file. It was showing as incompatible. He refused to buy the standard version, so he sent Anna over the dialogue information for her to implement. This only made Anna more stressed and gave her too much work to do.
A screenshot from the final 'build' of Mecha Mercs. Can you spot the problem?
In Conclusion
We all learned a great deal from this project. I learned the importance of having a working, playable build at every step of the process. I also learned to make note of those who fall behind or don't participate with the group. While the game ultimately failed, the project was a success. Each of us produced very good work that we should be proud of, and we learned about the pacing, work allocation, and communication involved with team projects. I likely will attempt to finish this project on my own, as I do like the idea and I want to see it realized to the fullest. But only time will tell.