Count Floyd knows what he is talking about. Open worlds are great when they are vast, but for the team developing those worlds, it can be SCARY! But wait… now that we have Crowd Sourcing, we not only have terrified teams of developers we also have panicked patrons that have already bought into these worlds. For the latter, they may have a longer wait for their prepaid adventures if those worlds fall behind schedule. Some of these lofty open world projects might even fall in the event horizon of vaporware. Having had ongoing nightmares from both perspectives, I propose the old design adage, KISS, (Keep It Simple, Stupid) be updated for MMO’s and Open Worlds. Just like the worlds the acronym is often applied to, KISS should be extensible, such as… KISSASS (Keep It Simple, Stupid And Sensible Scope.)
Sure! This is a bit of fun on my part, but having fought through many world design battlegrounds and taking note of worlds in development, this updated design mantra is needed. All too often, open worlds spawn delusions of grandeur that can make many developers oblivious to the oncoming ‘Reality Train.’ And when that train hits, which it always does, things start to get axed, schedules are altered and sometime, good devs are even let go. The entire project takes a massive hit and the repercussions are felt within the gaming community. What might have been a grand game world becomes simply sufficient or lacking.
My current opinion on the matter is that open worlds should be developed in a smaller scope. Indeed, most are already designed that way when dev teams devote early milestones to the development of a portion of the world that contains every feature within its strata. This is sometimes called a Vertical Slice of the world and it can prove the effectiveness of each feature intended and reveal weaknesses in content and world design. If the vertical slice tastes good, then the whole pie should taste the same. Unfortunately, the intended scope of the world could fracture the foundation of a game schedule regardless of the success of a vertical slice. If the ‘Launch Scope’ is far greater than can be carried on the backs of the development team, you’re going to have some major problems. To add more stress, designers can often add features that were not in the vertical slice or art pipelines become clogged by team growth and a many tiered approval processes. This commonly occurred on projects I was involved with and it placed a lot of stress on teams and led to many a world being chopped up. In one of the worlds I worked on it led to the shattering and sinking of an entire continent well into development. But no matter how much pre-planning takes place, something will always go wrong, that is a given. Just don’t add on to the frustration by creating a scope too large for launch. Create a sensible scope for launch.
Looking back on projects, I am confident that strong conviction must be given to the ‘Launch Scope’ of your world. It doesn’t have to be as vast as your dreams. Not at launch. It just has to be large enough to sell your setting, compel players and allow for extensible content. As a team, you can commit to a small amount of features and a world that is large enough for your player population and Content Strata, the intended layers of player content. If you try and bite off more than your team can chew, the game will choke. But that does not mean your world will always remain the size of your launch scope. It shouldn’t. Integral to this design is the ability for your world to be extensible. You must be able to add more features and more slices to your world. We see this in old school MMO expansions and they work well and can be developed in tight schedules. They also create some of the most experienced development teams in the industry. Cheers to those ‘live teams’ that forged many of the expansion protocols used by MMO’s today. If a team is smart they can maintain a healthy growing MMO or open world game.
As I sit here typing at 3am, I almost forgot to mention one more thing I feel is needed for this new smaller Launch Scope to work, keep your changes in management to a minimum. Adding too many new managers to a project and shuffling their roles has always slowed the development process and led to tiny disasters such as disrupting team synergy. Changes in team size are inevitable, but changes in management should be limited. As with everything else, the team should be extensible. Some departments might not be needed to mid production. If you find you are adding a new department to a project, it should be for a feature you have already committed to in your design scope. Want to bring your sound team on later in the schedule, great! Want to add a team to support a flying mount feature that was not part of the original scope… oy vey! Like a line a cars on a multi-lane freeway, each new feature compounds other features, creating break lights and one hell of a traffic jam. Try and commit to a smaller scope and stick to it. A Sensible Scope! It might be neat to have 20 races and 18 starting cities, but be realistic with your budget and team size. Keep your launch scope simple and small. If your world is extensible, you should be driving along, your foot off the brake pedal and rockin’ some Van Halen tunes down the open world highway to a successful launch day.
Tony “Vhalen” Garcia