Vane

Hi all,

I’m Matt, programmer and part-time bizwhizz for Vane.

First off, as Raz says, apologies for the slow pace of devlogs. We’ve been heads-down on the below and others. Second, this one might get long.

Rewind to last fall; Vane’s TGS trailer got a great response, and we all sat down to really get into the guts of what this game was going to be. We came out of those talks with a few realizations:

This is small game but it’s a big small game
We’ll probably need some help (both in staff & in distribution/marketing) to finish the game to the level we want it

There’s a lot of discussion that went into these decisions that’s probably not appropriate for a devlog; maybe as part of a postmortem? In any case we were left with a game that had a larger scope than in our initial demo days in order to build the right kind of world for the player.

So, we basically started building a demo to show to potential partners. In preparing for showing to partners, we focused on a few key points for the demo:

Representative Gameplay We needed to make sure that our core gameplay (which isn’t done) made it into the demo in a representative capacity to communicate what the game is about in a short amount of time. This meant building a concise example of traversal, discovery & solving a puzzle using both the bird & child player states. Without the audience having the benefit of the context from the full game this was tricky, but worked pretty well given the time constraints we had and became a great lesson in how we communicate our design goals.
Character Controls Simple things like flying the bird or running the child around or *redacted* also had to work well and feel good despite being obviously unfinished. We took pains to build in some environmental interactions (again, not done) to illustrate our intention to make the character react to the world in a fluid, convincing way, which went some way toward communicating our goals for this.
Clear Schedule. This is tough for us. We want to iterate and iterate and we want to make the best game we can. At the same time we won’t be working on this game forever, so we have to commit to a schedule. We sat down and built one out (see below). The philosophy behind the schedule is worth its own devlog but basically we’re forcing ourselves to tackle the hardest part of our game, the environmental design, first.

Visuals. In upgrading the project to Unity 5 we’ve revamped a lot of our post effects, as well as incorporating new ones. We also redid haze and lighting. While we’re not using the GI in Unity 5 (the jury is still out on that), this gave the game a considerable visual boost - Vane is cleaner and smoother and looking more hi-def than before. This definitely helped wow people and move the game from its grainier Unity 4 days.

By the time we had something that looked OK, GDC was right around the corner, and GDC happens to be a great place to start conversations with potential partners. We booked tickets and started writing presentations & pitch docs.

Then we showed the game to our wives and girlfriends, and realized we had a lot of work to do to make the game in our heads match the game on the screen, and crunched Wink

An example - we realized that the flight mechanic took time to acclimate to (when taking off the controls go from XZ plane to XY plane) so we built out a canyon to serve as a fun playground to skim through but also teach the player a bit about flying. It also served a dual purpose of leading the player to the main features of the demo.

The “spouse problem” is really a whole post in and of itself, but this reinforced for us the need to have a long iterative period in the schedule, where we aggressively solicit feedback and tune the game. Vane is a game that doesn’t want to communicate anything explicitly to the player, so that means we need to be extra careful in blocking out and testing our environments to guide player in subtle ways where necessary.

Anyways, GDC! We arrived in San Francisco and our priorities were, in order:

Mexican food - thanks Taqueria Can-Cun!
Pitch the game and get a deal
Party with other developers

What it actually went like was:

Get in jet-lagged
Eat mexican food (success on one point)
Pitch game, get exhausted, pass out after 1 beer

Turns out a pitch meeting is:

Held in a hotel lobby or bar with high ambient noise
Limited to 30 minutes
Of which 5-10 min is small talk...
10 min presentation to set context & introduce team...
10 min game demo...
... and 5 min to talk about our schedule & how much money we need

Our schedule started easy at first but by our last day we were doing 5 meetings a day, and it was definitely exhausting. We learned that it’s really important to get as many meetings as possible, and treat even the longshot meetings seriously - not only to maximize the chances of a deal but also because you learn to pitch better every time. By the end we were ready for a beer...

We didn’t party much at all this trip; we were quite exhausted so we usually managed a few beers and then called it a night. We heard great things about the Wild Rumpus and hope to go next year.

We’re really happy with how the trip went and we had a lot of great conversations. We hope to be able to talk about those in more detail in the coming months.

If you’ve read this far, thanks! Have a special treat:

Over & Out,

Friend&Foe