Thinking Outside (& Inside) the Box: Game Design using Dr. Altizer’s “Design Box” Method

This week for Prototype 3, our task is to make an “indie” game using any established engine (i.e. Unity, UDK, Half-Life, etc.). For the first time, we have virtually complete freedom to create any game we choose – well as long as it is within our definition of indie. But what was most interesting about this project is that we would use Dr. Roger Altizer’s Design Box (DB). The DB is a deconstructive method for building ideas and as a result enable designers to formulate pitches that are more effective. Using this method for our current prototype, I hope to briefly explain the DB for those unfamiliar with it, and discuss the advantages and challenges in using this method for game design.

The Design Box
The DB centers itself around four concepts: Audience, Aesthetics, Technology, and Play/Theory. These four concepts facilitate a procedural means to foster and steer game pitches. To clarify the four concepts, to begin the Audience aids in conceptualizing the game’s intended audience (hence the name) and the consumption patterns of these gamers. For instance, the developers may determine that the game’s audience are males 15-24 that enjoy completive games or maybe a potentially unseen audience such as our parents, future employers, or maybe even cultural norms? These various audiences affect the development of the game for the reason that the designer(s) will acquiesce the game to fit the expectations of the group.

Aesthetics in the DB goes beyond the mere look of the game and bases itself on the perceptions of a genre. For instance, in our last prototype we wanted to create a game that encompassed the look and feel of a classic early 80s arcade game. Technology further influences the game idea. It can range from the game engine used to the intended platform that all limit what the designers can and cannot do. Lastly, Play/Theory is probably for me the most interesting aspect of the DB. Play/Theory is the philosophy behind gameplay and what questions to investigate in the creation of the game. These ideas may center around questions such as does my game use duel thumbsticks, mouse and keyboard, or even I want my game to resemble an early 80s arcade game.

After fleshing out these four concepts, inside the box the team composes pitch ideas. These pitches are framed as razors. A razor is a method to depict what the game is not. It usually follows the framework as Game X meets Game Y with “Hook”. For example, a team could pitch Left4Dead meets World of Warcraft with more open world exploration. This helps to define the game as well as give others an idea of how to visualize the game.

Learning its Potential via Prototype 3
For our latest prototype we are attempted to use the DB to help conceptualize pitches. In practice, I am learning the potential of Roger’s method, and as a result, it is enabling me to see how a team may use it to conceptualize pitches for our prototypes. To begin, it is forcing me to focus on the audience and how to define it. Audience as noted before goes beyond mere demographic information. Here, there are philosophies associated with specific audiences. For our prototype, for example, we are required to focus on an indie audience. Since indie is such a vague term, as a team we needed to define it through a segment of indie gamers we identified as personifying the qualities behind the genre. This caused us to think about what it means to be “indie gaming” and what type of game should fall within the genre. The DB consequently created a means to analyze indie gaming audience and this enabled us to understand how we could approach our game.

The DB assisted in creating razors for our ideas. It can be difficult to summarize a game in one sentence so that someone can visualize the game concept. The DB creates a framework to understand what the razor is and how that razor equates to the facets developed around the DB. The interplay between the DB and the razor fuels game ideas that are in direct response to the four concepts. The DB helped us play with game ideas and enabled us to pitch them in a clear and precise manner.

The DB finally helps game designers conceptualize the theoretical foundations of a game idea. It is easy for game designers to forget that there is a philosophy fueling the ideas behind a game. In our last prototype, we were unaware that the theory we were exploring was to completely comprehend the core rule set of an early arcade game in order to create an entirely new game. For this prototype, our theory is to identify an indie audience and design a game around these concepts. This idea therefore propelled us to understand “indie” and thus compose a game encompassing these qualities.

Since the DB was foreign to us, using the DB proved to be very challenging at times. This occurred because our team consistently tried to conceptualize an idea first rather than using the DB to fuel pitches. For example, when we first began defining our audience, we continually viewed indie in a perspective that agreed with our razors. This at times nullified the purpose behind using the DB. I hope with more practice using the method I can begin to use it much more effectively and hence create stronger razors.
During my short time with the DB, one critique I have of the method is that it can limit the ideas a team generates. Since it requires designers formulate games based on other previous games, other people who hear the pitch visualize the razor chiefly through these games. Hence, there is an expectation as to what the game should like because of its need to be similar to these other, usually highly successful, games. Furthermore, it forces designers to think “inside the box”, in other words focusing on limitations, rather than being allowed the freedom to experiment with ideas. Now the designers are attempting to define what the game is not and thus may have a difficult time envisioning the potential of theoretical game concepts.

