A few weeks back, James was sitting down to dinner with a few of his designer friends,
and they got to talking about an open-world game one of them was working on.
As they talked they ended up discussing how they each conceptualized open-world design.
Today, we're going to go over the same problem,
because it lets us talk about something we rarely get to discuss--
the fact that, sometimes when designing, the most important thing is:
how you conceptualize the problem you're approaching.
People can approach the same design problem and choose to solve it in radically different ways,
depending on their perspective of the problem.
Which in turn results in radically different games.
If you think of jumping over a pit as being about precision, you get Super Meat Boy.
But if you think about it as being about speed, you get an endless runner.
If you view action RPG combat as a way to make the player more connected to the character,
rather than seeing it as a way station between moments of character development,
you get Demon Souls instead of Fable 3.
So it falls on us as designers when we have the luxury,
to examine our premises before we dive into the thick of the actual design process.
So, open-world games.
There are at least two fundamentally different structures
for thinking about how to construct an open-world game.
You can conceptualize it as a game made up of towns, dungeons and open-world encounters,
Or, you conceptualize it as a game made up of modules in the old D&D sense.
In the first structure you build out towns, dungeons and encounters.
And then you slot them into the world as they fit.
in the second structure, you compose the world as a patchwork of loosely defined areas
that each have their own adventures running through them.
We end up using the Elder Scrolls series as an example a lot,
because it's the biggest budget, most marketed, longest-running fantasy open-world series out there.
But it's a good example of the first design philosophy.
None of us have worked with Bethesda before,
but I'd wager that even their team structure is set up along these lines,
with different people making the dungeons, towns, and encounters
and not a great deal of time spent coordinating between the groups to make areas of the world
feel like holistic zones with their own adventures and multi-quest micro stories running through them.
Baldur's Gate, on the other hand, is an excellent example of the second design philosophy.
Because the game itself is coming from a D&D pedigree,
it makes a lot of sense that they look at open-world construction in this manner.
If you look closely at that game,
you'll find that each of the zones on the map feels like a unified place with a mini narrative running through it.
Personally, I feel like the second approach gets you a stronger result,
as it lends itself more toward interesting encounters, rather than simply hack-and-slash combat problems.
It creates a framework that allows designers to craft a strong narrative in an open-world environment,
without losing the freedom of exploration that's so essential to open-world design.
Of course, the problem with the module approach Is that it's a bit tougher to pull off from a production standpoint.
First, you have to organize your teams so that they're working together on entire zones,
which requires a lot more communication and a lot more management overhead.
Second, it means that while you may be able to salvage some stuff here and there,
you are a lot more likely to have to completely scrap a bunch of work if one of the teams falls behind,
or their area just isn't coming together.
This method also creates two design challenges for you.
First, is the obvious fact that creating holistic micro adventures requires more work from your designers.
The alternative of simply creating the constituent parts of those adventures
(the dungeons, towns, and encounters) and then scattering them about the world doesn't require as much design staff.
The second challenge is and how you delineate the boundaries of those adventures within an open-world framework.
Baldur's Gate took the technologically necessitated,
but also simpler design approach of simply dividing the world into separate zones.
They had boundaries between these zones and whenever the player crossed them,
the game would pause to do a bit of loading.
This gave them an easy way to delineate the module or adventure space.
That is much harder to achieve with the Elder Scrolls' seamless world.
Dark Souls 2, which feels less like an open-world game to me, but I've had enough people insist to me that it is that I'll use it here,
anyways,
Dark Souls 2 also creates clear zone delineations,
but they do it through visual aesthetics and by having the zones actually all be spokes off of a central hub,
rather than a truly free roaming space.
Dragon's Dogma, on the other hand, provides a more module based experience than Skyrim within a true open world
by having its content seemingly designed as areas rather than as pieces
It's basically an Elder Scrolls type of game with a more Baldur's Gate-esque module philosophy for their open-world design.
But even they didn't truly go all the way in creating the module-like feel of old Black Isle games.
Instead they settled for giving each area a unique sense of theme, tone, and design,
but issued the series of quests and encounters that would make each area a small adventure in and of itself
with its own story to tell.
Actually, some of the best modern examples of module based open worlds come from MMO's.
If you look at World of Warcraft, many of the zones there,
especially later in the game, feel like unified adventures with little stories of their own.
But they too couldn't do it without clearly defined zones.
On the production side, I think all these problems are soluble
so long as you go into the project thinking of your world as a patchwork of modules
rather than simply a collection of dungeons, towns, and encounters.
On the design side, it's something you're going to have to play around with in pre-production.
It's easy to do the module thing with clearly defined zone borders but without zone borders or artificial gating,
making these adventures feel natural into keeping the player from getting lost in a mishmash of overlapping modules
as they inadvertently cross between them
is something that will probably require a unique solution for your game
As there's not a whole lot of successful examples to draw from.
Oh, before we go, I wanted to say something about sand boxes.
Often we seem to use the term open-world game and sandbox interchangeably.
They're actually not though.
Sandbox games are games where, you the player,
create part of the fun yourself by playing around within the world of the game presents you.
Games like these may benefit less from module-based design,
because it's not simply the adventure itself that makes these games engaging
it's also in finding new areas to mess around in and new ways to play with the systems the game gives you
Grand Theft Auto games get more mileage out of just building cool bits and socketing them into their world than a lot of fantasy open-world games.
Because in GTA, a well-placed ramp
is a new toy free to experiment with. You could spend hours trying to use it to land your car on an impossibly
high building or just enjoy throwing cars off it and laughing yourself silly.
Whereas a random troll camp and an open world fantasy game simply can't be played with in the same way.
So if you're thinking about creating an open world game, consider what your design approach should be.
Do you want to conceive your world out of a patchwork of modules or,
would you rather create a single huge space and sprinkle dungeons, towns, and encounters all over it?
They both have advantages and they both work.
But I've got to say, I'm looking forward to seeing a game crack the problem of providing
modules, many adventures, and tiny cohesive stories in a seamless open-world design.
See you next week.