"Press F to Intervene": a brief history of the Use Key Genre

There are NO *detailed* spoilers for BioShock Infinite in this post, so relax. I try to speak in a really general / vague way about what happens in the last third of the game.

Can a game about picking the right hat to decrease your machine gun recoil by 45.2% -- can that game reasonably do the work of talking about what it's actually about, much less talk about what it thinks it's about?

No, of course not.

But if there's one image from BioShock Infinite that I'm going to remember, it's this:

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.

Amnesia, Among the Sleep, and horror economics.

I used to have a low opinion of the many busywork-type interactions that fill survival horror games. To me, it seemed like these games were about managing this totally artificial-feeling, designed-to-death resource scarcity ("I need more red herbs! I need more lantern oil! I need 9mm ammo!") and scavenging your environment for supplies. How can you optimize your ammo usage for the future when you don't know where you'll be or what you'll be up against?

Maybe these horror games work sometimes because, really, they're about the experience of being poor. They're about paralyzing uncertainty and the inability to plan, but still surviving. It's about how math can tire you out.

No Show Conference is an intimate game dev / game crit conference at MIT. And they want talk proposals.

Last year, last No Show Conference, I had a pretty good time. I met many MIT games academics, East Coast indies, Canadian indies, and interactive fiction authors. It's kind of a strange crowd but I think it works, and the lack of bullshit really helps everyone talk to each other as people instead of networking opportunities. For this year, No Show's back -- and they've even lowered the price to make it more affordable -- which is pretty much unheard of, among the game conference circuit, and to me it shows that they don't just talk the talk but they actually go and do what they argue for.

Much like last year, they offer a $500 travel / hotel stipend for speakers.

So go and submit a talk! You have until June 7th. It's a conference and community worth supporting.

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)?

Cubemapped Environment Probes: Source Engine-style cubemap implementation in Unity 4 Pro

I wanted a static baked-in solution for doing cubemap-based reflections in Unity. Using cubemaps instead of (or with) traditional Blinn-Phong specular is great for games if (a) the light sources / environments stay static, and if (b) the player's camera will frequently be close enough to see small surface details. If that sounds like your game, maybe baked cubemaps are the way to go for you.

Thoughts on VR aesthetics

The current working standard for first person games is Valve's VR implementation in Team Fortress 2: the player uses the mouse to move an on-screen reticule, and if the reticule leaves the middle "dead space" screen area then it rotates the player's torso. Head tracking does not change where you're aiming -- and outside of giving you peripheral vision, it is somewhat meaningless within the context of the game.

Is that the best VR implementation we can do? To render it meaningless?

Right now, the Oculus Rift exists mainly in this realm of performance art -- where most of the interesting stuff happens when watching other people use the Rift, and imagining what they see and what their experiences are. The vast majority of videos out there focus on the player instead of the game ("This is the future of gaming. It looks like a dog trying to escape from under a duvet."), and the best Rift games focus on the intersection between virtual and non-virtual, like players who physically kneel on the ground to play the guillotine sim Disunion. I think much of this dynamic is informed by the growing dominance of Let's Play (LP) culture... which is to say that the "best players" are now the ones who can "perform" the game in the most compelling way and reveal new aspects of the game that we didn't realize before, and that way's context usually exists outside of getting high scores / headshots. What it means to be "good at a game" is slowly shifting from sport to sport as theater.

Virtual head animation has never been more human and true. We are all now cinematographers who can directly share our fields of vision in extremely subtle ways; the act of looking is now the most expressive input in video games today. And right now, the "best VR standard" is rendering it meaningless?

Don't forget that the Rift isn't just a display -- it is also a controller. Let's do stuff with it.

Post-partum: teaching Unity.

Here's a bit of reflection on my first semester teaching Unity at an art and design school, mixed undergrad / grad level. They're in the form of rough guidelines that I'm giving myself for next semester:

» Don't assume mastery of coding fundamentals. Some students will be able to formulate and solve abstract problems with little help, while other students will need to be taught the difference in syntax between variables and functions, repeatedly. Course prerequisites, even if enforced by your school's registar (at Parsons, they usually aren't), are no guarantee of mastery. In my class, I put a code comprehension section on the midterm exam, only to realize that some students didn't understand nested for() loops, which implies they don't fully grasp how unnested for() loops work either; but it was the midterm, and it was already too late. Some students didn't know how to use AND or OR, and some didn't understand scoping. I should've caught these problems earlier instead of unintentionally punishing them for it.
Recommendation: On the first or second week, conduct a diagnostic quiz that asks code comprehension questions, and assess which students need which kinds of help.

» Cover vector math, every day. Do light drilling. Even students with significant code experience may have trouble conceptualizing how vectors work together / what vector operations do, especially in 3D. I don't think I'd necessarily impose grade school drilling, like worksheets with 50 problems and 1 minute to solve all of them, but a few minutes or short drill, every day or week will help a lot.
Recommendation: At the start and end of each class, do some vector math problems together as a class. Practice thinking about vectors in multiple modes: visually as spatial coordinates, abstractly as sets of numbers, and procedurally as variables in code.

» Teach Maya and Unity, side by side, in parallel. I front-loaded the syllabus with Unity stuff, and only started Maya in the second half of the course. I think this was a mistake because we ended up having a 2 week break where students did very little code and focused on Maya, and it seemed to be like we were moving "backwards." I should've paced the class better to prevent this dead time.
Recommendation: When teaching the basics of 3D transformations in Unity, also teach the basics of 3D transformations in Maya, and emphasize the many similarities in interface and project organization: scene hierarchies, hotkeys, lights, materials handling, etc.

» Don't teach coroutines. I tried to teach this early in the course, and it ended up confusing a lot of people. Personally, I use coroutines constantly because I find them really useful for timing things... but maybe I shouldn't have projected my own practices on them.
Recommendation: Teach the use of timer variables and bookkeeping variables / using Time.time instead. It is worse practice sometimes, but it is a more immediately intuitive way of timing things, and reinforces fundamentals of controlling logic flow.

» End with procedural mesh generation / mutation? I really want this to be an "a-ha" moment of the course -- when students realize that everything is just a different way of storing data, and artists are just people who can figure out how to get the data looking and performing the way they want. Considering the emphasis on 3D, I think this is a much more coherent endpoint than my previous emphasis on AI and behavior.
Recommendation: If students have been working in Maya for a while and they understand for() loops, they might be ready to iterate through arrays of mesh data. Maybe look at implementing some Perlin noise or a simple sculpting tool.

This summer, I'm going to try to put these ideas into practice when teaching 6 week Unity intensives at NYU Game Center. Feel free to check-up on us on the class GitHubs (session 1) / (session 2).