Thursday, February 28, 2013

Castle of the Red Prince, by CEJ Pacian

CEJ Pacian is probably the best short-form IF writer today. His (?) writing is usually firmly grounded in a genre -- Gun Mute in Mad Max / apocalyptic Western, Snowblind Aces in pulp adventure -- and Castle of the Red Prince is firmly rooted in magical fantasy.

The best part of his work, though, is that these genres and settings aren't really the point. In Gun Mute, Walker and Silhouette, as well as this newest entry, Pacian is clearly more interested in formal experimentation on a small but vital scale, and the genre is just a shortcut to approach narrative effect faster. What if navigation doesn't involve cardinal directions? What if everything is a metaphor? Above all, Pacian is interested in re-configuring how we perceive and navigate through space, in a way that only interactive fiction can afford.

Castle of the Red Prince's experiment, then, might follow these rationales:

Wednesday, February 27, 2013

This one's for the hometown fans.

An image materialized in my head, and I was forced to try to realize it. We'll see how it goes...

Thursday, February 21, 2013

PlayThings, a toys and play symposium, 23-24 Feb 2013 at Parsons

PlayThings is a symposium about structures of play, and the ways in which design can enable or resist those structures. What does it mean to play? How meaningful is the distinction between toy and game? etc.

6 East 16th St, 12th flr
in NYC (near Union Square)
February 23rd - 24th
11 am - 5pm

Day 1:
a panel discussion around the ideas of play led by:
McKenzie Wark (Lang)
Colleen Macklin (PETLab)
Zach Gage (stfj.net)
Cas Holman (RISD)
moderated by John Sharp
+
a 3hr play session with various kinds of toys and games i.e. historical toys, mechanical toys, building blocks, plushies/puppets/dolls, board games, video games and physical games to introduce participants with the variety of things and activities that constitute as play.
(led by Kyle Li and Nick Fortugno)

Day 2:
Day 2 consists of a day-long workshop and play-jam session where participants come up with their own games, toys or other forms of public play and the creations are later reviewed by the panel and other participants.
(5 hr making + 1 hr judging/playtesting)
(basic toy building materials provided)

Wednesday, February 20, 2013

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:

Wednesday, February 13, 2013

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.

Friday, February 8, 2013

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.

Wednesday, February 6, 2013

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:

Saturday, February 2, 2013

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: