Production 1: Getting the Feet Wet

It has been a few months since I posted last. I tend to find time for personal projects in short bursts, so I will try to post several interesting things at the end of each month or so.

This Post is about the Production 1 class which we had in the Spring semester of 2009. I know its a bit late to talk about this now, but I only recently started the blog and I think its interesting enough to talk about it. This is a combination of a journal and a post-mortem.

The Class

For those of you who are not familiar with Champlain's curriculum, game design students go through several production cycles before graduating, each more intense and industry-like as time goes on. I don't know if it is an intentional act on the part of the teachers or an inadvertent side-effect of the type of students we have, but each year results in more politics, more drama, and more stress than the previous one... hopefully preparing us for the overtime nightmare that is the gaming industry standard production cycle at the moment.

Production 1 is our first chance to work on a multi-disciplinary team. In other words, the first time Designers and Artists work together. At this point in the curriculum it was determined for complex reasons that it was not yet time to introduce Programmers to the mix. This is probably because the projects are very small scale, and having a dedicated programmer is not always necessary to prototype a vertical slice of the gameplay. To my knowledge, our year had the best of this class so far because they decided to break the semester into two small production cycles. The first was designed to teach us a basic knowledge of project management and group organization as well as a smattering of flash. The second was an attempt to make a primitive flash game using what we learned. Long story short, I already had a fairly firm grasp on Actionscript 3 (flash scripting language) before entering the class, so I offered to be the programmer for the first half of the semester, but took on a project management role in the second. We did a pretty good job all considering. Nothing commercially viable, or perhaps even portfolio worthy, but we learned alot and produced a vertical slice of a fairly powerful art game: Clash.

The Team

The team we had consisted of a handful of talented individuals with varying levels of motivation and people skills. I say this because we liked to butt heads alot, particularly myself and the art director. It became a running joke that this was the meta-meta-game. (Read the section titled "The Game" to understand why there are MULTIPLE layers of meta going on here). In essence, we were in conflict over the making of a game that was supposed to get players to be in conflict by playing a game that was about... you guessed it... conflict. Now I have typed that word enough times that it is starting to lose meaning when I read it to myself.

Our team consisted of:

Dan Porter (me!): Producer / Big Headed Bafoon
Logan Dwight: Lead Sound Engineer / Art Director / The other Big-Headed Bafoon
Karl Markis: Lead Designer
Corey Livingston: The Programmer (Designer with little experience but ALOT of motivation to code)
Dan Burchett: Artist
Ben Gerowe: Artist

When we sat down to make the game, Ben Gerowe was not yet with us. He was an artist on another team which dissolved because of a technicality which prevented them from meeting the requirements for a deadline (which was not Ben's fault fortunately).

The Process

When we kicked off, Logan was forcefully in favor of making an "art" game. In other words, a game that had a deeper purpose than entertainment. Although we were in initial agreement on this, it was more than a week before we had an idea which we though was a viable game that still maintained this purpose.

We settled on the idea of Clash (see below) because it seemed the most technically feasible and had the most potential to achieve an "artsy" message without failing utterly as a game. The name was up in the air for a week or two, but Clash just had the right ring to it.

We openly invited everyone on the team to contribute ideas towards the final list of mechanics, and in the end we had a list of player/conflict mechanics and a list that detailed a series of enemies... each vaguely representative of various ways to tackle problems.

Each week, the various members of the team were assigned a series of tasks, the status of each of which was due in a weekly delta report. My job was to sift through the delta reports and make sure everything was up-to-date and to make sure that they actually reflected the assets we were cranking out.

It is important for the reader to understand that we were full-time students with four or five other equally demanding classes. On average, each of us put in 5-10 hours a week for the two month duration of the project. Honestly, it would be really nice if we could devote a full-time 40 hour/week effort on this, but it simply isn't realistic. The reality of our project was that it was something that was effectively slapped together in our spare time between the rigorous tests and essays associated with our other classes.

I make our time limitations clear because it was the major limiting factor on our scope. In addition, it is usually this factor that separates our work from professional/portfolio quality work. It was really frustrating to have so much talent and so little time to use it with. So.....

We plugged along at a reasonable rate with the exception of a few problems:

1) Logan and I fought about minor mechanics... alot. We eventually came to an agreement towards the end of the semester, but not before alot of bickering. This was really only my second experience with someone who had as forceful a personality as myself, so it was a while before I figured out how to approach him in a non-abrasive way. I feel that this is much the same for him, which is why we both had a good laugh about it at the end of the semester.

