The Coefficient of Clean pt.10

And what about 3D games! Displaying 3D objects or 3D environments on a 2D screen is inherently limited. Aside from splitting the screen and viewing a single object from 2+ different camera angles, there will always be a side of a 3D object that is obscured from the view of a single camera. Place a single camera in a 3D environment and there's no practical way a player can view everything. Of course, just because a game uses 3D graphics/space, doesn't mean important feedback elements will automatically be obscured. But it's a near guarantee. So if 3D doesn't automatically create cluttered games, the question is when does it and how?  

 

What's on the other side of the globe? One can only guess.

Consider 3D Camera Control

For real time 3D games like Super Mario 64 players are given control over the camera. Players can spin it left, right, up, down, zoom in over the shoulder, or lock it in place. It's important to understand that the analog control of Mario's movements are relative to the camera view. So camera control is a big deal. Considering the cleanness of the mechanics, being able to control the camera and Mario simultaneously affects the simultaneity of all the mechanics. 

If you haven't completely mastered 3D analog control and 3D camera control, you probably play Super Mario 64 or other 3D platformers the same way, by lining up the camera behind or to the side of the character and taking things one jump at a time. This is a way of simplifying the 3D space into a 2D one, an idea which I'll expound upon in an upcoming article. The reason players simplify the game this way is because understanding true 3D space and interpreting this space through a 2D screen is quite difficult. Judging any distance along the z-axis depth in a 3D space relative to the camera view is subject to ba3D (read more about it here). Without tight feedback design, games can greatly suffer from ba3D for a very emergent type of clutter. Notice how many games compensate in this area by featuring a circular shadow to indicate an airborne character's position along the z-axis. 

Consider Obscuring Elements

Yo, dog, I'm trying to play some Brawl!

Aside from ba3D, 3D camera design is generally plagued by all kinds of obscuring emergent issues. A odd piece of level geometry can cover up the camera view. Enemies or other characters can move in front of the camera (see Nintendog above). And it's possible for a camera to move inside solid objects. It helps when the system intelligently renders objects transparent so that if they get in the way, the player isn't completely blinded. Still, there seems to be no substitute for meticulously tweaked camera design. Super Mario Galaxy 1 & 2 or The Legend of Zelda: Twilight Princess are two games with very complex 3D environments and very polished camera design..  

However you play, you must understand that real-time 3D games will most likely suffer from some combination of these cluttered elements; simultaneity of controls (camera and gameplay) or ba3D/other obscuring camera issues. If there is no camera control there's a good chance that the developers have enough control over the presentation to avoid these issues. Rail shooters like The House of The Dead 2, The Typing of the Dead, Resident Evil Chronicles, Sin and Punishment, and Star Fox 64 have much more potential to be clean games than Super Mario 64.  

Consider Camera Control as a Mechanic

For FPSs the camera control is built into player aiming. In the same way that the camera is indirectly controlled by Mario's hoizontal movement in Super Mario Brothers, players control the camera view by aiming in an FPS. Or is it direct camera control? Is camer control linked with aiming, are are they one in the same? Can they be separated? If so, what does that matter when they're designed as one? Is camera control even a gameplay mechanic?

The following is a dialog between me and myself. 