In spite of these minor critiques, I do see the potential of using the DB in game design. In practice, it does help a team better visualize how to approach a game and I know it will definitely help as I move forward as a producer and game designer and I look forward to using it more in the future so that I can realize its potential.

 

7-Lessons from the First Half of the Semester

Taking inspiration from Tina Kalinger (which you can read her post here), I decided to write a blog post reflecting on what I have learned thus far. For this post, I decided to create a short list of the lessons I have gathered throughout the first half of the semester in the EAE program. I’m very sure there are more, but to keep this blog post succinct, I’ve decided to include a list of seven primary concepts I have discovered in my first eight weeks as a video game producer.

Lesson One: Always Keep a Positive Attitude
I found that keeping a positive attitude helped my team maintain a optimistic perspective, even through challenging events. A positive attitude can be infectious in the same way negative attitudes can become a cancer for a team. Being positive helped me to encourage the positive efforts of the team. Hence, I found that when I reflected a positive attitude, even during moments when inside I was in a state of panic, the team maintained a strong attitude towards the project. Maintaining a confident demeanor ultimately reflected in our work and in the positive feedback we received as a result of our prototypes.

Lesson Two: Team Cohesion > Individual Skill
A lesson I have taken away is that when people are able to sideline their ego and work together, the resulting experience and product is greater than a team full of highly skilled individuals. Even though I feel I have been blessed with very talented people in my first two prototypes, team cohesion helped us to collaborate our efforts and push ourselves to create a better game. It becomes a cyclical idea: when a team enjoys working together the product reflects this experience. Thus, when team cohesion makes working fun, it consequently encourages the team’s effort.

Please note that team cohesion is always susceptible to Groupthink. Groupthink is the idea that maintaining team harmony outweighs challenging ideas that may result in conflict. Therefore, it is imperative as a producer that I am aware of creating a healthy environment to the point in which team members feel safe challenging ideas and aspects of our game design.

Lesson Three: A Producer Assists the Team’s Efforts
One biblical narrative I’ve always appreciated is the story of when Jesus washed his disciples’ feet. Even though he was the Son of God, he humbled himself to the point in which he bathed the dirty feet of the people who followed him. It seems that he believed that showing he was not above those who followed him he would counteract the idea of putting oneself above the rest, even in a high position. Using this story as a foundation, as a producer it is important to realize my role is assisting my team in anything that is needed, thus serving their needs, instead of telling them what to do. It is my job to make it easier for each person to complete his/her work.

Sadly, some producers feel that their role is to be a taskmaster – which may stem from the fact that producers are usually the first ones fired when a game does poorly. They feel that the responsibility lies in micromanaging the team in order to ensure the game is in budget and on time. To shoot down this notion, in our production class Amy Atkins constantly reinforces the idea that a producer makes the efforts of team easier so s/he can optimally perform his/her duties. Therefore, I know that I need to always help my teammates and aid in making their work more efficient.

Lesson Four: Limit Scope  
Scope is an important concept to control in all aspects of game design. Personally, I love thinking and dreaming big. However, as a producer my job is to ensure the game is within budget and ships on time. Since we have yet to implement budgets (thankfully!), my major priority is to ensure the game is completed in a timely manner. Therefore, when the scope is too large, the game has the potential to fall behind schedule and/or lead to the infamous “crunch” people in the industry dread. I consequently have learned this semester to keep the scope manageable without compromising our team’s creativity.

Lesson Five: Focus Priorities
With that, I realized the importance of maintaining team focus on priorities. This idea can be difficult to implement at times and especially during our first prototype. It is very easy to get sidetracked and begin working on other features or mechanics that are of low priority. However, to aid in maintaining our priorities, in our last prototype we began using the production software Trello to track our backlog and prioritize tasks. This helped our team tremendously in maintaining a clear focus on the prototype’s priorities, and for this reason, helped our team create a very viable prototype.