2) Delta reports, which were required as part of the class, were a pain to deal with using Unfuddle, a hosting service for a subversion [SVN] file management system which also contains many project management features. Unfuddle made managing tasks difficult because the system it uses for tracking time on individual tasks is difficult to figure out. In essence each person is responsible for clocking their time on a TASK BY TASK BASIS. I can't stress how terrible an idea that is when dealing with a project this small. On a larger project it would make sense, but when some tasks take a half hour to complete it actually takes longer to enter, record, submit, and re-check the time spent on each task than it takes to do the task itself.

3) Logan had a habit of not showing up to certain meetings or filling me in on the actual status of his work via the Delta reports. Although he carried through all of his tasks, I was not sure of where he really stood at any given time despite repeated questioning. Part of this was because of his role as sound engineer (which is hard to measure when there are only a few tracks and each of them is really long), and part of this was because he was a Resident Assistant (RA) at the college that semester and had other duties for him to attend.

4) Corey had little programming experience in Actionscript 3. Everything we accomplished was largely a result of him banging his head against tutorials and documentation until it worked. Towards the end we sat down together and cranked out half the game in a few days because there were so many bugs.

5) This was one of my first attempts to lead a team with little outside direction. I failed miserably in some areas, specifically in remaining neutral during team conflict. In addition, I feel that I did not do an adequate job leading team meetings in the beginning, which often dissolved into quarrels over minor points. This was resolved later through a combination of private communication between myself and each of the group members, and through the sheer willpower of the team to be successful despite setbacks.

6) Logan convinced the team to switch to Flash CS4 early on in the process. This was problematic because not all of us had access to this program on our personal computers or previous experience with it, as opposed to CS3 which several of us had worked in and/or had access to. In addition, CS4 is an enormous memory hog when compared with its predecessor. All of the sweet tweening algorithms that sold us on the idea of CS4 were quite expensive from a memory standpoint, and resulted in the game having a low framerate. Had we known more about Vector art before starting the project (Flash likes Vector far more than rasterized art for the really neat special effects), we would have used static raster assets for our more numerous and less dynamic enemies. However, CS4 did some really nifty things which made our game stand out, so ultimately I am undecided over whether this was a good or a bad decision.

7) Ben Gerowe is primarily a 3D artist. His traditional art skills and knowledge of Flash were far behind those of Logan and Dan Burchett who excelled in this area. He was incorporated into the team after roles had already been defined and the project had been scoped for our original resources, so there was very little for him to do when he first joined the team. I blame this partially on the class for being structured in a way that inserts people onto the team after the project has been scoped for a smaller group of people, and partially on myself for not utilizing his skills more. However, after a week or two we were able to train Ben in some of the sacred ways of Flash-art and he was able to almost single-handedly create the spectacular scoreboard art that makes the Clash mechanic work! Kudos to Ben for tanking through a rough semester and coming out with more knowledge for it.

However, there were many ways in which this project went fantastically:

1) Everyone seemed really enthusiastic about the game itself. This is perhaps the most important part because it made us settle our differences and pull through.

2) The art looked really cool. Although there were complaints about the fact that sometimes our game looked "like a petri dish" because of the germ-like appearance of a few of the enemies, our art was more animated than many of the other teams. In addition, there were less glaring issues of collision and weird mis-placed objects than in some of the other games. It flowed together relatively well considering the limited amount of time.

3) Logan REALLY came through on sound. I was skeptical of his ability to deliver because of some breakdown in communication along the way, but in the last week he delivered some fantastic audio tracks that really brought the game to life!

4) Our game worked! Corey did a bang-up job on programming considering he had no formal training in it.dWe managed to put in about 90% of the mechanics (both gameplay and feedback) that we intended to at the outset. We probably could have refined our scoreboard to help promote the theme of our game a bit more, and we certainly could have tightened up the code and the Vector art framerate issues. However, most of the other projects were either completely non-functional or lacked the fluidity/tension necessary to instill the player with a feeling of enjoyment. Translation: some of the other games just weren't very fun. Ours was, so I was very pleased.


The Game

