Builder's Brawl Postmortem
Hello everyone, Sam Boydstun here to deliver the final postmortem for Builder's Brawl. A very long journey it has been to get to this point, as the game has traversed two separate semesters at California State University, Chico and has been a labor of love for 25 students over that time. In this post I'm going to share with you some of the accomplishments we achieved as a team this semester, what went right in development and what went wrong, and finally some of the lessons we will take with us in our future endeavors.
What We Achieved:
- Camera System: Overhauled
- Ragdoll Physics Introduced
- 2 New Levels ( Mushroom / Island )
- 2 New Gameplay Features (Boards of Differing Sizes / Limited Boards)
- 4 New Environmental Effects
- 10 New Visual Effects Added
- User Interface: Overhauled
- Victory Screen: Implemented
- End Screen: Overhauled
- Level Select Screen: Overhauled
- Tutorial (Free Play Level): Implemented
- Complete Sound Design: Implemented
- Complete Student Composed Music (8 in Total)
- Visual Update to all past 5 levels (60 Assets)
- Volcano Level: 90% of Models Updated
- River Level: 75% of Models Updated
- includes Characters / Boards / All Trees / Rocks ect.
- Animations: Overhauled - (Run, Board Slam. Idles)
- Personalities for characters implemented
To simplify this long list of accomplishments, this semester the team completed an almost full graphical and user interface update along with two new gameplay features. We implemented clarity features like a control screen and a free play level that gives players the ability to mess around and learn the game before real combat. The game now boasts full sound design that includes 8 student composed music scores, and a complete overhaul to the way its camera system works to better player experience. The team worked extremely hard to make this game as polished as it is, and I believe in this long list their work speaks for itself.
The "Right"
1. Pre-Production
First and foremost the beauty of continuing a game along into a second semester of development is that much of the pre-production on the project is completed. Many of the same team members rolled over onto the new team including the producer and several of the engineers and this gave the development a ton of legitimacy in both its proposed scope and vision. Heading into the second wave of development we already had nailed down several documents that included all of our sound design tasks, our visual effects tasks and a basic "how-to" on creating levels. From early on the new members on the team were given the resources to get up to speed and on task to creating content that was consistent with the base game.
Furthermore, we knew from previous play-testing that our game was fun that our core gameplay loop was engaging. Players enjoyed pushing each other off cliffs and hitting each other with boards and our main goal from the beginning was to leave this interaction totally intact and focus on polishing the rest of the game. The time we spent over the summer preparing to pitch and deliver the game in the fall lead to a clean and direct vision of how we would progress Builder's Brawl.
2. Playtesting and Feedback
One of the greatest focal points added to development was a playtest schedule. For a game that had already seen several playtests that were not properly managed, we decided to really sit down and find out if the information we were asking was really helping us make a better game. To fix this, a large amount of time was put forth to develop the questionnaire in which we employed Psychology and directed questions to find out what our players really did know about the game all the while not leading them into any answers. Every single feature in the game was posed with a series of three questions. Did you notice said feature, how did you notice it, and what were your feelings on it. (Yes/No Recognizance, UI Element, Emotion). Next we held a fresh playtest full of people who had never played the game even once.
What we found was that our game had a very glaring issue with clarity, it wasn't clear to our players all the abilities they could use and what the point of the game was. Was it a game about racing to the flag, or was it about building? Oh and why are there points involved? Previously those we had playtested we never posed these questions, it was more focused around the design or bugs they encountered. This level of playtest opened our eyes and completely changed our development cycle for the better. We had time to fix the issues and bring about calm.
3. Flexibility of Schedule/Scope
Due to this flexibility, we were able to finish all of the primary and secondary features proposed during pre-production and even some of our wishlist features such as color specific personalities for the characters. If anything came up we were always in the position to pivot and accomplish it and because of this the game ended up having a ton of features we had only dreamed about.
The "Wrong"
1. Lack of Feature Polish
Builder's Brawl has a ton of features. The game includes 7 levels and 6 environmental effects that occur on some of those levels that can impact players including fireballs, lightning, sandstorms, and acid clouds. There are moving animals in the scenery, animated environments, ragdoll physics, full sound design, unique building mechanics and a round based based game design complete with a free play tutorial to start every series, an end screen after every level and a victory screen at the end. All of this is followed by a points system that is tracked through each level and awards a winner at the end of three games.
After naming off all of those features, would you be surprised to learn that not all of them are polished and fully playtested? Builder's Brawl in many ways suffers from the creep that happens to dreaming designers and bell and whistle loving players. Though we completed all of these features and implemented them into the game, many are not playtested and iterated upon much past their inclusion into the game and local testing. Though we added features to address clarity, we never had the time to conduct another playtest to follow up on whether our efforts were truly successful. When it comes to the beautiful environmental effects, many also suffer from the fact that they don't necessarily feel dangerous and an overall lack of player feedback.
2. The Bells and Whistles
Starting out in the second cycle of development one thing became really clear, it was important for us to boost the art and update the game visually across the board. In our long list of updates we had gameplay features near the top followed only by implementing a ragdoll physics engine. In the way that it turned out, implementing a physics update caused our top engineer to be occupied for much of the development cycle. Thus many of our simpler but major gameplay changes like updating our push ability, came really late in sprint 6 out of 7 total sprints. At the end of the day we were so focused on the art and making the game professional that we neglected one of the core ideas of game design, in that the beyond any visuals the gameplay comes first and foremost.
What we ended up with is a visually appealing product and one that delivers totally on creating a world that feels alive and engaging. The only regret we can say then is that had we spent alittle less time trying to figure out how to get visual effects working and changing what we had already previously made, our combat could of been tighter. It still stands that its fun and engaging to our players, but more fluidity in the way our abilities worked could of really boosted it over the edge.
3. The Monotony of Continued Development
Before I start, this wrong in many ways is more of a lesson than truly anything that hurt our production. As students we often develop games in short periods of time, iterating an idea from start to finish and coming out with a decently composed product. Builder's Brawl however had the pleasure and honor to be carried on into another semester with another class. Thus for one of the first times in many of these students careers they experienced what it's like to work on a game that has a basis and a framework behind it and how development differs from trying to get a project off the ground.
Thus, we experienced what it felt like to come in and work on a project that needed in often cases boring visual updates and bug fixes. Retexture this rock, change this small gameplay feature, tweak this level. In a lot of ways we never pushed to really go outside of our scope and therefore many decisions were safe and calculated and ended up being not the most exciting decisions. We didn't push for new abilities and crazy new mechanics, and halfway through development we could feel the lull around the team.
The Lessons:
All of these rights and wrongs lead us finally, to the lessons. Lessons that we will take with us in our adventures and futures as professionals.
Embrace the chaos of development
Things go wrong. Its one of the easiest things to realize when developing games. The harder thing to realize is, we can fix it. Working with agile development and talented individuals we have the ability to change and morph our schedule, overcome the hurdles and still accomplish the goals we set out in the very beginning. Even when everything seems to be on fire and features are not working, there will always be light at the end as we make the necessary sacrifices to make it happen.
Design from your pillars
An engaging game can be built with capsules and boxes and if the gameplay is awesome, the game will be awesome. Too often we get wrapped up in visual features that inspire emotion and stimulation in our eyes that we forget that the true design of any game is wholly in its mechanics and their implementation. Breaking down design and allowing our pillars to guide us will have us accomplish the same emotion and much more engagement than anything visual can deliver.
Account time to test everything you implement
An obvious lesson that was often overlooked in our case is that the development cycle should take into account that every decision is followed with careful testing and player feedback. Even if we ended up with less features than we have currently, we could of polished them and made them perfect and that would of been more impactful than quantity. Player feedback is always key, they are our lifeblood.
Embrace Criticism
Not all feedback for your game will be positive, and many times during development we were challenged on a very key question, "why?" Embracing this criticism allowed us to really focus on what decisions we were making for the game's success and trajectory, and further it allowed us to see from a different perspective. Its hard to deal with especially when we so often look for support and praise in our projects, but it's a reality that criticism makes us stronger designers, modelers, animators, engineers, producers.. and as a direct result, makes our games better.
BE PASSIONATE
There is nothing like the feeling of finishing Builder's Brawl and having the ability to watch our players yell and scream as they joust for position running for the winning flag. In moments of despair about development, or moments of tedious long hours of work, we all never wavered from the fact that this was something that was better than anything else. Producing this game was exactly what I personally wanted to be doing with my time, working with my team even if it was countless hours outside of school and on the weekends. We loved being together and working on a project we knew would make many people including ourselves proud. Many of us dreamed about doing this kind of work as children and whatever the hours we are excited to continue it in our professional careers. At the end of the day, we are making video games and that trumps any low that tries to set us off course.
In Finale,
A special thanks to all of the team that worked on Builder's Brawl, one year ago we set out to make an ambitious project and in many ways we succeeded both growing professionally and personally. The hard work of these students will forever be honored in the quality of game we produced. We can be happy with the way we represented ourselves and our proud university.
Thank you - The BB Team
Get Builders Brawl
Builders Brawl
You are clumsy and average, the worst builder you know.. luckily so are they
More posts
- Dev Log 10 - w/ BurndownNov 13, 2019
- Dev Log 9Oct 28, 2019
- Dev Log 8Oct 17, 2019
- Dev Log 7Sep 29, 2019
- Builder's Brawl Continues Development!Sep 16, 2019
- Builder's Brawl - PostmotermMay 17, 2019
- Dev Log 6Apr 29, 2019
- Dev Log 5Apr 16, 2019
- Dev Log 4Apr 02, 2019
Leave a comment
Log in with itch.io to leave a comment.