Now, when I say “Netflix-style” in the title, I’m not referring to the idea of having people pay a subscription to access infinitely a library of games until the time comes where they stop paying their subscription, because that idea is bad. Instead, what I’m postulating on is the idea of a game development strategy inspired by Netflix’s content production pipeline, although the translation isn’t exactly 1-to-1.
So, we’re mainly focusing on the concept of Netflix Originals, which is the name given to projects that are produced, or co-produced, by Netflix. These projects have basically nothing to do with each other, except when they do, such as in the case of the interconnected Marvel/Netflix collaborations like Daredevil and Jessica Jones.
Vaguely inspired by this format, I present the Netflix-Style Development Strategy for Video Games, which you can tell is important, because it’s capitalized. It’s meant for a medium-sized development team, of probably at least 12 team members, with a fairly even distribution of specialties.
The first part of the Strategy is what I would call the Preparatory Stage. During this time, team members pitch the concepts for games they want to make, perhaps in the form of a game jam to produce prototypes, much as how Double Fine has done in the past. From these projects, the entire team selects a number of projects that they A) feel passionate about, and B) feel are similar gameplay-wise to the other selected project. Obviously, this judgement process might be a bit laborious, but it’s important that the projects selected share a good number of mechanical characteristics. These projects together compose what is called a Season.
With a Season selected, the Prep Stage ends and a new part of the Strategy, called the Group Stage, begins. Here, the entire team is working together, basically developing code, art, and design that all of the games can share. Programmers are developing general code for movement, inventory, menus, etc. that all of the games can share, as well as code for any mechanics the games share (here’s where the Season being cohesive comes into play. The more commonalities in the games’ mechanics, the more work can be done by the entire team during the Group Stage). Artists and sound designers make general assets that all of the games can use (crates, doors, GUI, grunts, whatever).
Once all of the common assets are developed, and all the work that remains would be specific only to a subset of the games in the Season, the Group Stage ends. Everyone who pitched a game selected for the Season becomes the new project lead on their game. They then create a small team out of whatever roles they cannot fill, and these teams divide, marking the start of the Cluster Stage.
During the Cluster Stage, there are a lot of small teams working on their own separate projects, building upon the general-use code and assets developed during the Group Stage to fit the needs of their own game. Maybe the RPG team is working out their leveling-up mechanics, while the shoot-em-up team is working on bullet behavior. The teams don’t break communication, however: optimizations and improvements made to the common code and assets get redistributed out to every team, and team members are free to ask for help and input from one another, and are in fact encouraged to do so. Ideally, the Clusters are still all working in the same space.
The games of the Season don’t release at the same time. The smallest project of the Season gets released first, at which point the team members from that project disperse out into the other projects. This continues until the entire team is finishing up the last game of the Season. Once that’s out, the Clusters are formally disbanded and the process starts anew.
Obviously, my experience with formal game development is limited as a student, but this is more of a thought experiment than a legitimate suggestion. As far as I can see, here are the positives and negatives of this design strategy:
PRO: Everyone gets a chance to be Creative Director
Everyone can pitch an idea or make a game during a jam during the Preparation Stage, meaning anyone has a chance to have their game be selected and produced.
PRO: Highly efficient
This is obvious. Anything that could be shared is, and no work is repeated amongst the Clusters. Furthermore, a nice, dense release schedule of games is ensured by staggering releases. Small teams making small games get to finish fast and release fast, while bigger games get slowly bigger teams, and get longer development time.
CON: Big teams can be suffocated by bad scheduling
If smaller teams take longer than they expected to release their smaller projects (which will almost certainly happen), the teams making bigger teams will have to carry their much larger workload on their few shoulders for longer, desperately waiting for new team members to come help shoulder the burden.
PRO: Big teams speed through heavy lifting, small teams work on passion projects
During the Group Phase, the entire team can combine their knowledge to hammer out the more generic and boring parts of the game, freeing individuals in the Cluster Phase to work on the things that they are interested in.
CON: Games come out samey
Since all of the games in a Season share assets and code, they’ll all probably be extremely reminiscent of each other
PRO: You’re releasing an anthology, not an epic
This is just a rethinking of the previous con: your team is instead working on smaller, related projects, giving them the chance to do some experimental stuff without using the entire organization’s resources on it.
PRO: Speed up acclimation of late arrivals to teams
When a game ships, the team members disperse out into the remaining Clusters. However, they don’t need to acclimate as much as a completely new team member would: they saw the game when it was pitched, they worked on a lot of the shared assets, and they watched and helped out with a lot of development previously, so getting up to speed is much quicker.
I don’t intend for this to be the last post about this idea. As I think about this strategy, and work on more game development teams, I want to refine this (probably crap) idea using my experience into one that might be one day actionable in my own indie studio.