The Good, The Bad, And The Other Stuff
The development of Bosscraft to this point has been wild with a bunch of different challenges along the way. It’s safe to say there are things the group was good at, and things the group was, to put it bluntly, just bad at. These items were discussed by the team and identified as our greatest strengths and weaknesses.
The demo was consistently on schedule or ahead. Implementation was done in a timely manner and assets were created and implemented as they became necessary and/or available. With one notable hiccup, the animations, the demo went through amazing changes over the course of the term. Huge sweeping design changes were implemented quickly and tested leading to the game concept to becoming much stronger as time went on. While Tim did most of the implementation, the general adaptability of the team to create small edits as needed to implement things quickly was a tremendous factor in the demo being as strong as it is.
The team overall did a good job with the various presentations through the term. The scrums became stronger with every version, likewise the Sell presentations also grew similarly better iteration to iteration. Everyone contributed to the presentation either in actual presenting or in creating the presentations themselves. The members of the group who gravitated towards presenting did so and those who could write and organize them did that. The team worked well together on these and while communication in general was not our strongest suit, we managed to communicate and complete these effectively.
Concept and Design:
The game concept and design is one of the strongest selling points of Bosscraft in general. It takes a bunch of familiar ideas and puts them together in a cool way that is pretty easy to communicate. Our playtesting showed that is an idea people really like. Going back to our earliest brainstorming sessions and the first draft of the Design Doc, the ideas flowed naturally from everyone. Jamila had great insight into how the characters should look. Jeremy instantly saw how the gui should be formed and had good input on the control scheme. Jacob was on top of it when it came to coming up with abilities and mechanics. Tim was able to quickly prototype these ideas so they could quickly evolve. Even later in the term, when the decision was made to drop the development of the prep phase, the game design remained strong. It had to adapt to be more strategic in the battle, but the team easily did that.
Changing how abilities worked not once, but twice, was a huge change to the core gameplay, but the core concept became even stronger.
Easily the weakest aspect of our groups performance. Playtesting was slow coming, inadequate, and hopelessly lopsided. In part it could be chalked up to the difficult nature of playtesting the game. But each member needed to pull more weight in this department. There’s not that much to say about it other than that it should have been much better. With a total of 32 playtesting results at the time of writing this, that’s hardly a slam dunk.
Meetings in general were very sparse. Most communication was 1 on 1 other than a weekly meeting on Skype to discuss the past week and create the presentations. In person meetups and working together as a whole would have vastly helped reduce time spent on several issues, most notably animation in the latter part of development. When we did have meetings they were productive and they were more and more efficient. They were quite helpful in keeping everyone on track. That we didn’t have more of them was a shame, and something that needed to get fixed.
With all the various tools we were forced to use to manage the project, we wound up using all of them rather poorly. Teamwork PM did not feel urgent to the whole team and casual conversations over Facebook or any other communication means were far more common. This had the side effect of the project not being tracked as well as it could have.
The Git repository was not utilized to its full potential. The project and all of its assets were available in a reasonably well organized fashion for every member but it was not utilized to full advantage. Versioning and rapid iteration would have helped identify problem areas quickly and have made the game much more polished.
The Animation Quest
The only major game deliverable we failed to meet was the animations for the characters. Who was responsible changed hands a couple times and on top of that the team members were learning new tools. Individually, the group members were all capable but there was a major communication breakdown in getting these done. This may have been fixed by knowing everyone’s skillset better from the outset. We wanted to mention this separately from the good and bad because while we failed to meet the initial deadlines, the execution and implementation in the end was still solid. It was an important element to the game and learning from what caused the issues is important.
A lot of lessons have been learned and some changes to make instantly come to mind:
- Greater Individual Responsibility
- Every member has been trained in Unity, Modeling, and Animation–they are all capable and should all be able to contribute to the project directly
- Members should know what they are responsible for and who and how it gets delivered
Increased Meeting Frequency
- Simple, meet more, learn what people are doing–avoid the animation debacle
- This is a need rather than a want, it can and must be done better.
- The scope of the game is a little out of control for only one programmer
Asset Scoping and Organization
- Asset lists are very helpful, they should have been used much more often
Overall, the experience was a positive one. There was a lot of individual growth and people trying roles they hadn’t done before. At the end of the day we have to deliver a product and, while it wasn’t what we initially anticipated, we’re proud with what we have accomplished. Our number one request would be more time to do stuff even more justice–maybe in Workshop 2….