• Is camera control a mechainc? I'll approach an answer by addressing another question; is pause a mechanic? Pause has no effect on the game state. It actually halts the game state. And even if you manipulate options in the menu during a pause, the game merely resumes when you unpause. I say it can't be a mechanic. 
• Pausing may not affect the game state, but it can change the nature of the gameplay challenge. You can activate some option in the menu. If you have a limited amount of time to complete a task or it's a relfex based challenge, pausing the game can give you extra time. So if you use the pause function to affect the challenge, it's a mechanic.  
• By that logic, the volume button is a mechnic. New challenges can be created by removing audio tells from the gameplay by turning the sound off. 
• Hearing sound does change the gameplay experience, but I wouldn't consider MUTE a gameplay mechainc either. But camera control is different. The camera can affect gameplay actions. In Super Mario Brothers enemies, actual interactable elements, spawn up off screen when the camera view draws near.
• I could just as easily say that these enemies spawn up when Mario the character draws near. Therefore, there's no way to prove that the camera in that game, which is still indirectly controlled by Mario anyway, affects the gameplay.
• Then what about Super Mario 64? When you change the camera angle it changes the relative control of Mario's movement. MOVE is a mechanic. Therefore, camera control affects a mechanic which affects the gameplay.
• Yes, it changes the relative controls, but it does not change game state directly. You still have to MOVE to move. I could mess with different menu options in an FPS that will change my controls. That doesn't mean that these options are mechanics. 
• What about a game in the first person with gameplay designed around perception? Moving the camera around is how you see different targets to gain information. Without this info, you won't be able to make informed decisions to win. Like playing with fog of war, the limitations of what you can see is a part of the game.
• I admit that I want to put camera control in a different group than PAUSE or MUTE. I'll say that camera control seems to be an action that doesn't inherently have a reaction that affects the game state but does affect the presentation and possibily the gameplay challenge. I'll call it a mechanaic. In the meantime, I'll think about tweaking the definition of a mechanic. 

Getting to the bottom of terms and terminology is harder that it looks. Examining the cleanness of 3D games continues in part 11. 

Comments

[NathanS]

Having Internal debates when your torn on something, a sign of madness, or deep thoughts? I'm hoping the latter because if it's the former they'll be coming to take me away any day now..

[Richard Terrell (KirbyKid)]

@NathanS

Maybe they'll take us to a wonderful place where people are free to talk about games in a meaningful way with specifics and everything. If such a place doesn't exists... we'll have to make it. I'm sure the internet has enough room.

[StephenM3]

In Super Mario World, you can scroll the camera left and right with the L and R buttons. Enemies (such as offscreen-spawning Bullet Bills) will appear when the camera scrolls to a certain point in the environment. Thus it is possible to force the appearance of an enemy by scrolling the camera. This can be used to bring an enemy to you while you are still standing in a relatively safe area, instead of walking into a more-dangerous environment where the enemy spawns.

I'd say camera control CAN be a mechanic, depending on whether it effects gameplay or not. Other things also fall into this zone: For instance in racing games, sometimes you can honk your horn to no effect on the game state. In some other games, however, a horn honk can alert pedestrians to flee, clearing an obstacle.

In a poorly-designed puzzle game, "pause" can allow you to figure out a solution while the timer is stopped. I could imagine a fighting game where you can "pause" the action, input some sort of game-changing command (such inputting a fighting move, which has the result as if you had input it "instantly") that would be impossible while not paused, then unpause.

Something can be used as a game-functional "mechanic" in one game, while another game can include a very similar feature that is not used as a gameplay mechanic.

Or so I see it.

[Richard Terrell (KirbyKid)]

@StephenM3

I like the way you're thinking.

In an FPS, when you move your view you also move your character. The character looks around which changes its animation and hitboxes. That's an effect on the gameplay interactions (or potential interactions).

Thinking along the lines of evaluating the cleanness of a game, what happens when the car horn (like in the example you gave) only makes pedestrians move out of the way on level 1 out of 100 levels. Is it a mechanic 1% of the time? Do we count off of the HORN for not being dynamic for 99% of the game (which falls under the mechanics part of the formula)? Or do we count it as an arbitrary limitation (in this case allowance) that falls in the subjective area?

Depending on how you go, different penalties would be taken.

I like how you specified by saying "game-functional." This implies that 1) the mechanic in question has a function i.e., you do something and the game responds somewhat reliably/predictably. And 2) that this function works along the value scale(s) for achieving the goal(s) of the game.

Would the HORN mechanic count if it only makes pedestrians move out of the way and if you couldn't hit them with your car anyway? What if they have no effect on the game interactions whatsoever besides appearing to get out of the way? Would this mechanic merely be like a near flourish or Easter egg surprise?

Getting to the bottom of questions like these is exciting. It's like philosophy meets game design.