The Perpetual Testing Initiative

Video Games

Portal 2 Level Editor

This week saw the release of Valve’s new beginner-friendly level editor for Portal 2, dubbed the “Perpetual Testing Initiative”. Many have praised this new software for its accessibility, and have advocated it as an entry-point for first-time level designers. I had a chance to experiment with it a little myself, and I’d like to explore some of the specific principles Valve employed to create this remarkably approachable editor.

Booting up the editor for the first time gives you a simple rectangular testing chamber. The walls and floors can be dragged in any direction to expand the space or create connected chambers and corridors. Puzzle devices are dragged and dropped into the world from a tidy panel on the left side of the screen (very much like The Incredible Machine.) Right clicking these elements in the world exposes a small selection of options, and allows you to connect them to other devices. Simply moving the camera around the 3D space will likely be the most challenging interaction for a fledgling designer.

The editor is stylized like a blueprint: elements appear simpler than they do in-game, some devices (like the Aerial Faith Plate) project dashed path lines, and ceilings / backward-facing walls are automatically hidden from view. A working knowledge of Portal mechanics is assumed, as there are curiously no tool-tips to explain how the various devices function. Even I had to use trial-and-error to figure out how the Track Platform works, as the official Valve wiki is unfortunately sparse at the time of writing.

A great deal of editor’s simplicity derives from the fact that it’s not a generic tool designed to make levels, but rather a very specific tool to make test chambers. Test chambers in the Portal universe have a well-defined format. They are white, sterile, closed and grid-aligned rooms. They contain some permutation of the 32 devices. They necessarily have exactly one entrance, one exit and one observation room (which functions as the level’s main light source.) These fiction-appropriate constraints keep the editor simple by limiting the number of possible ingredients.

The devices themselves demonstrate a similar simplicity; both input devices (buttons, laser catchers) and output devices (laser emitters, piston platforms, etc.) maintain only binary states. Attaching several inputs to the same device will require them all to be active (logical AND), but there is no sanctioned way to achieve OR, NAND or XOR. Connections between devices are always visible to the player, as the editor automatically generates an in-game dotted line between them. Keeping the interaction between devices simple allows the editor to abstract away from any sort of complex scripting logic.

Fundamentally, the Portal 2 editor works so well because of the judicious use of physical constraints. In The Design of Everyday Things, Donald Norman describes how these types of limitations “constrain possible operations” such that “desired actions can be made obvious.” Since it’s almost impossible to do the wrong thing in this editor, the only possible actions are correct ones. Designers are thus free to experiment without fear of breaking the level in an esoteric way. The only clearly incorrect operation I’ve found is placing two devices in the same spot; the feedback for this error is clear and immediate.

In my few hours of experimentation I made a simple test chamber called “Ducks & Drakes”, which you can download and play by hitting subscribe in the Steam Workshop. You should also check out the Perpetual Testing Challenge over at the MapCore Forums.

Tags:  · 

Moving Pixels Podcast

Video Games

League of Legends - Sona & Jax

A few weeks ago, the gents from the Moving Pixels podcast invited me to join them in conversation about League of Legends. League is an extremely popular free-to-play game in the style of Defense of the Ancients, and I’ve been rather hooked on it for the last few months. Jorge Albor, G. Christopher Williams and I discuss what we love (and hate) about the game, Riot’s clever business model, and the type of community that competitive games attract. You can download the podcast or subscribe on iTunes at the link below:

Moving Pixels – League of Legends

Since it’s been seven months since my last post, here’s a quick list of what I’ve been up to lately: I gave a talk at Juegos Rancheros (Austin’s indie game collective) back in November. Pax Britannica was ported to Montreal’s Arcade Royale and demoed at the Prince of Arcade showcase. Mostly, though, I’ve just been working hard on Starhawk (look for it on shelves May 8th!) However, all this does not excuse my writing hiatus; I’ll endeavour to resume regular blog cromulence over the next few months.

[Sona & Jax Lunar Revel fan artwork by RUshN]

Tags:  · 

Mechanical Drama in Jamestown

Video Games

Jamestown Screenshot

While I’m not typically a shmup player, lately I’ve been enjoying a great indie shooter called Jamestown. It piqued my interest with its colonial Martian setting and beautiful pixel art. However, the game’s lasting appeal rests in the strength of its peculiar Vaunt mechanic.

