Rebound

Custom Engine C++
Producer, VFX Designer/Programmer, Gameplay Designer/Programmer
5 person team, 5 months

The player's ship has no onboard weapons of its own, and can only attack by redirecting enemy fire

We really wanted to go overboard with our particles and feedback. I think we accomplished that goal

Rebound was a really fun project for me. It was my first major game after my medical leave from school, and I actually joined the project about halfway through. The team had had major problems during the first half of production and was struggling to stay afloat after losing several members. I took command of the team, hired two new team members, and charted a course towards success.

To say the first week was challenging would be a major understatement. The two members who remained were badly shell-shocked from their harrowing experience with their old, toxic team members. The two members I hired were in a similar boat, in that their previous team had dissolved due to poor leadership. Nobody felt comfortable with one another either due to mistrust based on their negative experiences with previous teammates or simply because they didn't know each other yet.

As Producer, it was my job to make sure that everyone on the team was capable of performing at their best. This entailed ensuring that everyone felt comfortable enough with one another to freely communicate and cooperate together, having a clear direction for the future of the game, and fairly doling out concise and actionable tasks to each member.

The first hurdle we had to overcome was to pull together and learn how to work with each other. And what better way to bond than with a pizza party? I of course got  everyone's dietary preferences and restrictions beforehand (thankfully nothing came up that would prevent a pizza party); always have to make sure nobody gets left out. We hung out, talked, ate pizza, played video games, and all in all had a blast.

After the party, it was like we were a whole new team. Everybody felt reinvigorated and highly motivated to work on the project. We began by scouring our codebase for two reasons: firstly, so those of us new to the team (myself included) could familiarize themselves with the project; and secondly, to look through and see what was actually usable. Unfortunately, what we found was not very promising. Nearly all (at least 75%) of what the team had produced the previous semester had to be completely overhauled in order to make it serviceable. By the rules of the class, we had to be finished with refactoring our code within the first 5 weeks of the semester. Thus we entered into our first crunch period.

Thankfully, all of our team members were extremely competent and were capable of completing tasks with little micromanagement. We had team meetings every Monday and Thursday where every member shared what they were working on, how they were feeling about it, and whether they needed any help with what they were working on. Any time there was even a shadow of doubt over whether they were capable of completing a task on their own, it was my job to coordinate private meetings between whoever was having difficulty and students from other teams, teaching assistants, or professors. Motivation to continue working at their best was (and is), in my opinion, the single most important factor to a team during crunch time. Everyone on the team was fully capable of accomplishing every task I set before them (it was part of my job to tailor and assign tasks so that they were), so it all came down to two factors: whether the person wanted to do the work, and whether they thought themselves capable of completing the work.

To put this belief into practice, I added an addendum to the end of our Thursday meetings: we shared what we had accomplished over the course of the week; whether we were proud of what we had done, if we were unsure of it, or even if we were unable to finish our task for the week. Regardless of what the person shared, everyone would always give them highly positive feedback and verbal appreciation. The completion of large or particularly difficult tasks were always met with wild adulation from myself and the rest of the team. It is extremely important to create an atmosphere where team members feel comfortable sharing everything about how their work was going and not just when things were going well. Otherwise, you will fall out of touch with your team and be unable to accurately gauge the health of the project. I also continued to bring in cookies, candies, and other treats to reward my hard-working team, which I'm sure also had a positive effect.

Through these methods, we soared through our crunch time, and began to piece together a wonderful game. Although we were out of crunch, it was important not to let our weekly rituals fall by the wayside. Though it may have been convenient to do so, letting them slide would allow my finger to slip off the pulse of our project, preventing me from accurately judging our progress.

We continued in this way for the rest of the semester, growing and learning as a team. At the end of our time together, we had completed a game which  we were all exceptionally proud of. You can even watch the trailer I made for the game  below!