This is the post-mortem originally created for the game by the entire group.

Did we achieve the game you set out to make in the proposal?

We believe that we were mostly able to achieve the game we set out to make in our proposal. We successfully created a game with the gameplay and aesthetic layed out in our planning document: a Pokemon Ranger “clone” set on a wild-west-themed planet where you capture bees by drawing lines. Where we failed in achieving our goal was in the amount of content we set out to create. We had initially planned for a more in-depth overworld, more interaction between the player and the bees, more bee variants, more/longer levels, etc. This goal was not achieved mainly due to over-scoping and a lack of time. We severely overestimated the amount of time each of us would have to contribute to the project each week, as well as the amount of time it would take to implement certain ideas. Overall though, we are happy with the work we were able to accomplish, as it feels like a demo for the game we had initially planned to create.

What went right?

1. Ideation and Planning Our planning and pre-production went very smoothly. We have all been on the same page since the beginning when it came to what our game would be like and where our game would go. We knew that we wanted to make Ready Robot almost immediately and that we wanted to make it about a cute wild-west robot. This allowed us to hone in on the exact experience we wanted for the players and allowed us to get to work fast. There were also very little to no arguments over the direction of the game. We all stayed agreeable when new ideas came to the table, and never shot anything down, which kept us always moving forward. 
2. Modular Development From the beginning, we programmed all of our systems to be simple and modular in the hopes that code could be reused and that new systems could be added in with relative ease. Doing so really helped to cut down on the development time of later additions like the final version of combat and enemy variants. This not only helped us get our minimum viable product done very quickly, but it also helped us to make large additions to the game without too much hassle.

What went wrong?

1. Hitting Due Dates - This problem hit us almost immediately. Right from the start, some of us struggled to keep up with the workload and to get the work they assigned themselves in on time. This is most apparent when looking at the first “build” of the game. Only one person got tangible work done (Alessandro), leaving us with nothing but a non-intractable wandering square on a blank blue background. Things never got as bad as with that first sprint, as we all did our best to get something done for each sprint, though it wasn’t always as much as we had planned or what people set out to do. One of the reasons was of course time management; we all had other classes vying for our attention and time, so we couldn’t always work on the game. We also all faced burnout during different points in the development process. Earlier use of our Trello board and smaller deadlines in the middle of the sprints could have mitigated this issue.
2. Scope - During each sprint plan for Ready Robot, we would always over-scope. Plans for entirely new features and additions would have to be either dropped or pushed back each sprint, which resulted in lower morale and in a lot of cut content. Some of the things we dropped included locked doors (which could be opened when enough bees were captured), at least 6 additional bee variants as outlined in our planning doc, and the planned terraforming mechanic that the game gets its subtitle from. Our planned combat gameplay (drawing loops around an enemy) was almost cut as well, but just barely made it in. All of this unfinished and cut content could have been avoided with more careful planning, keeping our scope low, and potentially the addition of a “Stretch Goals section to keep our priorities in check.

What are the lessons you learned?

1. The main thing that we learned was to set up clear communication channels from the very beginning as well as clear communication expectations. This would have helped all members of the team to stay on the same page in regards to what was being worked on. 
2. We also learned to have a clearer division of labor while still encouraging flexibility. While we had clear roles, this ended up meaning that certain aspects of development got left to the wayside because they didn't fall neatly into one person's 'role'.