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.

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!

Some Unity 5 beta impressions

I'm making a small Thief-like with integrated level editor (3rd time's the charm!) to test (and teach myself) four (4) main feature-sets of the Unity 5 beta -- physically-based shading, integrated image-based lighting, real-time global illumination, and the UI system introduced late in Unity 4.6 but might as well have shipped in Unity 5. Here's my opinion so far:

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

Reading public Google Drive spreadsheets in Unity, without authentication

I'm working on a project with a collaborator who doesn't use Unity and doesn't really have an interest in game development (gasp) but it is still important that she can add/edit item data for the game. From a practical workflow perspective, I probably would've kept the item data separate from the game code anyway, to make it easier to balance and tweak stuff. This is usually the stage at which you'd make your own level editor or game database editor or something, but maybe there's a better way -- we can just tell Unity to read from a public Google Docs spreadsheet and parse the data. That way, anyone can edit the game levels or localization strings or whatever from anywhere in the world, and the game client will update data seamlessly.

A lot of this post comes from Clark Kromenaker's great post on accessing Google Docs services with C#, and a lot of my setup process is the same as his.

However, my particular project didn't need any data kept private, the game itself didn't need write access to the documents, and authentication looked like a pain (e.g. using OAuth 2.0 requires you to open a browser window so the user can okay the permissions? Yeah, no thanks) so I worked out how to access read-only publicly published Google Drive spreadsheets without any logins or anything.

The Game Studies of Game Development

This is an excerpt from "Queering Game Development", a talk I'm giving at QGCon (October 26-27) at UC Berkeley. Registration is free and open to the public.

You could see "games", as a complex field of theory and practice, as roughly the sum of three sub-fields: Game Studies, Game Design, and Game Development.

Teaching struggle.

The other day, I sat down with a student in my Unity class to review some course material and answer some questions. They were wondering why their code wasn't compiling. Their code looked something like this:

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.

Game development as drawing; gesture, iteration, and practice.

(NOTE: There are sketches of nude human figures in this post, with their anatomy intact.)

If you ask any great AAA game artist about the single-most important thing you can do to get better at art, they'll probably start mumbling about "foundation." Photoshop, Maya -- these are just newfangled versions of pencils or paintbrushes or clay. They won't really teach you how to paint, or how to sculpt, or how to look at things and represent them. In this way, a bit of traditional, non-digital fine arts education can be an extremely useful tool sometimes.

In the pretty casual 12 week, 2 hours a week drawing class I took, the teacher presented two ways of thinking about drawing:

The joys of sub-projecting in Unity

Let's say you have a personal Unity framework full of useful models, prefabs, shaders, scripts, etc. that you'd like to use across several projects. How do you best deploy that framework?

If you use version control, then maybe in each Unity project folder you'd also have a special folder hooked up to an SVN or a Git submodule. (Though I find Git submodules to be scary and unwieldy and more trouble than they're worth.) If you don't use version control, maybe you'll keep a separate Unity project just for your framework and from that you'll export a new Unity package every now and then, then separately import and update the Unity packages across your different projects as needed.

There's a third way that I'm trying, inspired slightly by how the Source Engine's filesystem works: basically, you keep all your projects *inside* a main Unity project, so they exist more as "mods" or "sub-projects", and they interface with each other as well as a main framework folder that has core prefabs and scripts.