Sponsored By

Oil it or Spoil it!

Rusty game mechanics will annoy your players. Let's find out how to improve user experience by sanding off rough edges and applying game design "Oil."

Lars Doucet, Contributor

August 10, 2016

13 Min Read
Game Developer logo in a gray background | Game Developer

"Juice" is probably a game design term you've heard before.


By Agricultural Research Service
Public Domain

It was first coined in the seminal article How to Prototype a Game in Under 7 Days:

“Juice” was our wet little term for constant and bountiful user feedback. A juicy game element will bounce and wiggle and squirt and make a little noise when you touch it. A juicy game feels alive and responds to everything you do – tons of cascading action and response for minimal user input. It makes the player feel powerful and in control of the world, and it coaches them through the rules of the game by constantly letting them know on a per-interaction basis how they are doing.

(emphasis mine)

The term is elaborated in these two excellent talks, "The Art of Screenshake", and "Juice it or Lose It":

"Juice" is a kind of polish, but a very specific kind -- excepting animation, it's nearly perpendicular to the traditional concept of "production value." Simply improving graphics, sound, and other measures of "quality" doesn't necessarily add juice, and vice versa. It's just as easy to imagine a richly rendered 3D game with lifeless interactions as it is a simple 2D game with garbage screenshots that positively bounces to life when you play it.

As Petri says:

It's impossible to give broad statements that are true for everything, but adding Juiciness to your game makes your game better 100% of the time, guaranteed.

;)

With that out of the way, I think there's another equally important kind of polish that doesn't get as much attention, perhaps because it doesn't have it's own term yet.

Let's call it Oil.

By W. W. Denslow
Public Domain

Whereas Juice is highly visible, Oil is really something you only notice when it's missing. A well-oiled hinge is smooth and silent, but a rusty one squeaks, groans, and annoys the crap out of you. If juice is all about making your game come alive and enriching interactions by maximizing the output you get for a single input, Oil is about minimizing the friction and effort that goes into making an input in the first place.

To put it another way:

Juice adds pleasure,
Oil removes pain.

But let's be specific. Just as the two talks on juice did, let's look at a bunch of concrete examples of how you can improve an existing design just by adding a few drops of oil.

Dragon Warrior

The original Dragon Warrior (aka "Dragon Quest I") has a contextual menu that you have to use to interact with everything. If you want to talk to someone, you walk up to them, bring up the menu, and select "talk."

If you want to open a chest, it's similar: step on top of the chest, open menu, select "take."

You have to choose a specific action just to walk down a flight of stairs:

In all of these cases, there is exactly one thing you can do with any of these objects anyway, so a single contextual "action" button would suffice. This is the path Final Fantasy took, which imitated Dragon Warrior in many ways, but added a few drops of oil along the way.

Talk to a character? Approach and Press A.

Open a chest? Approach and Press A.

Walk down a flight of stairs? Just walk on top of it!

Now, to play devil's advocate, Final Fantasy's single action button limits the available choices. What if you want the player to be able to search an innocuous looking floor tile with bones on it that happens to hide a secret treasure? Even considering this, the mandatory action menu is unnecessary - you can achieve the same complexity but still improve the experience.

My rule of thumb is:

If there is only one possible, unambiguous, non-regrettable action, the action button should just do that one thing.

Talk to the person. Open the door. Pet the puppy.

If there is more than one choice, or if the action is likely regrettable (rob the shopkeeper, smash the door, kill the puppy), then the action button should bring up a menu. If a player is standing on a tile with a skeleton on it, and they're not touching anything else that's interesting, and they press "A", it's probably safe to say they want to search that pile of bones (they're certainly not trying to "stairs" it). But if there's a treasure chest, and chests in this game can have traps, perhaps you should show a "open the chest?" dialogue first.

These things may seem obvious to us today, but it clearly shows how a few drops of oil can make massive improvements.

And speaking of Final Fantasy, it has some rusty hinges of its own. Let's look at that next.

Final Fantasy

We're in a shop and we want to buy some healing potions to stock up for a dungeon run. Here's the entire UI flow for that action:

Now do that 98 more times.

You have to push the A button three times to buy one healing potion, and there's a pause between each menu, so it takes ~1.5 seconds per purchase. That means buying a full 99 heal potions takes two and a half minutes of mindlessly mashing A. And Lord help you if you wanted pure potions or tents, because then you'd have to remember to push DOWN each and every time to select from the list.

Keep in mind that in this late-game scenario, I have 9,090 gold, and 99 heal potions only costs 5,940, so this is obviously something I should be able to do.

Notice how much better this gets with a single UI tweak:

It could be streamlined even further, but just being able to manually scroll the quantity up to 99 is a huge boost to efficiency and cuts down on a lot of pain.

Obviously the interface is only so clunky because of the game's age -- subsequent Final Fantasy titles improved on this and many other pain points -- but it stands out as a classic example.

Here's another example from FF1. Each turn, you assign actions and targets to each of your party members, in a manner still used in modern RPGs. However, there was a key oversight -- if an enemy happened to die before a character assigned to attack it took their turn, that character would simply wave their weapon in the air at nothing.

Players had to be sure to spread out their attacks to avoid "wasting hits", and to make matters worse, enemies had no visible indication of their HP -- you had to know from experience and just keep track of the current state in your head.

Later Final Fantasy games fixed this by automatically redirecting attacks assigned to dead targets to randomly chosen living enemies.

X-COM

Next, let's compare the classic global alien invasion simulator, X-COM: UFO Defense, to both its modern remake XCOM: Enemy Unknown, and the fan homage Xenonauts.

The original X-COM is a great game, but some parts of its interface haven't aged well. For instance, you have to manually and individually re-equip all your soldiers at the start of every single mission. It will automatically make some decisions for you, sure, but if you have specific loadouts in minds for specific soldiers to take best advantage of their differing stats, you're facing ~5-10 minutes of tedium at the start of every mission.

There's other bits of fiddly minutiae and rusty mechanics:

  • You can't open a door without walking through it (and possibly getting killed in reaction fire by an enemy waiting on the other side).

  • You have no indication of the path a soldier will take when issuing a movement order, so you have no idea if they'll take the sane path behind cover, or if they'll randomly take the scenic route through no man's land and get themselves killed by reaction fire.

  • You have to remember to purchase or manufacture individual ammo clips of different ammunition types for every different kind of weapon, and you have to manually allocate these to every soldier on every mission.

Each of these are addressed in both X-COM and Xenonauts - opening a door is a discrete, separate action from movement, you receive a visual preview of the path your soldier will take before you commit to a move order, and each game streamlines ammunition management in its own way.

"But Lars!" you say. "The minutiae is what gives X-COM it's strategic depth! The new XCOM is great, but mechanically it's a greatly simplified game!"

And that's 100% true. XCOM: Enemy Unknown is a very different game from X-COM: UFO Defense. Instead of letting you take as many actions as you have time units for, you have a streamlined "move twice, or move and take one action" system. Instead of arbitrary soldier inventory with a weight limit, X:COM Enemy Unknown has predefined soldier classes with explicit inventory slots (ie, only one grenade per soldier -- two if you're lucky), and no ammo clips to contend with whatsoever.

X-COM: UFO Defense

XCOM: Enemy Unknown

To be clear, oil is not necessarily about streamlining or simplifying mechanics.

In most cases, applying oil simply means presenting the exact same underlying mechanic in a better way. In the cases where it does involve changing the underlying mechanic, it's about doing it in the least destructive way possible while getting the maximum improvement in user experience.

That's where Xenonauts is an excellent point of comparison. Where the new XCOM loads up on juice and production value while also streamlining the game design, Xenonauts leaves most of the original structure in place and mostly focuses on oil.

For instance, the New XCOM and Xenonauts both feature soldier class systems, but the former is an entirely new mechanic complete with skill trees, item restrictions, and other prescriptive rules, whereas Xenonauts' classes are simply customizable equipment loadouts. X-COM's classes completely change the nature of the game, whereas Xenonauts' classes simply let you equip everybody faster and get on with your missions. Xenonauts also preserves the original game's time unit system.

