Showing posts with label architecture. Show all posts
Showing posts with label architecture. Show all posts

Sunday, May 22, 2016

Progress report: Moses


Now that summer vacation is here and I don't have to teach, I now have a lot more time to put into some projects. Here's one of the new ones I'm doing for the summer:

"Moses" (tentative title) is a collaboration between me and Eddie Cameron for the Power Broker game design challenge. It's kind of like 80 Days plus SimCity / Cities In Motion -- you are famous urban planner Robert Moses and you have to drive around New York City and visit various locations around the map, but to make commuting easier, you can also build public works projects like highways, bridges, public housing, a UN building or two, etc. which all interacts with the traffic simulation and public approval. Maybe there will be little narrative vignettes and conversations along the way too.

Eddie has been doing all the complicated math simulation stuff, while I've been writing a lot of the basic game code and UI. We're still basically in the early prototyping stages, trying to figure out a lot of the game as we go along. Here's some of our thinking...

Monday, March 7, 2016

A history (and the triumph) of the environment artist: on The Witness and Firewatch


This post vaguely spoils random bits of Firewatch and The Witness. I wouldn't worry about it.

Only a few years ago, hiking games (first person games with a focus on traversing large naturalistic landscapes) were rather fringe. Early indie masterpieces like Proteus and Eidolon abstracted the landscape into pixelated symbols, with a special interest in simulating weather and wildlife to make it feel real. But it took "mid-period" hiking blockbusters like The Vanishing of Ethan Carter, Everybody's Gone to the Rapture, and Dear Esther (2012 remake) to monetize the genre with all their glossy near-photorealistic graphics.

Now we are entering a later period of hiking games, epitomized by The Witness and Firewatch's less realistic visuals. It represents these environment artists finally asserting their control over a project and their identities as artists, within older traditions of gardening and landscape painting. To better understand this latest shift, let's think about the social and technical history of the environment artist in 3D games.

Thursday, July 2, 2015

Lighting theory for 3D games, part 4: how to light a game world in a game engine


This is part of a series on how I approach game lighting, from a more general and conceptual perspective. I build most of my examples in Unity, but this is meant to be generally applicable to any 3D game engine, most of which have similar lighting tools.

We started by thinking about light from a cultural and conceptual lens in part one. In part two, we treated light more instrumentally in terms of level design and readability. Then in part three, we surveyed the three-point lighting method for use in games. But none of this theory matters if we can't actually achieve it within the semi-hard constraints of computer graphics.

Lighting is traditionally one of the slower or "expensive" things to calculate and render in a game engine. Consider the science of visible light: countless photons at different wavelengths bouncing around at unimaginable speeds that somehow enter your eye. To do any of this at a reasonable framerate, game engines must strategically simplify light calculations in specific ways, and then hope players don't notice the inconsistencies. It is "fridge logic" -- we want the player to nod along, as long as it "looks right."

Okay, so how do 3D game engines generally do lighting?

Thursday, June 4, 2015

Local level design, and a history / future of level design

Right-side modified from “Unscaping the Goat” (Ed Byrne, Level Design in a Day @ GDC 2011)
This is adapted from my GDC 2015 talk "Level Design Histories and Futures" and resembles a similar but much shorter talk I gave at Different Games 2015. By "level" it means "level in a 3D character-based game", which is what the industry means by the word.

The "level designer" is a AAA game industry invention, an artificial separation between "form" (game design) and "content" (level design). The idea is that your game is so big, and has so much stuff, that you need a dedicated person to think about the "content" like that, and pump it all out. This made level designers upset, since they were a chokepoint in the game production process and everyone blamed them if the game was shit. To try to bypass this scapegoating, level design has changed over the past decade or two, from something vague / loosely defined, to something fairly specific / hyperspecialized.

What is the shape of this level design, what did it used to be, and what else could it be in the future?

But first, let's talk about chairs.

Sunday, May 3, 2015

Lighting theory for 3D games, part 3: the heresy of three-point lighting


This is part of a series on how I approach game lighting. Part 1 was about light fixtures, and part 2 is about light as a formal material.

In part one, we began by thinking about light culturally -- light has meant different things to different people across history, and you must consider that meaning when lighting your spaces. But in part two, we observed that much of our everyday relationship to light is more immediate and less intellectualized, that we often use light to help us do things. Theoretical frameworks about light help us articulate what we think the light is doing.

One of the most common theoretical frameworks for lighting is the three-point lighting system, used mainly in photography and film. As I argued in part 2, one of light's most important jobs is to allow you to read the surface or topology of an object. The three point system helps us formalize light source in terms of how to "read" an object. (I also argue that it has some serious weaknesses for 3D video games, but we'll get to that in a minute.)

