Friday, January 04, 2013

Play to Conceive

Principle: Play without a purpose for new or better experiences.

As you develop your game, engage in unstructured play to get a feel for the game's mechanics and the gameplay opportunities they offer. Approach it as a curious child would, by looking, observing, grabbing, manipulating, throwing, arranging, assembling, taking apart, and putting back together everything around you to develop an intuitive sense of how it all works.

While playing, allow yourself to think of new mechanics or ways to improve the existing ones. Is there some mechanic that stands out as particularly fun or interesting? Could a seemingly unimportant mechanic be brought to the foreground? Is there something about the objects in the game that could make for a new and interesting mechanic?

This is different from playtesting in that it's intuitive, unstructured, and completely informal. You're not looking for bugs, flaws or balance issues; You're just playing around while looking out for interesting experiences within and beyond your game in its current form.

Example: Will Wright's SimCity evolved out of a war game called Raid on Bungeling Bay. That game included virtual cities with factory buildings the player could bomb and destroy. In playing with the game's editor, Wright discovered that building new cities was more fun than the game itself. He continued to develop the editor, adding new features and making the world more dynamic, ultimately leading to the development and publication of SimCity.

Friday, October 15, 2010

Narrative and Consequences

The holy grail of narrative game design is a game with a carefully constructed narrative that players can influence to the same degree as their real lives. The goal is to have stories that are every bit as engaging as traditional narratives but created in such a way as to enable a rich variety of player experiences.

For games in which content is written primarily by human beings, creating such flexible narratives is almost certainly impossible given the number of potential choices for the player -- far too many for any author to account for. On the other hand, for games in which content might be generated dynamically with the aid of computer algorithms, current Artificial Intelligence approaches aren't advanced enough to produce engaging narratives.

A less ambitious goal, therefore, is to make games in which players' decisions are limited but significant: limited because the possible choices and outcomes are only a small subset of those that would otherwise be available, and significant because the players' choices make sense to them and have a perceptible effect upon each game's environment. Even so, merging together narrative and gameplay is difficult to accomplish successfully.

Players should be offered meaningful choices

"Is doing X a better choice than doing Y? Why?"

For players to make effective decisions they need more information than games of this type typically provide. A game's narrative should be crafted in such a way that players can, in most cases, make informed decisions. This doesn't mean that optimal choices should be obvious or require no work to ascertain, but that players should be given the chance to foresee, to a reasonable degree, the possible consequences of their actions. Always provide enough information for players to have some idea of what the outcomes of their actions might be.

Players shouldn't be afraid to make decisions

"What if I make the wrong decision? Can I try again or am I stuck with it forever?"

Players may fear the possible consequences of their actions, leading to what some people call "analysis paralysis". It may be that players lack sufficient information as to the possible outcomes of their choices, or it may be the game is designed in such a way that players expect the consequences of their actions to follow them for the rest of the game. Players should have enough confidence in the game's design to know their experiences will not be ruined by making the "wrong" choices. Avoid long-term negative consequences and allow players to recover from undesirable outcomes.

Players shouldn't feel like they're missing out

"What would've happened if I'd done Y instead of X? What if the alternate ending was better?"

Having multiple paths for players to follow means players don't get to see all of your story. While this conceivably adds to the game's replay value, there are players who would rather not play through the entire game a second time just to see the parts they missed. Alternate endings are often little more than a gimmick, a testament to the narrow set of choices offered to players. Consider whether paths not chosen really add to the player experience and keep in mind that a narrow set of choices does not truly afford a sense of freedom.

Avoid the illusion of choice

Damned if you do, damned if you don't.

It may be tempting to have a large number of alternatives for players to choose from, but if all the alternatives lead to the same outcome then all you're doing is providing the illusion of choice. As already stated, providing significant choices means that players' choices actually make a difference in the game. Avoid offering choices that don't make any difference.

Narrative puzzles

In light of the fact that players' choices are severely limited compared to real life, avoid shallow, falsely personalized narratives in the style of "Choose Your Own Adventure" stories and instead make your narrative elements integral parts of your games' puzzles -- into parts of the games' mechanics. Just like some games call for the manipulation of objects in solving puzzles, games with narrative puzzles call for the manipulation of dialogue and story elements in pursuit of each puzzle's solution. This avoids the problem of complicated branching while still providing meaningful choices in the context of each game's narrative.

Tuesday, September 28, 2010

Controlling Aspect Ratio in Unity

Games made with Unity allow users to pick a screen resolution on startup through Unity's Display Resolution Dialog. While it's possible to disable this feature and force a game to use a particular resolution, it's generally not a good idea to deny users the ability to set the game's resolution to whatever they think is best. Such flexibility comes at a price, however, and one of the costs is the loss of control over the game window's aspect ratio.

Differences in aspect ratio aren't necessarily a problem, but I think it's generally a good idea to keep things as consistent as possible regardless of the system on which a game is running. For the camera, such consistency ensures that what you see during development and testing is also what players see once your game is released: Objects visible from a particular vantage point will be visible on all systems, and those that aren't visible will likewise remain out of view. A consistent view across systems means the context is the same for all players, with no player seeing more of the environment or the objects within it than intended by the game's designer.

While Unity's game editor allows developers to choose between a number of aspect ratios while developing a game, there's currently no way to specify a particular aspect ratio when a game is run outside of Unity's development environment. There is, however, a way to do this with a bit of extra effort. What follows, then, is a tutorial on how to guarantee the use a particular aspect ratio regardless of the game's resolution.

The first step is to create a camera script to adjust the camera's viewport according to the game window's current size and the desired aspect ratio. The script is created by choosing Assets -> Create and the desired script type from the editor's menu, after which the code to set the aspect ratio is added to the script's Start() function so that it's executed during the camera's initialization step. Here's some C# code that does just that:

// Use this for initialization
void Start ()
{
// set the desired aspect ratio (the values in this example are
// hard-coded for 16:9, but you could make them into public
// variables instead so you can set them at design time)
float targetaspect = 16.0f / 9.0f;

// determine the game window's current aspect ratio
float windowaspect = (float)Screen.width / (float)Screen.height;

// current viewport height should be scaled by this amount
float scaleheight = windowaspect / targetaspect;

// obtain camera component so we can modify its viewport
Camera camera = GetComponent<Camera>();

// if scaled height is less than current height, add letterbox
if (scaleheight < 1.0f)
{
Rect rect = camera.rect;

rect.width = 1.0f;
rect.height = scaleheight;
rect.x = 0;
rect.y = (1.0f - scaleheight) / 2.0f;

camera.rect = rect;
}
else // add pillarbox
{
float scalewidth = 1.0f / scaleheight;

Rect rect = camera.rect;

rect.width = scalewidth;
rect.height = 1.0f;
rect.x = (1.0f - scalewidth) / 2.0f;
rect.y = 0;

camera.rect = rect;
}
}

Once you've saved your new camera script, add the script to the camera by dragging the script from the Project window onto the camera's listing in the Hierarchy window. Now when you run your game the camera's viewport will be scaled and positioned to match the desired aspect ratio*.

Now the next step is to add a second camera to render the "black bar" region of the screen. While you can choose to render whatever the second camera is pointed at, in most cases you'll want to set the camera to render only a flat color such as black. To do this:
  1. Create the camera by choosing GameObject -> Create Other -> Camera from the editor's menu.
  2. Set the camera's depth value to -2 so it's rendered underneath the main camera (whose depth value defaults to -1).
  3. To set the black bar region to a solid color, set the camera's Clear Flags to "Solid Color", set the Culling Mask to "Nothing", and finally the Background to the desired color.
That's all you need to do. Now your game will run with the desired aspect ratio regardless of the user's choice of resolution.



* When running your game from within Unity's editor, be sure to have the Game window open and visible in the editor when you run the game. There's currently a bug in Unity 3.0 (and possibly in earlier versions as well) where the window resolution reported to the script does not match the actual resolution of the window inside the editor if the window isn't visible at the time the play button is pressed, leading to a viewport with the wrong size.

Wednesday, September 02, 2009

Saving, Reloading and Player Failure

When the subject of free versus restricted saving comes up, people often end up conflating the issues of players being free to save their progress at any time and games requiring players to replay certain segments upon failure. The assumption is that the proper response to player failure is for the game to reload the latest save state, thus leading to a framing of the issue of loss of player progress in terms of free versus restricted saving.

Unrestricted saving mechanisms are essential in modern games in that they allow players to quit the game at any time without losing progress. This does not, however, mean that loss of progress upon failure is an illegitimate mechanic. Countless commercially successful game designs that purposely incorporate just such a mechanic show quite clearly that loss of progress upon failure is a perfectly legitimate mechanic. Ultimately, the answer to the "free save" dilemma is not to design a game such that progress can never be lost, but to design a game such that its response to player failure isn't coupled to the game's save system.

Therefore:

Principle: Uncouple a game's save/reload mechanism from the game's response to player failure.

Rationale: A game's response to player failure should be designed into the game rather than be defined by something as arbitrary as when was the last time the player saved the game. Instead of reloading the latest save game whenever the player fails at a particular task, restore the game to a state that is known at design time given the player's progress so far. This makes it possible to divide player progress into milestones without subjecting players to a crippled save system.

Monday, July 20, 2009

Emotions in Games

Authors and filmmakers who wish to evoke particular emotions in their audience often rely on the audience's ability to empathize with the characters portrayed in the narrative, and especially with the protagonist. The author sets up situations in which characters experience particular emotions in the hope that the audience will themselves have similar feelings, or at least understand why the characters feel the way they do. The author is in control of the characters' emotions, while the audience's emotions derive from sharing in those characters' feelings and experiences.

Game designers who wish to evoke particular emotions have it somewhat more difficult. Unlike books and movies, where the author is in full control of the protagonist, it is the audience itself that is largely in control of a game's principal character or characters. Although designers can script particular emotions into a game's protagonist by taking control away from the player or reducing the number of available choices, this can feel like cheating to a player who feels his or her character should be feeling something different; An author like Shakespeare can write Romeo such that he wishes to die upon seeing an apparently dead Juliet lying in front of him, but a game designer cannot force the player to wish the same for his character.

How, then, does a game designer create emotions? Several options present themselves:
  • Atmosphere - Designers may encourage particular feelings in players by presenting them with emotionally suggestive images, sounds and music. This is all about transporting the player to an emotionally suggestive imaginary environment.

  • Subject matter - Audiences can respond emotionally to particular subjects. Games can touch upon the human condition or deal with controversial subjects to evoke strong emotions. If done incorrectly it may earn a game more critics than fans, but done correctly it may perhaps be the most crucial element in crafting mature, dramatic game experiences.

  • Gameplay challenges - The mechanics of games and competition encourage certain emotions in players. At the simplest level, these emotions concern the player directly rather than the player's character. In games that contain a narrative, these basic emotions can be modulated through narrative significance, in that overcoming or failing at particular challenges has specific narrative consequences designed to promote particular feelings in both characters and player.

  • Other characters' emotions - Just like authors can evoke particular emotions by getting the audience to empathize with the characters he creates, so can game designers evoke particular feelings by getting the player to engage emotionally with the characters in the game. Unlike in books and movies, however, it is a mistake for designers to rely on the protagonists emotions, which are perhaps best left unstated.

Wednesday, November 26, 2008

Moving Around in 2 and 3 Dimensions

Here are some differences between ground-level 3D and top-down 2D environments, and their implications for ease of navigation:
  1. The way the shapes of objects change as the player moves around the game environment. In 2D environments, rigid objects retain their projected shape as they change position and orientation due to player motion, while in 3D environments their apparent shape can change significantly.
  2. The way the angles between objects change as the player orbits around a particular point or travels along a path1, as measured from the camera's perspective. In 3D environments the apparent angles between objects are significantly affected as the player moves around, but remain fixed in 2D views.
For these reasons, a 2D view is generally more stable than a 3D view, as it doesn't change quite as radically as the 3D view when the player moves around the game world. Furthermore, since the view in top-down 2D games doesn't usually rotate as it does in 3D, a typical 2D view is remarkably stable compared to a 3D perspective. A stable view provides a more recognizable context than a more dynamic view, which makes it easier to tell where you are and which way to go.



1. If the player is moving along a straight line, angles between objects will change only if parallax is present.