The Benefits of Working with an Additional Producer

Before our first prototype, I was weary of working with another producer on our prototypes. I figured, since the prototype assignment consisted of small teams of five and the prototype was to be completed within a short amount of time (only four weeks), that having an additional producer would be more detrimental than beneficial to the final product. However, after three prototypes and now beginning a forth one, I am seeing the error in my perspective and realizing how important it is having an additional producer on the team. In this blog post, I will outline three reasons why having another producer is valuable in the game development process.

The Obvious: Sharing the Workload
One apparent benefit to having more producers is spreading the workload. At the beginning of the semester when we barely knew what a video game producer entailed, having a second producer didn’t appear essential since there was little work we completed. However, as we moved throughout the semester and learned the process of being a video game producer, the workload increased exponentially. This caused having an additional producer helpful to the process. With the need to create and maintain a backlog, pitch our game, compose one-page pitch and game design documents, and assist our team whenever help was needed, these instances demonstrate how important having another producer is in helping completing such assignments. Thus, it would be too much for one person to accomplish all the work of a producer.

Compensating for Strengths & Weaknesses
One aspect that has crept up during my time as a producer is realizing my strengths and weaknesses within my role. These aspects can be exacerbated and become exposed when working alone. With that, it is great having a fellow producer that is able to compliment aspects of myself through his/her own strengths and weaknesses. This can make production more efficient and effective over the long-haul. Now both can use their talents to help the team with the game.

The Producer Cabal
This leads to my last point: producers can discuss challenges and problems together in order to better address these concerns. This idea came full circle during our last prototype when I was working with my fellow producer. During the ups-and-downs we experience, we did our best to discuss challenges that were affecting the prototype and used this brainstorm to learn how we could effectively address them. The additional producer thus aided in working together to solve problems while at the same time ensuring team cohesion.

Having additional producers can be a great asset for the team. I have learned throughout my first semester the benefits of having an additional producer. As much as I felt it would be better working alone, I have seen the error in my thinking and now understand how valuable a fellow producer is in creating a prototype. I hope moving forward into projects, and eventually our thesis game, that I can use what I learned from working with another producer so that we can make the best possible game.

Postmortem for Prototype 3: “Get the F@#* Off My Lawn!”

0Map

Game’s early artistic design

This round of prototypes was very much a learning experience. There were times in which various obstacles pushed our limits of our team. Nevertheless, in the end I was happy to see our game finally realized in a fully functioning prototype in spite of the challenges we faced as a team. This postmortem therefore will detail the aspects of the prototype that led to my successes as a producer as well as aspects I can improve on moving forward into our last prototypes of the semester. Although this time around proved to be a challenging endeavor, I know it will be beneficial for myself in becoming a successful producer.

From the beginning, we experienced challenges. To begin, creating the idea for this game was tricky. In order to generate ideas for our prototype, we were required to use design cards that outline concepts to drive ideas for games. We were also tasked with using Dr. Altizer’s Design Box method in order clearly characterize our game and use it to define “indie” games as an audience. The Design Box and concepts behind indie helped us to generate game ideas, but we fell into the trap of attempting to fit a game into the requirements for the prototype. This led to our team struggling to produce a game idea that corresponded with the task while at the same time ensuring everyone was excited to create it. As a result, we spent the first two days wrestling to come up with a viable game idea.

Our first concept for a game produced excitement for the team. However, I became worried about the scope. To begin, initially our scope appeared too grand. We originally aspired to make a 3-D open world game in which the player is trying to make it home after a night of Trick or Treating. Thus, my thoughts were that this was too ambitious for a four-week prototype. Furthermore, we failed to do our research to see whether there was a similar game concept. After pitching our idea to both Amy and Corrinne, we discovered that our initial design was similar to a previous game. This led to feelings of anxiety since we had only a day left to meet the requirements for the assignment and pitch it the next day.

From our desperation, when speaking with the other producer on our team, I developed an idea that incorporated both the Halloween theme our team were fond of but smaller in scope than our initial design for a prototype – more on this later. Thus, we decided to create a tower defense game in which a person plays as a grumpy old man who is trying to prevent Trick of Treaters on Halloween from disturbing his rest. This took our earlier ideas we had and made it more palpable for our team.

IMAG0349

Postmortem board of prototype 3

Even though I believed this new direction would control scope, this proved to be much more of a challenge for us as a team. We had no idea the difficulties that came with making a tower defense game. In other words, as much as tower defense games appear simple in design, there are many design decisions and level design challenges that we needed to address in order to make a fully functioning game. Because we did not mitigate the notion that tower defense games take time to design and implement, we fell behind with our work in which we never truly recovered from.