It's called "three point" because there's at least three light sources involved:

Thursday, March 19, 2015

Lighting theory for 3D games, part 2: a formal approach to light design, and light as depth

Here's how I generally, theoretically, approach lighting in my games and game worlds. Part 2 is about light and function, mostly for level design.

In part 1, I talked about how different light sources have different connotations to the viewer, and these meanings are culturally constructed. In New York City today, an antique Edison bulb connotes trendy bourgeois expense, but 50 years ago it might've been merely eccentric, and 150 years ago it would've been a thrilling phenomenological novelty.

But people rarely intellectualize lighting this way, in, like, your own bedroom. In your daily middle class Western life you don't usually agonize over the existential quandaries of electricity, you just flip the light switch without looking. When in familiar places, we experience light as a resource or tool and take it for granted. So much of our everyday relationship with light concerns its functionality and what it enables us to do.

Saturday, March 14, 2015

"Local Level Design" at Different Games 2015, April 3-4 in Brooklyn, New York

"American Corinthian" via
Paolo Pedercini
In about 3 weeks at Different Games 2015 in Brooklyn, I'll be speaking about "local level design", a practice of level design that I setup in opposition to industrial AAA level design methods and procedural level design. Local level design is level design concerned with player community, sustainability, and context; it rejects a top-down formalism that demands game levels exist as territories with strategic affordances orchestrated by an architect, and it sidesteps a technological imperative to engineer and articulate a fixed grammar that a game engine must understand. Instead, local level design is highly conceptual, to the extent that few people actually play these levels at all.

If you'll be around the New York City area in the beginning of April, come hangout at Different Games, and perhaps see me talk! Or if you can't, but still want to support the conference, then know that they do accept donations.

Details and stuff (but no schedule yet) are at their website. See you there maybe!

Sunday, February 8, 2015

Upcoming talk: "Level Design Histories and Futures" at Level Design In A Day, GDC 2015


I'll be presenting a talk on "Level Design Histories and Futures" at the Level Design In A Day track at GDC 2015, alongside other stuff by Clint Hocking, Joel Burgess, Steve Gaynor, David Pittman, Forrest Dowling, Nels Anderson, Jake Rodkin, Kate Craig, Brendon Chung, and Liz England. It's a huge honor to be associated with these people.

My talk is about level editor histories, the level designer as an industry role, level design as modernist formalism, and what a postmodern sustainable level design practice might look like. I'm kind of serving as the theory-heavy talk this year, right at the end of Tuesday at 5 PM, so I'm going to try to synthesize a lot of the previous talks together and propose some frameworks to digest them... and um I hope I'll see some blog readers there / I hope you'll still be awake at that hour!

If you can't make it to GDC, I'll try to put up the slides afterward, and I'm sure it'll be streamed or recorded or something.

Thursday, January 29, 2015

Lighting design theory for 3D games, part 1: light sources and fixtures

Contemporary Jewish Museum (San Francisco, California)
Here's how I generally, theoretically, approach lighting in my games and game worlds. Part 1 is about the general concept of lighting design.

Mood is the most important end result of your lighting. The "functional school" of game lighting, which maintains that lighting exists primarily to make a space readable so that the player can navigate it and shoot people -- can be useful in my eyes but only so far as that gameplay is tactical violence, and when that violence can support evoking a mood. The rest of the time, some designers often seem content to light their spaces like a furniture catalog, or even leave it as a total after-thought. Lights can do more than show-off your normal maps and show where to walk to trigger the next cutscene, okay?

So let's begin: lighting design is a discipline that has existed since the beginning of sunlight.

Friday, September 12, 2014

Liner notes: Intimate, Infinite (part 2), on protagonists / race / gardening / chess.


These are some notes about my process / intent in making my game Intimate, Infinite. Spoiler warning is in effect for this game as well as the 1941 Borges short story that inspired it. Part 1 is on my general reading / plotting / interest in the frame narrative.

Borges' protagonist Tsun, or my Wang Peng (a name taken from a fictional college student in a Mandarin language textbook) has mixed motives for killing the sinologist.

He's a Chinese man more or less assimilated into Western ways, with a healthy dose of self-loathing for his own heritage. That makes this story one of the few "Western literary canon" texts that directly engages with how Asian people might react to Westerners being fascinated with Asian stuff (side note: in this vein, Irma Vep is one of my favorite movies / I really want to make an Irma Vep game someday)

Tuesday, August 5, 2014

On video game corridors in "Elements of Architecture"

I wrote about video game corridors for the huge expensive hardcover 1000+ page Rem Koolhaas book-set "Elements of Architecture" -- it's part of an entire book about corridors, alongside books about doors, walls, etc.

