On Limits and Demonstrations, and games as conceptual art.

This is a sort-of-review about Limits and Demonstrations, by Jake Elliott and Tamas Kemenczy. It gets just a little spoiler-y, but not in a way that'd seriously compromise your enjoyment.

Most people play chess with pieces and a board, but to many players that's not the actual game -- it's just a mnemonic aid, a thing that keeps track of chesspiece locations so you don't have to remember where your rook is. The people who live and breathe chess, however, can play chess just by reading chess notation in a book, which is to say that the game takes place entirely in their minds. This is more or less what happens when you lose a heated multiplayer match of Starcraft and agonize over what you could've should've didn't do, and wonder what alternate paths you might've taken. Likewise, I'd imagine the most skilled Starcraft players can play Starcraft entirely in their minds.

It's not just in games either: Beethoven was deaf but he could imagine the notes and harmonies so well that it didn't matter, and a Chinese concert pianist was jailed for 6 years but stayed skilled by "practicing in his head."

But I think game designers, designing games directly as a form of conceptual art, is still a relatively new thing.

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:

My Spring 2013 at Parsons

This semester at Parsons, I have two things going on:

1) I'm teaching an undergrad / grad studio elective course.

Currents: Building Worlds was originally pitched as an "introduction to Unity" class, but then the administration said that Parsons never conducts purely "software" classes. They suggested teaching Unity through some sort of theoretical lens -- and the class design is probably much better for it. So now, it's kind of an intro to Unity / C# / working with expressive 3D / architectural theory class, and it argues for "3D" as a unique expressive medium in itself. There's also a strong focus on discussing "behaviors" theoretically, and how to combine simple behaviors to produce some sort of emergence... whether that's what constitutes a "world." I think I'll assign a chapter of 10 PRINT as a reading? (The "Currents" prefix is like a disclaimer -- "This course is an experiment. Take it at your own risk.")

2) I'm also a "consultant" / aide / "technologist" on another course, taught by Colleen Macklin / John Sharp / Heather Chaplin.

Datatoys is a collaborative class between journalists and design students to re-imagine journalism as a toy -- to turn data into interactive systems that demonstrate patterns of behavior. "Let's face it," began the journalism professor, "reading the New York Times is really boring. Print journalism is dying. Now, what is the journalism of the future?" What are the politics inherent in toys and play? How do we reconcile that with the ethics of journalism? If play is independent and unstructured, does that resemble how journalistic objectivity is independent? Can players act as journalists? How and when do toys lie?

The multidisciplinary nature of these two courses is what makes them conceptually strong and compelling, yet also very difficult to realize into actual designed things... But if they were easy, then they probably wouldn't be worth doing.

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

Devlog: "Conanbowl"

(lighting / color test with random NPC mobs)
Me and Eddie decided we should make a game this past / current weekend. It started with our usual process: clicking "random page" in Wikipedia until something strikes us. This time, we were struck by "The God in the Bowl," a Conan the Barbarian short story where Conan has to solve a murder (?) when he's actually there because he wants to rob the museum, but then a ghost kills a bunch of people?

Anyway, this concept resonated with us: an adventure-ish game where you must steal things and solve a case; you're a kleptomaniac detective in Victorian-ish London, and you're assigned to cases where you're actually the thief.

Or something like that.

2/3

At some point, I think I forgot I was making a game. It became more like this expansive simulation of every possible reality, folding into itself; I caught myself wanting to make everything interchangable with everything else, to let every piece talk to another piece and act like yet another. Everything was a network, a graph, and every node was another network. Recursion upon recursion.

There's a tendency in game development to think that you will always be coding "the" framework you can re-use and re-use for everything. Everything should be modular, endlessly recyclable, endlessly useful. It's hard to let that go and accept that you should focus on making a game, first -- a game that works -- and not an engine or a library or something that'll change everything as we know it. I ended up forgetting the most basic lessons of making.

Convo felt too big, and it felt too big by 2/3. I had to cut 2/3. I don't know how I can quantify a fraction like that, but I thought about my ability to build and engineer and develop, within the timeframe I wanted, and decided it was overextended by at least 2/3. I've cut a bunch of stuff, but I'm not sure if the scraps on the floor -- do they add up? Is it enough? How do you know if you've cut too much? Is this what Peter Molyneux feels like?

More details soon...

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.