Final Presentation
Postmortem
If you have been keeping up with this blog, you may have gathered that the path has been long and the learnings have been plenty. As such, the postmortem is on the longer side, and can be found here if you wish to read it in full. An excerpt of the major takeaways section will be just below for a taste of its contents.
The Big Lesson(s)
If you are reading this, you are probably here to understand what the lasting takeaways and lessons from this project are, whether you are the project instructor, an interested ETC faculty member, or a member of the next pre-production project. Extracting lessons from this project is a little more complicated than just looking at what went right or wrong, since the approach and effective pre-production tools can change drastically based on the type of game being developed, the scope of pre-production, and even the type of people on the team. However, through the semester the team was able to extract patterns and learn why the things we did were or were not effective. The lessons here aren’t all encompassing of the growth of the team, but are widely reflected in the different successes and failures the team experienced.
1: (Get the team to) adapt to new, uncomfortable workflows
This is by and far the most critical lesson and enabler of success on the preproduction project. In large part, many of the lulls in preproduction didn’t come from misguided development, but rather being slow in pivoting and adapting to new goals as well as being reluctant to part with past processes.
That being said, no one comes into the preproduction project completely ready in this manner. Both artist and designers had to familiarize themselves with this concept over the course of the entire project, which takes time and is an inevitable slow down for the early preproduction process. However, as the team matured we were able to more responsively keep up with the preproduction needs, enabling our team to be more bold in decision making.
Proper communication and pipeline also falls into this category, since the interplay between design and art is very unlike other projects. Part of the nature of the project is that the entire concept can shift on its head literally overnight, which means that whether desirable or not, lots of established details get tossed out. The team as a whole needs to be synced in order to minimize work that turns obsolete, and the iteration cycles need to be short enough to keep discoveries relevant.
2: Tools are only effective in the right place and time, and in the right manner
Going through preproduction, you will inevitably amass a set of tools helpful for clarifying the game concept; perhaps you even came into the project with a few tools already. However, not all tools will help you understand the thing you need to progress right then and there. Even fairly common tools such as design pillars and player stories can be detrimental or confusing when not used in the right context.
That being said, just because one tool was ineffective at one point in the preproduction process, doesn’t mean that it can’t be incredibly helpful at some other point in the process. Trying an approach only to have it fail on your team feels pretty terrible, but going through the process of trying it should teach your team a little more on what is needed to utilize the tool and what it is helpful for.
One last thing to watch out for is the danger of tool misuse. Tools such as player stories serve to demonstrate where the team is lacking. However, it is incredibly tempting to take the content generated from player stories and incorporate them into the built design by default. That being said, player stories typically benefit from decisions being finalized and pillars to reject certain directions, making it deceptive for when in the process it would be helpful. What would be helpful would be to keep mental boundaries on what the desired outcome is, and how exactly the design is expected to change based on the tool being used.
Overall, there are innumerable tools out there that are extremely powerful when used in the proper time and place. Naughty Dog uses whiteboxing and improv as a way to playtest key moments. Shell games uses cardboard and “brownboxing” to get a feel for spaces. Be open minded and look for as many tools as possible, and be open to trying new things while simultaneously being prepared to pivot if it doesn’t look like the tool is working in your favor.
3: Find ways to say no
This lesson is less relevant in the exploration phase, when the goal is to investigate as many avenues as possible, and becomes increasingly more relevant later in the project when the goal is to land at a unified design. This is because design is all about compromise. Choosing between choices A and B will inevitably lead your idea to become different games. This isn’t a bad thing, but it’s important to keep in mind that every time you make a decision, your game changes. Sometimes, the decisions to include a new feature or mechanic will weaken themes or the alignment of other existing mechanics.
Because of these reasons, it’s important to, if not be aware of how the decision you are making changes the state of the game, but at least understand the stakes for not screening decisions. The question then becomes how to develop a set of criteria whether to accept or reject proposed changes or directions. Design pillars are a common tool to help give consistency to decisions, but doing so requires the pillars themselves to be more or less solidified which might not be the case. Having a member of the team who has the clearest vision and ownership over the concept is another helpful way to be able to make definitive decisions. In this case, or even if the team doesn’t have a primary vision holder, care has to be taken that the team social dynamic isn’t overwhelming in one way or another, and that team members aren’t too accommodating or confrontational.