4. Leaving story for last
This is pretty self-explanatory, but a little more forethought would have saved the designers on the team a boatload of stress. We were so busy during the entirety of development with implementing game features that the cinematic sequences we had planned for Penned were created within the last two weeks of development. As such, they didn't get the polish that they certainly should have and, though they did come together, it was without a doubt a quintessential rush job.
Another aspect of this that in retrospect should have been done differently was our delay in finding the right voice talent in a good time frame. We realized within the last few weeks that we weren't happy with the writing or the voice of our two main characters, Poe and Finley. This made for a complete rewrite followed by three separate recording sessions to fix the dialogue. In the end, I wound up voicing Finley (which makes presenting the game to anyone an... interesting experience) and Poe was taken over by a very talented friend of one of our designers (thank you, thank you, thank you Logan).
A word of advice to game-development students: don't ever use more than one or two people to write your game's dialogue. It's just a terrible idea. Your writing will sound patched together and awful to an extreme.
5. Not making unpopular decisions
During the FIEA capstone projects, each team is chosen to have a series of leads: project lead (that's me), a design lead, an art lead, and a programming lead. Any big decisions are intended to come down to us and it establishes a hierarchy that is meant to echo that of the industry.
This had been the first time any of the other leads or I had been on a team of this size or a project of this scope and we were in a perpetual state of learning. And it showed. Making decisions that a majority of the team isn't happy about (cutting features, adding features, redoing subpar work, the list goes on) is something that we, more often than I'd like to admit, failed to do.
Personally -- and particularly in the first half of the project -- I was excessively accommodating. It was a student project and I really needed people to be motivated. I admit that I was afraid that if people started to dislike me for making unpopular decisions, they would stop working. And so I did everything in my power to keep everyone happy.
This was a massive mistake on my part. Sometimes people won't like you. And sometimes people are hard to motivate (particularly when going through a rough patch; it's a natural occurrence and people should expect it to happen). But allowing that to get in the way of what you know is a good direction for the project is not only a mistake, but it is a disservice to both the game and the team.
Good leadership and people wanting to be your friend are two very different things. You can have both, but it may not happen. Being okay with that is important.
What Went Right
1. A very strong concept
Emily Krebs, our lead designer and the big mind behind Penned, pitched the game in December almost identical in concept to how you see it today. Oftentimes in the development of student games the point of the game can get a little muddled. We wanted to make a quasi-educational game with a quirky, tongue-in-cheek style and a nontraditional approach to applied learning. We made exactly that, and it's something to be legitimately proud of.
Throughout development, we would always come back to the same question: Does what we're making help you learn? That question was what kept much of our decision-making in check yet gave us the flexibility to get really creative.
For example, we really liked the word "inebriated" and wanted to get it in the game. The animators were psyched about making drunk walks for our enemies and the results are impactful and pretty hilarious. That outlet for creativity, and the natural constraints we developed the game around, allowed people to collaborate in ways that were sometimes surprising and hugely beneficial, both in the game's result and in our education.
2. Team flexibility and general hat-wearing
During different times in development, we would have moments where certain things needed to get done and we just didn't have the amount of specialized people to accomplish tasks. Animation tweaks, creating cinematics, paint-overs, implementing UI, scripting events, converting the game to a controller, particles, and a slew of other details all needed to be done.
This team was extraordinarily good at taking on tasks that they weren't necessarily comfortable with for the sake of getting things done. Across every discipline, team members would be okay with leaving their area of expertise for the sake of the project, and often gained another skill because of it. I mean it when I say that certain members of this team really stepped it up when the project needed it, worked very hard, and made Penned what it is now.
I want to express how important I think this really is, not only in student projects, but in game development as a whole. A willingness to attempt new things -- and be okay with failure in the pursuit of success -- is one of the most valuable qualities you can have in game development. Trying and failing is part of the process, but the tenacity necessary to eventually come out with something awesome is an incredibly admirable quality to have. There are many people on this team that had that strength of character and it's been a real pleasure to work with them.