Here we finally are folks, the end of the line. Final sprint review! Our game is finished and I cannot even begin to express how amazing this team has been, they all deserve to be recognized for their hard work! This final sprint review will be a slight mixture of actual sprint review and postmortem, so it will be in a slightly different format than normal. Let us start with our finalized burn down chart.

Sprint 7/ Postmortem: Last one out, hit the lights.

 As of the finalization of this developer log, our game is finished with a total of 470 points and we completed 423 of them!

As you can see we fell slightly behind in our productivity, but as far as ensuring the game itself matched the vision laid out for us, we accomplished our goal! With only 47 points remaining in the backlog, most of them are smaller changes, quality of life changes or simply items that were removed from the game. While obviously we would ideally want to have every single card accomplished, it is nice to know that we did not have to cut any large portion of the content for Into the Woods in order to meet our goals. Next lets move onto things that did not go quite the way we wanted them to.

What went not so right:

 Initial forming: The first few sprints we had a lot of progress in many areas of our team, this led us to focus on those areas of progress instead of ensuring that everyone was progressing the rate we needed them too. This led to complications down the road as work was discovered to be behind in some areas (not due to the developers themselves, so much as myself for not checking in on them).  Fortunately we eventually got everyone on the same pace and were able to prevent it from being a long term issue for the project.

Full plan laid out: While the vision for our project was complete and laid out in the Game Design Document, the cards that were supposed to explain and break down the work for that vision were not always complete. Sometimes the wording would change, or sometimes the card would simply be forgotten until the time came to accomplish the task. As noted in an earlier sprint review, there were some instances where the cards were already accomplished, but were already in the backlog. This lead to us having to spend time investigating the backlog and cleaning it up. While this problem was eventually solved, it created an issue where the backlog was constantly expanding.

Mad Dashers: This was an interesting problem to have, but several team members would accomplish their cards and assignments extremely quickly. This would lead to some teams being very far ahead or some individuals running out of work. This actually helped feed into our previous problem, where we would scramble to assign things and just sort of write up whatever and not sort too much through the backlog. As we cleaned up the backlog and got the first two issues under control, we also began pacing our team members better and this helped remove most of the mad dashes. It also helped that the designer and myself sat down and would make a plan at each sprint start  for what needed to be accomplished. 

But not everything that happened was bad! I just listed that stuff first to get it out of the way, lets talk about what went right for us!

Day 1-End All Stars: From day 1, our team was working their tails off and moving to make this game a reality. I mentioned earlier that the vision was mostly intact from start to finish, and it is completely true! This is most readily understandable when you see how the first and final builds looked when compared to each other.
I personally like to think of it as those "RTX OFF/ON" memes, but any way you slice it, the game looks just like the same game but just BETTER. I really appreciate that our team was able to pull this off.

One Vision, One Purpose: Despite the fact that the cards were not always written well, the vision for the game was written out in the GDD and served as a guide post for so much of this project. It helped when we were scoping the game down and cutting items, but it also helped so we could easily explain to the team what was expected of certain aspects of the project. We wouldnt have to guess at how big something would be, or how important it was planned to be for the players because it was already written down.

Team Communication on demand: While some of the initial team formation was rough, it was not outside of expected parameters. As the team grew together and became acquainted with working with one another, they began spending time hanging out with each other. This team dynamic was encouraged by myself and our Designer so that much so that eventually people were hoping around from section to section, communicating with other teams with out the need for us to do it for them. This really helped with cutting down the amount of time needed to get items across from one section to another, and showed when we accomplished things like last minute bug fixes, model implementation or even animation projects for our enemy models.

So what would we do differently?

Well we would certainly have spent more time on the initial Trello board, this would have served to create a more realistic expectation of how much work needed to be completed.

We also would have enforced deadlines more so that we would not be up so late for something as simple as attempting to build out our game. These sorts of things should be accomplished while the sun is still in the sky, so we can get decent rest.

We also very much would have enforced a naming convention system earlier in the semester, this would not only cut down on the amount of confusion in building the project, but also would have helped us with testing and bug fixes as well. Having 3 different main menu scenes with slightly different names gets old real quick.

What would we do again?

Team cohesion was amazing and we absolutely would have done it again. Having the team all hang out to play minecraft every so often, or sharing what they did on the weekends with each other helped build a form of trust. I believe that also helped them improve their work communications with each other.

Making a plan and sticking to it may have taken a bit, but once we got that system down it worked really well. In the future I think it will be important to adopt a similar system so that we never have to ask ourselves "whats next"?

Before we get to my final bits of what I personally learned, I want you to gaze upon this amazing collection of work that the team put togehter over the semester. Once again, I cannot thank my team enough for the heroic efforts they put into this game. Think of this as a sort of "Best of Into the Woods" if you will:

What did you learn Nathan? 

 Well honestly I learned a lot about time management, not just mine but EVERYONE'S. It honestly has such a big impact for something that is so simple, this one aspect of a game can easily break it down into an mess. 

I learned that buffer time for your team to deal with bugs is important also, there is no way a person can sit there and honestly expect for everything to go all smoothly the first build. It will be nice to have a little bit of leeway in the future to work with.

Trust but verify all things, even your own work. Just because something appears to be done, does not mean that it works. Systems that operate fine functionally on their own could cause major issues when combined with existing systems. Nothing is complete until you ensure that it works in the project itself, not separated and certainly not when its just some random branch of the build. 

And that is it! This was your look at the Production side of Into the Woods, I have been Nathan Beste and I encourage you to check out our game along with the other CAGD games! To my friends and family: thank you for your help and support this semester. To my team: yall  are rockstars and I hope to work with you again some day. Have a great summer everyone, you have officially made it out of the woods!