Falling behind affected team morale. As a result, it created disagreements with some member’s suggestions, which became exacerbated as we strived to build a working prototype. At times the team differed on game mechanics, gameplay ideas, and thematic conceptions. Even semantics fueled discussions that impeded our progression. This pervaded throughout our time working together and hindered our movements forward with the game and its mechanics.

This instance demonstrates successes and challenges I experienced as a producer. I feel that I was able to urge our team to explore potential ideas before marrying a game idea. However, at times my team appeared to take a defensive stance when I questioned some individual’s ideas. I like asking questions to help a person flesh out his/her ideas, but at times some may see this as a means to dispute his/her concepts. I know moving forward I need to express to the team that my desire is to get us to explore the ideas from every direction so that we can build the best game and avoid groupthink that can suffocate creativity. I hope to take charge of this notion in my next prototype.

“If you have a positive attitude and constantly strive to give your best effort, eventually you will overcome your immediate problems and find you are ready for greater challenges.”  — Pat Riley

The disagreements furthermore led to poor communication among the team. This began when we first attempted to find ideas for a game in which we all thoroughly liked. Since we struggled to generate prototype ideas and effectively discuss them, this led to our team feeling a bit reluctant to communicate his/her ideas openly. Considering this experience, I need to be much more effective in creating an open environment in which everyone’s ideas feel valid. I attempted to create open discussions, such as desiring to take time to address questions and comments that came about during our weekly review with the faculty, but the damage was already done and some teammates were not willing to discuss it further. Nevertheless, I need to nip this problem early and find more effective ways to maintain team cohesion, but at the same time still picking their brains so that we can make the most effective game possible (rather than solely focusing on team cohesion).

Despite these challenges, I also had some additional notable successes along the way. Our artist Tyler Ricks gave me and my fellow producer, Topher Nadauld, a tutorial on using Maya. I thoroughly enjoyed our brief time learning the tricks to creating art assets for our game. It definitely gave me a clearer perspective as to what goes into creating art assets and the time it takes to produce them. Furthermore, as noted in a previous post, I created a game design document for our game. The GDD I feel gives the team a clear picture of our game, keeps our team focus on these ideas, and helped me to develop our one-page pitch document and subsequent presentation.

Although this prototype was challenging on many fronts, I feel that they helped provide me clearer perspective to myself as a producer and how I can be more effective in the future. As the great NBA coach Pat Riley once said, “If you have a positive attitude and constantly strive to give your best effort, eventually you will overcome your immediate problems and find you are ready for greater challenges.” This is direction I plan to take going forward so I may become a successful producer.

Learning the Importance of being the Advocate for the Player

Throughout the semester, our production class instructor Amy Atkins has constantly reinforced the idea that one of the producer’s principle roles is to be an advocate for the player. Since most development teams are deeply invested in a game’s creation, therefore knowing every facet of the game, it is easily to overlook how the user will experience the game. This idea came full circle for me when on Tuesday we discussed games that did not live up to our expectations because of how a game was marketed. From this discussion, one lesson we learned is that in some instances games suffer because there are no one viewing the game from the perspective of the player.

To clarify this idea, in class we discussed EA’s latest release of Sim City earlier this year. SC is a beloved franchise that places the player in the role of managing a city. SC is addictive (my wife was quite found of Sim City 2000 and played it religiously) and fans of the game waited a decade for a new iteration of the franchise. However, what EA seem not to foresee is the user base and how they would react to the new version of the game. In our discussion, Amy noted that in an attempt to reach a wider audience, EA reimagined the player as gamers who enjoy playing Facebook games online for no more than a couple of hours.

What they overlooked therefore were the core SC players how they like to consume the game. These gamers typically play for hours on end without the need of an internet connection. As a result, when they released the game, some hardcore SC gamers were outraged with the product, especially since it demanded a constant online connection. EA essentially developed a game with the desire of gaining a broader audience and thus overlooked the principle consumers of SC. And in the end, this effort hurt the IP and its chances of moving forward with new SC games.

This case study illustrates the need for the producer to act as the voice for the player. The producers of SC could have taken a step back to see how it would affect the player and his/her enjoyment of the game. There was no one being a voice for the player. Ultimately, no one focused on the core user but instead on a player base that were not traditional SC consumers.

