Now that Production 2 is finally over, I feel that it is a good time to take a look back on the Spring 2010 semester while its still fresh in my mind. Since this class was substantially more demanding and complex than production 1, I will devote several rapid-fire posts to explaining how the semester went.
This post will be about the people in the class and what the class is about.
The Class
This semester I was studying abroad in Montreal, so the class size was quite small. There were about 14 people in the class.
The goal of the class was quite simple: each team of 3-5 people must produce a refined vertical slice by the end of the semester. No holds barred!
Because this was Montreal, there was substantially less oversight by the instructor. This is due to the fact that the instructors in Montreal are industry professionals first and teachers second; they do not baby us at all.
The Instructor: Guillaume Langlois
His day job is working at Space and Dream, a company that specializes in interactive installations.
He has a reputation among students for expecting more than is technically possible in a semester. This is both a blessing and a curse; he will let teams tackle challenging projects with little interference, but will also expect miracles where none should be expected.
I must preface this by saying that I deeply respect Guillaume as a teacher, so any criticisms that follow are merely to serve as a backlight for the various hurdles we overcame throughout the semester.
His PROS:
Guillaume is a master at pushing students to the limit. He demands the best all the time, so nobody in their right mind would try to pass his class with less than 100% effort.
Guillaume is all about results. You can't bullsh*t past him with words or documentation. This can be frustrating at some times, but nobody passes his class without something to show.
His CONS:
One of the most frustrating aspects to Guillaume's class is that he can look at something that was incredibly difficult to accomplish and dismiss it as if it were sub-par or expected.
On top of this, Guillaume has a habit of judging only the visual elements of a project. He dismisses programming accomplishments unless they have a visible impact on the game (tightening code or streamlining class structure doesn't count). As a result, he acts as though design does not exist until it has been implemented and often attributes things which were designed, scripted, or programmed as "a good job by the artists."
He has a knack for making team members depressed because he tends to focus on the "stars" of each team and attribute success (or failure) to them.
The Students
PRODUCERS:
Alison Seffels - One of the only two students in the Design major to also specialize in business management. She is aiming for a career as a producer, and is thusfar the most talented and organized project manager in the year. Alison has the best time management skills of anyone I know, and is usually all over her team like white on rice.
Dan Porter (me!) -The other of the two students in the Design major who is also specializing in business management. Alison and I have all of the same classes and have similar career goals. Between the two of us we have had the most experience (I will make no assessment of talent, as this would be biased) in team leading of anyone others in our major. I have a great deal of experience with programming/scripting and often pitch in when necessary.
Chris "Chief" Ferguson - A designer with aspirations to lead, Chris took up the mantle of producer this semester. He is the "nice guy" of the class. Chris went from meek to assertive overnight as he was pitted against the difficulties of a lead.
ARTISTS:
Chris Siroonian - An artist with a penchant for Steampunk, his notebooks are covered in robots. Chris was one of my roommates this semester. His 3D art pieces are quite impressive.
Ben Gerowe - A 3D artist who originally applied to the college as a Designer but wound up in the Art degree. He started two years ago with little ability in creating art and has transformed into a 3D-making-machine over the past year. He is constantly comparing himself to other artists which causes him to perpetually push himself harder.
Logan Dwight - A powerful personality, Logan is the least likely to back down of anyone in our class. He proactively goes after what he wants, and plows past any obstacles in his way. Logan tends to be more of a "high artist" in the sense that he always aims more for an "experience" than a purely entertaining piece. Logan's strength lies in graphic design rather than 3D, and his UI designing/arting abilities are second to none.
Ben Rogers - A softspoken but hard working artist, Ben gets the job done. He is a powerhouse of work ethic and will not hesitate to stay up late completely redoing something that needs to be reworked.
Josh Terry - Josh spent his first year at Champlain studying game design, but when he took Intro to 3D Art as a class, he was seduced by the dark side of the EGD majors: ART! He is one of the most talented 3D artists I know because of his sheer anal retentiveness. Josh is all about the details. Because of his training as a designer, Josh is also uniquely able to relate to the other team members who are not artists. Josh is the rock in any design argument, refusing to be swayed by any biased opinions.
DESIGNERS:
Dustin Dano - A talented systems designer, Dustin is a veteran tabletop gamer. He grasps even the most complex mechanics in a heartbeat. Dustin is an easy going designer who tends to agree with the group, but always weighs in with his analysis of a decision.
Corey Moore - A working machine, Corey completely ignores whether or not he has done a task before when tackling something new. He can learn a scripting language in a few days and crank out functionality like nobody's business.
Tom Triplet - A quiet designer with a head full of ideas, Tom usually waits till the end of a discussion to stir things up. He is a dedicated worker who plugs along when others would be lax.
Karl Markis - He is Karl. There's not much more to be said than that. I won't get into Karl because I couldn't begin to describe what a unique individual he is.
PROGRAMMERS:
Bryan Hare - A guy with an insanely accurate memory for the most obscure programming facts, Bryan is the type of guy that remembers a seemingly useless function for a year before saying "Hey, I think there's something that can do that in the library" at just the right moment. Bryan is good at communicating on a team, and will contribute to design decisions one way or another.
Steve Beaulieu - The most talented programmer in our year, Steve is the most pragmatic person I know. He tackles each task in a systematic fashion. Steve has more communication and time management skills than any programmers in our year, so he breaks the stereotype that programmers tend to get.
Tuesday, July 6, 2010
Monday, July 5, 2010
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.
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.
Subscribe to:
Posts (Atom)