The bit that I've read has a pretty contemporary approach to things, talking about film geography and nationalism in the same breath as my lonely page that touches on the technical / level design aspects of corridors.

Look mom, I'm a published architecture critic now!!!

Wednesday, July 9, 2014

"Keys" by Ryan Trawick, and the emerging shape of post-mod culture and walking simulators


Keys is a newly released single player Source mod, made mostly by Ryan Trawick, that is freely available to anyone with a Steam account.

... Which is made possible by Valve's generous licensing of their Source SDK 2013 Base. This is kind of a big shift in policy for Valve. Historically, mods have been locked to their parent platforms so that they could drive-up sales of triple-A retail (e.g. people buying Arma to play the original Day Z, or Warcraft 3 to play the original DOTA), but something here has changed. Perhaps Valve has decided they have enough money, or perhaps they realized Steam is already a powerful platform to lock-in people anyway. So now, Source 1 is kind of transitioning into more of a middleware platform like Unity or Unreal, though most people outside of the TF2 / CS:GO communities have generally moved on already.

What are Source mods in a "post-mod" age, where they're not even modding a retail game anymore, and they're freely distributed and shared? Can we even still call these things "mods", or have they transcended that type of framing?

Tuesday, May 20, 2014

Notes on discontinuity and interiors in open world games

To enter a different level in Thief 4, you frequently have to mash [E] to pry open glowing windows (or lift fallen wood beams) as the game "seamlessly" loads the next level in the background. You will see this screen a lot.
An "open world" is a marketing tool / level design structure where the game world is gradually loaded or "streamed" as you explore it, so that it seems like one large long continuous level. In many respects, this continuity is an illusion; the game developers built the world in chunks and the game engine thinks of the world as chunks, but players experience the chunks as they're stitched together. It's an immersionist fantasy -- of no loading screens or progress bars, of seamless transitions between worlds.

But as I mindlessly mashed the [E] button on my keyboard for the 30th time to enter a different level in Thief 4, I realized that (a) this is a really bad attempt at hiding load screens, and (b) I tolerated the (brief but just as frequent) loading screens in Skyrim much better because those are honest about what they're doing. A loading screen unambiguously signals discontinuity to the player, a break between parts of the world. An open world overworld can only exist if there's an underworld beneath it, and I argue that it's okay (or better) if you clearly mark the borders because it's okay if we stop interacting with a game for a second.

When do open worlds choose to be discontinuous with a menu, loading screen, or lobby? When does one wait to "enter" an interior, to voluntarily break the flow of play?

Saturday, August 31, 2013

Further notes on developing games for virtual reality.


I'm pretty sure no one remembers that I promised to release Radiator: Polaris at the end of August 2013 (shhh), but here's what happened -- I was asked to join the Oculus VR Jam, so instead I've spent the last 3 weeks working mainly on Nostrum, a Porco Rosso inspired arcade flight sim / narrative-y roguelike. I think I'm going to work on it for another week or so before going back to Polaris.

A lot of my interest stems from VR requiring developers to re-consider a lot of basic ways of doing things in video games.

Friday, August 16, 2013

"Gone Home" and the mansion genre.


This post does not spoil any specifics of the "plot" in Gone Home, but it might sensitize you to its delivery mechanisms and some details.

A mansion means: old, rich, and scary. The most quintessential "mansion games" that emphasize these qualities might be Maniac Mansion, Thief, and Resident Evil -- these games would not work without the mansion tropes that figure prominently in their game design. Most importantly, mansions are big.

Gone Home is very aware of its place in the mansion genre, a genre that emphasizes the primacy of inventories, objects, and possessions. Here, the lightweight puzzle gating and densely hot-spotted environments evoke adventure; the first person object handling and concrete readables evoke the immersive sim; the loneliness and the shadows evoke horror. In a sense, this is a video game that was made for gamers aware of all the genre convention going on -- in particular, one moment in the library will either make you smile or wince -- but in another sense, this is also a video game made for humans. Gone Home carefully negates or omits core "gameisms" of the very genres it comes from.

The characters in Gone Home are tolerable (or even great) because they do not hesitate in doorways and stare blankly at you. It's the same trick that Dear Esther pulled: fictional characters in games develop full-bodied, nuanced personalities precisely when they're *not* constrained by fully simulated virtual bodies present in the world. (Maybe Dear Esther is actually a mansion game?)

Monday, July 29, 2013

Radiator Book Club: Architecture, design and criticism.

Book Club posts recommend books and approaches to consuming them for today's go-getting game developer / enthusiast.