In such instances, even when a team is invested in a specific feature or game mechanic, the producer needs to effectively assist in determining what the user will enjoy and how it will enhance their experience playing the game. Without a voice for the player, the money and time devoted to the game is wasted. This philosophy provides the team with someone who can play devil’s advocate and suggest what may or may not work. Thus, it is important to have the producer visualize how the audience will enjoy playing the game.

I love this image!

As a result, I have taken this concept to heart. Every prototype we have created thus far, I have attempted to see the game from the eyes of the player. Although my perspective is an assumed viewpoint, my goal is to provide an avenue for asking questions in our design and intentions. These questions help distinguish the user experience and how our game may satisfy this audience. Afterwards, I bring these concerns to the team so that we can address these questions and conscientiously consider the user’s perspective. It therefore helps with the game design enabling us to emphasize what makes the game enjoyable for the player. No longer are we only observing the game through our own biases but aim to capture the game from the player’s viewpoint.

Being the advocate is a tough job for any producer. But in the end it is probably one of the most rewarding. It is consequently challenging acting as the voice for the player, especially when someone invests in an idea or feature. However, in the end it compels the team to see the game through a player’s eyes and therefore allows for creating a more enjoyable game.

 

Recognizing the Importance of a Game Design Document (Even in Rapid Prototyping)

Last fall I enrolled in the EAE’s Game Design I course as a means to supplement my doctoral studies (which as you know I left to pursue my dream of a career in the video game industry). In this class, our final project was to envision a game and afterward compose a game design document (GDD) to explain details of the game. From this experience, I discovered that it demands significant time to write a proper GDD, and as a result, I couldn’t imagine composing one for our four week prototypes. Despite this position, for our first prototype, I attempted to create a GDD, but since I followed the same basic format I used in my earlier game design class, it proved to be too large of a task to tackle and thus I abandoned the notion.

However, last week after listening to others in our production class describe how the GDD has been enhancing their work, I decided to reconsider utilizing a GDD for this round of prototypes. And after finding a template for composing a condensed GDD on Gamasutra, it has made the idea of not using one irrelevant. As a result, I created a GDD for our game. And through my brief time utilizing it, I am discovering the benefits of employing one for our prototypes.

Keeping Focused
One key application I have noticed is that using a GDD enables the team to maintain focus on a common outlook for the prototype. Throughout the semester, I observed that there are times when we lose a common vision for the game. This can therefore impede the development of the prototype since team members may not cohesively be able to visualize the primary mechanics and features of the game.

Thus, a GDD theoretically can overcome such problems and provide a foundation for the prototype. Now, everyone can use the document to understand the fundamental concepts for the game and what can be done to ensure the vision is completed while at the same time being flexible to adjust the chosen features.

Helping Non-Native English Speakers
An additional argument for implementing a GDD is that it can help non-native speakers. To clarify this idea, a team in our production class recounted how they desired to create a GDD to help communicate more efficiently with a non-native speaker. They found by using a GDD, it helped this person better able to understand the game, enabled him/her to provide more input into the game, and therefore created a mutual vision for the prototype.

Since each team I have worked with thus far has had at least one non-native English speaker, I feel that using a GDD is essential for clarifying ideas behind the game for non-native individuals while fostering stronger team synergy. Furthermore, this allows the person to better participate in the creation of the game since now they have something to reference. For example, I know that I tend to speak fast and move from one idea to the next in a blink of an eye. Consequently, I can see why a non-native speaker may have difficulty in following my train of thought. And although I am aware of this shortcoming, I can use the GDD to help overcome any misunderstandings caused by my vocal rate since now a person can refer back to the GDD to clarify what’s been discussed while at the same time provide them an avenue to respond.

Assists in Visualizing the Pitch for the Prototype
With the final presentation for our prototype a little over a week away, after composing our initial GDD, I am realizing how it can be used as a model for our pitch. As a producer, at times it can be easy to shelf working on the final pitch in favor of other responsibilities. This can place formulating the presentation at the back end of my priority list. Nevertheless, the GDD creates an easy and time saving way to access information that may be important for the presentation. Having a document that clarifies the description of the game, core mechanics, features, and art therefore enables us easily to use it to create an accurate pitch for the game.

Although I have just begun using a GDD for our rapid prototyping class, I am beginning to see how this is a tool I will continue to utilize going forward. I hope that using a GDD will enable the team to stay focused, help communicate better to non-native speakers, and assist in the development of our game’s pitch. My ultimate desire is to use my time in the EAE program to perfect using the GDD.