Bez on a Bike: Bridging Creativity with Technology

Yesterday I jumped on my bike, and rode out and got me the cheapest Shader 3.0 enabled graphics card that money could buy... ~170 Eurobucks. I took the opportunity to be a tourist around Amsterdam city. I've been in Holland almost two years now, but, as is typical for people with heavy workloads (and nerdy, agoraphobic dispositions) I had never really known it very well. The path back and forth to work is etched into my brain, but the possibilities off that well trod route were under-explored.

I let impulse guide me around the city, almost trying to get myself lost. Quite by accident, I rode past my previous employers' apartment. It's a place that I had only previously been to via tram and taxi. Funny how the experience of traversing through the world feels so different when you're in control of where you're going. If you're being lead somewhere, or following a pre-designated path, the cartographical part of your brain must switch off or something. You stop caring about mapping how to get somewhere because it's out of your hands. You're not responsible for your direction, or getting to a location. It's a bit like following an implied path in a scripted FPS, or uncovering more nuggets of story in a lot of other games. That's the reason I hadn't known the route before - I had never visited the area with the responsibility of finding my way back home.

Finding this path under my own steam and being responsible for my own path was a small revelation. I was being incredibly coscient about the areas I was passing through so that, as a last resort, I could always work my way back home. As the geographically disparate locations of my house and my bosses' suddenly linked up in my head, I got a feeling of how the traffic system in Amsterdam flowed, as it does, in its concentric circles and spokes which radiate out from Central Station.

Finding the route was practically random. There was no map reading, no approach, and not even an intent to find the place. However, if I wanted to, I could have used a methodology that would make mapping the route more of an inevitability than a fluke: I could have spiraled out from my starting point, touching the previous arcing path with every cycle, very quickly giving me a highly connected mental model of the street layout. People use this technique to find dead bodies.

I mention this because it's a good analogy for creativity (not the finding of dead bodies). Edward de Bono and Michel Gondry seem to agree that creativity manifests itself in the elegant leaps between seemingly dissonant ideas. Paraphrasing de Bono "Successful Creativity is 100% silly in foresight, and 100% logical in hindsight". Creativity isn't about creating new thoughts - it's about constructing bridges between existing ones.

Anyway, I rode on home, because I was eager to engage in some technophilia.

One fairly painless install later, I had Render Monkey open. It seems like a great tool in that it completely exposes shader functionality while taking away the pain of setting up an environment for it. Scanning through the examples, I started to build up mental models of the common techniques and functionality used to generate a range of shaders. Each new example bridged a gap between what I wanted to create, and what was possible... Sorry, no, I'm still not going to mention what the game is... But now you know that it requires some considerable Shader tech. (And a bit of googletective work would probably reveal the game... If you figure it out, I do hope you'll keep it quiet for a while).

I'd like to claim to be technology-agnostic. To me, a game is a game is a game, whether it's played on a computer, on a pitch, on a board, or in the mind, but in the face of things, it's quite hard to say that I really am. While this game could be done without shader technology it'd probably not hit its intended targets. I feel that it's rare that technology enables significantly different game play possibilities, but it does happen, and this might be one of those cases (probably not, if I'm honest, but the tech definitely allows us to hit a critical aesthetic). At the same time, I don't feel like I'm being a slave to technology when I consider where the game's concept is coming from...

If you look at a cross section of video games, it seems that they lie between two extremes. At one extreme the game's concept has been created with a complete disregard for how current technology can be leveraged to meet the vision. On the other end, there is such an obsession with show casing technological trinkets that the game's design plays second fiddle - the infamous "Tech Demo" games (although in some cases, I'd argue that the elegance of some of the design is underrated).

The former gets produced due to individuals with stunning personality but a lack of understanding of their canvas; that is, the technology and production pipeline they must contest with in order to see their vision through. The latter extreme comes from those who simply have no real compunction to pursue anything remotely artistic (in the interactive, rather than audio/video sense) - the GPU's the star.

When the gameplay-bereft technical beauties appear, their gleam hides their shortcomings, and if nothing else, they're nice to watch while someone else plays for you (assuming you have any kind of a technological sweet tooth). And when those games with unfulfilled grandiose promises appear as buggy shadows of their platonic (and possibly impossible) ideal then we say "Aww. Well, at least they tried to do something different".

The media seem to criticize neither, mainly because they're not allowed to see the truth during a production - they're allowed to talk to the talkers in a company, and are sold the image of a development utopia - or where productions are obviously tough, it's "living the dream", and "we live on coke and pizza!". But that's a rant for another time.

I don't mean to criticize either extreme. In my book, every approach is equally justified. It's just that a director has to be responsible for the quality of the results. If they don't work out, it's probably not that the theory is wrong. More likely, it's because the theory cannot co-exist with reality.

It just seems to me that the middle ground is your sweet spot By that, I don't mean that Technology and Design have "equal say". It shouldn't be able Technology and Design being locked in a power struggle. They should be symbiotic. They should respect and engage with each other, understanding each other's needs and trying to come to an artistically accomplished, but technologically plausible result. Artistic success comes from understanding your limitations, and working with them, rather than against them. That means knowing your canvas. In our case, that means knowing what Shader technology's strengths and weaknesses are.

...The game we're making is something I've had on my mind for several years now, before shaders existed, and before I really knew of a proper way to approach it. It was a really rather abstract idea, floating around, certainly not born of a possibility that technology had thrown up. It remained in that platonic limbo until I started to learn about how shaders worked.

I started to investigate at a very superficial level, and saw how vertex and pixel shaders were basically these power-houses for visualization - simple algorithms applied in brute force onto big chunks of data, throughputting a whole lot of data, constantly. Like anyone, I started to think of how one would use the technology to make superficial graphical doo-dahs - some realistic like refraction and bump mapping, and some abstract, like minter-esque feedback buffers and colormaps. I thought of ways in which I might be able to pull off some of the rather abstract OpenGL 1.0 effects in my previous game using shader technology.

Then, quite by accident, I found my previous employer's apartment game concept. A mental cycle path between the raw game idea and the technical approach had been laid down in crazy paving, its course weaving without intent. Out of a cloud of ideas, two haphazardly found each other, and became one. As a result, we're on the cusp of finding out whether this technological approach really works. If it doesn't, we have a few other possible solutions to try. I'm fairly confident, but you never can tell, eh?

Like I say, I think that there's more to being creative than hoping and praying for a eureka moment (or smoking funny cigarettes for the hyper liquefaction of one's train of thought).

At the same time, trying to actively be creative is never going to stop you from getting lucky.

Self Motivation

I do apologize for immediately posting nothing at all. I have 3 or 4 draft posts which start with nice small snappy ideas, but then seem to simply spiral out of control and try to solve world hunger (though not very well).

My next post was going to be about self motivation, but it's really hot here, so I just went to bed instead. No AC kinda sucks. Eventually AC in europe may become rather standard, but only when the north sea is lapping at my feet... in the brendan hills.

So, despite suffering from heat exhaustion most of the day, and getting food poisoning yesterday, we're doing alright.

Tommy Refenes is the coder who works with me on our game. He was one of the engine coders at Streamline before we all decided to leave. He's just recieved all the hardware he needs, and is starting up a Subversion server so that we can code remotely. He's already got a basic DX9 environment going, along with a console and various input interfaces. The engine is also being built with multithreading in mind from the start. Some of the techniques we use could be called "brute force", relying on the nature of the target hardware. In many 360 games, there's a lot of processor power going untapped, so we're trying to be smart about how we process and pipeline everything from game play to sound to graphics.

I'm trying to get my head around some of the shader tech we'll be using and planning game code architecture. We use a wiki to document everything we work on, listing everything from game mechanics and algorithms to business plans and marketing ideas. I personally like to try to document everything I can about a game well before coding anything because it forces me to be intentional. It means that I can't just say "yeah, let's have kick ass feature #131516" without seeing what affect it will have on the rest of the game. It means that I won't code anything half heartedly, or without proper respect to the rest of the architecture (unless the name of the game IS experimentation and prototyping, in which case, anything goes).

Design documents change all the time, naturally, so we try not to look at the document as something that's set in stone. It's more like a repository of knowledge about the project, changing day to day, but helping us to maintain a united vision of the game (even if that vision alters over the development). Since it's a wiki, it's very easy to track each other's changes, and share ideas, text, images etc. It can also rather naturally guide the design of the code architecture (which is both good and bad, but basically comes down to how well you design software) and via "needed pages" can show you what areas need more elaboration before the design can be called "well formed". Damn I love my wiki!

One interesting thing I've encountered with wikis in the past is that although they can give a very detailed (albeit sprawling) specification for a design, it's very hard to communicate a higher level idea of what the hell the game is about. In other words, you can understand each individual component of the game, but it's hard to see how they bind together to make something interesting. As a result, I make pages which explain lots of emergent strategies made possible with the core rules. This gives a newcomer to the wiki lots of practical possibilities in the game, and explains how the core rules give rise to them.

At some point we'll open up the wiki for public scrutiny incase anyone is interested.

Pretty soon I should be able to start actual game play coding - I've been preparing all my favourite physics equations in anticipation, but most of the work will be in game play element management.