Quick heads-up about two upcoming events:

first, I’m going to be talking at Playful, a one-day event run by Pixel-Lab as part of the London Games Fringe. It’s got a fabulous line-up, is at the beautiful Conway Hall, and is a steal at twenty-five quid. If you’re wondering whether or not you should go, then yes, you should. If you’re wondering what I’m doing there: a short twenty-minute session (as they all are, in fact), entitled Everything Is Multiplayer Now. It’s a remixed, rejigged, and heavily updated take on some of the ideas in Playing Together.

I’m going to shoot off shortly after I’ve spoken there – not because of the quality of the afternoon line-up, because let’s face it, it’s cracking – but because I’m making my way to Nottingham for the remnants of Gamecity, a three-day games festival (that begins on Thursday the 30th). It’ll be a shame to miss the first day, but I’m hoping to catch Jonathan Coulton and his Zombie Choir, not to mention the excellent events on Friday and Saturday.

As part of that, I’ll be giving a lunchtime session on Saturday, in the Mogal-e-azam Indian restaurant. That’s going to be entitled “A World Run By Gamers“. The brief precis I supplied looked something like this:

It’s more likely than ever that in the coming years, people with power – political, industrial, corporate, technical – will have played videogames. And not just had a passing experience with them; they may actually be what we might term “gamers”. In the coming years, the world will face such as impending recessions, peak oil, and global warming (not to mention all manner of other difficulties over the horizon). And it’s not just impending disaster; there are all manner of positive challenges we’re going to have to rise to. What have videogames taught the leaders and innovators of tomorrow? What are the necessary skills for the 21st century that gamers have been learning for years? What can we learn from games, and what can gamers – and game designers – take to other industries and sectors? Tom will examine these questions with reference to MMOs, football management, survival horror, twitch-shooters, beat-em-ups, and more, with barely the briefest reference to SimCity.

Which, you know, could be interesting. And if it’s not, then the food will be good (and you know the rest of the festival will be awesome).

So: end of the month, lots of stuff about games in London and Midlands, and that’s where I’ll be.

Katy, over at Kitschbitch, writes about Nokia’s new “transmedia” advertising campaign, and comments on it’s ARG-iness – or rather, its un-ARG-iness – and feels disappointed, saying:

…given that Nokia were the trailblazers of using immersive play to engage with consumers, doesn’t it feel like they’ve missed a bit of a trick here?

I was going to comment, but my comment grew and grew, and it felt like a post in its own right.

I’m not sure I’d agree with some of Katy’s criticisms. What’s emerged as a “traditional ARG” has basically consistently turned out to be very engaging for a tiny number of users, very costly to run, and usually exhausting for all concerned. They’re difficult to sustain and few companies ever go for a second ARG.

So a “campaign you can interact with” is a much more realistic interpretation of an ARG, you could argue: it requires far less involvement to get people in, meaning that your advertising dollar reachers more end users; it doesn’t require too much of a long term committment; it’s not community driven, meaning people can have the experience on their own, without having to invest time in building new relationships; whilst it’s interactive, it’s a constrained form of interaction, meaning it’s easier to control and keep on the rails.

The one thing it does have in common with an ARG is that it’s timeboxed: it runs for six weeks. Want to play it after those six weeks? Tough. That’s actually one of the biggest problems facing ARGs: getting away from that timeboxed nature.

So whilst it’s not the bleeding edge of ARG design, it’s probably a much more practical decision for an advertising division on Nokia: it’s less of a loss-leader than another Beast or ILoveBees; it’s engaging a broader degree of consumers but at a shallower level; it’s an order of magnitude or three less complex than a full-blown ARG.

I’m not necessarily convinced by the implementation, but I don’t think the lack of scope is reason for criticism per se; if anything, the “simple ARG” is perhaps harder to get right than the long, complex narrative that you can fix in retcon later on. The upfront budget – advertising, filming, media costs – here is bigger than most ARGs; the running cost is smaller. That sounds like a sensible way of keeping costs where you’re in control of them.

And so I think I’d argue that it’s actually more innovative than throwing a massive ARG budget at the problem: they’re trying to learn from ARGs to see what an affordable, practical interactive campaign, made by advertising/digital media agencies (rather than ARG agencies) might look like. That’s got to be worth a point or two.

There’s been some really interesting posts on the games blogs recently about the relationship between the player, their character, and the game’s camera. Obvious highlights include Mitch Krpata’s recent post about cameras, and his follow-up, about the camera’s implementation in EA’s Dead Space. In his first post, Krpata outlines the issues:

In a game, there are three entities sharing control of the experience: the player, the camera, and the character. The difference [between games and eg. books] is that these don’t exist on a straight line. They all overlap, like a Venn diagram. In a first-person shooter like Half-Life, the player, the camera, and the character are all the same. In a third-person action-adventure game like God of War, the camera and the player are distinct, but the player and the character are mostly one and the same. In a strategy game like Warcraft, the player and the camera are the same, but the characters are on their own.

Krpata in turn was responding to Corvus Elrod’s excellent series of posts about the camera in gaming. In one, Corvus comments:

…it’s only a matter of time before someone turns their artistic attention to the video game camera and implements a system so risky, so rewarding, so compelling, that it changes the vocabulary of game cameras forever.

Vocabulary is an interesting word; an important part of the process of understanding an issue is finding a way to express it, and I think a lot of the vocabulary of games-cameras is currently derived from cinema. We need to move towards a game-native vocabulary for cameras, and whilst something might change that vocabulary forever, I think it might be a slower, more evolutionary process.

And that all leads me to the post I wanted to write about originally, which is about a single thing the camera does in Alone In The Dark.

Alone In The Dark

I recently downloaded the demo of Alone in the Dark (hereafter AITD) from Xbox Live, mainly because I was curious about the game: its review scores were all over the place, and the best I could ascertain from the forums was that it was very much a thing of shreds and patches.

The demo confirms that. It veers from moments of brilliance (in terms of graphics engine and interaction design) to appalling control implementations and awkward combat. The in-coat inventory is a classic example – it’s a beautiful interface, and really appropriate, totally ruined by the way you manipulate it. It’s hard to call a game that takes so many risks bad, but it falls on its face in many areas. I’m really not sure I could face playing the whole thing.

But. There’s always a but. And in this case, it was something the game does with the camera that is so daring, so brilliant, I couldn’t help but be impressed.

The game begins in a first-person perspective. Your character is somewhat groggy, having been kidnapped, and his vision has a habit of blurring. The only way to clear it is to blink, an action performed by clicking the right thumbstick. In the first five minutes, you do a lot of blinking.

This is cute, but it isn’t the thing that impressed me.

After the initial sequence, you eventually come across a mirror, and the game jumps to a cut-scene, viewed from the third person, where your character sees himself in the mirror. The camera pans around him, taking him in, as he admits that he has no idea who he is. He doesn’t recognise the man in the mirror.

Then, you realise the cutscene is over, and the game has jumped to a third person perspective.

That’s what I thought was brilliant: the idea of tying the camera into the narrative like that. You’re only allowed to see your character when the character has finally seen himself; the perspective shift represents the amnesiac Carnby seeing himself for the first time. From this point on, you can toggle between first and third person (and you tend to do it a bit – certain actions are easier from each perspective), and the action loses its significance. But the first time it happens, it’s a real surprise, and it’s really smart: the game’s interface reflects the character’s understanding of himself.

That feels like a game-native understanding of camera: the idea that camera can be something that helps to express the seams between the player and the character. Which is, of course, what the camera in games is: a kind of boundary object between the player and the character.

I must have lost about six or seven hours trying to get a Rails application deploying from Git in the past week. I could push and pull from the repository, but could I get the thing to deploy via Capistrano? No, I could not.

The problem, as far as I could tell, was not with Capistrano. It was a simple SSH problem. I block port 22 for SSH on the server in question, for security reasons, and use a different port. But, no matter how I specified it, Git was insistent on trying to pull over 22. I did a lot of Googling, and found lots of conflicting answers, none of which worked.

And then I learned my lesson. That lesson is: when Linus tells you what to do, you do it:

Use the “.ssh/config” file ;)

So I configured a hostname in .ssh/config on the server, and everything worked instantly.

A lot of problems tend to come down to SSH, it seems. After that point, everything went swimmingly.