Picaro

Previous attempts at the build interface were mostly just...

irondavy — Mon, 30 Jan 2012 09:08:39 -0500

Previous attempts at the build interface were mostly just conceptual explorations. Now that we’re very close to having a complete spec for V1 of the game language, I had to start thinking seriously about this experience.

I started with the basics: how to create, connect, and populate rooms. Clicking on a blank space (the darker squares) creates a new room. This is represented here by the box in the top right, with a plus sign (that being the hover state). Drag new items & characters out of the black palette bar (top left) to add them to a room.

The checkerboard layout has no semantic meaning, it’s there to keep the interactions constrained, as well as to let writers organize their rooms. How the game handles > 25 objects remains to be seen, I have sketches but nothing has quite clicked.

You might recognize snippets here from 37Signals apps, Google Maps, and Photoshop. My general attitude towards interface design is to use established patterns unless you have a very good reason not to¹, especially in your early versions. In our case, we want to get out of the writer’s way and let them focus on making the thing. Familiar patterns are the fastest way to get there. It also tends to make development cheaper, and we like things pretty scrappy.

I’ve felt out of my element throughout this project — designing the play interface without any background in game UI, for example — but this, specifically an authoring tool, is a challenge I’m comfortable with. Next step: how you actually change the properties of these objects.

One good reason: if your product is primarily differentiated by its UX. ↩

Initial tests confirm that Picaro on VMU would be completely...

irondavy — Fri, 27 Jan 2012 14:30:15 -0500

Initial tests confirm that Picaro on VMU would be completely miserable and unplayable. Unfortunately, we already signed deals with Sega and Picaro will only be available on this platform. Here’s to our continued failure.

Meet the Team

irondavy — Wed, 25 Jan 2012 12:34:43 -0500

I’d like to quickly introduce our impossibly handsome team. Everyone pitches in ideas for features and product decisions, but we are finding our little pockets:

Casey Kolderup

Casey is an engineer over at Gilt, which means he’s used to working in a solid gold development environment. I tricked him with promises of planet-sized diamonds and now it’s too late: he’s working on the backend that will power Picaro’s game creation and management tool.

Joe Bernardi

Joe is a front-end engineer and writer that I’ve worked with many times on Sleepover projects. As both a writer and a coder, he’s helping shape the language the games themselves are built in, and how that language interacts with the player interface.

Rob Dubbin

Rob is a writer on some show that nobody watches or votes for in presidential primaries. He’s writing our first games, and helping us discover new needs and possibilities for the game language. He’s also experimenting with Python scripts that generate games procedurally, which was a massive possibility that we hadn’t even considered until recently.

David Cole

I am an interactive product designer, currently on paternity leave and between jobs. I started working on Picaro as a kind of thought experiment, and I remain the creative lead: scoping releases, designing art and interfaces, and writing HTML & CSS.

We plan to keep growing Picaro, so if you’re interested in pitching in or just offering ideas, please get in touch.

A Home for the Small

irondavy — Mon, 23 Jan 2012 11:58:22 -0500

Picaro fuses a lot of the ideas I’ve had over the past few years (at one point it was much closer to Jason Rohrer’s Sleep is Death), but it’s current incarnation came from ruminating on short games.

Most other types of media have short forms, but even the shortest gaming experiences tend to be measured in hours. You could argue that high score games (like a Pac-Man or a Canabalt) are short, but in most cases the author expects you to play many sessions of those games.

Robert Greenberg, in his great introduction to the music of the High Baroque, characterizes Bach’s singular genius as knowing how much time each of his ideas deserve. Small ideas are given a few seconds at most, while large ideas will stretch out. By ignoring small ideas in games, we ignore a significant category of meaning. One only needs to look at poetry or photography to see how much can be packed into a brief experience.

Why aren’t we making and playing more short games? I believe there are a number of important factors.

On the player end, games often require you to sit down in front of a console, power it up, dig out the disc, slog through menus and loading screens, watch an opening sequence — you’re already an hour deep by that point and you haven’t even hit the meat of the thing. We’ve designed Picaro so that you can start a game as soon as you click a link, on any device.