ARCHITECTURE
These are books that I find useful for learning about architecture as design and theory. I've never formally studied architecture; my reading usually has to pass a "can I apply this to video games?" test that is intellectually cynical but like whatever. Fortunately, few things in architecture fail that test.

Grammar of Architecture (Emily Cole)
Every single environment artist should have a copy of this book; it's basically a 300+ page cheat sheet that talks about common decor patterns / floorplan structures of most pre-Neoclassical architectural styles around the world. Cole generally does a good job of balancing discussion of ancient Indian temple ornament with the The Alhambra's mathematical dimensions, trying to explain the history and ideas behind individual elements. It's effective because it doesn't try to be deep and is content to be a general survey, relying heavily on (numerous, small) drawings and pictures. It gives you a fast surface understanding of a style (e.g. a few pages for Gothic, and that's it) -- enough to build it and move on. These are, essentially, 150+ pre-assembled moodboards.

Friday, June 14, 2013

Design reboot: Thief.


This post relies on familiarity with the gameplay / affordances in Thief. You may want to read Dark Past or my write-up on "Assassins." You're also encouraged to read through Mr. Monahan's Design Reboot blog.

I've been watching Thief 4 coverage over the past months and I'm increasingly convinced that I'm going to hate it. So let's pretend, just for fun, that I'm making a Thief-like... What are the best qualities of Thief to preserve, and which parts of the sacred cow would I lop-off? Here's what I'm thinking:

KEEP: Level size. Thief levels vary from medium to extremely large. "Life of the Party" was a single mission where you had to traverse an entire cityscape of rooftops through two dozen buildings and then also infiltrate a huge skyscraper at the end. Sheer architectural scale is important to maintain a sense of...

KEEP: Infiltration and exfiltration. You have to get in, rob the place, and get out. There's always an outside and an inside, and it's great to feel that you're not supposed to be inside. But previous Thief games usually neglected exfiltration as redundant backtracking or worse -- something totally nonexistent because you've already incapacitated the entire guard garrison by the end of a mission. (My favorite Thief 1 mission, Assassins, is one of the few missions to really do something with exfiltration.)

ADD: Organic use of dynamic lighting. With dynamic lighting and shadows, you can do totally unimaginative setpieces where you have to hide in a guard's shadow or hide in the shadow of moving objects on a conveyor belt. But something else is going on here: with dynamic lighting, open doors and windows become light sources -- and if you can close the door or block the window, you've "extinguished" that light -- but if there's a ramp in front of that window, you can't put anything there to block it because it'll just slide down, etc. That possibility sounds much less horrible than a contrived puzzle that you designed to death.

Thursday, May 30, 2013

Design futures: AutoBrushes, levels that build themselves, and the politics of procedurality.



If Bethesda's detailed GDC presentation about modular level design kits for Fallout / Skyrim showed me anything, it's that modularity is actually a huge pain in the ass -- and not the good kind of ass pain either. Why should we keep building 3D levels in this slow, totally unnecessary way, with a workflow that's at least a decade old?

I remember a time when level design was slightly faster, and that time was the time of the brush. What if we could combine the benefits of modularity (variety / adaptability / abstract detail out of design) with the benefits of a brush-based workflow (simplicity / speed / focus on "platonic forms" of design)?

Monday, April 29, 2013

Let's Play: the first section of Anomalous Materials from Half-Life 1



So I recorded a Let's Play for Jake Elliott's "Let's Play" event in Chicago a few days ago. Since the event's now over, I thought I'd share the video for the entire internet to see. In it, I talk a bit through the design of the first section of Anomalous Materials, and how it played with the affordances of first person views / represents two divergent ideas of "realism" / presence, and what being in a virtual world entails. WARNING: a good portion of the video is me staring at a wall and talking over it, sorry...

Saturday, February 2, 2013

Narrative systems workflow; using Fourier analysis and level design metaphors to systemize stories.

This assumes familiarity with Shakespeare, a procedurally-branching narrative system that I'm designing. For an overview / introduction, read "More talk, more rock."

I started by arguing that interactive fiction's narrative systems expose too much complexity and detail to its authors and players, or at least more than most people need or want. With Shakespeare, I hope to achieve just a fraction of that functionality, and I think that fraction is enough to be very compelling while facilitating a writer's work.

In engineering Shakespeare, I think of the system in four parts:
a) The real-time system that runs algorithms, interfaces with the game as the player plays.
b) The data / format of narrative itself, how it's structured.
c) The Unity editor interface for generating, editing, or creating the narrative data.
d) The suggested workflow / instructions for using that interface.

Now that I have enough of a base implemented, I'm starting to think more about that last part, the operations design. Roughly, I think the tool could work like this: