The senior show is rapidly approaching, and everyone is busy cutting reels together and scrambling to put the finishing touches on their games. This is also the time of the year that crunch rears its ugly head. However, here on The Firing Squad, we’ve managed to keep our scope under control. We’re borderline anti-crunch at this point, and I wanted to discuss how we’ve managed to do that this semester.
Firstly, we tired to have a strong vision of what we wanted our game to be at the end of our development cycle. With this, we can develop a rough, skeletal plan of major feature deadlines.
Secondly, and this is the most important activity, each sprint, we planned out the next four sprints. This allowed us to stay ahead of developmental growing pains without pigeon-holing ourselves into an inflexible plan. Each time a sprint grew closer, it would become clearer and clearer so our next sprint was clearly planned, and had at least 4 weeks of thought put into it.
The end result is that we’re feeling the crunch far less than some of our peers, and the project is looking fantastic. I’m incredibly proud of my team for achieving all they’ve done this semester, and I’ve super happy with the final product.
Are you new to blogging, and do you want step-by-step guidance on how to publish and grow your blog? Learn more about our new Blogging for Beginners course and get 50% off through December 10th.
WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.
For the most part, The Firing Squad has worked together exceedingly well, and communication has been more than exceptional. So what happens when team members stop communicating, and how can we fix it?
In my process, first step is always determining the cause in the computational lapse. In this case, a major industry networking event was hot on the minds of some team members. The focus shifted (understandably) to this event and away from the project, and communication levels fell. Now that the conference is passed, we can direct our efforts toward restoring communication.
In some cases, it might be necessary to setup dedicated tasks inside of your management software to facilitate communication. In this case, I did create those tasks, and so far it’s been a great help in plugging communication holes.
I’m keeping a close eye on it, as it’s near the end of our development cycle, and I’ll update how team communication is going in my next blog post.
We just passed our alpha milestone, and the next 4 sprints are looking bright. We scoped appropriately for the time we had to finish the project, and the team is having a blast picking the stretch goals that aren’t so much of a reach anymore. In the next two sprints that make up our beta milestone, we’re working on polishing our existing systems, finalizing assets for menus and UI, adding the 3 remaining weapon parts to complete our part roster, and possibly implementing a duel map and mode time permitting.
We’re excited that we get to dedicate some time to the polish goals we’ve had for a while. We’re on track to finish strong, and we’re hard a work for materials for the senior show. I constructed a rough skeleton of our final trailer, and I’m scripting/scheduling the shoot this sprint so we can have ample time for editing and re-shoots as necessary. We also have a few drafts of our official poster for the gallery.
Overall, the project is progressing fairly smoothly. As soon as I’ve made the first rough cut of the trailer, I’ll post it up here.
Thanks for reading!
We are rapidly hurdling towards the end of our senior project. We only have 4 sprints left before we reach gold master. This means we have to shift to showing off the game, and think about final additions we want to add. Therefore, we have reached out to two underclassmen who have shown interest in producing music for our game/trailer. We had a very productive meeting, and I’m very excited to see what they produce.
Speaking of meetings, we recently had a leads meeting in which we talked about overall team health, project health, and our plan for finishing the semester up. To put it simply, we’re in a great position. Much of our final sprints will be dedicated to polish, and we have a bunch of breathing room for feature completion.
Overall, I’m feeling fantastic about this project, and the rest of the leads feel the same.
Congratulations to the team are in order! We have officially passed the greenlight milestone, and have moved on into production. This means we can really start to execute the plan we’ve had in mind since the beginning of the semester.
This week also marks an important leap forward in implementation. The past 3 sprints we’ve been spooling up and creating, everyone working in separate branches on our repository. Finally, we’ve been able to implement a ton of that work, and it’s made the game so much more. re[Mod] is starting to feel good as a shooter, and that’s an incredibly important point to hit.
However, this new implementation comes with some stumbling blocks as well. Due to the number of things introduced, bugs have reared there ugly heads, and we need to spend some time squashing them. Luckily, the increased number of issues isn’t affecting the feedback we get a QA. Despite a major issue or two, we’re still seeing massive excitement for our game at QA. People recognize it, it generates buzz in the testers that play it, and more often than not players at QA participate in matches above the 1 mandatory match we have them play before filling out the form. QA response quality has also been stellar this semester with far more specific feedback on game systems and bugs.
Overall, we’re in a good place on this project. We’re trucking along and completing our tasks, and most importantly, the plague affecting our team has ceased.
I’ve touched on this topic before, but unfortunately, I have to touch on it again. There are some impediments in development that you can’t avoid, sickness being one of the main pain points. We’ve had a few of our team members who have been suffering from illness after illness, and as the producer I’m concerned. First and foremost, I’m concerned for the well being of those team members. No one wants to be sick, and these two have been dealing with it for nearly the entire semester so far. It’s my sincerest hope that they recover.
So what does this mean for the project? A few members being out of commission means an overall decrease in project velocity. Because of this decreased velocity, we have to start shifting responsibilities for those out of commission onto those who can currently work. This decreases our bandwidth overall for what work we can get done, and we need to make scope adjustments as necessary.
This has been a hit in our productivity, but otherwise, the project is coming along well! We had our greenlight milestone last Wednesday, and I believe it went well. I’m looking forward to what the rest of development has in store. Hopefully, good health!
This sprint is an important one. It’s the last sprint before our first milestone: Greenlight. For this milestone, we need to examine all aspects and moving parts of our project for potential issues, and work on possible solutions we could implement down the line during production.
Luckily, we’ve been doing this proactively throughout production, so many of the requirements of this milestone have been completed already. This lets us focus on starting to implement and solve the problems we’ve identified instead of spending entire sprints doing documentation.
My team and I are feeling confident that we’ll pass the greenlight requirement, but we’re spending this sprint to cover all our bases and ensure we’re set.
Last sprint, we sprint failed. When this happens, the most important question to ask first is “why did we sprint fail?” Understanding why allows us to learn from the mistakes that occurred last sprint, and implement systems and contingencies to prevent them in the future. This can solve communication problems, pipeline issues, and a whole other host of production maladies.
So how about dealing with things outside of our ability to quickly fix? We had some of these issues last sprint, mainly in the form of loss of velocity due to sickness, and loss of velocity due to technical issues we did not have control over. Two of our team members were sick with the flu last sprint. Specifically, two members went through the rise and fall of the worst of their flu systems this sprint, meaning we estimated workload for less sick people than thought. This caused us to miss some tasks.
The second part of our problem has to do with all too common technical issues. There were some apparent issues with how the lab computers were imaged between semesters, and it has caused some massive issues logging into and completing basic functions on them. This added some massive overhead to any task being completed on a lab computer (for example, it took one hour of setup and troubleshooting alone in order for one of our programmers to begin work). These problems were out of our ability to fix, as they’re handled by the Champlain tech crew.
The key in dealing with situations like this is not attempting to fix a problem outside of your control, and rather adjust required work to fit current velocity. We’ve adjusted based on this for next sprint (now that yet another team member is sick), and we’re hoping that we’ll have a smoother sprint this time.
Project initialization is my favorite time in development. Every person on the team is fresh and recharged; ready to dash into the project with a re-invigorated sense of motivation. In our case, we have new members coming on to the team, who offer new insights and ideas to the project, and find creative solutions to existing problems.
This also means our work hours bandwidth increases by about double! However, this does not mean velocity increases by double. In facet, the opposite might be true. The addition of new team members can bring changes to the team dynamic, which in turn change the velocity of a team. I’m closely monitoring not just how well we work together, but how we work together in hopes of fostering a positive team dynamic early. Happy team = happy project!
I have no major worries about the team moving forward. I’m excited to work with such talented individuals, and I’m sure we’ll have a great time.
I’m back from a brief hiatus to talk about the outcomes of our project this semester. I’ll start by confirming that our project was approved by the faculty for another semester of development. Our team is supremely excited to hear that news, and we’re incredibly motivated to make our game a fantastic experience next semester.
Because of this, we’ve taken on 4 new team members: one artist, one programmer, and two designers. They’ll give us enough development velocity to implement the myriad of features and tweaks we have planned.
So on to the actual postmortem. I’m going to follow the classic “what went well, what went not so well, what could have been done better, and what was learned” model of the game postmortem, framing my thoughts in bullet points about the game and the process we went through to get it where it is.
What went well
- Very little team conflict. We worked well with each other, and were in agreement on most game matters. The only big conflict we had was right at the beginning when we were deciding what engine we would use for development, and even that was solved rationally.
- The team took to the scrum framework well. Everyone was comfortable with agile overall, which allowed us to focus more on the project and less on the logistics.
- 1 week sprints helped us showcase our iterative process well when it came to the final.
- Sprint planning meetings became shorter and shorter because of everyone’s ability to work with redmine and understand each other’s workflows.
- We never “officially” sprint failed! We had roughly 95-100% of our tasks completed each sprint, and even then tasks were only rejected due to a focus change, and not due to lack of ability.
- Slack was a great medium for communication, and we all used it to it’s fullest.
- QA usually gave great response. People enjoyed the game massively, and on occasion came back to play it again after they had finished all the other games.
- I enjoyed the QA process.
What went not so well
- We had some unavoidable illness that made a few sprints a bit difficult
- Marketing wasn’t as strong as it could have been. I have to re-examine my ability in this category for next semester to be better prepared.
- Our game had some feedback issues in the end that caused the faculty to have trouble with the premise overall.
- Overall art was a bit “safe”. We could have pushed some areas to make it a bit more visually stimulating.
- Unity was an unconventional choice for a first person shooter, and unreal would have fit the project content better. Our art team would have been more appreciative as well.
What could have been done better
- We could have managed our trailer building a bit better. We did it in an unorthodox manor, and it ended up causing issues.
- My blog posts could stand to be longer.
- I missed scheduling a room for my team a few times.
What was learned
- Proper versioning and repository management helps a project massively
- the FPS crowd is hard to please
- Player feedback matters a lot
- Networking is an undertaking on a 3 month project
- Players a quite sensitive to things they perceive as unfair.
- Angry QA testers leave bad feedback.