There’s also the problem of a common language. Most games have to spend considerable time (hours, often) teaching you the controls and mechanics. We do have shortcuts for this: if you play one first person shooter, you’ll have a big leg up on the next one you play. Even then, each shooter treats these patterns in a unique way (that’s what makes them interesting). The genres that have developed a common language are the ones we’re drawing from: interactive fiction and point & click adventures. By flattening out the learning curve, players can just dive right in.

For the author, making a game is a substantial investment, especially if you can’t code, draw, compose, model… We’re hoping we can focus on one component, writing, and deliver the best experience for games expressed in that format. We’re not there yet, but eventually you will be able to make Picaro games without touching a bit of code¹, and the language is being designed with that in mind. Our scaffolding will lower the resources required to make a game, which means that a game doesn’t have to be large and complex to be worth the author’s time.

Picaro is a very limited platform, especially this early version, but we think this kind of focus actually opens up a lot of new doors, both contextually and creatively. In our brief time with the format, we’ve surprised even ourselves with its potential. Specifically how that’s true is something we’ll be talking about in the near future.

You will be able to edit the code, though, and we expect that the language itself will outpace the GUI in complexity — and that’s just fine. We think we can make these coexist without dampening the experience. ↩

Say Hello to Picaro

irondavy — Mon, 23 Jan 2012 09:38:52 -0500

I’m really excited to tell you about our new project: Picaro.

Picaro is a way to make and play small adventure games. They play a bit like interactive fiction with the control scheme of an old Sierra/LucasArts adventure game. If that was gibberish: the games are completely text-driven, but require no text input. You don’t type “use the key on the door”, you tap “Use”, “Key”, “Door”, then you’re told in a few sentences what happened.

In a way, this is the worst of both worlds: the restrictive agency of mouse input and the limited expression of text output. But this is precisely why it’s exciting: clicks in, text out is the cheapest, simplest format for a narrative game.

It’s so simple that games can be designed in a GUI, without touching a bit of code. This is one of the big aspects that gets me excited, and indeed the first bits I designed were concept pieces of a potential builder GUI.

We’re looking for more writers who are interested in helping us test the format and find the mistakes we’ve made and edges we’ve yet to discover. If this describes you, and you’re up for clawing through JSON, send us a note.

"Mainstream games ask for and receive a very high level of time commitment, which can be very..."

irondavy — Mon, 23 Jan 2012 03:06:28 -0500

“Mainstream games ask for and receive a very high level of time commitment, which can be very enjoyable but disappointing to me when I put down a game after several hours of play and realize that I have nothing important to think about about other than motions my avatar was performing and perhaps what I was killing. On the other hand, art typically has to be rapidly consumable, typically in just a few minutes or even seconds. My favorite art fits into that short amount of time so much story or concept that it gives me enough interesting things to think about and digest that it takes longer to do so than it took to experience the piece.”

- Wes “Window Cleaner” Wilson in an interview on gamescenes (via notgames)

Creating a context for short games is actually part of the vision for Picaro, something I plan to discuss more in the future. I don’t believe long, repetitive games are inherently flawed, even if they’re mostly about killing (see Far Cry 2 for a cerebral example of a faceshoot game) but I do think shortness can be a virtue.

Just your standard teaser post featuring a cryptic series of...

robdubbin — Mon, 23 Jan 2012 01:14:52 -0500

Just your standard teaser post featuring a cryptic series of numbers.

irondavy: I suspect this will reveal a lot about the project...

irondavy — Sun, 22 Jan 2012 21:57:28 -0500

irondavy:

I suspect this will reveal a lot about the project that I’m working on with Casey, Joe, and Rob. I previously linked to an early shot of the build interface, and here are some shots of the play interface, the other end of it. It won’t be a native app, but we are thinking of this as a mobile-first experience.

irondavy: Remember this? It lives! More soon!

irondavy — Sun, 22 Jan 2012 21:57:21 -0500

irondavy:

Remember this? It lives! More soon!

irondavy: Brain is churnin’ tonight.

irondavy — Sun, 22 Jan 2012 21:55:26 -0500

irondavy:

Brain is churnin’ tonight.