Cohesive Design

Going to deviate a bit here, or rather return to a favorite topic – design.

I read the following article on Gamasutra from Stephan Frost on how to manage development of an MMORPG.  It got the brain juices flowing.  First, background.

I work in IT as a lead systems integrator/architect.  My job is to take extremely complex systems and make sure all the pieces fit together, while meeting business, security and functional requirements.  That pretty much means, on budget, on spec and on time.  My current project has about 500,000 clients and a team of about 100 working on it.  Ok, background complete.

If you played the recent Deus Ex you (and the world) noticed that the boss fights in that game made no sense when compared to the rest of the world.  The former was all run&gun and the latter was extremely open ended.  That’s a lack of systems integration, where people use the same tools, have the same goals but get there in different fashions.  It creates a jarring feel when players go through it.

Independent Design

Independent Design

In the MMO space, there’s the leveling game and the max level game and, for the most part, these systems are also not integrated.  WoW has next to no links between the various systems – pet battles don’t mess with scenarios don’t mess with raids, etc…  It means there’s no conflicts between systems but it also makes it feel as separate games.  GW2 has an interesting approach where all content is auto-leveled.  RIFT links a few systems together, mostly around you know, rifts…

For a team of 100+ people to work together and ensure a cohesive experience for the consumer, they need solid direction.  In IT, certainly architecture, we have Concepts of Operation (ConOps) and architecture designs at the reference, technical and detailed level.  The ConOps gives a high level picture of how the client is going to consume the service and sets expectations.  You’d see raids, housing, crafting, exploration in a ConOps, including how they interlink.  A reference architecture is a ‘behind closed doors’ guide for similar systems.  Say a art style guide, so that all the assets are similar.  A technical architecture is one level deeper, explaining the various components in that system.  A raid guide would say something like, it has 24 people, this type of class diversity, this number of bosses, the expected completion time, and how it interlinks with other systems (tokens, crafting, etc…).  The detailed architecture is explicit in design.  It would be for a single raid, explain the flow of the zone, the boss abilities, themes and so on.

Think about the WotLK expansion and the raids that came from it.  Ulduar and Trial of the Crusader were extreme opposites in terms of detailed design.  Before someone started coding those zones, there had to be a plan for people to connect to and milestones to reach. Raids don’t just magically appear from some code.

Now think about how an entire game maps out, with 20+ teams working on their various systems.  Classes, crafting, zone design, quest design, lore design, raids, housing, travel, art design.  Either they work in silos for 2 years and meet later on, in a massive clash of conflict or you plan it out right so that each one accounts for the other and there’s an open path of communication.  Jim in the housing group says to the other leads, “Hey, I think it would be great if we could see housing items acquired in other systems.  It would give prestige to players and provide an extra carrot in the other systems”.  “What a great idea! Let’s see how we can work it in.”

Integrated Design

Integrated Design

From a player perspective, it means that each system has an impact on the other and that you can make progress across the entire game, regardless of what system you prefer.  You like to craft?  Well, it’s used in housing, raiding and questing.  You like exploring?  It impacts the world by putting in trade routes and creating new spawns.  It means that when you move from one system to another, you don’t have to learn a completely new game.

I really appreciate Stephan’s post on the matter.  It provides clarity on the complexity of system design.  Hopefully more developers can provide similar insight into their work styles.

 

2 thoughts on “Cohesive Design

  1. Pingback: Where I discuss crafting again | Healing the masses

  2. Pingback: Where I discuss crafting again - Healing the masses

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s