The earliest stage of game development is always a time of ambiguity. Dealing with nebulous concepts which even the team itself needs to work through before the vision is consistent with everyone, and harboring personal attachments to certain ideas whether we want to or not. Sometimes, depending on the novelty of the concept, the team may have to start from basically scratch to create it, since no usual framework exists beforehand from which to pull inspiration and expedite the first steps.
Having been immersed now in three separate prototyping stages this semester, I developed (equally intentionally as passively) a better understanding of how to best traverse this vague yet entirely necessary period. In a game, and any complex project, conceptualization must occur before the team can buckle down and get to business. So, I'm going to lay down three of what I think are the most important pillars of a good prototyping week, using my third cycle this semester as an example.
1. Aligning on the Vision
The first thing my team and I did in our third prototyping week is align on one idea, and quickly. After sifting through a list of fifty concepts (in a bigger studio the list could have been hundreds of items) the final idea that remains was still quite vague. What my team did well was we took the time to discuss this chosen concept for about half an hour so everyone had a concrete, unified vision of what it was supposed to be. This idea turned out to be a game set in a small village in a fantasy version of Scandinavia, where a Viking fisherman finds an ancient, sunken down ritual stone. This stone awakens an eons-dormant god who would go on to assist the village if they garnered him more followers. Main mechanics would include skating in circles on a frozen lake to cut holes in it, releasing demon worms to defend the village from attackers and more ritual stones.
This idea may seem complex, and that's because it is. It's absolutely convoluted. But despite its absurdity on the surface the team was able to converge on the vision for it, asking questions and inputting their own ideas along the way. I facilitated the discussion, allowing all to speak and steering certain ideas in a direction that would agree with scope. I find that when it comes to design, I have a knack for building off of other's ideas. My team presented a cool concept, and through my facilitation it became nuanced and doable. We happened to think it was cool to be able to play as a god controlling its followers, and the ice cutting mechanic tied it together in an interesting way.
2. Detaching from your Idea
While we were voting on concepts on our big list, the last three or four were pretty strong. These are always the ones which the creator will have some emotional attachment to. Specifically, a programmer on my team had come up with an idea about running around a Home Depot. He had been inspired by the size of the stores and all of the machinery and stair-ladder things the employees use to get from place to place. When the ice cutter idea was ultimately decided on, he expressed his disappointment but maturely moved past it. This allowed the team to collectively understand each other's commitment to the chosen idea, and to keep the process short time-wise. I vocally let him know this and he seemed to appreciate it. Some jokes were thrown about how he would spearhead the Home Depot game as a solo project on the side and "show us, show us all" but no real tension festered and he was professional about it.
3. Providing Alternatives (Productive Negation)
So remember how we had agreed on the ice cutting game and quickly created a collective vision? Well it was a good thing we did that, because our programmers were able to immediately get started on building the game...and the first thing they noticed was that it was going to be near impossible to do with the tools we had. We had time to call an emergency design discussion meeting to talk about solutions. This is where we participated in what I will from now on call "productive negation." This is when somebody rejects an idea or an aspect of an idea with good reason, providing an alternative at the same time to keep the discussion going. Our team realized that we had to make a tough decision here; do we find a different core mechanic, accept the risk and move forward, or scrap the project entirely? We weighed our options for about forty-five minutes, explaining to each other why their proposal wouldn't work and suggesting something else, but nothing good came up. I eventually made the executive decision to cut it.
The good news is, this provided the programmer with the golden opportunity to pitch the Home Depot game once again. You could tell how much he liked the idea because now the concept had more depth. It actually impressed the rest of us, and that idea is what turned into Gnome Depot, the game we took through Greenlight and worked on the rest of spring semester.
So, the strongest prototyping weeks come from teams that can think macro. Learning from this particular week, I will continue to take and allow input from all sources. It really can come from anywhere, especially in an Agile environment. I'll encourage my future teams to work smart and fast to obtain a unified vision soon; after that, everything just falls into place.