Open World Encounter Design

And how to make it compelling

The 40 Second Rule

When thinking about the scope, size and distribution of your encounters in the open world you will have to consider the time between encounters. This tends to vary from game to game.

This matter is highly dependent on Player speed and Map Size, since the number of encounters in an open world will be higher or lower depending on those factors.

• Number of Encounters decreases if the map is small and the player is super fast.
• It also increases if the player is super slow and the map is very large.

Ideally you want your map to be large enough to support a various amounts of activities if the player speed is moderate and not very exaggerated.

Encounter Overlap

It is very important to make sure that encounters don’t overlap when triggered.

A player triggering an encounter should only trigger one activity and not 4 at the same time

In open world spaces this might be difficult if you are dealing with a small space, that’s why experimentation and good relation with your AI/Encounter design team is key to getting the best possible experience.

If by any chance you might get to the point where organic design would not be possible (and I am talking about having enough space, enough robust systems, you actually have to go in and script every encounter) just make sure that the makings of each encounter stays simple and that you can piggyback on the systems that already exist.

It’s ok to micro manage one encounter but working with 25 encounters in one region of maybe 500x500m might prove problematic in terms of how much time you would have daily to adjust every individual encounter.

Going for modular, prefabs or easily editable groups will save you a lot of time in the long run, since dev time tends to sky rocket.

The basics of how to distribute them have been covered in my previous blogs. You get to define the list of encounters, their spread and their position on the map, however you also want to consider that, since we are talking about open world games, sometimes you might want to allow the player to avoid these encounters by giving players enough space to maneuver around the encounter is as important as placing them down.

Experiential Variation

Encounters should be replayable

If there is one thing I learned over the years is the fact that when you are designing these features it is easy to fall in the trap of designing them as one shot encounters.

This often leads to having very static encounters that are always there and that the players will encounter every time.

It’s fun once, twice… if you are lucky maybe even three times however afterwards it will get really boring.

You will have to remember that the player’s position is unpredictable, they might stick around or they might go somewhere else but if they stick around and you respawn the same encounter every time it will break the immersion.

So a series of factors need to be considered when approaching these issues. Things like: How long has it been since the player had an encounter? Has this type of encounter been spawned here before? Can we have a cooldown time on this encounter, before the encounter gets to respawn? What happens when multiple “partners” trigger multiple encounters in multiple areas of the map and how do we juggle the AI budget to handle that? Is instancing a thing in this game? Etc.

Combining all these factors, compiling the data, distributing the correctly, and playtesting after every chance will reveal a different type of user experience.

Yeah! I know! I know! The fact that it’s a map filled with icons is a bit of a cliché at this point (at least from a player perspective). However from a developer standpoint this is a great way of keeping tracks of where goes where. It doesn’t have to be user facing to work.

Playtesting

It will be up to you (and your directors and leads) to decide if that’s the experience you want for your game, however… please consider the fact that your “own” opinion is one of many and it might be best to translate this into a larger playtest where everyone can sit down, play the game and express their opinion on how things are going/feeling.

Also to note that when a playtest is in progress it is best if you as a designer are following some simple rules:

• You are not in the playtest
• You tend to observe the other playing the game
• You can take rigorous notes
• You don’t interfere in any way with the playtesters
• You are always willing to take the written results with a pinch of salt

If you did your job right there should be no surprises during a playtest.

Systemic Interactions

Why less is more

You might want to consider the debt and breath of your systems before starting to cover this subject in your game

The tendency will otherwise be to go all in and make the more compelling, most interesting set of interactions between two systems ever made, however let’s not forget that you are not matching just two systems here. You might have to pair at least 20 with each other.

So the key is to try to make these interactions as economic as possible based on what sets of stimuli you already have available in the game.

While it may be compelling to design that Animal ecosystem as in depth as you can, you will need to consider the following factors:

• It only matters if the players can see it.
• You don’t want to confuse the player (the player needs to understand what is happening)

Map Size

Map size is a weird subject

Technically you should only go for a large map size if you have the tech to support it. That means Engines that can handle region streaming, LODs, Object Streaming.

It’s also beneficial if this streaming is and can be done relative to the player position.

Assassins Creed, Watch Dogs, Farcry game allow the world objects to stream in and out based on how far or how close they are in relation to the player. This is done through a series of concentric circles that vary in diameter (30,45,60m) around the player and everything in the map streams in and out of existence based on how far or how close they are.

Also using occluders helps a lot, although it tends to limit creativity.

They also facilitate turning the AI, Objects, Etc. into simplified, less costly forms of themselves. This helps a lot with memory budgets and allows the game to run properly on normal gaming devices.

Older engines like Source or Id Tech tend to load everything at once only focusing on portals and occluders to optimize the game however this means that how much the player can see becomes a problem, so in general you want to block LOS as much as possible in order to keep things under control. This leads to more controlled spaces and natural occurrence of vistas although possible needs to be heavily planned ahead of time.

Also technical tricks need to be employed.

Compiling and managing data

Keeping a tight control over your map data is critical. You need to be able to manage all these details in an easy and comfortable way.

Usually employing a spreadsheet is useful since it allows the information to be stored in one place where you can keep it under control.

If you can establish a cross dependency between the spreadsheet and the engine data that can facilitate faster real time updates in your spreadsheet in order to keep things up to date on a regular basis.

Otherwise each designer working with that data will have to manually update the changes in the document. This is why it’s best if the information goes in a waterflow manner from direction to spreadsheet to user/implementer.

This way the users can keep an eye on the document and have a clear idea of what the details of the feature they are working on are. If the designer considers that an error is in place that might lead to an adjustment of the data in the master file then a discussion with the manager/director/lead should clarify it.

Player Attention Span

In an open world game the player tends to play to the game in two different ways:

Directed

• The first one is the directed way. The players get an objective (usually something simple) dictating where they should go or what he should do (the delivery of the objective is not important here) and then the player proceeds to solve the objective (ideally using the game systems).

This tends to narrow down the attention span of the player.

Non Directed

• Non Directed. The player does not get an objective, however the inherent conditions of where/how the spawn happens dictates what he should/ca do.

This tends to lead to a broader attention span for the player since a better use of the systems/tools becomes available.

Note

• All experiences are ultimately directed in the end, nothing is left to chance, however by widening the player’s attention span he becomes aware of the complexity of the systems surrounding him.
• If the player can put 1+1 together to match one system with another system to produce an effect then the seed of systemic interaction is planted in the player’s brain and what you need to do is create a systemic progression that naturally unveils the systems to the player over time.

Variety and how to keep it fresh

I talked a lot about this in my Automata blog. It’s important to keep things fresh and simple.

Innovation doesn’t come from complicated things that have little impact. It comes from simple things that have a high impact on everything.

The player is always at the forefront of the experience and thus the results of building interesting encounters come from having a good match between the controllable (player tools systems) and the uncontrollable (game systems).

The player needs to experience two things:

• Systems interacting with other systems
• Player systems interacting with Game Systems.

To make a fresh analogy it’s like when you are teaching another person how to do something by doing it yourself:

• Children tend to learn by watching their parents, Then by doing it themselves, failing and trying again.

So we could break it down into several phases:

• The Introduction — Usually defined by a set of systems interacting with each other in a position that the player can see
• The test — The user proceeds towards trying to influence those systems using his available tools and producing an effect, or failing to do so
• The Repetition — The user repeats the attempt until a satisfactory result is produced.

If you had flashbacks of Mario attempting to jump over a pit and dying over and over again you are not wrong. It’s exactly the same thing, but a much larger and broader level.

Systemic Interactions

The beauty of systemic driven games is that they allow for the player to feel clever by experimenting with systemic compositions in an attempt to master and control the world around them. This might be seen as an attempt to find the best possible strategy to solve a challenge, or just a way to find satisfaction in making the game play itself. Both versions are correct.

The design challenge however comes from making sure that creating a large spectrum of interactions between systems doesn’t break the game.

This means that if interaction between two systems is possible it should produce interesting results, however having 25 systems interacting with each other usually tends to lead to 625 effects that depending how they trigger might interact with any of the 25 systems again leading to more complexity. It’s just not sustainable.

Although that is not bad, and there are definitely games doing that out there, what you want is to make sure that the core of the game is visible to the player through these interactions. That means the game needs to fit the gameplay direction.

And here’s where systemic presets and tropes come into play. These are large pools of curated events that singularly serve the purpose of having those systems exposed to the player, they also tell a story that fits the narrative, mood, theme of the game, and help ground the experience.

To generate these presets thing about:

• The setting of the game
• The available systems available
• What sort of stories can you tell using them?

The examples can vary:

• Mules attacking the players for their loot when they gets pinged sensor s— Death Stranding
• Bandits lying in wait in bushes as Eivor travels through Sherwood Forest — Ac Valhalla
• Cops arresting civilians in London — Watch Dogs legion
• Drones scouting a beach in the vicinity a telecommunication outpost — Watch Dogs breach point
• Eagles attacking Cultists — Far Cry 5

As a practical way of visualizing these things think about these systems as either static or stationary:

• A stationary system will always be there — if a player or ai interacts with it it will produce an effect — Cargo Sensor ping/BT Territories in Death Stranding
• A moving system will travel through the world, often intentionally through a static system territory — Occasionally triggering an interaction.- Patrols, Cargo Trucks, Predatory animals. Sometimes they will encounter other moving systems causing another type of encounter trigger.

Conclusion

I would have liked this entry to be a bit more useful in terms of actual “how to” guidelines but the reality of it all is that it depends on a lot of factors, and if those factors are not clearly defined then the design process falls to a standstill.

Sure you can try to wing it but that might result in failure when the answers to your questions become available.

Here’s a quick recap:

• Know your systems
• Know how they interact with each other
• Create systemic tropes based on these interactions and based on the theme of the game your making
• Judge the technical limitations of your game
• Organize these tropes in a nice easy to manage spreadsheet
• Implement
• Playtest
• Iterate

Yeah! That’s pretty much it.