Xenonauts

Furthermore, in Xenonauts you still have to manage ammunition and inventory. However, they only kept the actually strategically interesting bits of this system. As long as you've researched a certain weapon type, you automatically have infinite amounts of its ammunition - but only at your base. When you send soldiers out on the field, you still have to decide whether it's better to load them up with a spare ammo clip, or an extra grenade, because they can only carry so much before suffering from weight burden.

In XCOM: Enemy Unknown, you still have to reload weapons in battle, but you can take that action an infinite amount of times. In Xenonauts, if a soldier has to reload but doesn't have a spare clip, their only recourse is to switch to another weapon (if they even have one), or run to another soldier and get a resupply. This makes for tense and exciting missions, just like in the original X-COM.

And even if Xenonauts had kept the base management minutiae of ammunition supply chains, it would still improve upon the reloading mechanic. To reload in Xenonauts, you simply click a single button from the main battle HUD. In the original X-COM, you have to dive into the soldier's inventory screen, fish out a spare ammo clip, and manually drag it onto their gun.

When your weapon's out of ammo, you just click on the clip icon.

 

NintendOil

But Oil isn't just for strategy games and RPG's. If you look back on classic games that still stand the test of time, you're likely to find well-oiled mechanics. And nobody's been consistently better at this then Nintendo.

Source: David D'Angelo

What's going on in this image? Notice how Mario is slightly underneath the left side of the block, yet when he jumps up he gets subtly pushed back flush to its left face. A naive collision detection algorithm would make him hit the block. Without this tweak, it would be extremely frustrating to try to jump on top of blocks in narrow situations, or between single-block gaps.

This is present in Super Mario Bros. 3 as well:

Source: David D'Angelo

EDIT: I didn't even notice this until David pointed it out, but in SMB3 notice how Mario hops up a bit extra when he would barely miss the jump!

But it doesn't end there. You also see this subtle collision-smoothing behavior in the Zelda series -- if Link would get "caught" on a wall but it's obvious the player's intent is to move forward, Link gets silently smoothed back onto the clear path:

Source: David D'Angelo

This sort of thing has been part of the Zelda series from the very beginning, and Troy Gilbert has an excellent breakdown of the subject that I highly recommend.

In this case, adding "oil" is literally about smoothing off the sharp corners!

Forgiveness, Please!

Another example is "Platform edge forgiveness", which can be seen in indie games like Braid, Spelunky, Mercenary Kings, Canabalt, and Offspring Fling!

An overly literal collision engine will make you fall as soon as your feet leave solid ground. But what if you give the player just a few extra frames, and if they push the jump button a few milliseconds too late, you still give them a valid jump?

Kyle Pulver has a great article on this subject:

"If you do this right then the player wont suspect a thing"

Source: Kyle Pulver (see article)

Oil it or Spoil it!

Summing up, it's impossible to give broad statements that are true for everything, but adding Oil to your game makes your game better 100% of the time, guaranteed.

So there you have it.

;)

 

EDIT: I noticed that unlike "Juice" and "Juicy", "Oil" has a problem with it's adjective -- "Oily" has a negative, unappealing connotation. But a helpful reader suggests "Slick" as an alternative. I like it!

Read more about:

Featured Blogs

About the Author

Lars Doucet

Contributor

Lars A. Doucet is the President of Level Up Labs, LLC, an independent game design studio based in Bryan, TX. His latest project is the successful RPG/Tower Defense hybrid Defender's Quest - http://www.defendersquest.com/. In addition to his work at LUL, Lars has been a consultant who specializes in 'Applied Gaming,' an emerging field that uses game design and game technology for new uses both in and out of the entertainment sector. Lars' applied gaming projects include Super Energy Apocalypse, in collaboration with the Houston Advanced Research Center, and CellCraft, through Wake Forest University and the MacArthur foundation. Lars has also consulted for Rice University's Center for Technology in Teaching and Learning and Texas A&M University.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like