How Prototype #2 is Evolving My Perspective on Rapid Prototyping & Game Design


For our second prototype, our instructors decided to throw us a curveball – more like a knuckleball to be honest. At first, I wasn’t sure if it they were being masochists enjoying the suffering of their pupils. However, after explaining their rationale and after I took time to reflect on their decision, I am beginning to understand what they are ultimately trying to teach us this time around.

Our instructors noticed in our first prototype that many of us aimed at creating full games. As a result, they determined that we did not understand the fundamentals of rapid prototyping. In order to evolve our grasp of this concept, they decided to require the class to pick an early arcade game from the late ‘70s to the early ‘80s. This wasn’t because they were feeling a hint of nostalgia (well maybe). They implemented the requirement to have us use the chosen game’s core rule set as a foundation for our prototype. Our job was to add a new mechanic to the core rule set and consequently determine how we could manipulate the original design to produce new strategies for the player. In the end, they hoped we would make the primary rules more enjoyable and unique. And we had to choose a game, create a prototype with the game’s rule set, and add another mechanic to the design all in only one week. This forced me to rethink how I approach video game design and organizing our team.

Before moving on to demonstrate how this new process has evolved my thinking, I would like to clarify why they have chosen this prerequisite for our prototype. Our professors argued that in our last prototype we were creating “vertical slices” rather than performing rapid prototyping. Vertical slices are a form of prototyping that emphasizes showing off a portion of the game in way that represents the finished form. This takes more work to complete, but can be very persuasive when presenting the prototype to industry professionals.

However, this approach rarely provides the opportunity to show how the idea is enjoyable and doesn’t allow the team to experiment with game mechanics. As our professors noted, utilizing a vertical slice for a pitch the audience may not view what makes the game fun. This is dissimilar to a whitebox for the reason that it enables game developers to experiment with ideas and see what works. Furthermore, the team doesn’t have an opportunity to experiment with game mechanics and features because the team is focused on designing a game close to the finished product. Hence, rapid prototyping allows the team to focus on the core rules and determine if they work in reality. As Chandler noted in her book on game production, “It is better to spend a day or two (or even a week) prototyping key features of the game, than spend several weeks implementing a feature that ends up not working as expected in the game” (p. 147). Thus, rapid prototyping enables developers to focus on the “fun” (as Dr. Altizer would argue) and consequently gives developers a chance to test important features of the game.

prototyper_logoThis idea caused me to have to rethink how I view game design and production. In the past, I begin by taking a deductive approach to game design. In other words, I begin crafting a game by conceptualizing an overarching theme, and I use this theme to build the game. For example, for our first prototype I used a narrative theme as the foundation for the game. This allowed me to visualize how it would work as an entire game. I felt that by starting with a theme I could answer questions regarding motivation as well as argue for immersion for the player. I thus forgo beginning with gameplay mechanics and instead use thematic elements to design the game.

Therefore, this inductive approach to creating a game has forced me to focus on game mechanics, rule sets, and at the end of the day what makes a game fun. This method enables me concentrate on producing a rapid prototype in which we can ultimately experiment with gameplay mechanics that can make the game enjoyable for the player rather than solely focusing on making a unique game. Now I see the benefits of starting with the gameplay and mechanics, so much so that I am using what we are learning in the class as a means to formulate my other projects (which I will briefly detail a bit later).

The requirement for this prototype also has helped me to alter how I manage being a producer. What I have found challenging is keeping the team focus on designing a new mechanic to our chosen game’s core rule set rather than on our natural inclination to begin with a new game. It is very easy to get lost in designing an entirely new game that we forget the conditions of the assignment. At times, we become sidetracked by centering on a theme and a backstory for the prototype, especially because we need to occupy the artist’s time through assigning ideas for conceptual art. Therefore, we did conceptualize a theme for the game, but at the same time, we are attempting to keep focused on a new dynamic that will generate additional strategies and tactics for the player while making it fun. I hope that I will be able to assist our team in maintaining our focus on game mechanics to build an enjoyable original flash game for the next three weeks.

This approach has been difficult for some of us, but I know that the assignment will eventually help me learn to concentrate on what makes games fun. As noted before, I already have begun implementing these ideas in a nonacademic side project I am working on. Our team is now focused more on making a viable and enjoyable prototype than on concentrating our work on its theme and backstory. For this reason, I am already witnessing the value of this assignment and maybe I’ll be able to hit this knuckleball right out of the park.

Christening the S.S. Reunion: What I Learned from Our First Prototype

ssreunionscreenWorking on our first prototype for the EAE program has proved to be a very rewarding experience. Our team worked hard to progress our game from a conceptual idea to a functional prototype. I am happy to say that what we produced was a very viable prototype. Consequently, these four weeks have provided me with insights about myself as a producer that I can use going forward in the program. In this post, I will therefore detail our successes as a team and what I accomplished as well as what I can do to improve my role as a producer.

Overall, our prototype went very well. After the feedback and praise we received from our peers and faculty, it became clear that our prototype was a success. To give a brief description of our game, S.S. Reunion is an action/adventure game that puts the player into the role of navigating a toy boat through various locales. The player will do his or her best to avoid hazards in order to reunite the boat with a little girl (you can read more about the game and see sample gameplay here*). What I feel made our prototype successful is how quickly and easily we acquiesced to a common vision for the game while at the same time always evolving our goals through maintaining an open dialogue. As a result, our team never became afflicted by groupthink. On the other end of the spectrum, our team also did not succumb to egotistical motives that would have impeded the game from reaching its potential. This made working with everyone a fulfilling experience and thus it showed in the prototype we produced.

Our Postmortem board

Our Postmortem board

From our time working on this project, I discovered several facets that aided me as a producer.  For instance, our group avoided the dreaded “crunch” that plagues game development. We avoided this problem by focusing on limiting the scope of our game to fit in with the four weeks allotted to create the prototype. However, this objective did not surface at the beginning of our project. The first few game ideas we generated, besides not being the most creative ideas, were too large in scope. After realizing this problem following our first day of class, I resolved to create a game with a simple mechanic so that we could concentrate on improving it rather than merely trying to get it to function. This made the last week working on the prototype more about perfecting our controls and level rather than scrambling to make the game behave correctly.

As noted in the last paragraph, I was able to lend my creative design as a producer. Since our initial pitch was not received well (in addition to the oversize scope of our original idea), I wanted to create a game that was simple yet enjoyable. I thus conjured up with the initial design of the game and narrative we would use to drive the prototype forward. The reason I chose to include a narrative was to generate motivation for the player. In other words, I wanted the player to understand why s/he were controlling the boat and why it was important to help it make it through each level and zone. Therefore, I desired to answer the question, “Why should I care about controlling this boat?” This became the foundation for the game and thus enabled me to exercise my creativity.zone2

Additionally, even though I was able to create the initial design and narrative, as a producer I wanted everyone to be involved in the game design process. I purposely created a collaborative environment in which everyone’s input was important for the prototype. As Chandler’s book on game production noted, when each team member feels involved in the game design process, s/he will in turn better identify with the project, and thus, be motivated to create an enjoyable and entertaining game. Hence, I did not want the game to be solely my idea, but instead I resolved to make it our idea. This in the end made it our game and it showed in the final product as well as in the camaraderie we developed.

Another aspect that worked well was being the focal point for the team’s communication. With years of training in the field communication (whether as a consultant, instructor, or as a graduate student), I have learned the finer points of effectively opening up channels for communication. As a result, I was able to coordinate the team’s communication, thus keeping everyone up-to-date with the prototype. boatandmouseThis became critical towards the end when we were finalizing our prototype. It was imperative that we kept in contact during these final days in order to organize how we were going to finish the prototype. Communication enabled us to stay on the same page as well as helped us design an effective prototype.

“It’s fine to celebrate success but it is more important to heed the lessons of failure.” — Bill Gates

Even though I was able to utilize several facets to help our team successfully complete the prototype and present it, there are definitely aspects I can take from this project to make me a more effective producer. For one, as mentioned in a previous blog, I would like to better implement features of SCRUM, especially the backlog and burn-down charts as detailed in the SRUM process. SCRUM is an Agile process used in software development for more effectively prioritizing aspects of the project as well as creating avenues for effective communication. After learning about SCRUM at the end of week 2, we learned the benefit of employing a backlog for our prototype. Unfortunately, I did not effectively implement a sufficient backlog for our team. Since SCRUM was introduce after the midway point in the prototype process, it was difficult adapting and implementing a backlog and burn-down chart to our work. Nevertheless, late in developing our prototype we could have used a burn-down chart to focus on creating a working prototype while backlogging features of our game, such as collisions and our camera shake when colliding with objects, at the end of our list. Consequently, it took longer than it should have to put into action a viable prototype so that we could playtest the game. Because of this experience, I will therefore be applying aspects of SCRUM in future prototypes.

zone3When creating example gameplay for our prototype, I also learned that I should vary the gameplay style for the client. To clarify, when we showed off our gameplay during our pitch I wanted to emphasize the tighter controls and speed over our earlier versions of our prototype, especially from the one we showed in our mock presentation. However, what the video emphasize was only one aspect of the game rather than the different ways the player can approach our gameplay. This made our clients confused whether it was merely focusing on the speed of gameplay rather than what we had tweaked to increase the game’s challenge. As such, in future prototypes I will place more emphasis on creating example gameplay video that shows a more complete gaming experience.

In closing, I very much enjoyed creating our first prototype. Although I still humbly consider myself a neophyte, I feel that I am beginning to grasp how I can become an effective producer. And consequently, I hope to take the aspects that made our prototype a success, what worked as well as what I can improve as a producer, to future prototypes.

The Scrummage: Learning the Value of SCRUM

We are finally reaching the end of our first prototype. It has been an exciting adventure for all of us. A group of five people who never met before this course have taken an idea and worked hard to make it their own. And what’s amazing is witnessing our vision come to fruition. Therefore, our little wooden boat is ready to launch.

Despite my excitement for the culmination of our first prototype, this week I would like to focus on how much value I have found in the SCRUM process for software development. SCRUM is an Agile development process that helps teams efficiently complete projects. SCRUM has become an important practice in the video game industry for helping development teams create and maintain the product as well as evolve it through rich feedback. Additionally, what makes SCRUM so appealing is its simplicity in implementing and using the system, as well as its cost benefit since there is no need for in-depth training. Although I have only recently been introduced to the system and thus beginning to absorb the facets of SCRUM, through my time working on our first prototype I am appreciating the value in using the process. I can therefore see how the system will empower me to become a much more efficient and stronger producer.

In week 2, our professor, Robert Kessler, familiarized the class with the SCRUM development process and its advantages for our prototypes. The first aspect we learned are the brief 15-minute meetings, aptly named Stand-Up Meetings since the team stands during the duration, detailing what each team member is working on, what s/he has completed, and what s/he hopes to complete. When our team first employed this brief meeting, to be honest it felt awkward. In my mind I had an idea of what I wanted to discuss, but the notion of succinctly recounting my work for the day was foreign to me – especially when we had so much still to do. Furthermore, the subsequent brief meetings (mainly before we concluded the day) led some of us unaware of what else to add. In other words, I felt as if I was repeating what I had earlier recounted. Because we were working on some long-term individual projects, I consequently did not know how to relate my work status.

However, the more we practice using these short meetings, the more I began to see how much they helped us visualize everyone else’s work, keep us on task, as well as address any immediate problems. What the Stand-Up Meetings allowed us to do was to be in constant communication. This enabled us to evolve the project and more directly keep it on task. Moreover, the Stand-Up Meetings enabled us to easily transition into a longer, more formal meeting. Since the brief meetings gave us an opportunity to understand what each team member was focused on and if there were any problems, they eventually brought up topics that warranted further discussion. As a result, the short meetings helped us clearly determine how we could better focus our work.

Another great aspect is SCRUM forces the producers to keep a backlog chart. The backlog displays the progress, prioritizes, as well as depicts the timetable for the project. For me, initially it was difficult making a backlog for the prototype, especially since we were recently introduced to it at the end of the second week. And honestly I am still struggling implementing and maintaining an appropriate backlog – which is something I want to strengthen for the next prototype. Nevertheless, as a producer I see an unambiguous benefit to utilizing a backlog. Backlog helps the team focused on specific tasks and on the priorities of the project. During our time working on our prototype, there were several instances where we needed to take a moment and ensure we focused on our main concerns and aspects of our game. It is very easy to become sidetracked by working on low-priority items. Therefore, keeping a backlog ensures the work of each team member centers on the goals of the project and emphasizes clearly what needs to be completed first.

Thus, SCRUM has facilitated our work and ultimately our project. Even though I have yet to fully grasp this development process, I am very much excited to observe how SCRUM will assist me in my future work. I know I need to be more active in implementing SCRUM, especially the idea of the backlog. Nonetheless, I can already see how it is going to positively impact my future work as a producer.

Channeling Bartle’s Taxonomy of Gamer-types in Our Prototype

Level design was the foremost aspect to my studies this past week. Whether it was working on our prototype or in the curriculum of Game Design II, the philosophy behind level design has been central to my work. Nevertheless, when I was able to reflect this weekend on how we conceptualized our levels for our game, what I found interesting is how subconsciously our prototype fit in with Richard Bartle’s taxonomy of player-types. Although I have familiarity with his work from a previous course, as I became reacquainted with his player-types, I began to recognize how we had made design decisions that mirror his ideas. Therefore, in this post I will explore how our level design decisions relate back to Bartle’s ideas and how Bartle’s taxonomy can assist designers in understanding how to better approach level creation.

Before I move forward to demonstrate how these ideas are interwoven into our design, I would like to briefly cover Bartle’s work for those unfamiliar with it. To explain the different player types, Bartle uses the four suits from the French deck playing cards (i.e. the standard 52-card deck). For instance, the Diamond suit represents Achievers because, as he put it, “they’re always seeking treasure”. The other suits follow this same pattern of logic. Spades represent Explorers for their need to search every crevice in the gaming world to see what they can locate in the process. For Bartle, Hearts are Socializers that desire actual or even virtual in-game relationships. And finally Clubs denote Killers who strive for competition in which they seek to dominate, and even destroy, their opponents.

Using this taxonomy, some developers try to satisfy each of these gamer-types, while others will focus on satisfying one or more of them. For example, World of Warcraft stands in the middle by balancing each of these functions while a game like Journey focuses mainly on Explorers and Socializers. Consequently, these ideas become important for level design since the type of player determines the philosophies behind a game’s levels.

To get a better idea of how they can influence level design, when we were creating the levels for our game, we intuitively considered these gamer-types. First, when constructing our levels for our game, we wanted to create incentives for people who prefer achievement within a game. For example, since our game allows the player to control a toy boat as it makes its way through various levels, we agreed to implement a timing feature that calculates how fast the player completes the level. This in turn is compared with an older score as well as others who have completed the level when connected to the internet. Furthermore, we decided to include a collection element in which the player will strive to collect items throughout a level. This gives the player an incentive to meticulously wade through a level. Lastly, we desire to include an achievement for players that make it through the entire game without needing to restart a level once. Here, we took the ideas of achievement into account so that we could reach this audience. Hence, a designer can take advantage of an Achievers mindset through good level design.

Furthermore, designers can also satisfy Explorers through expanding elements of their game. In our game, for example, we will implement secret passages and multiple paths the boat can undertake by choosing which break in the stream to follow. In this illustration, we chose to create avenues for people to explore in our game rather than necessarily making each level linear. Replay value is therefore enhanced because of the exploration elements, and as a result, we did not merely want to limit what was on the screen, but give this type of player an incentive to keep playing.

Game designers may see the benefit of including elements for socializing. Socializers desire to either connect to other players and/or relationships by way of non-player characters (NPC). As Bartle noted, “Socializers are proud of their friendships, their contacts and their influence”. The social aspect is implemented in our game through connecting the player with NPCs the boat meets along the way. This came about after a colleague suggested that if we were to bring in characters to the narrative, it would enable the player to better relate with the game. Using this idea, we decided to create two characters the toy boat meets along its journey. These NPCs include a frog the boat meets in Zone 1 and a mouse in Zone 2. The inclusion of NPC therefore allows Socializers to feel a part of the virtual world. The Socializers for this reason are able to connect with other characters and in the same time see how their influence extends into the gaming world.

Finally, good level design can satisfy a Killer’s nature. Please note that Killers do not solely associate with what their name denotes, killing. However, it also connotes players who find a profound satisfaction in competition. In our project, we are making levels in which the player fights against a “boss”. One of the levels we hope to implement pits the toy boat with his mouse friend against a large crocodile living in the sewers of the city. Here, the player needs to defeat the antagonist as best as he or she can. The level design also gratifies Killers by calculating the time it takes to complete a level and comparing it to other gamers, including their friends. In addition, there is a free-for-all mode in which the player attempts to survive for as long as s/he is able to withstand. This too is compared with other players’ scores. In this way, the player is not just trying to “beat” the game, but also other people who play it. These examples show how we can address Killers in a level, even if the game’s central character is a toy boat. Thus, Killers can be satisfied in many ways.

As revealed in this post, Bartle’s taxonomy assists game developers in establishing how level design will affect the different types of gamers. Even though Bartle’s taxonomy is an oversimplification of gamers, in other words it assumes that there are only four gamer-types and thus limits how we see them, it does give designers a means for composing levels to meet various gamers’ expectations. Therefore, when reflecting on our design choices for our game’s levels, I can easily see how Bartle’s taxonomy of gamer-types can help us better understand our design choices.

“Fulfill Your Destiny”: My Long Road to the EAE Program

My path to this program is unique like many in my cohort. The road that led me here has been a bit unconventional, but in the same instance, has shown how becoming a producer and a game designer is my calling. Personally, I do not like sounding fatalistic or appearing as if my life is one linear fantasy game. Nevertheless, after you read this blog post, I hope you will see how much gaming is not only a part of my life, but truly a part of me.

The adventure began in the summer of 2004. It was the summer that I started playing games after a 5-year hiatus. Even though I did play games before this summer with friends on occasion, and religiously when I was in my adolescence, this summer awakened the sleeping giant that had slumbered for half-a-decade. What created this renaissance was after my wife and I purchased the Nintendo GameCube from Costco. They had a wonderful bundle deal at the time, and even though I was tempted to buy an Xbox, the GameCube was just the right price for this struggling graduate student trying to make ends meet in Hawaii.

It was because of this purchase that I began researching the latest games and information about gaming. But where could I turn? To ascertain the information, I began watching X-Play, Attack of the Show (before Olivia Munn spoiled it for me), Cheat, and any show G4 generated. I still remember waking up early before going to my summer job tuning into G4 to catch up on the latest development in gaming and in tech.

It was in 2005 that I finally purchased an Xbox. This allowed me to play great games such as the Halo series. But what I really enjoyed was experiencing my first RPG, and one of my all-time favorite games, Knights of the Old Republic. Even though I had been playing video games since my brother sold his mini-bike to purchase an Atari 2600, I had never once really played through an entire RPG. And boy was I in for a treat. I remember playing the game hoping not to disturb wife while she slept. It made those hot, Hawaiian summer nights something to look forward to. I still recall how shocked I was to learn the game’s twist (I won’t spoil it if you haven’t played). My jaw stayed open for the rest of the night and into the morning. And I also remember playing for more than two hours fighting the game’s antagonist over and over in order to finish the adventure. I teared-up when the game came to its conclusion. I never knew a video game could be so moving, that video games could touch my soul in such a way. KOTOR showed me how far games had come in the decades in which I had been playing games.

Later that year the Xbox 360 made its way to the market. While coming home to visit family in Southern California, I did my best to locate one of these marvelous gaming machines. I recall searching through forum posts for the hope of determining the nearest shipment. Luckily, I discovered that a local Best Buy close to my parents’ home would have a limited shipment of the console. And I came away with a new, shiny Xbox 360 before many people had the opportunity to purchase one. It was a dream come true.

The next year I spent it composing and completing my master’s thesis. When the summer came rolling along, it was difficult obtaining responses from my professors since during the summer most professors escape the university campus. Because of this, I purchased Elder Scrolls IV: Oblivion to fill the void between writing a book and waiting for my professors’ replies. Oblivion is still one of the greatest gaming experiences I have had to date. After spending the day writing, I would play deep into the night and early morning, spooking myself through every dungeon crawl, trying to hold my screams of delight when finding that special loot. It was a great time and one I will never forget.

After I had completed my thesis, my wife and I returned to California in order to help care for my ailing father. It was at this time that video games became my escape. In May of 2008, my father eventually was overcome by his illness. To cope with the loss, I spent that summer playing through the entire Metal Gear Solid series as well as FIFA. Video games were not only entertainment for me, but it also became a great comfort throughout this gloomy time in my life.

Games helped me to move on from my loss and my focus eventually returned to my future goals. My aspiration at this time was to obtain a Ph.D. Consequently, I began applying for doctorate programs around the country. Since I love video games, I decided my emphasis would be examining how video games reflect culture. The University of Utah accepted my request, and in the fall of 2011, I began my doctoral studies.

But as time moved forward, I started to feel confused. I began to sense that my calling was elsewhere since the more I studied gaming and played games with my wife on the weekends, the more I wanted to be a creator rather than an observer. I yearned for becoming a part of the art, but since I never thought that I could ascertain a job in the gaming industry as a producer or designer, I didn’t think it was possible. As a result, I had to suppress this notion as hard as I could.

This desire came full circle when part of my doctoral studies, I enrolled in the EAE’s Game Design I course with Roger Altizer. The course introduced me to game design, the EAE program, and others who shared my deep passion for games. When the course was coming to its quick end as great classes often do, I was very depressed. I kept telling myself that if there were a program like this when I was younger, I would have jumped at the chance in a heartbeat. The time in the class activated an obsession to join the program.

This past spring, I acquiesced to this longing, and I resolved to take the leap and apply for the EAE program as a video game producer. When I was accepted to the program I was ecstatic. Even though I had already completed two years in my doctoral studies, I had little reservations leaving the program. I felt that I was finally on the right path for my life. I knew that something had brought my life to where I am supposed to be.

It has definitely been a long road to get here, but even though it’s been quite a journey, I am happy to reflect and see how fate, how destiny has taken me home. I am excited to be a video game producer as well as designer. And I hope through this post you can appreciate my love and passion for gaming as well as why I desire for a long career in the gaming industry. I hope you will continue the journey with me through my blog posts here.

Challenge Accepted: What I Learned in My First Week as a Video Game Producer

Typically when playing a new video game there is a detailed tutorial level that helps the gamer acclimate to the gaming environment. However, if the first week as a video game producer is indicative of an MMOG, the tutorial lasted a few seconds and afterward I began tanking a series of level-40 dungeons. Despite this initial shock, my first week allowed me to jump into the fire and start to learn what it means to be a producer. And I am happy to say I loved every minute of it.

Because of being refined by the fire, this first week enabled me to learn a few things. First, I discovered what it means to “control the scope of a game.” As my newly formed team and I began to contemplate our initial game ideas, we noticed that these ideas were just too large for our small team to adequately complete, let alone make a great game. Even though they were not very large in scope, the thought of having our engineers learn a new engine, the artist envision how the game will look, as well as focus on strong level design would have made it difficult to churn out a strong prototype in just four weeks. Our initial idea, however, seemed to control this idea of scope. In spite of this, when we introduced it to two of our professors, they suggested that we should revisit the drawing board – more on this later.

Nonetheless, after our first idea crash and burned, we returned to a game in which we felt strongly about its prospects. Since we were in a crunch, we deemed that it would be easier to fall back on one of our original ideas than to create a completely new one. But as time began to weigh on us and we were developing our pitch for the game, we noticed that this game was too large in scope for us to create a viable prototype. To give a better perspective as to why the game had problems with scope, the game was designed to be similar to Sim City in which we were focusing on the disaster aspects of the game, but instead of the disasters being prevented, the player would create these disasters. Although this was in many respects a fine idea for a game, the time required for us to create calculations and probabilities for the destruction of the city would have caused our group to leave the game for the most part incomplete.

As we were closer to the day for our pitch, consequently, we made scope an important factor for our game. We finally were able to formulate a game that would allow us not only to prefect a simple game mechanic, but also permit us to create a wonderful narrative for the game – which was inspired by a rain storm that passed through as I sat stressing about the lack of a game idea. This game focused on a young girl who loses her favorite toy, a boat her deceased grandfather gave her, while it began raining heavily. The player takes control of the boat through controlling the environment with the duty of helping the boat survive hazardous conditions so it can be eventually reunited with the little girl. This game would enable us to overcome our earlier problems with scope that would have created chaos for our team. I was glad to have noticed this lesson before it was too late.

Second, I realized the importance of taking risks. As noted earlier, the first game we were pushing quickly crashed and burned. As one of professors euphemistically remarked, “Let me just say: I don’t hate it.” We read between the lines and decided in an instance to write off the game. But what pushed me to reconsider our idea was after Amy Adkins (a former producer for EA, and now a professor and producer for our program) spoke to me about our initial idea. She said, “Unlike what you’ll experience [in the industry], this program allows you to take risks. So take risks.” Amy was correct. We needed to take more risks and attempt to create a game that was unique rather than something that was more of less run-of-the-mill. Therefore, I took her words to heart and felt that if we were to move forward, we needed to create something much more novel and moving. Hence, we saw the need to take risks if we were going to be successful in the program.

Finally, I learned that there are no secrets to being an effective producer. Last Thursday we were lucky enough to tour EA’s studio here in Salt Lake City. Despite all of us in the program being full-grown adults, we couldn’t help feeling like a child that just woke up Christmas morning. During our time visiting EA, we met some artists and producers. After they presented themselves, they allowed us the opportunity to ask a few questions. Since I am a future producer who is very curious as to how appropriately manage people, I asked the producers if they learned any secrets during their time in the industry to ensure worker satisfaction, but at the same time, have them highly productive. Rich Reagan, a producer for EA, replied by using famous films and their characters (such as Harvey Keitel’s character “The Wolf” from Pulp Fiction) to illustrate that a good producer is one that does not focus on what caused a problem or predicament, but instead concentrates on tackling the issue. Instead of laying blame, the producer becomes Mr. or Ms. Fix-It and does what s/he can to find a solution for the dilemma. Thus, he believed that there are “no secrets” to being a producer; therefore producers are there to ensure that everyone is able to perform at their highest level.

My first week was definitely a learning experience, and by the end of the week, I needed a good night’s sleep. Nevertheless, through the intensity I learned valuable lessons I hope to refer back to throughout my studies in the program. And this was just the first week, I can’t imagine what I am going to learn in the coming weeks and months. So stay tuned…