Finding Innovative Ways to Iterate

Mark Jarman’s concept art for our thesis game

The first milestone coming up for our thesis game is EAE day. This will be the second opportunity to show off our game. Since it is now less than two weeks away, EAE Day has become the focus for our team. However, having a working prototype to show off has been proving to be difficult task for the reason that we are taking the original prototype we created in Unity and are recreating it in Unreal 4. This biggest challenge has been getting the network to play nice with the game since our game is multiplayer focused. Fortunately yesterday, the our engineers made it an emphasis for getting it working, and so far, a prototype for EAE Day looking promising for our game.

Nevertheless, one concern expressed to us by our professor Bob is that we would not have time to truly iterate on our game and its current design. As the creative lead, this too has become a major concern to me since iteration is what fuels innovation. And since we will just have the basic build of our game in Unreal 4, at least at this point, we may not have time to iterate.

Even though it may be difficult to iterate on our design at this juncture, we are coming up with several ways to address this challenge. One of the methods we are thinking about iteration and testing our design is through paper playtesting. This gives us a chance to visualize what options we could possibly take in an analog form. It becomes a “board game” version of our game and design.

Also, playing around with the original build created in Unity could provide us with perspectives as to what feel we desire for the game. We can play with it to see what works, what doesn’t, and what we can iterate on with the new build. Lastly, one last possibility to play similar games to the one we are designing. This will help focus our attention defining and refining our core mechanics.

Hopefully next week we will have the core game built that we will be able to begin the iterative phase. And we are looking to see how the game is received during EAE Day on April 24th. Hostile Territory has a ton of potential and we are pushing to make this promise a reality. If you’re reading this and not from EAE, then please join us on April 24th.


Back to Work! Starting the Thesis Game.

After GDC and becoming inspired by my contemporaries, I was ready to begin the week. With the long days that preceded our two weeks away from classes, I finally felt fresh to make this final push in my first year in the EAE. Nevertheless, this feeling of being rested assisted in addressing several issues to finally begin the project. Coming into this week we had four important matters that we needed to tackle. These included what engine to use, solidifying the core design, attached a theme to our game, and finally locking down a team name.

The first priority for the week was deciding what engine to use. We built the original prototype using Unity. However, after GDC and seeing what other engine could bring to our game, we wanted to explore both the Cry Engine and Unreal 4. We decided to take a couple of days to research each engine. After researching the two engines and determining how they could impact our game, the team decided to go forward with Unreal 4. The reasoning for this was the simplicity as to potentially designing levels for our game. Nonetheless, one of the biggest challenges for our thesis game is creating the circular walls that rotate in which people would be able to walk on the walls. At GDC, one of our team’s engineers overheard that being able to utilize the circular design, and especially walking on walls, could be problematic. Taking this information, we decided to go into our weekly sprint determining whether Unreal 4 would be suffice for our game and if not, we would fall back on using Unity.

This week we wanted to solidify the game’s basic design. Going into our break after finally picking our thesis game, I began to notice that our game’s scope might need to be tuned to compensate for summer months. This occurred after playing many hours of Battlefield 4 and Titanfall. What I noticed was the problems both games had with lag. Since our game is a multiplayer game with direct combat, as the game’s creative lead, I was a bit frightened with the thought that if developers with abundant resources can’t get the netcode correct, this will be a challenge for a ragtag bunch of student gamers. As a result, I began contemplating ways to address this problem. One way is to use indirect combat to attack other players. This would allow us to possibly overcome problems with lag since it would be less noticeable. Indirect combat hence became an important aspect going forward.

Also, with the thought of potentially showing our game off to IGF and others at GDC next year, the idea of multiplayer became a bane in my mind. I thought, how are people going to experience our game without playing against other people? One solution proposed is that we could use “bots” that are A.I. controlled NPCs. But bots in my experience take away some of the fun from multiplayer games – which is one of the critiques of Titanfall. This forced caused me to think of ways we could explore using A.I. players, but at the same time make the game feel compelling. Using this idea I began to look into games such as Monday Night Combat and SMITE in addition to Titanfall to see how mechanics from MOBAs could aid in our game’s design so as to make the game feel like a chaotic battlefield. With that in mind, the AI could be used to attack while being used as a resource for the player. Thus, we are looking into how we can make the multiplayer element feel exciting even with a limited amount of players rather than merely playing against dumb bots. 

One of the biggest challenges we have faced has been attaching a “juicy” theme to our game. Since we began the idea for the game centered on the game’s mechanic, a theme was developed from it. This led to our now famous rotating, circular environment. However, our professors were not too happy with our parallel universe thematic approach. They felt it appeared like “Space Marines” reminiscent of Halo rather than something provocative and memorable.

Because of their perspective, we have had to revisit our game’s theme. But since since many people on our team come from different walks of life, different countries, and political stances, finding a controversial topic can be difficult. One of the ideas our professors proposed was to use our mechanics to reflect ideas of religion in a humorous manner. However, some people on our team do not desire to address religious themes and thus people were not too thrilled to pursue it. So as a team we have done our best to find a theme we would all be motivated to pursue, but at the same time would be interesting. And as a producer, I want my team to feel motivated to work on the game. Thus, if we can’t find the juiciest theme I know I can live with that as long as my team is motivated to make an enjoyable game for our audience. The theme nevertheless is still in progress. So stay tuned!

