Created with Griffin Hay, Gerardo Hernandez, Connor Phillips, Justine Sax, Chris Tutor, and Zachary Kunkel
In Spring of 2017 at Moorpark College, I participated in a class in which the only project was a single game made with a group of fellow classmates. For most of our group of 7, this was our first game and our first time working on a game project as a group.
We chose to go big with our game and made a brilliant story with a vibrant world about a girl conquering her fears in her dreams and realizing her inner worth. We prepared a ton of exposition, discussed a lot of features, and worked endlessly to make the best game we could.
For as smart and as talented as we were as a group, we were not yet prepared for the challenges that faced us. We had massively overscoped the project and had spent a lot of time working on things we did not need to prioritize. For instance, I spent a week developing and perfecting a fall damage algorithm for our game that went into a health system that ended up being unused. Beyond that, I started the project with the belief that all I needed to be was a writer and designer. In a game like this, I learned that I had to be more than that. I had to be a programmer, a level designer, a quality assurance tester, an advocate for the players, and so much more.
For anyone interested in reading further, these are the class-assigned postmortems written by me during the project.
Level One Post-Mortem: Al Dente
Bonus: Random Design Notes from the Beginning
Moving forward, I would like to share a few things that I have learned from the experience. In addition to the technical skills, experience with scope, and teamwork experience, I have learned several core lessons that I will be taking with me. Some of these were new to me, while others were solidified by the process.
In no particular order,
- Nothing can be assumed. Everything should be documented.
- Working with someone also means trusting them to do their role correctly.
- Every role is important to the success of a game, regardless of direct impact.
- Learn to manage expectations, and to recognize the expectations of others working alongside yourself.
- Playtesting is meaningless if you don’t act on the feedback.
- Prototyping mechanics cannot be skipped and is the highest priority until it is done.
- Game design needs to be an iterative process.
- Always ask “is this fun?”
- A smaller, funner game is better than a larger, more complete game.
- Game designers can create several different versions of the same thing that all work.
- Trust yourself as a game designer. If you stop trusting yourself, others will too.
- Communication is crucial. Not everything needs a full team vote, but everyone should know what is happening.
- Gatekeeping exists. It’s not always malicious, but learn to recognize it.
- Not everything needs to be made from scratch. There’s plenty of accessible assets and it’s okay to use them.
- Your team is there for you. They want to help when they can.
- Mistakes will happen. How you adjust is what defines you.
In conclusion, I’m genuinely happy to have gone through this process. I learned a lot about game design, a lot about myself, and a lot about working with other people. And learning new things is one of the reasons I got into game design in the first place. Feel free to check out the game project link below. I’ve also included the game design document, written by myself and Justine Sax.