First week of production wrap-up
I am still trying to figure out how I want to present this information to you with these blogs. I think it is easy to say that I can just create a template and fill it in every time there is enough information for me to report on. It sounds good, but with the nature of game development, and life, I do not know what the next sprint will bring. A template for this week might not work three weeks from now.
For now, I will start with a ‘quick hits’ section where I go over some things that came to my attention and how I resolved that issue. ‘Quick hits’ is meant to be a small overview of a situation. Then ‘A closer look’ will be a little more in-depth into my thought process and give you a little more information about the situation. So please bear with me as I do my best to articulate my thought process to you all.
Quick hits
Got buy-in from the team to use a wiki application for game documentation and not a long form Game Design Document (GDD). This helped the design team with the onerous task of making a traditional GDD while breaking it down into smaller sections where it was easier to work on and read.
Identified that the art team was not comfortable setting up version control (P4V) on their own. I proactively implemented a plan to have their workstations in class set up for them as well as instructions of how to do it from home (more on this in the next blog).
The art team recognized they didn’t have the knowledge to complete some of the animation tasks the project needed. I encouraged Sierra (art lead) to partner with her instructor to set up a time to review that material. I reassured her that we would make time in the production schedule to allow this to happen.
Linked all pertinent information to each task within our project tracking software (HacknPlan). This included linking to the location where documentation needed to be completed as well as reference information for the artists and other team members.
A closer look - Giving up control
At this stage of development, the design team and I had a lot of work ahead of us hammering out most of the details about how the core mechanics will function in addition to the user experience. I’ll be the first to admit that design is not the area that I am strong in. I believe that I am a passable designer, but it is not an area that I excel. With that being said, I still wanted this to be a productive meeting. I felt like I needed to provide solutions to the ‘problems’ that we did not have answers for yet. These ‘problems’ being things such as how core mechanics worked, level design, item upgrades and so forth. The initial results of the meeting were not good.
For a specific example, I had concerns with how the player was going to come across weapon upgrades within our randomized levels. At this point, we knew the player would begin each level in a starting ‘room.’ Then we would use prefabricated level sections (rooms) with Ryan’s random level generator to create each level. At the end of each level, there would be a boss the player would need to defeat to move on to the next story beat. Enemy types and their location would be tied to specific locations within each room. Each of the player’s weapons would be strong vs a specific type of enemy unit. Weapon upgrades had a low chance of spawning within each room once all enemy units were defeated.
Some of the questions I asked the team, “If the enemy composition is random and the player’s weapons are randomly given to them, how do we ensure that the player will have the tools they need to defeat each type of enemy they could encounter?” “How do we provide an environment where the player can learn how to use the new weapon they just earned?” “How do we provide a good First Time Player Experience if everything in the level is random?”
As mentioned above, I had several ‘solutions’ to these problems and wanted to talk about it with the team. I personally did not care which ‘solution’ we chose, I just wanted to get something decided. We could always make changes and improvements though iteration later on in development. The problem with this approach was that too many of the finer points were left up to interpretation. The ‘solutions’ had too many details and opinions in them. The designers and I proceeded to talk circles around each other. Too many options. Not enough clarity. Trying to design by committee. Most importantly, we had no one to take the design and run with it. This unproductive conversation lasted for an hour right up until morning break.
During the break, I had a chance to gather my thoughts and I knew something needed to change. Once back in the meeting I said, “Look guys, being a designer is not what I am good at. I am better at building teams and managing individuals. What I need is for someone who is passionate about this to step up and take control over all aspects of this design. I honestly do not care what direction we go. I just know I am not the person for the job.” With that, Spencer immediately volunteered to take up the challenge and began overseeing all the aspects of the game design. After that, the meeting went smoothly. I stepped back and let him makes all the decisions we needed to make. I did step in as needed with an occasional '“How do you plan on doing…” or “Just keep in mind, we still need to have X done before…” as I saw fit.
Conclusion: I had to give up control. I do not mean design control. It wasn’t something I wanted in the first place. What I was giving up was the control on failing. I was too preoccupied with not failing at all. This was on display with all of my ‘solutions’ for all of the ‘problems.’ This solution allows me to focus on the larger tasks and problems with the project as a whole. In addition, it affords the opportunity for Spencer to create, make mistakes, learn, and grow as a designer and developer.
