Defining Boundaries: Creating Credible Obstacles In Games, Part 2By Gareth Griffiths
[Recently, Sidhe usability expert Gareth Griffiths examined a number of styles of boundaries in games for their visibility and affordance -- interface-design terms that describe how easy they are to comprehend and use -- and found them lacking. That's the bad news. What's the good news? Griffiths has synthesized the comments from the original piece into a follow-up which looks at potential solutions.]
Previously, we looked at the various types of boundaries that a game player often collides with when in a game world. The article examined the invisible barrier, multitudes of inoperable doors and those other barriers that magically appear and disappear -- to name a few.
From the comments it received, it was plain that while many agreed with the point put forward, it was clear that more thinking would be needed that could maybe offer viable solutions to the situations that were put forward. In order to do this, I decided to go back to the drawing board. Armed with a bucket-load of information from the numerous comments, I decided to sit back and ponder this question.
The first stumbling block in this process, though, was that whenever I'd come to a seemingly viable solution, the devil's advocate would pop into my head and whisper ways it would break.
What was continually bothering me was that, while what we are playing is called a "game", we still struggle with the issue of reality versus fantasy. On the one hand, if a game goes beyond the bounds of reality too much then you often hear players saying "Oh man, there is no way that would happen in real life!" But then, on the other hand, you're just as likely to hear someone say, "Why won't the game let me do that? It's a game! I should be able to so what I want!"
Because of this we need to tread carefully and somehow incorporate some fantasy into the reality -- standards whereby the player can do crazy stuff that basically adheres to the boundaries that would exist in the real world.
Now, I'm not saying that we shouldn't use things like doors, walls or other kinds of barricades, but it is important that they are consistent, fair, and conceptual, and that they follow the visibility and affordance guidelines I discussed previously.
For example, take a game that sees you walking alongside a cliff, that won't allow you to fall off the edge, no matter how hard you try. This is probably a good thing, isn't it? There's probably nothing worse than running along when all of a sudden you make one slip-up and down you go. And yet, if you can just hug the edge and no matter how hard you try it will just be impossible to fall off, will this break the immersion more?
A good example of this was the chasm that appears as a result of an earthquake in Gears of War. This blatantly stops you from going anywhere because you cannot fall off the cliff, as shown in Figure 1. So is this good or bad? Does it tear the player away from the game in some way?
Figure 1 - Gears of War chasm
In order to look at the various types of boundaries, I decided it would be easier if I could first place them into some kind of category that way I would be able to organize things easier.
Firstly we have a "macro" boundary, which would be described as the world area. This is the limit of your game world: we will not come across this that often -- the cliffs in Gears are an example. Secondly, we have a "micro" boundary, which the player will come across often within the game -- doors, for instance.
Before we look at this in a gaming sense, what is our macro boundary for the real world? What lessons can we take and apply them here?
First off is our constant friend: gravity. No matter what we do, it is this force that connects us to the world. Sure, we can break the shackles of gravity, but we must use specialized tools: an airplane, or the space shuttle, for example. We can cheat gravity for a little while with the use of gliders and other contraptions, but other forces then come into play -- such as the weather -- and this barrier is once again encountered.
Gravity also plays an integral part within our game worlds. We can only fly with specialized equipment and even only jump over certain objects. Even the outstanding Crackdown, which allowed your super-cops to jump amazing heights, as shown in Figure 2, was constrained to this universal force.
The thing is, even though we could actually do away with gravity completely in games, this would possibly remove any suspension of disbelief. Even allowing games to "cheat" this force, maintaining gravity still works quite well, even in the face of powerful characters, if it is worked into the story -- which is what Crackdown did so superbly.
Figure 2 - Crackdown's gravity-defying leaps
So, our macro boundaries are there as the "big picture". They can bind -- for want of a better word -- the player into an area within the game world. An example from the comments from the previous article's discussions was an island. Here, the obvious macro boundary is the ocean. Sure, we can allow the player to swim -- but bogged down with equipment, they can only go so far before they must either come back or drown.
Another way we can keep the player on the island is to put a danger in the way -- sharks, for instance, work pretty well. However, if we use this kind of boundary then it becomes necessary to make the boundary visible from the onset, which means our visibility and affordance rules now come into play. The player can see the fins, and as fins mean sharks, they afford danger.
However, if we had the scenario where the player swims out and sharks for no apparent reason suddenly attack them, then it makes no sense. But ensuring the player can see the dorsal fins from the shore reinforces that it may be pretty dangerous to try and swim away. This now makes the boundary plausible and contextual. Of course, if there happens to be a random boat moored up somewhere that won't allow the player to get in for some reason, then this micro boundary breaks the macro boundary.
Another example I can think of is the recently released, excellent GTA IV. In this instance, the player is kept to one island due to a terrorist explosion having blocked up the bridge. In today's chaotic political climate, this is feasible (albeit slightly clichéd) and it works. However, I do believe the developers could have worked it better.
What happens is that when the player completes a certain mission, the bridge is suddenly cleared of all problems. While this is fine, it may be more immersive for the player to hear that the bridge is still being worked on as they progress through missions over the car radio. This could be taken a step further by actually showing workers on the bridge, as the debris gets physically smaller. So now we are working the macro boundary entirely into the story, which will make more sense when it comes to be fully cleared.
Another comment left from the previous article was that boundaries could be incentive-based. When I first read this I thought it was excellent. Instead of a physical boundary, we've now got a mental one, something that is tied into the narration of the story. The example that was given was one whereby if you leave the island, your girlfriend will be killed (we always use islands for some reason).
This sounds great. But then I thought about the various types of gamers out there and then I started to wonder what would happen if you had someone who said "I don't care if my in-game girlfriend is killed. I'm off!"
What happens in this situation? If the player decides to cross the boundary and the kidnappers kill the girl, will it be game over? If so, will this in itself feel unfairly constrained? Is there a danger that the player would say, "I don't care if she lives or dies. Just let me go!" The only way this could work is if it was worked so intrinsically into the plot that it was absolutely necessary that the girlfriend survive. This now becomes very feasible.
A good example of an incentive-based boundary is the fantastic Battlefield: Bad Company (and also the previous BF titles). This technique manages to create a believable macro boundary that ensures players do not leave the playing field and instead remain in the field of battle. This is achieved through both visual and audio cues, as seen in Figure 3.
Visually there is a large red marker around the border of the map, and should the player stray into it, a warning message appears and states that they are leaving the combat area. An auditory warning states, "You are entering enemy artillery range" -- though, again, they should both really be the same message. Also, why they decreased it from 10 to five seconds is beyond me. But, that aside, I think this works well because it is believable, and works well within the game's genre.
Figure 3 - Battlefield: Bad Company, out of boundary warning
The Micro Boundary
The micro boundary is actually surprisingly difficult to solve. The macro boundary can be worked into the narration and the stream of the game but when it comes to the small boundaries that the player comes across whilst playing, how do you go about doing that? What are the options available?
Let's take, for example, the humble doorway. In a game where there are may be hundreds, it won't be possible to be able to interact with every one of them, simply because of the amount of work involved for something so trivial. This, however, got me thinking. What if we do have a situation whereby the player will be faced with a multitude of doorways? How can we solve the issue then?
When all seemed to be lost the helping hand actually came from a quote an old teacher said to me once: "Don't tell me what we can't do, instead tell me what we can do."
I'm sure he got it from someone (possibly Admiral Nelson, if memory serves) but this quote made sense in this context, too. If we have a multitude of doors (or any other kind of barrier) then we don't need to tell the player which ones they can't go through but simply tell them the ones which they can!
However, the flip side is that there may be times when we do want to impose a challenge where the player may want to find the correct door. What do we do then? Do we revert to the old style of continual trial-and-error or is there perhaps a more elegant solution?
Back to another field of study -- web design. When designing web sites, the rule is "three clicks and that's it." In three clicks or less, the user is supposed to be able to find what they want. Why can't we use this magic number for games, too?
If we do want to have a number of doors in one place that are to be identical and only one opens, then possibly limiting this number to three could be enough to ensure the player does not get frustrated. I could be wrong in this -- and more research is required -- so if anyone out there wants to collaborate, I'd be more than willing to help but, as it stands, it does seem to actually make sense.
So, now we have a potential solution, but how do we now go about explaining to the player that some can be interacted with and some can't?
In the previous article I mentioned how Call of Duty 4 actually tells the player with a message on the screen if something can be jumped over. To my knowledge this doesn't detract from the gameplay at all and in fact may actually improve immersion because the player is not required to perform a trial and error routine on every small thing.
Is the solution therefore to simply explicitly inform the user what can and cannot be passed? In some situations? Yes. In others, no. Below are four possible solutions to this dilemma.
- Make the intractable boundary blatantly
different to the others. If a player can quickly differentiate between the two,
then this will make things a lot easier. A door to be interacted with could
appear slightly open, while a barrier to be broken can already appear a bit
worse for wear. We could also add sound coming from behind the object to
indicate that something lies behind this
one as opposed to the rest.
These suggestions also tie in well with the rules of visibility and affordance because a player can tell what can and cannot be interacted with and, just as important, how they can do so.
- Explicitly inform the player with an icon or something flashing. The player will quickly see this and know which one can be interacted with and which cannot. The problem with this is that there is a danger that immersion could be lost. However, this may be balanced out by the fact that being unable to find the right way is no longer frustrating the player. If the player doesn't want this option, then it may be feasible to allow them to turn it off.
- If the player has an object in his hand, we could get it to somehow react to a breakable object -- quiver or vibrate for example. The problem with this though is that the player could potentially miss it and can still spend a while hunting for that "sweet spot". Also, what happens if they don't have the object in their hand?
- A timer-based system that offers hints. This could be extremely difficult to achieve but if the game could somehow offer assistance as and where it is needed (a player taking over five minutes trying one thing over and over for example), then we could alleviate a lot of potential frustration.
The biggest problem in any of the above examples is that it undoubtedly means more workload for the developers. However, surely going that extra mile will make a difference? The other problem is which to choose.
To be honest with you, I don't think there is a one-size-fits-all solution here. If the game requires the player to be able to quickly identify a way through, then explicitly tell them (Call of Duty 4 is a perfect example), while the fantastic-looking Mirror's Edge (As seen in figure 4) has areas that light up in red to indicate which way to go.
However, if there is no real urgency then it may be okay for the player to have to hunt for the solution -- but we must still ensure that it is easily distinguishable from all the rest. So option one, combined with the "magic three" rule is probably the way to go here.
Figure 4 - Mirror's Edge, red path explicitly informing player which path to take
The final two could be used to some extent, but they could end up being so fiddly to both develop and use that using them as a solution could actually be more detrimental to the game than using nothing at all -- invisible walls, for example.
It is important that whatever boundary type we use in a game is done well. I'm going to go out on a limb here and outright say that some we should never use are:
- Invisible walls
- Non-understandable barriers
- Magically appearing barricades
I personally think these just remove any sense of realism within a game and should be avoided at all costs. I know some out there will argue with me that they are necessary but I am sure there are much better alternatives.
However, if you noticed I deliberately put a space between the second and third entry. The reason for this is that I believe the third type of boundary can still work, but only if it is worked into the narrative of the game, instead of having something just appear which halts the player's progress. This could even be another form of macro boundary.
The problem with games now, though, is that as technology progresses, then the games will become more complex and as they become more complex then players will demand more realism -- our games need to reflect this. If the player comes across something like a small wall they cannot walk over for an unknown reason, then no matter how technologically amazing the game is, it stumbles and fails in the simplest of ways.
Our macro boundaries should always be contextual within the game as they are the ones that will keep the players where we want them to be. If we use incentive-based boundaries then these will need to fit 100% into the narrative. It would be easy to break this kind of boundary but, at the same time, it could end up being the one viewed in the most positive light.
Micro boundaries are the ones which will have the greatest influence on players -- as it is those which they will encounter the most -- and, as such, are the ones which need to abide and be most aware of the visibility and affordance rules.
Figure 5 attempts to highlight the close relationships between the various versions. Our world rules feed into the macro boundary, which is in turn made up of a close-linked relationship between narrative- and incentive-based boundaries. Embedded within the game we have our micro boundaries which will still follow the world rules but will have their own set of ways to deal with them which must have a strong link to both visibility and affordance.
Figure 5 - Relationship between macro and micro boundaries
Additionally, we must always take into account that the micro boundary can also have a direct influence on the macro one too -- as was given in the brief example of the boat being unable to leave the island.
This article has expanded on the previous one and has attempted to offer solutions to the various boundaries that we come across in games. It has proposed that by splitting the boundaries into two types we can get into a mindset from the start what we will be dealing with.
Whatever type we use, it is important that we always think of the player first. By creating barriers that are believable and are worked into the game in a manner that makes sense to the player, then the game will benefit.
While in the game, we always want the player to have a sense of achievement and satisfaction, which ultimately leads to (hopefully) fun. If there are things that can directly reduce this in any way, then surely we should be careful not to implement them. It may be that the player will not even notice the little touches we put into these boundaries.
However, this is probably what we are after, because if something is viewed in a negative light then this usually has a tendency to stand out like a sore thumb and detract from the game itself, whereas the "good" aspects often go unnoticed.
While this may annoy developers somewhat ("We spent days on that.... didn't anybody notice it!?") it's a far better alternative to players going "Oh man, that sucked!" or "Invisible walls again! Man, I hate them".
I look forward to discussing this with you all.
Return to the full version of this article
Copyright © UBM Tech, All rights reserved