Game narrative as improvisational theater / negotiation.

The current narrative systems prototype Shakespeare has been somewhat disappointing so far: the director switches, seemingly erratically, between 5-6 different plot threads, and nothing seems coherent. I need a way of (a) allowing the player to influence story pacing / scope, and (b) a way for the system to push back, to try to force some story pacing / scope.

For this, I'm looking at how improvisational comedy generates and upholds structure. You might've heard that improv is about "always saying yes," but there's a lot more to it, apparently.

Specifically, longform improv comedy involves actors cooperating to "find the game" -- to find the core of a joke. Each actor makes "offers" to expand upon a premise and move action forward, hopefully toward a funny destination, and usually, actors err on always accepting offers ("saying yes") and building upon it since "blocking" offers frustrates your scene partners. However, it's very possible to "say yes" to a premise while still "blocking" the "game."

Here's an explanation from an NYC improv comedy personality, Will Hines:

Approaches to game development education.

I'm currently teaching a Unity class at Parsons called "Building Worlds" -- and I'm treating it as my opportunity to get everything right and Solve All Problems in Game Dev Education... Obviously, the reality of the class is much more complicated, and ambitious teaching philosophies never really survive a semester intact.

But before I become bitter and jaded, here are the main principles / pillars I'm starting with:

0) Game development is not game design. The former concerns process, implementation, and engineering, the latter is the art of theoretically abstracting behaviors and relationships into something compelling.

1) Breadth. Everyone should know a bit of every aspect of game development, a "liberal arts" education in all facets of development, and everyone should be able to make a game entirely by themselves. All developers should have basic drawing / modeling skills, basic coding skills, and basic design skills. Of course, everyone has their specialties and interests, but the goal of game development education should be to produce independent, T-shaped developers who can see the big picture and collaborate when they need to. Don't specialize too early.

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.