Thanks for the Interest

Well, we've announced the game now, which gives me the luxury of being able to tell you in detail about details you really didn't want to know details of: for example, Tommy just finished our instancing management, which means we can finally have the famous crowds of beees! They're in there, and moving around nicely ontop of a bee hive surface which grows as they move around (clever shader stuff going on there). Just by pure luck of emergence, when the bees are about to be captured, they look a bit scared, like they're trying to escape the other goos' clutches!

Right now, we're trying to pull the demo together properly so that it can be shown to interested parties. We're finishing off game modes, totally revising our menu (which was a bit of a quagmire of prototype code), re-doing the HUD, polishing sounds (thanks Justin). We're also doing a proper background audio-viz, which will be taking a leaf from the demoscene book (though hopefully not to the point of plagurism!).

Because of the video, we were linked from a few places, and got more than twenty one hits! Over 4 days! Amazing!

Feedback on the video has been really useful, and highlighted issues that we'll work on, or atleast explain better. I should say, by way of excuse, that we had been coding for 20 hours before we started recording that video, and stayed up another 6 hours editing. I feel tired just thinking about it.

Some people didn't immediately get that the core point of the game was to capture Goo by surrounding it. I guess we've been working on it so long that it seemed self evident to us (and other people felt that way about it, too). Still, in the next video, we'll have to make that painfully clear.

It also wasn't clear/convincing from the video that the game is one of those "simple but deep" affairs. People suggested that it needed more buttons, or powerups, or levels, or just more perceivable complexity. I've always thought of it as "Liquid Go", hence the title of the game. Go's incredibly simple, and unarguably deep. I really want to keep a hold of that property, and would argue that once you try the game, you'll very quickly become aware of the interplay of density and territory: with territory, capturing is easier, but it's easier for your goo to be divided by slicing attacks. With density, it's harder to be punctured, but you're smaller, slower moving, and easier to surround.

Of course, Go is turn based, so you have time to think with your higher consciousness. Goo is much faster, and therefore becomes more about experimenting with strategies and seeing their results immediately, which helps you to build quickly an intuitive sense of strategy. You're creating instinctive reactions. It's still strategy, but at a different level to Go's. Gillen said it was like "Protozoic StreetFighter", and that feels right on the money. StreetFighter 2 might be button masher to people when they first come to it, but you get a sense of flowing strategy pretty quickly if you give it any time.

On the other end of the scale, people said that it could potentially get too chaotic. From the beginning of development, I've been vigilant about this. We've worked really hard to create a physics model which we can tweak to perfection. I investigated fluid dynamics early on, and found that things like Navier Stokes (a fairly realistic approach) weren't going to suit this style of gameplay. Navier Stokes gives rise to chaotic outcomes very quickly. For me, this isn't usually a useful quality for a player - if their input in the game turns into "noise" too immediately, they don't feel a sense of Perceivable Consequence. Success, failure and consequence in general don't feel like direct results of player input - instead they're due to the seemingly random (but, infact, chaotic) whim of the fluid model being used.

Some games have used it to good effect, mind you, but I don't think it would have worked here where intuitive and expressive control is a prominent goal. The point is, it's far more important to give people a good sense of control than to have purely "realistic" physics - the two are not mutually exclusive, of course, but very often in games, the latter takes precedent over the former.

We use a pseudo soft body physics model - hundreds and thousands of points have connecting and disconnecting spring forces between them, as well as friction. Points from different goos have a different relationship, so that they don't overlap too readily, and so that fast moving blobs can scythe through the enemy, or have their movement slowed by the enemy's density. This gives us an atomic level of control. After tweaking these base forces enough, you get a sense of how these changes affect the higher level gameplay, and all of a sudden, you've got this plyable goo which works for you, rather than despite you. At the same time, all gameplay is an emergent result of these simple spring forces, so it doesn't feel like the physics have been contrived... it feels believable, even though they're unrealistic. That's kinaesthetic verisimilitude, word fans!

Still, if none of this sense of control is immediately clear in the video (go fig. It's not interactive), then we probably have to present it better. The BeeHive skin certainly helps explain goo density and behaviour a lot more transparently than previous goos have, so we can get there.

Blah, I'm wandering off into random thoughts. Thanks for your attention span.

Jonathan Blow Interview

This is an interview with Jonathan Blow, who has had my respect for a long time based on his work for the IndieGamingJam. He's about to release Braid. We're hoping that Braid will be to Prince of Persia what Portal is to Prey - plunging deep into an interesting mechanic where previously developers have only dipped their toes.

Up until now, details have been a bit thin on the ground surrounding the game. It's very interesting to hear the guy's creative process. He talks about a lot of issues which we can certainly relate to. In working on our current game, chaos has always been a big issue. We're trying to model something normally modelled with deterministic systems, which result in really pretty simulations, but which also very immediately explode into unpredictable possibilities. I've always called this "Perceivable Randomness" - when logical causal steps are obfuscated to the player, and it becomes difficult to understand how the system works, and therefore, how to manipulate it - like a magician hiding his tricks behind a cloth.

It's simply not very helpful for a player to be able to call on a system (deterministic or not) which he or she can't anticipate the result of, even after trying through trial and error (or even explicit guidance) to build a mental model of it. Where random elements are concerned, we can at best gage the typical deviation of an outcome from its mean, but only after many, many iterations (part of the reason random Rolling still exists in RPGs is because of this - we feel as though we're still trying to grok combat systems, even after the 500th WheltSnipe has been mashed. Hmm. I'm getting blog deja vu, so I'll get back on topic now).

We try to ensure that our system comes to rest quickly, and makes its immediate causal links obvious and easily predictable: a quality which Doug Church calls Perceivable Consequence (and according to Google, I am the world's most prolific misspeller of that phrase).

When it's just a few game elements you're dealing with, Perceivable Consequence is fairly easy to maintain (both cognitively and computationally) by simply not introducing random factors, or indiscrete values mapping onto wildly dissonant outcomes. Our game has hundreds (possibly thousands?) of elements all springing off each other in real time, which you'd think would cause massive causal explosions. However, everything is well "frictioned" so that we can bound our possibility space.And because friction is a passive property of the physics (resistant force increases with velocity), that bounding feeling doesn't feel sudden and arbitrary (like a glass wall). It's a rare case where technology (in this case, lots of multithreading) has enabled a game play mechanic. All the brute force physics we're using in our game is there to ensure we have a system which doesn't explode quite so readily - pulling something which could easily become perceivably random back into something with great perceivable consequence.

God, this is just too vague to be useful to you, isn't it? Point is, Jon is expressing a lot of things that we've come to learn during this development, so it's reassuring for us. Really looking forward to this.