Lesson Six: Let Each Team Member Perform What S/He Does Best
When I was a young man, my father (who spent 23-years in the Air Force and 16-years in civil service) related to me a great technique for increasing a team’s performance. He recounted that when transferred to a new supervisory position, in the beginning he would not alter the work style of the team. He would observe what worked positively for the team as well as determine what needed to be tweaked to increase the team’s efficiency. After a few weeks he would start modifying what he felt needed to be changed while maintaining aspects that worked favorably for the team. My father’s philosophy stemmed from his belief that workers are professionals performing what they have been trained to do, some for many years, and to micromanage them would only lead the team to resent him and consequently negatively effect production.

I have always taken this philosophy to heart. Similarly to my father, I desired to let my team work without me being constantly over their shoulder or having to know what they are doing every second of the day. Consequently, I let my engineers and artists perform their highly trained specialties. I saw my duties were to keep track of what aspect of the game s/he was completing, asking how s/he visualized the task to his/her vision of the task, determining if there were any roadblocks I could help with, and make priorities were being addressed. I observed that this made each member feel ownership of the task and resulted in him/her feeling a part of the creation of the game rather than as a cog in a machine. Thus, my father’s theory creates freedom, trust, and creativity on a task as opposed to producing a sweatshop mentality to game design.

Lesson Seven: It’s All About Rapid Prototyping!
One idea I struggled with is focusing on performing rapid prototyping. During both prototypes, I tended to focus my team’s efforts on creating vertical slices. I know even in the last prototype in which for the most part we were performing rapid prototyping, a lesson I learned is not to focus too much on polishing the game. Rather, this time could be better spent focusing on experimenting with new mechanics that bring about new strategies, tactics, and/or emotions for the player.

In conclusion, I have learned many lessons in these first eight weeks and I cannot imagine what I am going to learn in the remaining weeks. I know when I someday reflect on this time in my life years from now, maybe I’m reading this sometime in the future, I will observe how much these lessons are timeless to my work. I hope that these lessons and others will continue evolve my philosophies of what it takes to be an effective producer.

Postmortem of Prototype #2: A Slow Start Leads to a Strong Finish

Screenshot #2

As noted in a previous blog, for our latest prototype we were tasked with selecting a late 70s or early 80s arcade game, take the arcade game’s core rule set and add additional game mechanics in order to ultimately make it an improved game. The requirements set forth for this prototype proved to be a challenge and at times pushed our team to its limits. In spite of this, I am happy to say it turned out to be a very rewarding experience resulting in an enjoyably fun game. Therefore, in this postmortem I will reflect on how the challenges associated with this project are helping me learn better approaches to becoming a more effective producer.

The first week working on Prototype 2 was a difficult one. We spent most of our time first trying to define the parameters of the assignment, afterwards attempting to lock down a late 70s/early 80s arcade game we could use for this project, and finally determining a theme to build on this core rule set for our game. This caused us to fall behind the rest of the teams in our class. This initially led our team to become unsure of where to go and how to complete this project. The laborious start also caused a bit of tension within our team. However, after realizing the importance of moving forward, we used the pressure to band together. It was at this stage we finally selected the game, Time Pilot, and conceptualized an additional mechanic to add to the core rule set of the game.

Original Time Pilot

Using my love of the game Geometry Wars as inspiration, the additional mechanic we used to build on Time Pilot was to add limitations to the game world. Since Time Pilot is a free-flowing shooter with no limits with where the player is able to, we felt that adding limitations to the level would create additional strategies for the player. We also decided to add obstacles that could act as cover, or even trap the player if not used well, to further generate new tactics. As a result, what we found is that the game experience changes given that now the player needs to consider the limitations to the game space as well as learn to use the obstacles to his or her advantage. As such, the new mechanics we found through play-testing made the game more enjoyable for the player. This became our starting point and from there we were able to add several new mechanics and features.

From these turbulent beginnings, I was able to notice a couple of things. To begin, the other producer and I did not start by mutually working together to focus the team. Instead, we spent a bit of time working out the dynamics of the assignment and what direction to take the prototype. This slowed us down since we stubbornly stuck to our designs and desires for our chosen game. Nonetheless, after recognizing we were leading our team to a crunch, we realized that in order to move forward we needed to work together in order to effectively complete the project. This led to the second aspect I accomplish during this time: focusing the team’s efforts to complete the task at hand. I was able to help refocus the team on completing the assignment. As a result, after this first week of stagnation, we rapidly moved forward and created an exceptionally viable prototype.

Screenshot #1Once we were able to move forward, I was able to work more successfully with the team in a variety of ways. One way I assisted the team was in performing what Amy Adkins suggested the role of a producer is: to make the work easier for the engineers and artists so that the game can be on budget and on schedule. Using this philosophy, I began finding ways to aid everyone on the team. I took it on myself to compose ideas for the puzzle elements for the levels, create new ideas for features and mechanics, and lastly gather arcade sounds for the game. By taking on these tasks, I was able to support the engineers and artists as well as the other producers focus on their tasks and consequently complete the project on time. Furthermore, I implemented the production software, Trello, in order to help spotlight and prioritize our tasks. Trello allowed the team to understand what the team needed to accomplish every week and in what sequence we needed to perform these tasks. Using the software made it easier to keep ahead of our work, especially when not in school. This allowed us to become more efficient in our work.

Postmortem

Postmortem Board

One element that I will change for the next prototype as a producer is to focus less on polishing our prototype or more on experimenting with additional game mechanics. Towards the end of our prototype, even though we added new mechanics to the game, we wanted to provide our professors and cohort with making a vertical slice of our game. Hence, we moved forward with making the game appear like a complete game. This took away resources that would have been best used for crafting new and enjoyable game mechanics. Thus, as this assignment attempted to promote, I will on the next project focus directly on rapid prototyping instead of creating a finished product.

In spite of our start, we created an entertaining and fun game. So much so that one person who play-tested our game during our presentation to the class remarked that he could easily see himself continually feeding quarters to play it. Nevertheless, the time I spent creating and completing the second prototype with our game are helping me to become the producer I hope to be. Now onto the next challenge.

Discovering Effective Ways to Communicate Cross-Culturally Through Prototype #2

This week began the much-anticipated Battlefield 4 beta. Because I was very excited finally to experience this game, I downloaded it as soon as I could. The BF4 beta inserts the player into the city of Shanghai as both the United States and China battle for victory. Thankfully this scenario is merely relegated to fiction. Nevertheless, even though DICE envisions a major conflict between these two countries, my experience working with a team comprised of mainly Chinese students has been a great learning experience for me. Through my time on this prototype, I am discovering how to not only be a better producer, but how to become a more effective communicator. Consequently, I will recount how working with team comprised of individuals from a different culture and language has helped me learn how better to communicate my ideas and enjoy working within a diverse team environment.

The first aspect I learned as a producer is I need to take time to explain my ideas and thoughts. At first, I made the common mistake of speaking too rapidly for people who are nonnative English speakers. Since I tend to talk as fast as my mind can think, I could see a puzzle looked on my teammates faces when addressing an idea or organizing our work. Realizing my error in communication, I began to be mindful of my vocal rate. After considering this, it thus enabled my words to be better understood more clearly and accurately.

Additionally, I found that if clarify what I said through drawing or using objects to relate my ideas helped in relating my ideas. Whenever I found that I was having difficulty relating a game mechanic or gameplay idea, I would physically draw the concept for the team in order to create an analogue impression of the idea I was trying to relate. Furthermore, I would also use various objects, mainly anything I could find close to me, to express how a game mechanic could work. I would use anything I could find, including my own hand to show how something could work in the game or clarify an idea. This enabled me more effectively to communicate with our team.

Lastly, I discovered that clarifying what a team member related to me made our time more efficient. Please note here that this idea is not some great discovery of mine. I was taught this concept years ago as a communication student. However, like many methods we learn, my brain filed it away until I remembered it for this prototype. As a result, I began to clarify what we related to one another. Whenever I was unsure or could possibly misunderstand what my team member said, I would therefore do my best to restate what he or she stated. This helped to prevent misunderstandings caused by the differences in language.

After working on this project for the past two and a half weeks, I have come to respect and enjoy my time with my Chinese teammates. They definitely have done their best to make me feel a part of the team. It has been a challenge, and it must be a greater challenge for my international friends, but one I feel I have learned from and through these lessons learned, I know I can take them forward with me in my future endeavors. And as much as I enjoy playing BF4, I pray that the scenario shown in the beta never comes to fruition. We can not only learn a lot from each other, but make great games if we are willing to take the time to overcome any cultural and language differences.