The jist of Clash was that it was essentially a two-player co-opetetive (yes, you are both working together and in constant competition with your ally) game based loosely on the Asteroid mold. Each player has a ship that can run into objects pointy-end-first to deal damage. Players can hurt or help each other, but actually benefit from fighting occasionally since a cumulative slow effect will gradually limit their effectiveness unless they attack one another. Some enemies require teamwork to destroy and enemies spawn fast enough that one player will have difficulty keeping the screen clear.

Eventually the players are overwhelmed, so they must make a decision (verbally or internally) to help or hinder each other. Killing the other player usually results in a low survival time but high personal score, whereas helping the other player throughout the game usually results in a long survival time but a mediocre score for both players. This game plays similar to the prisoner's dilemma because the optimum score/time can be achieved by backstabbing the other player towards the end of the game. Although the game itself was buggy, had a terrible framerate, and did not have 100% of the features we had hoped, it still succeeded in testing the fundamental nature of its players.

The entire game revolves around the "Clash" mechanic, which is the core of the conflict which occurs in the space. Whenever one player touches the other player, a discordant note sounds, the music picks up to a heated pitch, and both players start blinking violently. At the same time, the score boards on either side of the screen slam together and begin sparkling as they grind against one another. Players can only harm one another while "Clashing," so a sneak attack is ineffective unless a player is pinned in a corner. Players can "resolve" a clash in multiple ways. They can attack one another, which is difficult because the two avatars are matched in speed and maneuverability. Alternatively, they can stay apart from one another... eventually they will "cool off" and the music will die down. Finally, they can quickly resolve their clash by working together to defeat an enemy. These three options are metaphors for conflict between people in a shared space.

Because the player is not specifically instructed on the nature of the Clash mechanic, the way they interpret these queues is indicative of personal psychology. Players who have played several times may notice that over time their ship gradually loses speed. This was to simulate the "stress" that builds up in a relationship. In order to release stress, the players must clash, which restores their movement speed. Regardless of how the clash is resolved, the speed will be restored, so it is up to players to figure out whether they want to use this mechanic peacefully.

We sat a few of the students and teachers down to play with one another without giving them instructions. This was intended because the controls are flashed briefly on the screen and the rest of the mechanics are communicated both visually and audibly. The intention is that players "figure out" what they are "supposed" to do. There is no way that you are "supposed" to play the game, so their choice is deeply reflective of their approach to a shared space. When we pitched this idea originally, most people were skeptical if the actual game would bring out this deeper meaning. Even some of the people who played the game said that they did not necessarily think that this was a reflection of their personal psychology because "what we were supposed to do was obvious." In a vacuum, these results would have disappointed us, but in the end we were pleasantly surprised to find out that we were indeed successful:

The Results

Each playtest of randomly paired bystanders (hereafter referred to as "players") approached our game with a completely different playstyle. However, each insisted that the way to play was "obvious" and that it left very little room for interpretation.

Our professor, who is normally a very modest speaker but who is secretly a highly competitive gamer, immediately attacked the two people we sat down to play with him. In fact, the first confrontation was between him and one of the more outspoken students, and they attacked each other within seconds of seeing the controls appear on the screen. Both of them claimed the game was competitive, and both of them died within a minute or two of the game starting because they were so weakened from fighting each other they could not handle the enemies pouring onto the screen.

Our next test pitted two of the less aggressive students in the class with each other. We selected people from the same team so that they would already have experience working with one another. The results were radically different! They never fought each other at all, but proceeded to systematically destroy all of the enemies that came onto the screen. They lasted for several minutes, but eventually died when the boss appeared (this actually caused some serious framerate issues because we used too much Vector art and the redraw time was insanely long). The two players claimed that it was clearly a co-operative game because there was no way to keep the enemies off the screen unless the two players worked together.

Finally, we tried a series of other pairing, each of which resulted in a different results. My personal favorite was the one where neither player thought about touching one another until their second game. The first game they played cooperatively until they were overwhelmed. The second, they brushed up against each other by accident and activated the Clash mechanic. The moment they heard the change in music and the visual conflict of their scoreboards, they turned on one another. Even though they had already played cooperatively with great success, they quickly took the queue to attack one another.

We decided the game was a great success, and I personally would like to return later to tighten up the script (the designer who programmed the game had little experience in Actionscript but did admirably well considering this fact). I have since come to have much more experience with AS3 (actionscript 3), so I should be able to improve on his success if I get the free time and motivation to do so.