Out now: AVSEQ


Big Robot’s first commercial game, AVSEQ, is here! We thought it might be a good idea to explain what it is…

BUT FIRST, LINKS:

Windows demo.

Mac Demo.

Buy Windows version for $5.

Buy Mac version for $5.

There is a SLIGHT DELAY in the payment being processed. I am sorry. Please do not hold your breath or you will pass out.

AVSEQ (which we pronounce “A-V-Sekk”) is an audio-driven game based on an installation design by our chief programmer, Tom Betts, who multi-classes as an artist and musician. The idea behind the project was to create a challenging, abstract action game in which you link up atoms to obtain a high score. As you do that, however, you unlock the underlying structure to each level, which is a musical sequencer.

Ah, so now we’re getting to the origins of that strange name. AVSEQ = audio-visual sequencer. As you play through the pretty-looking visual atom-linking element of the game you also activate the sequencer grid, creating musical loops. This process is random, so each level playthrough will create a different loop, based on the grid of sounds you are able to unlock on that level. Each AVSEQ level has 2.2300745198530623×10^43 possible audio permutations, thats 22 tredecillion in total. No, honestly, that’s a real number, we looked it up.

Anyway, moving pictures will help with the explaining, so here’s a new video trailer:

We will look at an iOS version too, if there seems to be enough demand for it.

Working On Fallen City…

Hello! We’re still working away on Fallen City. It’s been bumped back slightly to March 2012, but will still be freely available to play, and still be about little dudes in a city. Here’s a couple of images from today. Firstly the scene view in Unity, the tool we’re using to make the game, as we try to figure out the best configuration for sound effects across the level.

And here’s a shot from the game itself:

Click both for full size!

AVSEQ Approaches!


Our audio-visual sequencer game, the cunningly named AVSEQ, will be arriving in the next few weeks. We’re just polishing off some of the rough edges and putting together a demo for you. Initially it will just be available on PC and Mac, but we’re hoping to be able to bring it to a few other formats after Christmas. That’s really all the news for now, and the next thing you’ll hear a lot about will be AVSEQ, followed by the Fallen City release in the Spring of 2012.

How To Make An Infinite World


The time has come to reveal a little more of how we are progressing with the world generation of Game 2 / Lodestone. There have been a lot of changes since the previous post I made on the procedural techniques we are using. As a result of various succesful (and failed) experiments the terrain/world engine is now much more flexible and producing some truly epic landforms. In this post I am going to outline some of the key elements of our current world engine.

VOXELS

Well, everyone knows voxels are all the rage right now, but wait, we aren’t making a game with either ‘craft’ or ‘mine’ in the title! (Lodestone is about exploration, not construction.) Voxels are incredibly useful for storing 3D data, they are also ideal candidates for the application of procedural noise shaping functions. Voxel datasets can be quite memory hungry since they define forms as density clouds which record data for empty space as much as for solid objects, however they are very flexible and structurally formal. In previous 2D heightmap generation I used various noise functions to create interesting terrain, its fairly trivial to extend these functions to populate a 3D array instead of a flat matrix.

Of course we can’t just use a 3D density array directly or the game would look like a confusing field of stars. Most of the points in our array should actually be considered as empty, so we apply a threshold filter that essentially ignores any cells in our 3D array that are under a specific value. What we are left with is a set of solid cells that are within the threshold, this is essentially how cube world games like Minecraft operate.

cubes

Mapping voxel points in the 3D array to cubes is a nice and direct process that allows for quite fast generation and also for easy terrain modification (editing one point= editing one cube), but it inevitably leads to that distinctive boxy look. We wanted something a little different.


An alternative to using cubes is to ‘skin’ the density values in a polygon mesh. This leads to a more organic and flowing form, and is the route I took when translating our original 2D heightmap to a 3D space. There are various functions to produce polys from point clouds, most being related to the marching cubes algorithm. These functions take a 3D array of values and calculate the ‘surface’ of these values based on a specific threshold. Once a poly mesh is produced it can then be drawn like any 3D model in the game world. I had to tinker a little to calculate appropriate normals for the resulting mesh but soon came up against the nightmare problem of calculating UV texture co-ords for the polys.

TEXTURING

UV calculation is almost impossible, due to the constant size and directional changes of the polygons (unlike reliable cubes!) The best solution is to do all the texture mapping in a shader, using a combination of triplanar and noise based calculations. This applies the texture based on the normal of each texel, using the normal values to crossfade between different standard textures for each axis (x,y,z). The brilliance of this texturing technique is that you no longer have to worry what form the mesh makes, since it will always be textured consistently, without having to work out any UV co-ords. By adding some fractal distortion to the texture lookups in the shader you can also avoid obvious tiling artefacts and have control over the detail and scale of the final texture. There are a lot of tricks to producing interesting shaders for this approach (perhaps enough to justify another post entirely), but the result is worth it. Theres more info on this sort of texture mapping here.

SHAPING THE WORLD

Of course the actual shape of the polyon meshes produced by ‘skinning’ the voxels are dependent on how ‘interesting’ that data is. An unmodified noise function will produce a uniform distribution of forms with no consideration of axis. The actual aesthetic of the terrain comes from the various shaping functions that I developed to ‘carve out’ various selections of noise. A combination of layered octaves are used to modulate each other and a set of modifiers based on vertical position (the higher a point gets the smaller its density becomes) resulted in a nice range of resultant forms. You can use larger and larger scales of noise to mask out regions and superimpose other shaping functions on the basic data. This can help to eliminate the ‘same, same, but different’ feel of many procedural worlds.

I wasnt entirely satisfied by this though, because although it led to an interesting range of forms across a large distance, it meant you are still at the whim of the noise equation in terms of exactly when and where specific forms might appear. We want to be able to guarantee certain features or region types will occur within a particular distance. To accomplish this I wrote a secondary system that uses voronoi diagrams to generate a map of region types that are then used to directly effect the noise shaping functions. Each region type can dictate the form of the terrain, the distribution of resources and the type, frequency and difficulty of enemies. We can control the rarity and size of specific region types over a precise range (exactly 1 flat region per 100×100 units for example). The parameters for the region map are held in a template object and any world generation can be based on any template object, allowing us to produce a wide range of worlds with different distributions of region types.

INFINITY

The other aspect of the engine that has been both fascinating and frustrating is the fact that we are generating every world as an infinite plane. You can travel in any direction and the engine will keep making geometry until you reach the compuational limit of your machine. To accomplish this the world is split into regular chunks that are generated when your character moves and are discarded when they go out of range (or rather cached). The noise functions that shape each chunk are tied to the x,y,z co-ordinates of the world and therefore progress logically across any axis. Since the terrain is unmodifiable, we aren’t saving mesh data but regenerating it every time a new chunk is requested. I did try saving the data to speed up chunk generation when revisiting areas, but the filesizes were prohibitive (do you save mesh data, noise data, use RLE…) and the speed gain wasn’t worth it. Each world is based on a seed, which can be generated randomly or dictated, the seed is used for all the geometry and scenery so any player using the same seed will get the same world, same scenery, same enemies and so on.

Of course the world cant be stateless, we are trying to build something persistent. Therefore objects that arent static (consumed resources, enemies defeated etc) are saved per chunk to a world-seed savefile. This ensures that coming back to the same location will not regenerate objects that have been previously destroyed or removed.

More soon!

You can browse my other work over at Nullpointer.co.uk

Brooms & Bird Flaps: Major Milestones In Fallen City


This has been a strange week to be developing a game about cleaning up a wrecked city full of angry people. Fallen City is our first (but not only) project, and it involves brooms, tea, anger, inspiration, and cats. It’s a commission by Channel 4 Education, who wanted us to create something which examined the value of living in a city. A British sort of city. That’s what we’ve done.

Fallen City is a place that has already been allowed to fall into ruin and dereliction. Its inhabitants are bored, frustrated, ultimately angry humanoid creatures, many of whom are so pissed off that they are in an near-comatose state. Others are boiling over with rage, and continue to destroy or block off parts of the city. The player’s job, then, is to find ways in which to dissolve this ennui and rage, to bring the city back to life from dereliction. Fallen City looks a bit like management games of old (perhaps a hint of Dungeon Keeper in there) but it’s actually a sort of puzzle game. Figuring which buildings to create from the ruins you renovate, based on the kinds of staff you have available, is the main challenge for the player. If you want sort out the problems in an entire district, then you’ll need to make the right decisions about what that area needs. Getting 100% out of a level means cleaning the whole thing up, and choosing the right skills to unlock all the abandoned streets and annexes.


(Click for full size.)

There’s a little more to it than this, however, because we tried to reflect the implications of things like Broken Windows Theory, and also everyday experiences about how people feel when faced with urban environments. Our little creatures – Angries, we call them – are hyper sensitive to ruination, and will become extremely miserable if exposed to too much dereliction and abandonment. Push them too far and their energy – their attention span – will fail, and they’ll retreat to somewhere they feel comfortable. They might need a bit of cheering up – through music and street performance, for example – before they’re ready to help out. By default the Angries aren’t particularly interested in anything, and a few of them are swollen purple with rage at the world, the world that has promised them so much and then denied them it.

Yes, we’re playing with some odd metaphors for a videogame, and that stuff is even more stark this week, but I think what we’re prodding has a few different layers. This isn’t just social, it’s also about the material, functional nature of what cities are: Machines for living in, battlesuits for surviving the future. Infrastructure, we’re arguing, is too easily overlooked, but it shouldn’t be because it is bound together with making life liveable. The Angries need to bring their Idea Yards and the Curry Pumps back online if they are to remember why their city is such a valuable place, and how all the stuff it already has in place – its roads and pipes and cables – exist to look after them. We bring those unnoticed physical aspects of the city into focus, and allow the player to bring them back to life, and remember how and why they make life liveable for city-dwellers.


(Click for full size.)

We’ve done an enormous amount of work to get to this stage – as is evidence by comparing the most recent images above with a shot from the prototype, below – and I’m regularly breathing sighs of relief as the other talented Big Robot members and contractors make huge strides towards completing the game each day. This week alone has been a torrent of bird flap noises, exploding cats, weird goblin noises, and even minor moments of emergence.

This is the first game I’ve made since I tried to put something together with a chum aged 14, so it’s been quite an experience.

And, yes, it’s all come into sharp focus this week. A week of terrible events in real British cities, and week where our own Fallen City hit a major milestone. It’s a proper game, now, and there’s a strangeness to it echoing events in the real world. The issues we’ve been mulling over in cartoon, digital form have come into stark clarity, and that makes me hope that the game seems appropriate and interesting when it appears for you to download (free on the internet). If nothing else, we’re now working on something shockingly relevant, and that alone has made me want to get it just right.

You’ll find out more about that when the game arrives early next year.