The last priority to tackle this week was to finally lock down a team name. Luckily, coming up with a name was smooth and easy. After a quick discussion, since our game is now using indirect combat, we thought this somehow could be used as a name. As of this week therefore our team is officially called “Indirect Games”. This will be the name we will carry forever as we make our way into the industry.

It is exciting to be at this point. For me the future is whatever we make of it. Good times ahead and as much as we have faced challenges, I know this will be a memorable experience. Tallyho!

Taking Inspiration from My Time at GDC


GDC this year provided me with just as much inspiration as in my first year I was there. Last year my time at GDC inspired me to apply for the EAE program. And this year it has inspired me to create the most compelling thesis game we can make. Whether walking around the GDC Expo Hall, working the EAE booth, watching the GDC Awards show, or speaking with industry professionals, the enthusiasm for the thesis game grew exponentially. In this brief post, I will note specific moments that rejuvenated my passion to create a great thesis game.

On Tuesday I awoke excited to receive my pass for this year’s event. As a result, I went to the Mascone Center. It was an exciting moment picking up my expo pass and seeing my name on it, especially since I was finally coming here as part of the EAE program. Now I would be here as a video game producer rather than as an academic.


Wednesday also brought forth more GDC inspiration. I began by first walking around the expo hall and afterwards working the EAE booth. The EAE booth was located near the IGF showcase games. It was great being able to meet various people in the industry and showing off our wonderful games. It was further great witnessing some of the featured games for this year’s conference. Seeing them made me feel anxious to see our games there. And knowing that one of our own was among the mix caused me to want to continue working on our game. Later that day, we went to the GDC awards ceremony. It was great observing all the games and seeing what other indie developers were doing. It was an honor seeing the game Papers, Please winning many awards. I became inspired by the game’s message which addresses ideas of immigration. I’m glad that others embrace the game’s rhetorical message.


Thursday was in full swing. Since I wanted to gauge potential internship opportunities for a lowly producer/game designer, I hit the careers area hard. Even though there were little openings for internships, I luckily met some great people who provided some insightful advice and even may have found a possible internship position for the summer.

In the evening, many of us went to the Intel Student Games Competition. Here, our very own Cyber Heist, which was also an IGF student showcase winner, was competing against other student games. What I found captivating was witnessing my contemporaries’ games. Some of them were amazing and really polished – in spite of the evening being filled with technical problems from the hardware and audio provided by Intel, the games still shined. These games included Kraven Manor, Hymn of the Sands, Plushy Knight, Maestros, and Museum of Simulation Technology. They were amazing to witness and in the end is motivating me to create a compelling and an enjoyable thesis game.


For me, the paramount aspect of the entire GDC experience was spending time with people from my cohort outside of our work. It is great adventuring with others and sharing this experience together. In these moments one can only grow closer and I feel much prouder of our program and our work.

Well there you have it. I am now ready for the end of this semester and seeing where we can take our thesis game. I am very much learning from my time at GDC. It is nice to be able to escape the bubble of our studio and become a part of the larger community, and thus create an avenue in which I am better able to see what we are achieving and how we can further iterate on our ideas. Stay tuned…


Scheduling Time for the Schedule

Through the hectic nature of making a game, it is easy to overlook various aspects of being a producer. I know throughout my time this semester, with everything that has occupied our time in order to get down to the two prototypes, it has been a challenge to find time for other important tasks. Because of this, on Tuesday Amy met with all of us producers in the cohort to discuss responsibilities we needed to better address. Here, the main focus of the meeting was to encourage us to focus on scheduling.

Scheduling is important for our prototypes for several reasons. For one, the obvious is that a good high level schedule keeps the team organized and on time. One example of how easily a team can become sidetracked is the problem with “feature creep”. Feature creep occurs when a person desires to include a feature or mechanic even though it is outside the features list defined in the schedule. For such a problem, the schedule keeps everyone focused on what needs to be done and lessens the opportunity for going beyond the parameters of the game.

Furthermore, as producers we need to visualize how our idea can become a viable prototype. This can only be done through taking the core features of the game and determining if they can be implemented within the time. With that, scheduling helps us take into account the hours everyone has to work on the project. In our program, since we meet twice a week for four hours in our classes, we can simply calculate this time to know how long we have to work on our games. And doing this only creates a safe estimate of in-class work since on occasion we have lectures, guest lectures, presentations, meetings, etc. Therefore, understanding a realistic assessment of work hours, a schedule can help account for such challenges.

Scheduling additionally aids in compelling producers to create a game design document (GDD). This arguments stems from the idea that in order to clearly define the features of the game and thus know how long they will take to be made, the GDD helps clarify the extent for creating a feature. By understanding a feature, now one can go about understanding the time it will take to create said feature. This takes me to another point: scheduling encourages clear design. Out team on Thursday spent a considerable amount of time clarifying the short and long term designs for our game. The reason for this was to create a viable schedule for the prototypes. In other words, if we knew the particulars to the design we would thus mold a feasible high level schedule.

After Amy’s discussion with our cohort, it was clear to see that we needed to spend more time with scheduling. And for me, it helped clarify aspects that I felt that can only be addressed through creating a strong schedule.

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 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.

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.