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.
Monday, April 5, 2010
A Discussion of DOTA - Part 1
As a Warcraft III player and modder, I have to give credit where credit is due. Defense of the Ancients, or DOTA, is the most popular map for Warcraft III. To my knowledge it is also the only map that has ever prompted a mod-specific bugfix in a patch (one Blizzard patch actually read "-Fixed a DOTA related sound bug").
Anyway, DOTA has spawned many spin-offs, and has become a staple format of RTS mods. Today I will discuss three major versions of DOTA: the original DOTA Allstars (a map for WCIII), Heroes of Newerth (a standalone spinoff by S2 Games), and League of Legends (a standalone game created by Riot Games, which is a company started by the makers of DOTA Allstars). Another spinoff exists called Demigod, which I have not played (so I will not comment on it).
This post will go into some of my thoughts behind the design of these spinoffs and relate them to the original DOTA Allstars. The reason that I include DOTA is so that we can see the various problems/solutions that exist in each of the incarnations of this classic RTS format.
This is Part 1 of my little analysis of the three games. This section is mostly informative. If you haven't played DOTA, Heroes of Newerth, and/or League of Legends, I suggest you read this first so the rest of the post makes sense.
DOTA
---------
For those of you who don't know, these are the basic elements of classic DOTA:
(Skip this part if you already know how DOTA works)
Heroes of Newerth
--------------------
This game has essentially identical mechanics to the original DOTA. In fact, most of the heroes are direct copies of those that existed in DOTA, but with new names, appearances, and flavor.
Most of the differences between DOTA and Heroes of Newerth lie in the differences between the UI and lobbying systems that existed in Warcraft III. "Heroes" has absolutely fantastic art and special effects, which gives it a more polished look and feel than its counterparts.
Here are some of those differences:
League of Legends
-------------------
This game has a very cartoony atmosphere. Most of the units have exagerrated proportions and wacky coloration. The mechanics of this game are much different from the other two DOTA games. In addition, players are rewarded at the end of each game with points that will effect their ability to play in future games. Heroes in League of Legends are known as "Champions"
Anyway, DOTA has spawned many spin-offs, and has become a staple format of RTS mods. Today I will discuss three major versions of DOTA: the original DOTA Allstars (a map for WCIII), Heroes of Newerth (a standalone spinoff by S2 Games), and League of Legends (a standalone game created by Riot Games, which is a company started by the makers of DOTA Allstars). Another spinoff exists called Demigod, which I have not played (so I will not comment on it).
This post will go into some of my thoughts behind the design of these spinoffs and relate them to the original DOTA Allstars. The reason that I include DOTA is so that we can see the various problems/solutions that exist in each of the incarnations of this classic RTS format.
This is Part 1 of my little analysis of the three games. This section is mostly informative. If you haven't played DOTA, Heroes of Newerth, and/or League of Legends, I suggest you read this first so the rest of the post makes sense.
DOTA
---------
For those of you who don't know, these are the basic elements of classic DOTA:
(Skip this part if you already know how DOTA works)
- Each team consists of 5 players, each who controls a single, unique, hero unit.
- Each hero has three basic abilities and one "Ultimate" ability.
- Each hero has six item slots which can be filled with a variety of powerful items which can completely change the heroes effectiveness in combat. Some heroes have many different "builds" or combinations of items which make them effective in different situations.
- Each team has a "base" which they must defend. The goal of each team is to destroy the primary building located at the rear of the enemy base. They must destroy most of the enemies buildings to do this.
- Bases are located in the lower left and upper right corners of the map. Between the bases are three "lanes" which are large swaths of open area where most combat occurs.
- Bases periodically spawn weak units or "creeps" which which belong to the computer AI and will progress down the lanes mindlessly combating enemies in their path.
- Each lane has 2 towers per team that are in the field and a single tower which is located at the entrance of the base. Enemies must push past these towers to reach the base from that lane.
- Players must use their heroes to turn the tide of the combat my destroying enemy creeps, heroes, and towers.
- Killing enemies yields money and experience. Experience will eventually level a hero, making it more powerful and allowing it to learn more powerful versions of its abilities. Money (gold) can be used to purchase items for the hero.
- When a hero dies, that player loses a certain amount of money and must wait for respawn. Respawn takes between 10 seconds and 2 minutes depending on the level of the hero
- Each lane has two barracks located in the base of each team. One representing melee, the other representing ranged units. Destroying a barracks will PERMANENTLY buff the creeps in the opposing teams army. Most "pro" players acknowledge that destroying the melee barracks first yields a more significant advantage as there are more melee units spawned in each wave than ranged ones.
- This game is a free download
Heroes of Newerth
--------------------
This game has essentially identical mechanics to the original DOTA. In fact, most of the heroes are direct copies of those that existed in DOTA, but with new names, appearances, and flavor.
Most of the differences between DOTA and Heroes of Newerth lie in the differences between the UI and lobbying systems that existed in Warcraft III. "Heroes" has absolutely fantastic art and special effects, which gives it a more polished look and feel than its counterparts.
Here are some of those differences:
- Uses chat "channels" which are essentially lobbies in which players can talk while not in-game. This is similar to WC3.
- Players have a toggle-able overlay which gives them access to player statistics, a friends list, a messaging system and a few other features. This can be toggled even in-game, similar to the way the Steam overlay works.
- Has built-in voice support, allowing players to talk to each other without the need of third-party software like Ventrilo.
- Games are created and joined by users, similar to WC3, where a user must search for a game and join it manually. However, Heroes also features a ladder which is done by a match-making system.
- Players are given a Public Skill Rating or PSR. This rating increases when winning ranked games, and decreases when losing them. The amount of gain or loss is determined by which team has a higher average rating (the underdog stands to win more and lose less). This rating, combined with extremely accurate statistics logged on each player, allows players to discriminate when choosing whether to play with a given team. Both PSR and statistics are publicly available to other players.
- Players who leave a game can reconnect, unlike the original DOTA. If they do not, however, they will be considered a "leaver." Any time that a person leaves a game without returning this event is logged in their personal record. Other players can see how many games a player has left and some game types will actually prohibit players with a high leave % from joining the match.
- Unlike the original WC3 UI, Heroes of Newerth is designed specifically for playing the DOTA style map. Abilities are clearly displayed and use customizable hotkeys to allow the player to easily use them. In addition, the shop system allows players to purchase items and keep them in the base even when they are not nearby.
- Heroes of Newerth released a second map, called the Watch Tower, which is different from the layout of the original DOTA. However, many players in the community avoid this break from tradition.
- When one player lags, the others can keep playing, unlike WC3
- The game is purchased once for a flat $30
League of Legends
-------------------
This game has a very cartoony atmosphere. Most of the units have exagerrated proportions and wacky coloration. The mechanics of this game are much different from the other two DOTA games. In addition, players are rewarded at the end of each game with points that will effect their ability to play in future games. Heroes in League of Legends are known as "Champions"
- Players must "unlock" heroes to use them. Each week there is a selection of free heroes that all players are able to use.
- A player's account is considered to be a "Summoner" which is way the player is represented in the fictitious narrative of League of Legends. The "Summoner" actually summons the hero which serves as the player's avatar in the game. The player may increase the level of their summoner, which is different from the level of each hero within the self-contained loop of a single game. In other words, a player can be Summoner Level 30, but will still begin each game with a level 1 hero. However, a player with Summoner Level 30 will have many advantages that a level 1 summoner would not have.
- A summoner has a selection of unique summoner abilities (the full range is unlocked by level 12). Each game, the player may select two of these abilities which can be used to supplement the abilities of the hero they choose. Summoner abilities have a longer cooldown and are usually used for utility within the game space.
- A summoner has a rune book which allows them to gather up to 30 runes (1 slot is unlocked each level with a level cap of 30). These runes grant minor bonuses to the hero and is one of the primary means of "speccing" or customizing a hero. Runes are chosen before each game starts.
- A summoner has a set of Masteries, which work similar to the World of Warcraft talent system, allowing for specialization in offense, defense or utility. The summoner gets 1 mastery point every level with a max level of 30.
- Each game yields the player summoner experience and IP, which is used for purchases in the Store.
- Players are matched solely on a match-making system, although players can Friend other players in order to play arranged matches later.
- The Store can be used to buy new Champions, Skins (new appearances for champions), Runes, and Boosts which increase the experience/IP earned for a period of time (measured in days).
- Boosts and Skins can ONLY be purchased with "Riot Points" which are obtained through micro-transaction. (This is important... I will discuss the business aspect of these games as well). Champions can be purchased with both Riot Points and IP. However, RUNES may never be acquired with Riot Points, so no player may "buy" a combat advantage over another.
- This game is free to download and play. In addition, ALL champions and runes can eventually be unlocked through gameplay. However, players may purchase Riot Points which can be purchased through micro-transaction, which allows them to purchase champions. There are champion Bundles, effectively allowing a player to "buy" the game by unlocking most of the heroes in one pack. A transaction of $30 can buy one of these bundles, and there are two to choose from.
- All heroes have the ability "recall" which is a free teleport back to base. In other versions of DOTA teleporting could only be achieved by items which were expensive or expendable.
- All heroes have two summoner abilities, allowing them to have a total of 7 different abilities.
- Each map has many patches of "Grass." These thick areas of foliage provide a unique advantage over the opponent. Units inside grass are invisible except to other units inside the grass. However, they can see outside easily. This mechanic adds a completely new dynamic to normal RTS gameplay.
- Very few items have activated abilities. This means that most items only give passive enhancements to a players existing abilities.
- League introduced a new stat called "ability power" which is effectively the same as +damage but applied to spells instead of auto-attacks instead. This is important because it changes how casters scale with level (previously they tended to be very underpowered late game because of their reliance on set-damage abilities). However, League allows several casters to "carry" the game by being able to dish out increasingly large amounts of damage.
- Heroes tend to move very slowly compared to their vision radius. This sounds strange but its true. The reality is that in DOTA or Heroes of Newerth it was often easy to run at an opponent and disable them quickly. In League, most heroes can simply back up unless they are caught in an ambush or flanked.
- There are very few stuns in League of legends and many many slows. It is usually impossible to "stunlock" someone, but very easy to keep them from running away.
- There are NO "proc" stun items in league, nor even proc stun abilities. In other words, there are no heroes which can stunlock opponents by themselves for more than a few seconds.
- The damage scaling compared to mitigation and health makes it so that it is highly unlikely that a single hero can kill more than three or four enemies alone. This is different than DOTA or Heroes where many heroes can reach a "critical mass" where they can literally take out a whole team of enemies.
- Instead of barracks, League of Legends features "inhibitors" which prevent the enemy from spawning "Super Minions." Destroying an inhibitor gives a massive advantage to the other teams minions because they will have large tank units to accompany them. However, unlike DOTA and Hereos, inhibitors can respawn.
- Teams who are losing can surrender at 25 minutes of game time. This is based on a voting system and happens quite frequently when one team is out-matched.
- There are only 3 units that can become invisible in League, as opposed to DOTA and Heroes where there are many assassin units. Although invisibility is powerful, there are some games where it never comes into play at all.
Introduction
Since I just set up this blog I think its best to introduce myself and give a brief summary of how I came to this profession (and because it would seem silly to write retroactive blog posts for all the things I've done the past few years).
My name is Dan Porter. I was raised in an un-extraordinary suburb outside of Atlantic City, NJ.
Whats more important is that at some point I realized that I loved video games. Not just playing them, but making them.
I first started modding Starcraft, but probably spent the most time working with Warcraft III towards the end of high school. One day over the summer of junior year I started working on a map. I got sucked into it and ended up spending 3 sleepless days cranking out Cowicula's Wilderness Survival, one of my most successful maps. I decided I try to go to college to learn how to make games, which at the time was a pie in the sky dream. I did a bit of searching and discovered that not many schools offered a legitimate program in Game Design... most schools tend to teach students Maya/3DS Max and C++ and then call them game designers.
I discovered Champlain College by accident. The school was fairly remote, and not many people think of Burlington, Vermont as a tech center. However, the school did offer a 4-year bachelor's degree in game design, which was rare since many schools focus on 3D art and programming.
When I arrived at Champlain for my Freshman year I was surprised to find that their program was actually about game design. Rather than learning how to model or code, I was being taught about design principles, game mechanics, scope, and flow.
At the end of Freshman year, I found out about an obscure department in Champlain College called the "Emergent Media Center" which was apparently exploring serious games and other interactive media development. I applied for a job which turned out to be one of the best decisions I've ever made.
I worked over the summer on the Information Literacy Project. Our goal was simple; create a Flash game that would teach incoming college students about Information Literacy (just google it, its basically a more general term for researching information and using it). I was working on a team of about 8 people: a producer, 3 game designers, 2 programmers, and 2 artists. In 3 months we created a substantial design document and a working prototype of the game. We ended up continuing into the school year making a better prototype to satisfy our clients (the Champlain College Library in this case). The project was then shelved for a semester while the EMC focused on other projects.
In the mean time I worked on the IBM Open Worlds project from the fall of 2008 through the summer of 2009. We had a non-disclosure agreement so I can't go into detail. Suffice to say we worked on "exploring virtual worlds business management solutions." Spoocat.
About a year later, after doing lots of secret stuff for the IBM project, I returned to the Information Literacy Project as the which started back up again in September of 2009. Although I was a designer on the project previously I was given the position of Assistant Project Manager, which was essentially a producer role working directly under the staff supervisor, Ray McCarthy Bergeron. Ann DeMarle, the director of the EMC, had asked us to produce an iPhone game in the Unity engine based on the flash prototype we had made the year before. We familiarized the new team with the design of the game and defined our pipelines for production. Unfortunately, I could not pass up the opportunity to study abroad in Montréal (a veritable Mecca of game development). For those of you who don't know, Montréal is home to several studios for major game companies including EA games, Ubisoft, Eidos, Artificial Mind and Movement (A2M) and several others. Anyway, due to my semester abroad I had to hand off the project lead position to James Fraina, a senior game designer who was working as Lead Designer during that phase of the project.
In Montréal I have a lot less on my plate in the way of game production simply because I can't work at the EMC from up here. However, it has provided a plethora of learning experiences I couldn't have gotten anywhere else, including some crucial insight into how the game industry works (not to mention networking opportunities). Perhaps the greatest benefit of studying here is that my classes are taught by people who are currently working in the industry. I'd have to say the best insight to game design has come from my Advanced Seminar in Game Design teacher, Alex Hutchinson, who is currently a creative director at Ubisoft (he previously worked on titles such as Spore, Army of Two: 40th Day, and the Sims). On top of being an Aussi, he is probably one of the most intelligent and enthusiastic speakers I've heard, which makes listening to his rants absolutely fantastic. When it comes to game design, you name it and he'll have something to say about it. Another prominent figure is Genevieve Lord, the "boss" of the study abroad program and motherly figure to all of us game devs. Former industry producer, she has given some of the most sagacious advice on project management I've ever heard. We've also had quite a time in our Production II class, which has proven to be extremely hectic this year. Anyway this is still in progress so I will leave it for the rest of the blog.
That pretty much sums up the past 8 years of my life, so now that should serve as a bit of a back drop for the rest of my posts.
Thanks for reading,
-Dan
My name is Dan Porter. I was raised in an un-extraordinary suburb outside of Atlantic City, NJ.
Whats more important is that at some point I realized that I loved video games. Not just playing them, but making them.
I first started modding Starcraft, but probably spent the most time working with Warcraft III towards the end of high school. One day over the summer of junior year I started working on a map. I got sucked into it and ended up spending 3 sleepless days cranking out Cowicula's Wilderness Survival, one of my most successful maps. I decided I try to go to college to learn how to make games, which at the time was a pie in the sky dream. I did a bit of searching and discovered that not many schools offered a legitimate program in Game Design... most schools tend to teach students Maya/3DS Max and C++ and then call them game designers.
I discovered Champlain College by accident. The school was fairly remote, and not many people think of Burlington, Vermont as a tech center. However, the school did offer a 4-year bachelor's degree in game design, which was rare since many schools focus on 3D art and programming.
When I arrived at Champlain for my Freshman year I was surprised to find that their program was actually about game design. Rather than learning how to model or code, I was being taught about design principles, game mechanics, scope, and flow.
At the end of Freshman year, I found out about an obscure department in Champlain College called the "Emergent Media Center" which was apparently exploring serious games and other interactive media development. I applied for a job which turned out to be one of the best decisions I've ever made.
I worked over the summer on the Information Literacy Project. Our goal was simple; create a Flash game that would teach incoming college students about Information Literacy (just google it, its basically a more general term for researching information and using it). I was working on a team of about 8 people: a producer, 3 game designers, 2 programmers, and 2 artists. In 3 months we created a substantial design document and a working prototype of the game. We ended up continuing into the school year making a better prototype to satisfy our clients (the Champlain College Library in this case). The project was then shelved for a semester while the EMC focused on other projects.
In the mean time I worked on the IBM Open Worlds project from the fall of 2008 through the summer of 2009. We had a non-disclosure agreement so I can't go into detail. Suffice to say we worked on "exploring virtual worlds business management solutions." Spoocat.
About a year later, after doing lots of secret stuff for the IBM project, I returned to the Information Literacy Project as the which started back up again in September of 2009. Although I was a designer on the project previously I was given the position of Assistant Project Manager, which was essentially a producer role working directly under the staff supervisor, Ray McCarthy Bergeron. Ann DeMarle, the director of the EMC, had asked us to produce an iPhone game in the Unity engine based on the flash prototype we had made the year before. We familiarized the new team with the design of the game and defined our pipelines for production. Unfortunately, I could not pass up the opportunity to study abroad in Montréal (a veritable Mecca of game development). For those of you who don't know, Montréal is home to several studios for major game companies including EA games, Ubisoft, Eidos, Artificial Mind and Movement (A2M) and several others. Anyway, due to my semester abroad I had to hand off the project lead position to James Fraina, a senior game designer who was working as Lead Designer during that phase of the project.
In Montréal I have a lot less on my plate in the way of game production simply because I can't work at the EMC from up here. However, it has provided a plethora of learning experiences I couldn't have gotten anywhere else, including some crucial insight into how the game industry works (not to mention networking opportunities). Perhaps the greatest benefit of studying here is that my classes are taught by people who are currently working in the industry. I'd have to say the best insight to game design has come from my Advanced Seminar in Game Design teacher, Alex Hutchinson, who is currently a creative director at Ubisoft (he previously worked on titles such as Spore, Army of Two: 40th Day, and the Sims). On top of being an Aussi, he is probably one of the most intelligent and enthusiastic speakers I've heard, which makes listening to his rants absolutely fantastic. When it comes to game design, you name it and he'll have something to say about it. Another prominent figure is Genevieve Lord, the "boss" of the study abroad program and motherly figure to all of us game devs. Former industry producer, she has given some of the most sagacious advice on project management I've ever heard. We've also had quite a time in our Production II class, which has proven to be extremely hectic this year. Anyway this is still in progress so I will leave it for the rest of the blog.
That pretty much sums up the past 8 years of my life, so now that should serve as a bit of a back drop for the rest of my posts.
Thanks for reading,
-Dan
Subscribe to:
Posts (Atom)
