Update 08: Small Team Making an MMO!?
Can a small team really make an MMO?
Team
Creating an MMO can be a massive undertaking. Fortunately, a reminder of this is in the name.
So, rather than set out from day one to boil the ocean, we’re starting with a “proof of concept.”
In my experience, most games start with a core team, which prototypes, concepts, iterates, and validates, prior to moving into full production and scaling (both the content and the team).
These internal R&D or prototype teams are typically small for good reason. You don’t want too many cooks in the kitchen, and bigger prototype teams often operate under more time pressure, due to cost.
When a team is smaller & less expensive, and left alone (i.e. isn’t being nudged toward rapidly making the next Battle Royale), it gives the team time to experiment, iterate on core design, build team chemistry, and identify potential skill needs.
The current Project_N proof of concept team is no different from one of these small internal prototype teams.
Process
Within larger companies or when working with publishers, this proof of concept period also frequently requires the team to work through a series of “stage/phase gates” or “greenlight” processes.
These typically require the team to convince executive teams, members of the Board, fellow producers, marketing, sales, external producers, and any number of other stakeholders, that the prototype or proof of concept is worthy of making it to the next stage in development.
Every company does this a little bit different.
Some processes are solid, some are a completely political clownshow, and many come down to which team has the best salesman at the helm.
This can lead to teams spending more time focusing on the process, politics, or pitch - than the product.
And rarely, if ever, have I seen this process include the voice of the players (aside, from someone’s interpretation of the latest market research or focus group).
Communication
A key difference in what we’re doing, and why it may seem incredibly early for us to be showing anything at all, is that we’ve included our community from Day 1.
So, think of our small team as a core concept/pitch team - only we’re discussing our concepts openly, with our players from the very start.
We want our community and our conversations to serve as that vetting & greenlight process; not a gathering of execs or investors that likely wouldn’t play the game anyway.
This doesn’t mean that we’re looking to design by committee or lack specific ideas of where we’d like to head with the game.
And when things are a bit fuzzy or iffy, we’re open about that as well - and as a result have received some incredibly good feedback and ideas.
Finally, should we hit a point where we think things just aren’t working (the concept, team, funding, whatever), we’ll have that conversation, and I’d hope that our community learns from our process: its wins and failures.
Execution
The approach we’re taking is about staying lean as a team, learning what we need to eventually scale, and being open with our thoughts & checking them within the community we’re hoping to play with in the years to come.
We know that the most important thing is what people think once they’ve got the game in their hands. The culmination of our ideas and decisions will eventually be seen by players.
Ideas, theories, communication, and even updates like this are fine, but execution is everything.
So why lurk in the shadows and pontificate for months or years, only to have our players call bullshit on it later, when we could have just discussed it in real time?
at the conclusion of this process, we’ll use the metrics and foundation we’ve established during the proof of concept to scale our ability to deliver the larger game world accordingly.
And we’ll use those learnings to dictate the size of team we’ll need to deliver a game we’ve determined to be worth making.