When activated, Vaunt grants the player a seemingly arbitrary list of benefits: a brief bullet shield, followed by increased damage and a score multiplier for as long as the energy meter is kept filled. In practice, this mechanic gives Jamestown its own particular systematic rhythm of tension and respite. I’d like to use Vaunt to explore the idea that a game mechanic can have an inherent dramatic arc similar to those created by traditionally authored stories.

When I speak of a dramatic arc, I mean something along the lines of the three-act structure commonly used in storytelling. Strongly authored media (films, books, plays, etc.) map very nicely to this kind of structure, as does the authored content in video games. For instance, a level in Jamestown is composed of a series of increasingly intense enemy waves followed by a climactic boss fight. The pacing and intensity of this level design is determined entirely by the game’s creators.

Three Act Structure

When examining a game’s effective dramatic arc, we must of also take into account the player’s agency. The abilities that the player has control over can increase or decrease dramatic tension. For instance, a bomb move that kills all the enemies on screen gives the player a breather, thus creating a moment of dramatic respite. A slow powerful attack creates high tension (as the move charges) followed by low tension (as the hit connects.) These types of mechanics create a parallel dramatic arc authored by the player. The two arcs superimpose each other, interacting in a sort of wave interference that heightens some moments and dampens others.

What would the dramatic arc for the Vaunt mechanic look like? It begins with normal moment-to-moment gameplay, with its mild variations in intensity. Some high-tension impetus for activating Vaunt would then occur: a mid-wave difficulty spike or simply the filling of the energy meter. In response to this event, the player hits the ‘B’ button to activate the bullet shield and begin Vaunt mode. The momentary safety of this shield creates a brief nadir in dramatic tension.

Jamestown - Begin Vaunt Mode

After the shield has expired, Vaunt mode remains active as long as the player continues to replenish the energy meter by killing enemies. As I mentioned previously, remaining in this mode grants a score and damage multiplier. These multipliers increase the benefit of skilful play, which in turn increases the innate tension of moment-to-moment gameplay. Furthermore, surviving the duration of Vaunt mode grants an additional score bonus. The dramatic tension increases parabolically as the potential benefit of the survival bonus accumulates over time.

Vaunt mode can terminate in three different ways. The most desirable outcome, illustrated in the graph below, is when the player runs out of enemies to kill and the energy meter expires gracefully, granting the full survival bonus. In terms of dramatic tension, this would be a plateau followed by a resumption of normal gameplay. If the player instead becomes overwhelmed during Vaunt mode, she has the option to press ‘B’ again to activate a second bullet shield. This choice ends the mode prematurely, only granting half the survival bonus. This outcome would be represented graphically by a second brief peak in tension. Finally, the player could die during Vaunt mode and lose out on their survival bonus entirely.

Jamestown - End Vaunt Mode

These graphs reveal some general ways that a game mechanic can increase or decrease dramatic tension. When they provide momentary safety, increase performance pressure or ransom potential reward, they have a strong dramatic effect over time. We can also see how the mechanical tension interacts with the authored dramatic arc. The encounter design provides the high-tension impetus for activating Vaunt, and the level’s difficulty strongly influences which way the mode will end. The nature of Jamestown’s Vaunt mechanic works in concert with its strong level design to create an exciting gameplay experience.

The MDA framework asserts that game mechanics create an aesthetic response in the player. When we observe this response over time, we see patterns of dramatic tension and reprieve that match those found in storytelling. We often praise the narrative power of heavily-authored games, but the best video game tales often emerge from system-centric games like Dwarf Fortress, Civilization and EVE Online. If we acknowledge that game mechanics have inherent dramatic arcs that superimpose the authored content, then we can begin to analyze mechanics in terms of their storytelling potential.

→ 2 CommentsTags:  · 

The Principles of Programming in SpaceChem

Programming, Video Games

SpaceChem screenshot

SpaceChem is a remarkable puzzle game about fake chemistry. The game challenges you to build a factory in order to transmute the given input molecules into the given output molecules. While chemistry is the theme, on a mechanical level it has more in common with programming. The methods used to tackle challenges in SpaceChem are akin to real techniques used by computer programmers. I’d like to elaborate on these manifold similarities, as well as explore how games like SpaceChem could be used to promote procedural literacy.

The player commands two circular “waldoes” by laying out paths and instructions for them. The waldoes follow the path and sequentially execute any instruction they come across. They can grab, drop, rotate, sync, bond, fuse, request input or dispatch output. The waldo’s analogue in computing is the processor, a hardware component that sequentially executes basic operations defined by machine code. Like processors, waldoes are the engines that drive the control flow of a SpaceChem factory.

When a waldo grabs a molecule, it gains the ability to perform instructions directly on it. In other words, a grabbed element is more readily and rapidly available than one lying elsewhere on the grid. Conceptually this is analogous to storing data in registers, a form of computer memory that is accessed very quickly and that the CPU manipulates directly. Just as a waldo can only grab one molecule at a time, computers have very few registers and must therefore rely on caching.

If grabbed molecules are like data in registers, then molecules left on the grid are cached. The cache is a larger, cheaper form of memory, but it is slower to read and write. Data must be written from the cache to a register in order to be manipulated directly by the CPU. The amount of memory in SpaceChem’s “cache” is governed by the area of the grid (8 x 10). Each coordinate on the grid can therefore be considered a unique memory address. This analogy is enforced mechanically: a factory “crashes” if two atoms collide on the grid, since you can’t store two values in the same memory address.

SpaceChem screenshot

Each factory has two waldoes, and they must be properly coordinated as they move through time and space. This coordination is facilitated by the sync node, which tells a waldo to wait until its twin has also hit a sync node. Parallel waldo management is akin to parallel programming, and they share the same perils: deadlock, starvation, race conditions, etc. The waldoes are like threads operating on shared memory space, and sync nodes are functionally similar to semaphores (operations that tell threads to signal and wait.) Operating two waldoes simultaneously in SpaceChem forces the player to confront the same shared resource problems as parallel computing.

SpaceChem and programming involve similar challenges: laying out simple instructions to achieve a complex result while managing limited time and resources. Like a good software specification, each puzzle is clearly presented as a black box defined only by its inputs and outputs. The player lays out instructions, starts up the factory, observes errors and corrects them, iterating until the puzzle is solved. Solutions can then be further optimized to take less time and use fewer instructions. SpaceChem and programming are engaging, flow-inducing activities because they have an identical inner loop: implementing, debugging and optimizing.

At this year’s GDC, Michael John asserted that programming is 21st century literacy. If computer programming is currently considered esoteric knowledge, it’s because our general education is not preparing students to think about problems in an algorithmic or systematic manner. Ian Bogost calls this procedural literacy: “the ability to reconfigure basic concepts and rules to understand and solve problems.” SpaceChem may not be an ideal game for the classroom (it’s far too difficult, for one), but it strongly suggests that the best way to learn about and engage with complex systems it to play with them.

→ 1 CommentTags:

Starhawk Announcement

Video Games

Starhawk Screenshot

If you follow me on Twitter or elsewhere, you may be aware that I moved from my native Montreal to Austin, Texas last year to work for a new studio called LightBox Interactive. We’ve been requisitely tight-lipped about our project until this last Friday, when we finally unveiled Starhawk to the community.

Starhawk is a third-person shooter for the PS3, and a spiritual successor to Warhawk. The game is set on the lawless frontier of space, where the rush to mine rift energy incites conflict between the scrappy Rifter union and the post-human Outcast. These two factions form the basis of the online 32-person multiplayer. The single player campaign follows Emmett Graves, a gunslinger pariah hired to protect the small mining town of White Sands.

The core of the game is characterized by fast-paced action and air/ground vehicle combat on huge open maps. The most iconic of these vehicles is the Hawk, which can transition from a nimble airship into a staunch mech. It also features a new system called Build & Battle, which allows players to quickly call down fortifications, turrets, vehicles and reinforcements in real-time on the battlefield. This distinctive system unlocks a multitude of strategic options and gameplay styles.

Starhawk is currently set to release in 2012, and you can follow its development on the Starhawk website. You can also check out a profile video of our studio and interviews with the project leads on G4. I’ll also add the usual disclaimer that opinions expressed in this blog are always my own and do not represent my employer.

→ 1 CommentTags:  ·  · 

© 2007-2014 Matthew Gallant, hosted by A Small Orange, powered by Wordpress.