Part-Time Production: Tips for a Ragtag Team
Rome wasn’t built in a day, as the saying goes, but neither was it made by a single person. It required a number of different people with different contributions towards a common goal. Similarly, game development needs people from multiple walks of life all working toward a polished, fun experience. Managing development, however, can be difficult especially in the case of part-time development. To hopefully help you avoid some of the pitfalls we struggled with, I’ll be discussing some of these trappings and how we worked to overcome them on our VR title: Batteries Included.
Development Challenges
First, let’s discuss some of the issues we faced on the project’s development …
Varied Work Schedules
Our team was working on the project part-time, which meant fixed group development time was scarce.
Design → Prototype → Playtest
Game development requires iterating on ideas quickly … with VR, that is even more true due to the unique challenges it provides. Getting ideas from design to prototype has to be quick and (just as importantly) clear! Any time spent deciphering confusing designs or re-explaining them is development time lost. In our case, varied team schedules made clear communication vital to our development.
Virtual Reality Accessibility
Only half of our team had access to VR headsets, which meant that the other half had to go through extra hoops in order to see their ideas/developments tested in the headset. This made time to access the headset a valuable commodity throughout development.
Solutions
To combat these challenges, we came up with a few solutions that worked around our particular situation. We needed to find some means of managing development around everyone’s varied schedules, minimizing turnaround on the iterative process, and better utilizing time with the headset. Through a lot of trial and error, we’ve come to the system we’re using now which has helped us be more productive by leaps-and-bounds! Let’s take a look at some of the highlight ideas …
Lead Roles
Our first priority was keeping the iterative process quick and efficient. For us, that meant assigning one ‘lead’ for both the designers and programmers. These ‘leads’ serve as representatives for their respective teams, handling communication between design and implementation with the hope of each team having more time to focus on their respective tasks.
 |
| Development Pipeline |
This helps alleviate some of our development struggles in the following ways:
- Designers/programmers can focus on putting out content, with the leads ensuring a steady flow of work
- Having the leads clarify designs before passing them to programmers (hopefully) minimizes the need for programmers to seek out about design questions
- Leads have a higher-level overview of what their members are doing, which helps keep the long-term roadmap (and progress along it) clear
Team Workshops
As mentioned before, time for full-team meetings was scarce and often consisted of meetings due to limited access to a development station. Our solution? Team workshops! |
| Team Development Schedule |
In short, our goal was to concentrate each of our work meetings toward specific focuses of development. For our development, we used 2-week sprints with three main events:
- Task Updates - For this, leads would discuss the designs and tasks before delegating to their respective teams. Any progress, roadblocks, or other updates would then take place in these team-specific meetings.
- Short Workshop - This block was for anything that needed resolved in the short term. If designers needed to rework some of their material, code merges needed to be handled, or if there were any major updates to be made they would happen here.
- Long Workshop - The last day of the sprint consisted of a long workshop wherein we brought 2 VR setups to one location and worked for as long as possible on the remaining tasks of the sprint. This worked well as it allowed for two different operations (bug fixes, feature implementation, playtests, …) to be run simultaneously. This also greatly improved team morale since we could see any changes hot off the presses!
Final Remarks
Game development alone can be very draining with the ebbs and flows of development. It can be even more so when it feels like your development process is disjointed, leaving everything moving at a snail's pace. But it's important to persevere through it, always be open to try new approaches, and keep your development process iterating alongside your game. A more polished (and hopefully engaging) development process will help keep team morale high as you make progress towards completing your game.
Comments
Post a Comment