← View other post-mortems
Post-mortem

Condylura

Dylan Smith
Lv. 7
Dylan Smith Level 7
· 4 min read · 68 views
Condylura
Condylura
· 17th
Condylura Post-Mortem

<Written by Dylan Smith, Design and Programming lead>

What went well
  • Production and break scheduling was done rather well. By assigning tasks and a general time frame before the onset of the jam, our team was able to maximize our time and talents to bring together a functional game (where most of our team had never made a game before).

  • By designing the levels and mechanics on paper before a single line of code was written, we were able to ensure that the different elements in the game made sense and would interplay well in a digital format.

  • By assigning tasks within our team based on prior skill/experience, we were able to maximize our personal productivity. However, this also meant that some team members had a heavier workload than others (expanded upon below).

What could have gone better
  • Our game was lacking in mechanical fidelity and polish because we attempted to implement too many mechanics that none of us had experience creating before.

  • Because so many members of our team had little to no experience developing a game, establishing a good iterative workflow was difficult at first.

  • Because we focused so much on pre-production design, we were fairly locked-in to our game and development became an uncomfortably structured process. I would have preferred a more open-ended design with room for iteration and improvement.

  • Having a larger, inexperienced team presented issues with scheduling and work ethic. We attempted a regimented sleep and break schedule to ensure at least one person was working at a time, while in hindsight it would have been indescribably better to rest as a team and work as a team. It proved difficult to keep working when most of the team was asleep, and difficult to force oneself asleep while everybody else was working.

Personal Thoughts

All in all, I'm not especially thrilled with either the development process nor the final project this time around. Having as large and as inexperienced a team as we did made development a bit of a hassle, and having such a structured design plan made the game less fun to develop overall.

The biggest lessons I will pull into the next jam are as such:

  1. Work with a smaller team.

Having less people may seem like a setback, but when you only have 48 hours it pays to only have to communicate your ideas, thoughts, and concerns with one person than with half a dozen.

  1. Leave your design open-ended.

Don't worry so much about pre-production that you wall yourself into a game with no room to iterate or make changes. Make sure your team does this as well, with every portion of the design process.

  1. If you are the most experienced on your team, don't be afraid to give them advice/correct them.

The biggest mistake I personally made during this last jam was being too quiet within my team. I was worried about making the jam a fun and friendly experience for my team, but in doing so I feel I may have ended up accomplishing the opposite. I realize in hindsight that, especially during a game jam, it is better to have one's work criticized and/or corrected during development than to realize only too late the mistakes you made.

  1. In a team? Work as a team.

It was my speculation going into this jam that if my team worked non-stop, taking offset individual rests, it would feel as though more is being accomplished. This is absolutely not the case. If you're in a team, make sure you are all working at the same time. This will make the whole ordeal feel better for everybody, for a number of reasons.

  1. Have fun with it.

After all, isn't that why we make games? Use these jams to try something new, something goofy, and see where it takes you. My favourite time in a jam was making a game that I couldn't see the end of. Go with the flow and see where your imagination takes you. You might end up loving it.