Noserudake 2 and the language of development

Noserudake 2 is a fantastic Unity browser game where you balance things on a platform. It is also the sequel to Noserudake 1, and the Japanese developer's changes between installments are telling.

They gave the player direct control over rotating the dais, they enabled real-time shadows and textured the dais to give more depth cues, and the physics objects have been well-tuned to be more forgiving and have more weight and heft. Also, the slapstick shift between level 4 and level 5 is pretty brilliant, a joke through level design that transcends language barriers. But one of the most glaring new changes in Noserudake 2 is that the developer has added English translations alongside all the in-game Japanese text. The developer is clearly conscious that they also have a Western anglophone audience following their work. But why are they accommodating us?

"Get Better Soon" dev diary #3, skin and light iterations

This is a development diary series for "Get Better Soon", a commissioned game I'm making for Different Games 2014. If you want to see it and play it, then come hangout at Different Games next weekend in NYC!

Kris Hammes is finishing up the character. The 3D model geometry is basically "done" so now I'm just waiting for the last texture tweaks like chest hair. In the meantime, I've rigged the model with a standard "HumanIK" skeleton in Maya (so that I can easily re-target animations in Mecanim) and I've configured the shader so I can start figuring out how to implement these characters into the game.

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:

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.

"Well-Made: Back to Black Mesa" @ PRACTICE 2013

Very special thanks for Frank Lantz for inviting me to speak, and to Charles Pratt / Kevin Cancienne for counsel and emotional support, and Brendan Keogh / Dan Golding for convincing me that people even want to hear about stuff like this. Many of the ideas in this presentation will be expanded upon for the book I'm doing with Press Select.

First I want to set the record straight: I love Half-Life, but that doesn't mean it's immune to criticism. It is flawed in many ways. (Hard mode is too hard. The game is too long. On a Rail induces hemorrhaging. etc.)

I also think games mean things so far as you can argue for certain interpretations -- and I think Half-Life's popular legacy does not endure much scrutiny. Specifically, Half-Life's narrative is not subtle nor sophisticated nor conceptually innovative: from what we know about its development history and acknowledged inspirations, it is designed to be a schlocky silly action B-movie about a sci-fi disaster conspiracy, and I argue that reading is more convincing than thinking it's "the Myst of video games" or something.

That does not mean a schlocky game is bad; schlocky games are often fantastic. What I'm arguing, instead, is that many players prefer the weaker reading of Half-Life because they are seduced by the promise of technology without actually understanding what the technology is doing. Half-Life is magical and interesting and subtle, but not in the way that gamer culture mythologizes it. (At the same time, let's still be critical of what Half-Life does, and the values it represents to both players and developers.)

Hacking blend transition masks into the Unity terrain shader.

It is a truth, universally acknowledged, that grass rarely fades linearly into dirt. Grass is often quite clumpy. I wasn't satisfied with the non-clumpiness of my grass in a certain project, so I hacked Unity's terrain shader to add some blend mask support. You could probably use this technique for cobblestones, bricks, debris, gold coins... whatever you want to remain clumpy when overlaid on top of another texture.

First, let's think a bit about how Unity's terrain system renders the textures you paint on it:

How a "Last of Us" art dump thread teaches "vision."

At Polycount, Rogelio Olguin posted an art dump of some environments from The Last of Us, as well as some notes on his environment construction process. All of his posts are worth reading, but I'm going to copy the part that really stuck out to me:

"One thing I hold true is that one texture will not make things look awesome. Imo well balanced shaders will. I think we are starting to move away from this one texture looks sick. Like the below textures are kind of boring alone but together it looks sweet. I really do not think anything we did in ND is "special" it just well balanced from good forms and composition (Modeling) to materials treatments (texturing)"

This shift in AAA art workflows, from focusing on individual art assets to thinking more holistically about how shaders, lighting, and art direction work together -- I think most AAA-affiliated 3D game artists agree with that in concept, but a cursory look around the Polycount forums shows that many of them still focus on honing one perfect asset for one screenshot.

Part of the problem is a games industry that demands certain types of presentation, style, and specialization in portfolios. ("To work here, you must have one normal-mapped sci-fi crate prop, with perfect topology and no wasted UV space.") But I think most of this problem stems from a lack of vision.

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.

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.

Unity to Android (Nexus 7) with Windows, notes / workflow troubleshooting

Some misc. "quirks" I encountered in setting up a build pipeline from Unity (on Windows) to Android on a Nexus 7... some is mentioned on Unity's Android quickstart docs, some required additional research. Anyway, if you're having problems, here's a pile of different things to try:

A smoother triplanar shader for Unity.

To review: procedural UVs are amazing and you should consider using them in your games. Now, the old triplanar shader I posted was great at hard-edged cubes, but it didn't handle the transitions between textures very gracefully; curved surface like cylinders and spheres were forbidden.

So I took a look at how James "@farfarer" O'Hare handled the blending in his triplanar terrain shader, and how Tom "@quickfingerz" Jackson grabbed normals in his own triplanar shader (but the blending in his shader would "blow-out" a lot, I found) and I combined their respective strengths. I also added different handling for top vs. bottom textures, since grass rarely grows on ceilings. (Textures in the shot above are from Farfarer's pack.) One last change: I let Unity's built-in surface struct calculate world normals instead of calculating my own.

So far, I've been unable to get normal maps working with it, so if any enterprising blog readers would like to instruct me how to do it, and share that technique, then I'd be much obliged.

Here's my shader so far. Do what you will with it:

More talk, more rock: on algorithmic game narratives, speculative narrative design futures, and "Shakespeare."

Last time, I wrote about procedural narrative in the context of "process intensity." Here, I expand more on designing the procedural / process part.

