Sprint 8 (Mar 02 - Mar 06, 2026)

Sprint #8 3/2-2/6 - Wrap Up Week!

Production Goals for the Week:

To wrap up our final week, the team ran a post-mortem meeting. Here are our key takeaways and lessons that we compiled.

Lesson 1: Get comfortable being critical of your own work.

Our iteration process meant we were constantly going back and overwriting existing work. This required us to be open to feedback and critical of our own work. Our process reminded us that it’s okay for things to not be perfect on the first go.

Lesson 2: Perfectionism is the enemy.

We quickly learned that you can’t be a perfectionist, especially with such a short production timeline. It’s an easy trap to fall into but it will take time away from more important tasks. It’s okay for things to just be good enough.

Lesson 3: Beware of overscoping!

Coming into the project, we tried so hard not to overscope. This project proved to us that no matter how much you cut down on your ideas, scope creep will try to convince you to add new, cool, convenient features all along the way. Always keep your project’s feasibility in mind.

We very quickly went from a project that seemed reasonable to having so much more work than we could reasonably complete. We rushed features and didn’t properly maintain our code, naturally leading to increased technical debt. The more decisions or assets you make the harder it is to redirect back to a proper level of scope.

Unfortunately, the scope creep also led to a significant decrease in the team's overall work-life balance. Many team members started working more than the required eight hours a day, some staying very late into the night.

Lesson 4: Platformers are a difficult genre of game to make.

2D platformers are a well-established game genre, meaning there are high expectations for what makes a good platformer. We underestimated the difficulty of tweaking a platformer and adjusting for game feel. Our first rounds of playtesting showed us that many of our initial design decisions were incompatible, meaning we would need more iteration than we anticipated to get the satisfying game feel that we wanted.

We sometimes found ourselves comparing our progress to other projects in the studio. We worried about being behind compared to other teams. We realized after the fact that we can’t possibly compare our progress to other games, especially ones of different genres. Every game is different so every development process is going to be different.

For future projects, if you’re starting to feel this way, focus on your project and its strengths. Trust your teammates and trust that your project will come together.

Lesson 5: You will learn a lot about developing and making a game.

As we’ve discussed, we failed a lot and we iterated a lot. But this also meant that we learned a lot. For many of us, getting thrown headfirst into the project was the best way to learn about the game development process. This project gave us the opportunity to solidify and fully understand what we already knew about the theory and best practices of game development.

Lesson 6: Development takes time.

One of our biggest takeaways from the experience was that things will take longer than you expect. This project showed us that that development takes time and that you probably will not finish everything you initially planned.

Lesson 7: Communicate early and consistently.

We made sure to communicate our expectations for the project, ourselves, and each other at the start of the project. We also set boundaries in terms of work-life balance and working collaboratively. This helped us set the stage.

However, we encountered difficulty keeping up with consistent communication during production. In particular, we sometimes found ourselves just doing things and not properly informing the team and failing to communicate about team dynamic issues until after they were an issue. Our biggest communication failure was related to being on the same page about our final version of the project. During post mortem, we realized that we all had different definitions of the word polish, which had caused some teammates to feel dissatisfied with the game’s level of polish whereas other team members thought they had been polishing the game for multiple weeks. Looking back, we could have done a better job communicating with each other what our ideas of “polish” and “complete” for the project were.

Lesson 8: Working together in the same place every day was so important to us.

The team all agreed that working together in the lab boosted our productivity. We didn’t have to deal with scheduling headaches or having to wait for meeting time to communicate with one another. We strongly encourage future teams to work together in the same place as much as possible.

Lesson 9: You don’t know what you don’t know, and that’s okay.

This project was a massive learning experience for all of us. It’s okay to look back and realize you did something “wrong”. That’s what learning is for. Being flexible and willing to adapt as you learn more about the strengths and weaknesses of your project will make your project and you better.

Lesson 10: Working on a game is fun!

Despite all of the hard work and challenges we faced, we had fun. Making a game is such an amazing opportunity to do something you’ve spent years prepared for. It should be fun! We specifically spent time together outside of the project grabbing food or playing games and intentionally made our Sprint Showcases silly for the fun of it. Don’t take yourself too seriously!