WILL Talks GAMES: IS it Obvious?

As I sit here, gazing across to the other end of my college hallway, I tend to think of a lot of things as I stall for time to go home, dodging assignments and procrastinating like a smooth criminal.  A lot of my time sitting and thinking is dedicated to my personal projects, not my schooling: "I need some ideas for CrookedFingers articles", "What angle should I take to my next Let's Play?", or the ever-so-lovely "...isn't it weird that Mario games have a counter timing down, whereas Sonic games have a timer counting up?"

Y'know, just sittin' here...hanging out!

Isn't that weird, though?  Sonic the Hedgehog was birthed from the concept of finishing Mario's world 1-1 as fast as possible.  Why does the game record your time rather than rush you?  Why is there even a time limit in a slower-paced game like Super Mario Bros.?

Playing the role of an impromptu game theorist, I would have to say that every single mechanic present in a game faces a crucial design decision: will the player be shown this mechanic?  I would like to shed some light on something in video games I feel would only be considered if you were in the field, or if you were a college sick of asking random people what their New Year's resolution is:

Let's talk about Implicit and Explicit Design.

Now, did I just make those terms up on the spot?  Well yeah - trying to make your theories sound like a credible idea worthy of study is what being a theorist is all about!

My pitch here is that, whenever a feature is being put into a game, it's up to the developers to decide whether the player will know the feature exists - or at the least, whether or not the player will know how it works.

What you see: Lots of cutesy Pokémanz.
What I see: Smart game design.

When a player is notified that a background calculation or minor feature exists within a game, that's Explicit Design.  This is going to sound ridiculous and rudimentary, but examples include holding up to six Pokémon at a time, or that small Mario dies upon contact with an enemy.  Everyone who's played Pokémon or Super Mario knows these are rules in their respective games.  But what if they were designed implicitly?  Could they be designed implicitly?

The way in which the "six-Pokémon" concept is explicitly designed is to have access to a menu, usually reached by means of the X-button, START, or the touch screen, in order to access a visual list of your current monster roster via the "POKéMON" option.  The feature was designed to be accessible, known, and mastered by the player, no matter how simple!

How would you design this mechanic implicitly?  Take away the menu and PC system - essentially, remove any player-controlled method of checking on the status of your Pokémon.  This would be an especially stupid way of designing this specific mechanic though, right?

That's why knowing the difference and making the right decision is so important.

What's tougher to nail down is an example of Implicit Design is.  It is only implied to exist on the surface, after all!  I suppose it could be debated that very cryptic or well-hidden details could be considered implicitly-designed, but even then, it's a bit of a stretch.  If something is extremely well-hidden by a game, it's still explicitly put into the game to be found.  Perhaps we could consider things like Gossip Stones in Ocarina of Time to be a mixture of the two design choices!

BOI-OI-OING! Oh, and remember when you could
rocket-ship these things off into the sky

But what would entail an implicit detail?  It'd be the kind of thing that matters within the game, but is something you have absolutely no control over manipulating.  It's a rule set by developers, but is a rule that you, as the player, have no choice but to abide by.  Things like the level design, movement speed of the character, and enemy qualities (hitpoints, attacks, etc.) are all implicit details that are implied to be coded into the game, but are not things we have immediate control over unless indicated otherwise by another rule in the game.

If you want a really accurate example of implicit design put into a game, then there's one game mechanic across every game that utilizes them that remains static and forever hidden from control: experience bases.

In any RPG you play, you need oh-so-many experience points to advance to the next level.  That's pretty simple!  We also know that, as the games go on and you get stronger, you require more experience points to level up.  Now think of this: in 99% of all RPGs, it may be possible to have a bonus or item that grants you more experience points...but have you ever played a game where you can affect how much experience you need?

Ever wanted a game mechanic where you could change this?
THEN GO MAKE YOUR OWN GAME, DARN IT!

That's an implicit design choice - experience bases are derived from an equation that is pre-determined by the game designers.  Mechanics are usually left implicitly drawn because of the complexity or skill level require to make them accessible to the player.  Giving someone who would know how to work the mechanic may break game balance as well.  In this example, it's obviously both: you can't expect eight-year-old children to understand the different segments of an experience base script and deconstruct your computer science-approved algorithm.  Nor can you allow people who know how to deconstruct this system in order to make the game really easy for level-gaining.

Static systems that are meant to be regulated are usually implicit by nature, get it?  Even basic things like the range of Link's hookshot are implicit.  Anything that has a limit you can't normally surpass will fit this criteria!

Implicit systems can also be mechanics created by an assuming consumer.  What I mean is, essentially, "game clichés" are examples of Implicit Design.  We've all been hard-wired by games now to expect which button will make a character jump in a platform game, or which button will make a gun spray bullets in a shooter.  One stick moves the character, the other stick moves the camera - we've seen it all and memorized it.

Even that is implicit design!  It's simply implied to the player that they'll know how to control the game from the get-go.  By assuming the player has picked up on the patterns of control schemes, you can use that to your advantage as a developer to minimize the tedium of a tutorial.

Take a look at your favourite game, and you'll notice explicit and implicit design choices all over the place, whether or not the developers intended it as such.

Take Donkey Kong Country, for example - jumping was explicit, as was the roll attack.  But was the extra distance jump executed by the combination of the two?  There were some secrets you could only attain by exploiting the controls in this way.  Secrets were explicit by nature, but the methodology to get some of them was completely implicit.

That's how you grab a completionist by the balls.

These two design choices, no matter how well-thought out or not, are the foundation of an engaging game.  Certain mechanics have to make sense in how they're executed, as well as to consider the complexity being conveyed to the player by balancing what should be explicitly shown to the player and what should operate in the background.  Simulation games love having lots of explicit design - we want to have control and choice in what we do!  Puzzle games, however...well, we don't really need so many options and things to worry about.

What do you think?  What role do you feel implicit and explicit design plays in the development of a video game?  Which category would some of your favourite video game features fall under?  Which features blur the line between the two?  Sound down in the comments below!

~WILL