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:

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.

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.

Radiator Book Club: the Game Design Bibles

Several independent parties have asked me for book recommendations and stuff, so now I'm starting a series of posts about books to read, and some notes on how to possibly approach them.

THE GAME DESIGN BIBLES
These are core books that establish terminology and basic theory about games and development. If you've played games for a long time, much of this material will seem obvious / simple / not worth saying... but that's only because games are in your blood. A lot of it isn't obvious to everyone. So, it's important to maintain a "greedy" attitude in reading -- pick and choose what you like from these texts, and don't feel obligated to like (or read) the entire book.

Rules of Play (Katie Salen, Eric Zimmerman)
I'm pretty sure Rules of Play is taught in, like, every university-level game design class in the world. It's extremely comprehensive in approaching game design as science and culture -- it's pretty much a primer on everything. The problem I'm seeing, though, is in the people who've rarely played games but want to make games as a career: they read this book and think this theory IS games, rather than a tool that sometimes helps you think about games. (see: "the map is not the territory") These "textbook developers" have a strange way of doing things, often wondering aloud how best to satisfy The Five Different Types of Players or how to Teach the Core Mechanic, instead of, uh, talking like a human being. I think game design is really lucky in that the veterans / masters of this field will usually preach against simple fundamentalism like that... well, usually.

Radiator 1-2 Handle with Care, Sourcemod gameinfo.txt fix for Steampipe VPK file format shift

In the last few weeks, Valve has dropped the GCF file format. A "GCF" was like a ZIP file containing thousands of game files. They were usually quite large (several GB was common) and so they were prone to file fragmentation, which balloons loading times as games need to load more files and assets. With Left 4 Dead, Valve started shifting their filesystem infrastructure to a "VPK" format -- instead of being stuffed into one or two colossal files, game assets are distributed among many more smaller .VPK files, improving loading times. Valve has now converted all their older games to use the new VPK file format too.

It's great, but it has also broken most Source mods made before 2013. Fortunately, the fix is pretty trivial: it involves editing the "gameinfo.txt" to mount the file assets in a different way / order than before.

If you want to play Radiator (or any single player mod based on Episode Two), just follow these instructions:

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.

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

Notes on first person virtual reality / implementation in Unity.

I've been implementing the Oculus Rift VR goggles into my first person projects, and the process has been... interesting.

Valve's excellent introduction to working with virtual reality (per their experiences in porting Team Fortress 2) is the definitive primer to working with VR in a first person context, and more or less the state of the art. However, it also ends with a powerful notion: we're only just beginning with VR, and it's going to take time before we know what we're doing. Here's a very brief summary of general design guidelines, as defined by Valve:

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.

GDC tips

It's GDC season again... Daphny has a lot of helpful advice on having a good time at GDC, so make sure you read that. Here's some bits of my own:

• My write-up / thoughts / post-mortem of GDC 2012.
• Don't over-extend / over-promise / flake on people, don't promise to meetup somewhere but then realize that you're actually somewhere else, etc. I did this to people last GDC and felt pretty bad about it. GDC, in particular, is really exciting because there's so much going on, so it's tempting to try to do everything at once... don't do it. Pace yourself.
• That said: here's the official unofficial GDC 2013 party list curated by Brandon Boyer.
• If you must be network-y, then don't be network-y with people who aren't network-y. Use your personal judgment as to whether the person you're talking to (especially an indie or academic) will care about the business card ritual or if they're like Daphny, who uses the business card to mean, "please go away."
• Typical flow / activity of the week goes like this:
  

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:

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:

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

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...

How to Make Games with Twine

Public service announcement: Anna Anthropy has written a great short tutorial on making games using Twine -- it's perfect for people with little or no game development experience at all, and will allow you to make cool text-based games with choices and stuff.

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: