Four our last prototype, I was blessed to have one of the best teams I have been a part of this entire semester. And this blessing was apparent in the final game we created. Our final prototype therefore produced not only a fun game, but also a great experience overall. In this post, I will detail various aspects of our prototype, specifically addressing the early challenge designing our game and subsequently the successes I had as a producer in our final prototype* of the semester. (For more information about our game Protocol: Transcendence and a link to download the game, please click here)
As noted in a previous blog, our professors tasked us with creating a game that would be released on the Windows app store. The idea of publishing a game captured not only the cohort’s attention, but most definitely my own (especially since it will be my first published game). Thus, I deeply desired to make a game I would be proud to share with the world. Considering this goal, when we began contemplating the initial concept for our final prototype, I suggested three game ideas to get us started. My last idea caught fire with the team and therefore everyone agreed to pursue it further. The idea was to take the stealth gameplay from Metal Gear Solid, include the top-down perspective of Faster Than Light, along with the quick game sessions and procedural randomness of Desktop Dungeons.
However, as someone may deduce from reading the last sentence, when we pitched this idea to our professors Roger and Bob, they were not overly excited about the prospect of this game. They quickly noticed that the scope too much for a four-week game, and they let us know halfway through our presentation. Consequently, we reconvened together and scaled down the game. Luckily, my fellow producer Travis Turner took my initial idea and suggested that we could instead solely focus on stealth and thus not include any sort of combat. We also removed the procedural aspects for the levels since this would have consumed the engineers time. The changes thus helped to reduce the scope of our game while at the same time maintain the basic framework of our razor.
In this instance, the challenge of over scoping our initial idea, which has plagued me most of the semester, reared its ugly head once again. Luckily, like in previous prototypes, we nipped this problem early and thus were able to move forward while retaining the original game concept. Luckily, our professors were there to catch it right away and thus help us avoid this obstacle.
Although over scoping felt like a setback, it motivated us to create a great game to show off in our final pitch. From this point, the team worked like a well-oiled machine. One of the accomplishments as a team is that our engineers decided to use GameMaker. The reason for this is that anyone on our team could use it in the creation for our game even if the person was little experience programming. This led to some achievements for me as a producer. For example, I was involved in the creation of the level layouts for our game. Even though I have participated in creating levels for past prototypes, this time I was able use the game’s engine to generate assets. In addition to creating levels in GameMaker, I worked on AI pathing for the game’s enemies. I built the AI paths on several levels for the game (since we all worked on them, only one level made it into the game) and it was very much fun having to picture the meta game in order to make the levels and enemies challenging while also inviting for the player.
Furthermore, I provided the game’s sounds and music. For sounds, I found it enjoyable to mix my wife’s voice in order to act as voice cues when the player detected along with prompting the player when the enemies stopped their search. In conjunction with finding and creating sounds, I composed the game’s music using Garageband. My idea for the music was to compose a sci-fi musical score that would not overwhelm the experience. In other words, I wanted the sound to blend in with the background without distracting the player and the experience. From the feedback we have garnered, it seems I was successful with this intention.
Since our first pitch for this game did not go over well, it propelled me to rethink how we should approach our final presentation. A critique that I wanted to address from the first pitch was how we focused on the game’s thematic background and various features we intended for the game. Since we over scoped, the presentation became convoluted. Our professors expressed that they had little knowledge of what I game truly entailed. As a result, our pitch failed to show what our basic game was and how it would stand out from similar games.
Nevertheless, this led me to rethink our approach and thus led to another achievement I enjoyed during our final prototype. To overcome the flaws in our initial presentation, I reflected back to earlier pitches my classmates gave this semester. I noticed that our professors were more engage with pitches that focused on gameplay rather than formal PowerPoint presentations. Taking this into account, and given that we were required to have a completed game by the time of the pitch, I felt that it would be best if we focused on the game itself and therefore give a live presentation of our game. At first, I felt a bit intimidated by this presentation style for the reason that this would be the first time I would do a live pitch of a game. Additionally, I was also concerned with the fact that whenever you add additional variables to the presentation, there is a higher chance things can go wrong – such as tech failing or bugs rearing their ugliness. In spite of this fear, I felt that the power of a live demonstration outweighed any risk because it would ultimately focus the pitch on the game mechanics and features rather than merely talking about them.
My intuition proved correct; the pitch was a success and our professors were able to see what makes this game fun. So much so that Roger used the word “great” to describe our game and Bob said it looked “fun.” Showing the game off rather than simply giving a PowerPoint presentation describing the game thus aided with the game’s success among the faulty and our cohort.
The only aspect of our prototype that would have aided in the final product is if we would have had more playtesting of our game. As a producer, I always strive to playtest our prototypes as much as possible to fix or adjust any gameplay issues. However, since we did not have a version of our game we felt playable until the final week, we were not able to maximize the information gained from playtesting until two days before the pitch.
Finally, before concluding, I had some additional accomplishments of note. First, I composed and maintained our prototype’s Game Design Document. The GDD helped us centralize the prototype’s description, features, additional ideas, as well as a sample playthrough. In addition to the GDD, Travis and I composed the one-sheet for our final pitch. We took elements of the GDD and created a sheet that expressed our game’s razor, description, and unique selling points.
This final prototyped proved to be one of the best experiences I have had this semester. As a result, it led to great successes for me as a producer and even as a game designer. Although I experience some challenges early on, I was able to overcome them with the help of my team and assist in all aspects of the game. And as a result, we are proud to bring to the world our game Protocol: Transcendence. Now enough of reading my blog, go play the game! You won’t be disappointed. Don’t forget to let me know what you think.
*Please note that I will be using “prototype” and “game” synonymous since we were tasked with making a complete game rather than solely a prototype.