E.A.T. - Post-Mortem
Although the result of our team’s work on E.A.T. gave us a highly deliverable and focused product, getting there came through a series of tough decisions both from the production and design sides of development. The game both started out differently and changed directions midway through our project, as well as had numerous changes in our team makeup as we continued through development. This led to a strongly dynamic work flow which had various ups and downs in the development cycle, but the mitigations for each risk as we assessed them gave us ample amount of time to refactor and improve, even at the cost of our core gameplay.
When E.A.T. was first conceived, I was brought on board as a lead designer and associate producer. E.A.T. was vastly different at this time, going instead by the codename PowerGrid. At this time a prototype of gameplay had already been developed by the previous designer on the team, who had left school and made a vacancy for a design position before I was brought on board. During the first weeks of the semester, my duties were split between testing this prototype as much as I could, but left me with the inability to iterate it because the designer who created it had all of the source files. To accommodate this, I was tasked with making new prototypes to simulate the already-existing gameplay, but allowing us the option to iterate upon it as well. This is where the first of a number of failures on my part occurred.
When I was tasked with making the prototype I still had little experience with any of the editors available to me at school. In my attempts to want to create a prototype which would also give me experience at school or with software I would use in the industry, I tried to use the Unity Engine, which was trouble for me to pick up and learn. In retrospect I’ve found the Unity Engine increasingly easier to understand, but due to my unfamiliarity with component-based design and the principles behind archetypes, and editors in general, I was at a loss for how to produce what my team asked of me. On top of this, I found myself dissatisfied with the current state of our producer and took more and more of the production like responsibilities on myself.
While I still feel like the latter was an appropriate action, it was unfortunate for the design to suffer in this time due to my negligence of a prototype. In the moment I attempted to combat this problem by testing rigorously our current prototype, and proposing new ideas to the team. In the end, we made strong strives which led to a better game in the future, but I wonder still how our designs and our team could have differed if I was more timely with my designs.
At the first milestone of the semester we were standing strong with a core engine and a core concept which had been proven through lots of testing. However, doubt still remained among us due to the nature that this piece was never “owned” by anyone of us, and instead by the previous designer on the team. We kept trying to identify pillars, such as what games we all had passion behind, or what single bits of the prototype we had we enjoyed having. However, we all realized after our first milestone presentation that we had to depart with our game concept because no one was truly passionate behind it. This ended up resulting in two things: setting us behind again with another concept that hadn’t been tested, and more work for everyone on the table. However, I stand firm that this was the right decision because of the nature of our team, and the eventual consequences of our production issues with the team shortly thereafter.
Within the Prototype milestone I spent numerous hours attempting to iterate on a new concept, which we all were behind this time and felt passion towards in different amounts. This idea revolved around the absurdity of collecting as many power ups as one can, resulting in an extremely overpowered character met with extremely overpowered enemies. We explored and tested this idea to great effect, but more problems struck when we came to another staggering realization about our team structure.
By this point, our producer on the team was heavily burdened with classes, and the responsibilities of producer were falling more and more on my shoulders. The climax of this episode came when we had our first session with a professor for an extended work session, and all members of the team absent the producer decided that we needed to let him go.
Ultimately, I was the one who had to deal with this as the new producer on the team, and due to some unfortunate timing I confronted with the individual the day after what seemed like a great day for us moving forward to him. I had all of the necessary facts to back up my reasoning behind the decision, and he did understand exactly why it happened, but it was still the hardest moment of that year for me in a position of power. We both grew from it, and I for once explicitly knew my responsibilities were to the team and not to any single individual. As difficult as it was I handled it well, and we have remained friends ever since. However, the backlash between my other teammates and the previous producer was not so fortunate, which culminated in a period of silence and rejection by my teammates I don’t agree with, yet respect as their own decisions.
Because I was now the producer and the designer, my responsibilities had doubled, and I had to act quickly to change our design to meet our new team structure. My producer mindset was always alive within me as a designer, but now with the added responsibility I focused all on my attention towards deliverables and vertical slices of gameplay. Gameplay had to be scoped because of the extent with which the game team needed a design change, but I identified testing as the needed solution to our loss of time and development.
I took to testing every day as long as I could, and the rest of my time was spent producing and creating gameplay logic for the characters and enemies. Scope was cut down to a bare-bones platformer with high polish from our artists who recently joined the team, and moving forward I kept our eyes on only making sure that we had a game by the end of the semester. This strategy paid off but we came to the realization that this was definitely not the type of game we wanted; it had been cut down to only a basic platformer with power-ups and a cool theme.
As we needed to deliver upon a game that was a strong vertical slice, I refactored our design to attempt to accommodate the needs of the class and the needs of the team with the assumption that we wouldn’t carry this game over to the next semester. I identified everything core about the game and looked at each slice of each level, so that I could tweak the intensity of the game over the long run as well as keep power ups relevant and the focus of the game, instead of enemies or platforming mechanics. When we came to roughly two weeks out, our testing had paid off and we had come to refactoring everything that was criticized about our vertical slice, and then brought the attention to our instructor who laid out a few more troubles with intensity and focus in our game.
Taking his word into account, we powered through another week to iterate and design a more fully-fleshed out example of what we had intended for our idea, which met the visions of the instructors as well as the requirements for our grade. Yet, every aspect of the idea had become more of a task and less a cool new feature which could be added; this was the result of our agreement to split off after the semester was over for more stable teams with more fun projects that could exercise our skills. Everything about this project was for the grade and the experience, but not for the final piece of product we would be turning in.
By the turn-in of First Playable our game had hit every single requirement and nearly every advanced certification we could achieve, which meant we had an exceptional grade. This freed us up for finals and beyond and left us very stable at our farewell point, but the entire project ended up being the summation of individual experiences, and not the some great thing we all wanted. Regardless, we all learned and evolved from that point moving forward, and had a lot of fun with it; all of us helped get each other future teams and take the experience for what it was: a step forward in our learning as game developers.
When E.A.T. was first conceived, I was brought on board as a lead designer and associate producer. E.A.T. was vastly different at this time, going instead by the codename PowerGrid. At this time a prototype of gameplay had already been developed by the previous designer on the team, who had left school and made a vacancy for a design position before I was brought on board. During the first weeks of the semester, my duties were split between testing this prototype as much as I could, but left me with the inability to iterate it because the designer who created it had all of the source files. To accommodate this, I was tasked with making new prototypes to simulate the already-existing gameplay, but allowing us the option to iterate upon it as well. This is where the first of a number of failures on my part occurred.
When I was tasked with making the prototype I still had little experience with any of the editors available to me at school. In my attempts to want to create a prototype which would also give me experience at school or with software I would use in the industry, I tried to use the Unity Engine, which was trouble for me to pick up and learn. In retrospect I’ve found the Unity Engine increasingly easier to understand, but due to my unfamiliarity with component-based design and the principles behind archetypes, and editors in general, I was at a loss for how to produce what my team asked of me. On top of this, I found myself dissatisfied with the current state of our producer and took more and more of the production like responsibilities on myself.
While I still feel like the latter was an appropriate action, it was unfortunate for the design to suffer in this time due to my negligence of a prototype. In the moment I attempted to combat this problem by testing rigorously our current prototype, and proposing new ideas to the team. In the end, we made strong strives which led to a better game in the future, but I wonder still how our designs and our team could have differed if I was more timely with my designs.
At the first milestone of the semester we were standing strong with a core engine and a core concept which had been proven through lots of testing. However, doubt still remained among us due to the nature that this piece was never “owned” by anyone of us, and instead by the previous designer on the team. We kept trying to identify pillars, such as what games we all had passion behind, or what single bits of the prototype we had we enjoyed having. However, we all realized after our first milestone presentation that we had to depart with our game concept because no one was truly passionate behind it. This ended up resulting in two things: setting us behind again with another concept that hadn’t been tested, and more work for everyone on the table. However, I stand firm that this was the right decision because of the nature of our team, and the eventual consequences of our production issues with the team shortly thereafter.
Within the Prototype milestone I spent numerous hours attempting to iterate on a new concept, which we all were behind this time and felt passion towards in different amounts. This idea revolved around the absurdity of collecting as many power ups as one can, resulting in an extremely overpowered character met with extremely overpowered enemies. We explored and tested this idea to great effect, but more problems struck when we came to another staggering realization about our team structure.
By this point, our producer on the team was heavily burdened with classes, and the responsibilities of producer were falling more and more on my shoulders. The climax of this episode came when we had our first session with a professor for an extended work session, and all members of the team absent the producer decided that we needed to let him go.
Ultimately, I was the one who had to deal with this as the new producer on the team, and due to some unfortunate timing I confronted with the individual the day after what seemed like a great day for us moving forward to him. I had all of the necessary facts to back up my reasoning behind the decision, and he did understand exactly why it happened, but it was still the hardest moment of that year for me in a position of power. We both grew from it, and I for once explicitly knew my responsibilities were to the team and not to any single individual. As difficult as it was I handled it well, and we have remained friends ever since. However, the backlash between my other teammates and the previous producer was not so fortunate, which culminated in a period of silence and rejection by my teammates I don’t agree with, yet respect as their own decisions.
Because I was now the producer and the designer, my responsibilities had doubled, and I had to act quickly to change our design to meet our new team structure. My producer mindset was always alive within me as a designer, but now with the added responsibility I focused all on my attention towards deliverables and vertical slices of gameplay. Gameplay had to be scoped because of the extent with which the game team needed a design change, but I identified testing as the needed solution to our loss of time and development.
I took to testing every day as long as I could, and the rest of my time was spent producing and creating gameplay logic for the characters and enemies. Scope was cut down to a bare-bones platformer with high polish from our artists who recently joined the team, and moving forward I kept our eyes on only making sure that we had a game by the end of the semester. This strategy paid off but we came to the realization that this was definitely not the type of game we wanted; it had been cut down to only a basic platformer with power-ups and a cool theme.
As we needed to deliver upon a game that was a strong vertical slice, I refactored our design to attempt to accommodate the needs of the class and the needs of the team with the assumption that we wouldn’t carry this game over to the next semester. I identified everything core about the game and looked at each slice of each level, so that I could tweak the intensity of the game over the long run as well as keep power ups relevant and the focus of the game, instead of enemies or platforming mechanics. When we came to roughly two weeks out, our testing had paid off and we had come to refactoring everything that was criticized about our vertical slice, and then brought the attention to our instructor who laid out a few more troubles with intensity and focus in our game.
Taking his word into account, we powered through another week to iterate and design a more fully-fleshed out example of what we had intended for our idea, which met the visions of the instructors as well as the requirements for our grade. Yet, every aspect of the idea had become more of a task and less a cool new feature which could be added; this was the result of our agreement to split off after the semester was over for more stable teams with more fun projects that could exercise our skills. Everything about this project was for the grade and the experience, but not for the final piece of product we would be turning in.
By the turn-in of First Playable our game had hit every single requirement and nearly every advanced certification we could achieve, which meant we had an exceptional grade. This freed us up for finals and beyond and left us very stable at our farewell point, but the entire project ended up being the summation of individual experiences, and not the some great thing we all wanted. Regardless, we all learned and evolved from that point moving forward, and had a lot of fun with it; all of us helped get each other future teams and take the experience for what it was: a step forward in our learning as game developers.