Back in an expertly-conducted 2011 Rock Paper Shotgun interview, Dan Pinchbeck argued that game development culture unnecessarily separates narrative from the rest of a video game:

"I just want story to be talked about as a gameplay element that sometimes isn’t there. It’s part of the set of tools that a game designer uses to create an experience – and it should be thought of along the same lines, as physics or AI or something more mechanical."

We have physics engines or texture libraries, so why don't we think of narrative as a modular "asset" or "engine" or "library" to be swapped around as well? Why can't narrative be more "mechanical." Where's all the narrative middleware? (Storybricks doesn't seem to be doing too well, unfortunately. I also don't agree with them, that proc narrative is mainly an AI problem...)

The unportalable: games as paratexts and products

Several years ago, I sat-in on a "games as literature" course, and promptly got into an argument with the instructor. We were talking about Portal, and he argued the dark metal unportalable surfaces seem "sinister" because of their color, rustiness, sense of alien materiality and permanence, lack of affordance, etc. (This was also an introductory course, so a lot of his effort went towards getting students to make critical arguments about games at all.)

I argued that interpretation was irrelevant, and that type of thinking was obfuscating how these surfaces actually function to players: in Portal you don't think to yourself, "that wall is scary," but you more often think "I can't portal there, let's look somewhere else" or "wow that wall looks cool on these graphics settings." To me, the wall material told more of a paratextual story rather than a diegetic story.

Using screen-buffer masks in Unity Pro for a fog of war effect.

As I prototyped Convo, it became clear that I would need some sort of fog of war / sight radius visualization. Depth masks weren't very good for this because of the uneven terrain, and the other fog of war solutions I found involved a tile system (nah), or a vertex alpha plane (eww), or some other pretty convoluted thing. Lame. So I did a bunch of research and figured out my own technique... best of all, this visualization uses no script code at all, it's just shaders and geometry.

Also, you don't have to use this for fog of war. You can use it anytime you need to mask-off certain bits of the camera view on a per-object, per-triangle, or per-pixel basis. Like, maybe you'd want some stuff to glow red?...

The gist: (you will need Unity Pro since this uses render textures)
1) A camera's render texture is in RGBA format. You can technically do whatever you want with the alpha channel; most of Unity's built-in shaders use it to mask out alpha textures for various image effects.
2) If we use a shader that writes only to that alpha, we can use it to mask objects or pixels.
3) Then, we edit the image effect shader to modulate an effect with the alpha channel values.

If you need some more details and shader code, read on...

"Loving the Bones" in Game Developer magazine, October 2012

I adapted my blog post into a short article for the October 2012 issue of Game Developer magazine, promoting the art of the humble texture flat as its own art-form and mode of appreciation. The three masterpieces discussed are: Rob Laro's tankbuster sheet, Thomas Varoux's palace lightmap, and Anna Anthropy's miner spritesheet. Together, I thought they represented a good cross-section of non-photorealistic / desktop / mobile / 3D / 2D / environment / character art going on today. Pick up an issue of GD mag at the game convention nearest you, or squint at this low-res but somewhat legible clipping to the left.

The flat as art; the aesthetics of UV maps.

So the celebration of visual arts in video games like "Into the Pixel" is cool in one sense, but a little dishonest in another -- concept art is not video game art -- that is, it's not the art asset that goes into the game. Rather, I'd argue that the more authentic video game art is the sprite sheet, the texture atlas, the lightmap, the UV map. It's all about the flats. Understanding them requires understanding games on some level. ("UV means ultraviolet, right?")

I propose three aesthetics / three approaches to appreciating the flat:

How to dig holes in Unity3D terrains.

UPDATE FOR 2019: This post is 7+ years old, and new versions of Unity have updated the Terrain system. In principle, this technique should still work -- but the specific code and variable names are probably broken. I have no plans to update this post. Good luck.

Say you're making a Unity game that takes place in a large landscape dotted with windmills, and some of these windmills have tunnels that lead underground. But in Unity, the terrain collider is generated from heightmap data: it's essentially one giant bumpy plane. You can't punch holes in it.

Can we hack it to achieve the same result? Yep. Here's one way, there are two parts to it:

1) Hiding a piece of terrain geometry with a "depth mask" shader.
2) Disabling the collider so the player (or whatever) can pass through the hole, but collides with terrain other times.

If you need more detail, here's my specific implementation:

Rule Databases for Contextual Narrative... and spelling bees.

Valve's Elan Ruskin gave a fantastic talk at GDC 2012 on using "Rule Databases for Contextual Dialog and Game Logic" -- basically, the implementation behind the dialogue response system in Source games, most recently used in Left 4 Dead 2 and DOTA 2. I'm surprised more people haven't picked up on it because I think it presents some really effective research on procedural narrative systems.

A lot of game logic / narrative resembles a flowchart, especially with the advent of visual scripting systems like Unreal's Kismet or Twine -- resulting in this deeply entrenched concept of branching structure. Authoring and changing these individual branches is usually very expensive.

On landscape porn.

We couldn't do large, open, video game environments before. Now we can. However, this kind of power is limiting in its own way; you just see the same concepts of grand sweeping vistas, over and over. It's very beautiful and expertly crafted, but it also resembles the same stagnation of a mud-brown rusty metal corridor decorated with skulls -- a certain lack of imagination.

Conceptually, this is Thomas Kinkade, repeating, instantiating, stretching endlessly past our view frustums to infinity. It's always the same sunlit painterly natural realism with some normal-mapped ruins in the foreground.

France Diaries: sketches + a 3 sentence review of "Game Feel"

I'm in France right now. This is part of a series of game architecture diaries about France.

If anyone thinks I'm qualified to offer advice to beginning level designers, then here's that advice: draw, even if you're awful at it.