Not a manifesto; on game development as cultural work

So I've made quite a few sex games that have "gone viral" over the past year, and I'd like to talk a little bit about my experiences / practices. I would hesitate to apply these ideas to anyone else's situation, but it's what works for me, so here it goes:

Games are primarily conceptual / performance art; games are culture; it's more important to witness a game than to play it.

Most people haven't played most games. Conversations about games often start with "oh yeah I've heard about it" or "I haven't played that yet." Thinking about the vast intergalactic politics of EVE Online is so much more interesting than trying to play it, and watching high-level Starcraft play is much more interesting than drilling on a specific build yourself.

To "consume" a game, it is no longer necessary to play it. Rather, the most important thing about a game is that it exists, because that means you can think about it. (Or maybe, games don't even have to exist? Consider the endless press previews and unreleased games that engross so many people. These are purely hypothetical games that are often better than playing the actual finished product.)

Scripting the Unity Editor to automatically build to Windows / OSX / Linux and packaging the files in ZIP files.

I'm getting ready to release my next gay sex game, which means a lot of builds and testing. This game, in particular, has a lot of particular framework and infrastructure that involves copying over specific files directly into the built data folder. I don't want to have to copy over the files manually over and over, so I bit the bullet and decided to write an editor script that automatically does all this stuff for me, for all 3 desktop platforms that I'm targeting. This is really nice because it saves me a lot of time when making builds, and it also makes it more the whole process more foolproof since it prevents me from forgetting any files -- Unity is automated to include them for me!

Here are the main snippets + explanations of those parts of the pipeline, with the full script at the end of this post...

Game Development Studies reading list, Fall 2015

In the vein of "Platform Studies" or "Code Studies", we might consider a "Game Development Studies" ("Console Studies?") -- a field of research investigating the technical and material aspects of video games, from early prototypes to production code to distribution. How have various processes of game development changed over time? How does that influence what games are, or how they are perceived?

Here are six books that, I think, do much of that work:

PSA: free (and COMPLETE) photorealistic 3D character workflow from Mixamo

Mixamo got bought out by Adobe... as part of the merge, they've turned off all their billing systems... which means almost everything they have is now free.

"Fuse" is their (free) character modeling / texturing / creation tool that is miles ahead of the old Autodesk Character Generator -- from there, you send the character mesh out to their Auto-Rigger cloud service (also free) with 60+ bone skeletons and facial blend shape support -- and with every (free) account you register, you get 20 (free) animations, and you can potentially make unlimited free accounts. This is a complete character art solution from mesh to skin weights to rigging to animation, for free. It's pretty impressive, and you can easily make a game that looks like a prestige AAA FPS from late 2013. (These assets don't have the accuracy of photoscanned models or DX11 procedural hair, but they're very well crafted.)

Tentatively, they're going to shutdown this infrastructure on December 31, 2015 (I think, according to a cryptic e-mail I got a few months ago) when they've finalized more of the merge with Adobe, so make sure you grab as much stuff as possible while you can.

To celebrate, look at the brunch hunk I made in Fuse (above) and exported out to Unity. Again, it's pretty high resolution stuff with no restrictions. Make use of it for your games while you can.

I'm documenting this resource as a "PSA" because making the tools of photorealism accessible and widespread helps (a) sabotage game industry machinery that privileges fidelity as something valuable, (b) re-contextualizes realism as a stylistic choice rather than a "default" marketing tactic.

Have fun!

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?

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:

"Succulent" technical overview / behind the scenes

This is a high level discussion of how I achieved certain effects in Succulent using Unity. It spoils the game, so I recommend you play it and/or read my artist's statement.

To the game engine, the popsicle (or "ice lolly" or corn dog) in Succulent is the main director for the entire scene. It is essentially a psychic telekinetic popsicle that dictates music playback, effects, and character animations... The popsicle is god. Love the popsicle.

To many developers, the most obvious straightforward way to achieve this popsicle-sucking interaction would've been to create a hand / arm controller, and then parent the popsicle to the dude's hand. But this "direct" way would've been the wrong way; this game is about popsicles, not about hands. Tuning the hand and arm movements necessary to pilot it into his mouth -- it would've been painful and unnecessary. (This is why it's important to have a fairly solid concept before you start coding something. The concept and design will affect how you code it!)

"Stick Shift" technical tricks / backstage Unity peek

This is a high level discussion of how I achieved certain effects in Stick Shift. It spoils the game, so I recommend you play it and/or read my artist's statement.

The "car" in Stick Shift is actually (a) two different cars, one for each camera, and (b) neither car actually moves, ever.

When you want to create an illusion of motion, or at least have something read as motion, then you generally have two options in games: move the object around the world, or move the world around the object. Because I wanted to focus on the gestures in the drivers seat, it didn't make sense to actually simulate a road. A scrolling panoramic image of a city street, blurred and stretched horizontally, would give enough of an impression of motion.

Implementing real-world real-time stamina / energy cooldown timers in Unity C#

In Hurt Me Plenty, I implemented "real-world" cooldown timers, which persist even if the player restarts the program. The cooldown period elapses in "real world" time, not in game time.

This resembles stamina delays in many popular free-to-play games, but it also connects with the design tradition of using real world system clocks to dictate game logic -- maybe certain Pokemon emerge at real world night, or you witness events that correspond with real world holidays, or perhaps you can even kill a boss NPC by setting your console's system clock forward by a week.

Much like the implementations referenced above, mine is quite weak and vulnerable to circumvention and cheating: I simply save a system timestamp in the game's PlayerPrefs, and then check that saved timestamp upon loading the game. If the difference between the current system time and the saved timestamp is less than zero, then the time has fully elapsed and the game continues.

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.

How to make stuff look at stuff / demystifying turns and rotations, and working with quaternions in Unity C#

Julia set fractal thing of a quaternion function... I actually don't really know what that means, but it's pretty.

This is kind of a blog post more for my Unity students, but I figure other people on the internet might find it useful -- let's demystify working with rotations in Unity, and explore some useful techniques for doing so.

There are 2.75 ways to store rotations in Unity: (1) quaternions and (2) euler angles (directional vectors are the 0.5, and some math functions secretly take radians instead of degrees, that's the 0.25)...

Euler angles are the typical 0-360 degree system taught in most junior high / high school geometry classes, while radians are in "units of pi" and represent the curvature of a circle. Then there's quaternions, which are scary 4 dimensional representations of a rotation that you may have never heard of / can barely spell! Fortunately, you don't need to know quaternion math in order to work with rotations, Unity will handle conversions for you.

Okay, so first let's explore a most common problem: how do you make stuff look at stuff in Unity?

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.

On branching dialog editors and narrative design tools

I was prototyping a game concept with branching dialogs for conversations and/or CYOA story events, so I started looking at various solutions on the Unity Asset Store. Dialoguer looked the most decent, but generally all of them just made too many assumptions or enforced bad workflows, and seemed to ignore what made Twine so accessible.

So I've decided to make "Bramble", my own editor plug-in and system for Unity! Here are some factors in its design:

Notes on working with Source SDK 2013 Singleplayer Base

I've been working with Source SDK 2013 base for the past few months, and I thought I'd share some notes on workflow for any future modders who google to this post:

• If you are making a simple mod that uses default Half-Life 2 features, then you do NOT have to compile your own binaries. You can just tell Steam to use the ones that come pre-compiled by Valve from the already included "sourcetest" mod instead. Steam automatically downloads the correct binaries for the client's platform when they download the Source SDK 2013 Base -- which means you presumably get free and painless Windows / OSX / Linux support, as well as any new changes Valve merges into the codebase... As far as I can tell, most of the basic Half-Life 2 entities work in sourcetest, though env_screeneffect seem to be broken due to some missing shaders.

Introducing: Mural (v0.2) a simple 3D scribbling tool

EDIT: v0.21 adds .OBJ export from the webplayer; you can now actually use this to make models and import it into whatever you want. (If you want to use this in Unity, you will need to apply a material / shader that uses vertex colors and doesn't cull backfaces, so pretty much any of the "Particle" shaders)

There are 2 common modes in 3D polygonal modeling: vertex manipulation and sculpting. But for many of these workflows, a 3D mass exists mostly as a surface to be unwrapped and painted. If all we need is a 3D canvas to paint upon, why can't we just go straight to the painting part?

"Mural" is an experimental freehand 3D modeling tool similar to SketchUp's "Freehand" tool or the impressive Tilt Brush, except SketchUp imagines it more as a tracing aid and Tilt Brush relies on VR hardware and doesn't readily export geometry.

I want to make Mural as an accessible 3D tool that borrows game UI metaphors (specifically, first person mouselook) and directly exports the resulting 3D models for use in games, or anything, really. Many of the models made in Mural will not look like "traditionally" modelled 3D objects, and intentionally embrace glitchy non-representational aesthetics, twisted normals, vertex colors, and z-sorting artifacts. If it hasn't already occurred, I imagine the "politics of 3D" will shift to embrace these phenomena as artistic features rather than aesthetic flaws.

(I am also indebted to Rich Edwards' early research with "3d concepts" using semi-transparent planes.)

CHANGELOG
v0.22

• decoupled canvas movement from painting (thanks for suggestion @Dewb) so you can now move the painting surface WHILE painting

v0.21

• added simple .OBJ export for webplayer; press F12 to save a .OBJ to your computer

v0.20

• fixed stroke shader, colors now render properly
• added a color picker hue / saturation circle, adapted from code in UnityPaint
• replaced line renderers with generated meshes from Vectorosity
• added .OBJ export
• added very basic undo support (press [Z] to delete most recent stroke(s) )

WEBPLAYER (v0.22): http://dl.dropboxusercontent.com/u/19887116/mural_web/mural_web.html

FUTURE DIRECTIONS FOR MURAL: make it into a complete 3D world maker / game maker; add cooperative modelling / network multiplayer session support; better painting tools and interface; add file-writing and OBJ export in webplayer via JS hooks

Porting simple Half-Life 2-based singleplayer mods to Source SDK Base 2013 in 3 steps

If you have a lot of custom code, there are probably some compelling reasons NOT to try to upgrade your existing code to Source 2013 unless you have a lot of free time to hand-merge everything... but if you just have a mod consisting of maps running on Half-Life 2 or the episodes, the relatively easy update to Source SDK Base 2013 gives you better performance (the Steampipe VPK-based loading is much faster than the old GCF system), integrated VR support, and maybe most importantly, it is a freely available "standalone" release to anyone with a Steam account.

The process is basically 2 steps, but I added a 3rd pretty crucial "step" that came up in my own mod...

Someplace Else source files (for Black Mesa Source) + "Majestical" env texture set

A year and a half ago, I was working on a Source re-mastering of Adam Foster's classic "Someplace Else" to plug into Black Mesa Source. The appeal of modding a mod to remake a mod was intoxicating. Unfortunately I haven't really touched Hammer since then though, so I think I'm now forced to admit that I probably won't get around to finishing it.

I am open-sourcing the map file and textures I made for it in hopes that maybe someone more motivated can pick it up. If you're interested in finishing what I started, here are some design notes:

DECK (Doom Engine Creator's Kit) needs artists and sound designers.

JP LeBreton has recently announced the "DECK" (Doom Engine Creator's Kit) project, an open-source public-domain all-in-one bundle of Doom technology: a game engine + editor + game assets + tutorials, all integrated together and easily accessible. It's intended to empower people to easily make cool lo-fi 3D first person games and it sounds really cool...

... but it needs help. It needs some Doom-style character sprites, some Doom-style environment textures / decoration sprites, and a lot of audio design. Pitch in and help build free indie game tools!

Here's my contribution so far, some painterly-ish pseudo-photo "medieval manor" textures:

It was kind of fun to work at low resolution without having to worry about shaders or 3D meshes or UVs or whatever. I recommend it.

GDC 2014 Dance Card

Are you in San Francisco next week? Here's some stuff you could do:

• Critical Proximity, a free mini-conference where game critics mingle and grouse... productively? There's a pretty diverse lineup of speakers here -- non-critics, critical bloggers, academics, developer-critics -- and, uh, Ian Bogost?
• Unwinnable Party, a bunch of games people invade High Tide, a (very) divey bar in the Tenderloin. As far as dive bars go, it's a pretty good dive bar, though.
• Agency Launch, basically an excuse to hangout with people (or play Netrunner?) while sipping somewhat pricey drinks in the "Death Star bar" (you'll understand) overlooking downtown San Francisco.
• The gay game industry group is hosting a night at The Stud bar, which is probably one of the more inclusive gay bars in the city. The first 100 drinks are on them.
• The annual Wild Rumpus party at Public Works, one of the few times when people actually dance. Good game curation too, and within a few blocks of burrito mecca down Mission St. (or hipster mecca on Valencia St.)
• Lost Levels is a free picnic unconference where anyone can give a talk or run a session. Bring a lunch and hangout!
• TIGSource regulars usually invade the local Denny's (on Thursday or Friday night?) for a mini art / work jam. I strongly recommend a "Moons Over My Hammy" sandwich or an Oreo milkshake.

Sophie Houlden teaches you what 3D normals / "normal maps" are... with lots of pictures!

In case you're wondering, I paint the normals myself, that's a thing you can do when you know how they work ;) pic.twitter.com/FAi6EHe9EP
— SLENDER WOMAN (@S0phieH) March 2, 2014

The indie developer Sophie Houlden has posted a great visual explanation of what "normals" are, within a 3D video game art context. Full explanation is after the jump: