Post-Mortem
What went right:
- Defined art style early
Our art style was defined early on in our pipeline. This allowed us to follow guidelines to creating our art, giving us an amazing look and feel to our game.
- Team dynamic
Our whole team got along very well, giving us a platform to discuss important topics and never let things get too aggressive or create emotional problems.
- Prototyping / Game is fun
2 Day prototyping early on in our game design projects allowed us to see which of our ideas were fun and which weren't. This allowed us to easily test the playability of our games, giving us the foresight not to stick with a game that wasn't fun.
- Professional Feedback
Having professional game designers playtest our game and give us brutally honest feedback (however painful it seemed at the time .... thanks Martin :D) allowed us to not make silly game design mistakes, and realise what truly worked within our game.
- Unity
Unity as a program is simply amazing for small, indie games. It allowed us to quickly test features of our game, and tweak the gameplay right in the program without building. Also allowed the artists to create art on their local machines and export packages for easy importation into the main build of the game.
- Programmer leaving
Programmer tasked with a fairly important feature of our project simply left for unknown reasons, leaving us with a half-done dynamic camera that our already over-tasked programmers had to struggle with. Only having 2 programmers meant some features had a large waiting time to be put into the game.
- Scheduling / Organisation
We weren't working on a proper schedule, nor were we prioritising the most important features of our game early on in our pipeline. We spent overly too long on the prototyping stage of the project, rather then starting development at the right time. This made us rush towards the end when we did figure out a good schedule, and realised we weren't doing too well.
- Too many chefs in the kitchen
Some decisions weren't made by leads, instead by individuals, meaning features that could've been fun were cut without lead approval or features that weren't approved got in. This lead to wasted time and a confused team who didn't know whether some features were cut and whether some weren't.
- Unity Free's pipeline produces bottleneck
Unity Free's pipeline meant we had a very large bottleneck for both art and programming, as we could only use one machine to compile our features onto. This meant that some test builds didn't have features in them that had been in for a few weeks.
- LOUD NOISES!
There was distraction after distraction. Ranging from loud team mates who liked to be silly, to other teams coming to our room at the wrong time...even during crunch time, to loud music being played. This annoyed our team mates who wanted to work in peace and quiet, and wasted the time of the ones who had important features to get working and implement.
- Establish firm power-base from the beginning and start with strong leaders.
- Lock schedule down from the start, and spend less time prototyping.
- Don't give important features to those who aren't up to it or aren't too reliable.
- Make sure there are less distractions, by either asking them to leave when we are busy and want to work or just not letting anyone else into the room. Basic respect from other teams.
- Implement a way to create less bottleneck within our Unity pipeline if we use Unity in the future.