It’s all in my head

Is is as if you were playing chess 3

At coffee this morning Rilla was talking about how she wants to write beautiful programs, in the sense of complex code that makes beautiful things happen systematically (she’s teaching an advanced programming course in our department, so this of course is a very reasonable thing to be thinking about right now). And it was interesting to me how instantaneously my mind bounced off that as an approach to making from my own perspective. I very clearly see how great that kind of programming is, and it yields things I perpetually amazed by, but apparently my mind just doesn’t work that way? (Or, presumably more likely, I just have gone in another direction and my mind isn’t trained to think that way.)

Rilla proposed a difference between us in terms of our interest in where the play of a game is ‘located’, which is an interesting way of putting. I guess I think it’s maybe more about the ‘ideas’ of the game, but that probably tips my hand in a sense. When I look at the kind of stuff I make (and especially after the first year or two), it’s very much a case of (relatively) simple programming (rarely even something you could call ‘systems’) that are attempting to convey or trigger more complex ideas (complex in the sense of conceptual). So something like It is as if you were playing chess, for instance, is ludicrous simple code-wise – just dragging circles and replaying the positions of chess games – but is “about” much more than that (the idea of play as physical performance, the idea of expertise, the idea of play as a form of labour, etc.).

In fact I wonder if locating the complexity in the mind or in the code (or perhaps also separately in the aesthetics?) is something where you need to just choose? I wonder if making a conceptually complex game that is also very complex programatically just starts to be too complex? Maybe this is a problem some people have when they’re designing weird (and wonderful, surely) magnum opuses that are just so complicated on so many levels that they’re kind of impossible to finish or, if finished, kind of impossible to play and “get”? I don’t know, this is just a thought. Maybe you need simplicity in the “other” aspects of a game (or any interactive thing – or any artwork?) in order to sustain the complexity of one particular part of it.

And of course it’s not the case the “simple” parts are therefore easy to work with – creating simplicity is incredibly difficult. v r 3 is killing me on the implementation despite being technically very, very ordinary (make a space, put some water in it), despite ultimately being a game that is more about thinking and looking than about anything complex development-wise. And I assume it may well be similar for a really complicated piece of programming – say a procedurally generated game. The conceptual layer may well be quite simple compared to the code, but I’m willing to believe there might be a huge amount of (conceptual) grappling needed to work out the kind of simplicity that can sit atop the complex systems beneath in order for the game to be at all accessible to a player.

Or maybe it’s possible to make an insanely complex game in concept, aesthetics, and mechanics. How the hell would I know? I’m just sitting here doing my thing, man.

Back to work.

Compression of artefacts

Screen Shot 2017-03-13 at 14.08.04 Screen Shot 2017-03-13 at 14.07.33

In what are hopefully the final stages of making v r 3 now. I have every Unity and third-party water working sufficiently well in the space that I think it’s ‘showable’ now. That is, I’ve either tweaked things enough or made peace with their appearance enough to move forward. This means I’ve been paying more attention to the idea of the game as something I need to put out into the world. And so:

WebGL. I’m not going to fight with WebGL in order to make a web-playable version of the game. I’m sure it’s possible, but at the moment the build crashes almost instantly with various script errors that don’t make sense to me immediately and I feel certain that if I engage with this I’ll spend another couple of weeks trying to get things in order. And even then I’m not convinced that all the waters will even work in the web context. Better to just restrict this to a desktop experience I think.

Title. Realised I need a title screen, so I’ll get onto that at some point. Can’t just crash land in a gallery of waters. It will be so much more helpful if a little screen comes up that says “v r 3” and then you crash land in a gallery of waters. Right? I know.

Compression. When I build the game right now it’s kind of bigger than I “want”. I’m not sure what I mean by that, but it is (or rather was) around 180MB uncompressed, which seems kind of excessive. It’s basically the fault of all the millions of textures (images) that the different waters use to create their effects, some of which are are almost incomprehensibly enormous. This gets me to one slightly interesting thing, which is the idea of compressing the textures. Obviously if I compress them they’ll get smaller and the overall game will get smaller as a result. On the other hand, if I compress them, am I somehow diluting the artistic intent of the creator of the water? Again, it’s that same question of parameters applied to texture compression – to what extent is it my prerogative/duty/right to alter the default composition of one of the artefacts that I’m treating as artworks here? It’s like, if the Warhol doesn’t quite fit on the wall you don’t cut some of it off, so…

Anyway I don’t have an answer to that one. I guess I’ll compress them because my hatred of large file sizes is greater than my desire for originalism in this particular scenario. Also, if I’m interpreting the documentation correctly, Unity can do a particular kind of compression that doesn’t actually affect the texture when you play, but only in terms of when it’s being stored, so perhaps that’s win-win. For what it’s worth, the two images above are of a compressed and uncompressed texture respectively… or it’s the other way around… I can’t tell the difference/

That’s what I’ve got. Some days are harder than other.

Water-borne disasters

Screen Shot 2017-03-09 at 12.54.05

I wrote briefly about some experiences with water gone wrong in v r 3 a little while back, but since I’ve been rebuilding the game from scratch to eliminate some lighting problems, I’ve run into a couple of my old weird friends again, like “super sharp sticky-uppy water” (above) and so on.

The above image is what happens if I literally just take a specific water I bought and resize it to fit it into my plinth. In a sense, then, this is “just what the water looks like” when you apply that simple transformation to it. And it’s a transformation I don’t think is terribly unreasonable – I need the water to exist in a smaller area, so I resize it. The fact that the water ends up looking like this is, I guess, most of all a result of the sometimes extreme parameterisation of the various waters I’m installing in the gallery. There are generally quite a large number of factors to be controlled for any given water, and they tend to rely on one another for an overall coherence of appearance. Thus, if you resize the water above, you also need to make sure that you change other aspects like the frequency and amplitude of its waves so that they make sense in the new context.

On the other hand, the water above looks pretty amazing, I’m not going to lie. And there have been quite a few instances of “broken” water that has looked pretty spectacular. Some water, for instance, completely ignores its scaling and just renders to the horizon anyway, leading to the entire gallery being half submerged. Some water has little undulating pieces of itself sticking through the sides of the plinths.

So there’s certainly a beauty to these distortions of shaders and scripts. As I’ve heard a few times, there’s probably another gallery show just in that idea itself. There’s a challenge there I think, though, in terms of what the “rules” for such a show would be. I don’t think it’s necessarily fair to just work out a way fuck up a shader or other Unity asset so it looks ridiculous and then display that. It’s true that that appearance would be “within its parameters”, but it feels a little in bad faith perhaps? (As I write this I’m not so sure.) Instead I guess I’d want some sort of “reasonable” transformation (like the plinth scaling) that turns out to create strange effects. But of course lots of the problems I have with the scaling in v r 3 don’t end up being visually interesting like the jagged water – most of the time you just end up with a completely smooth plane or something along those lines, so that kind of wouldn’t work anyway.

In the end I always want some sort of underlying formal reason for things being the way they are, I suppose. I feel like that gives a player a framework for understanding what they’re seeing, rather than just what they’re seeing being kind of the end of it, like “look how crazy this is! ha ha!” I think in the past I’ve called this something like the “ground truth” of a project, I don’t know what a good name is, but it’s certainly a vital quality. Most importantly, I think, it really helps me make decisions and move forwards – you know whether a particular idea/technical process/visual meets the criteria of your core guiding framework. So for v r 3 I know that the underlying concept is that I’m wanting to provide a context for thinking about water as a technical/aesthetic object in the context of videogames. Everything I’m doing, from the positioning of the sun in the sky, to the shape of the plinth, to the parameterisations of the waters themselves is informed by the objective.

Without something so strict, I think I’d just constantly get lost or feel like I’m kind of deceiving the player – pretending there’s coherence and meaning where there isn’t any. Thus to do a project where I’m showing “messed up” waters, it’d need some guiding idea like “water when you scale it down” or “water with each parameter set to a maximum value” or something, and even then, with that “or something”, you can tell that I’m not yet a  believer in that version of the project. Something more like “messed up visions of water I encountered while making a different project about water” might be acceptable too, I guess, but it’s less conceptually interesting to me.

Etc. etc. etc. Sorry.

Beautiful, clear water

Screen Shot 2017-03-06 at 14.33.55 1

Thankfully I’ve managed to find a way to find one more frustrating aspect of v r 3 kind of interesting again. With one of the more expensive waters I’m using I’ve struggled mightily to get the configuration of the water “right” – notably to scale it down to my little plinth-amount rather than a lake/sea/river’s worth of water. The water looks great at a large scale in the demo provided with the water itself, but when I scale it down and put it in my plinth it looks terrible.

Or does it?

See, the reason I’ve been frustrated and fighting with this particular water is that you kind of can’t quite see it when it’s in the plinth. You can kind of make out some rippling, and if you move around you can see the light reflecting off its surface now and again, but there isn’t that satisfying kind of blue “here is some water” effect that most of the other waters provide when I put them in the plinth.

Except that water isn’t actually blue, right?

Water is, in its pure form, clear/transparent/see-through. So when I put this water in the white, featureless plinth and I can’t see it, there’s a sense in which it’s behaving more like water than the other water’s I’ve been working with. If you really got one of these plinths (in physical reality) and poured water into it, and looked down into the water, you wouldn’t see much of anything either. Unless it was rippling and caught the light, say.

So in fact the problem with this new water illustrates yet another fun tension in this project, or rather a question. Or maybe two questions?

To what extent is it my job to make any given water look good in the plinth? A lot of the waters, as I’ve detailed in past posts, don’t necessarily play nice with being scaled down, for example. I’ve been working on things like rescaling textures and normal maps and so on to have the water appear more like water, but another way to approach this would be a more hardline attitude of saying “whatever the water looks like when scaled and placed in the plinth is what it looks like”. That would be easier, too, but doesn’t sit right. My compromise has been to roughly try to convince the water to look like it does when it’s big, just contained in a smaller space, which has almost always required me to tweak various parameters (ineptly and with many curse words thrown about).

What does it even mean for water to look good? This is perhaps a deeper (ha ha) question? As above, I’ve tended to answer it by saying that the water looks good (or ‘correct’ perhaps) when it approximates what the creator of the water made it look like in their demo or prefabricated version of the water. However, as in my discussion of the clear water further above, sometimes you can’t necessarily do that because the water itself is closer to a physical simulation of water. If the water is designed to essentially be clear and thus to only draw colour from the container, say, then if you put it in a plinth and it’s basically invisible then it’s “good” in the sense of looking like water would really look in a plinth. But it’s also not good in the sense of how we kind of want water in a videogame to look in a plinth. We want it to look “watery”, and without really thinking it through that means it should probably be bluish and highly visible. This also starts to link up to larger ideas about “good looking water” as a real technical benchmark for videogames more generally, I guess. And again, I’d venture that it’s not necessarily the case that the most perfectly simulated water would be considered the best, but rather the water that somehow feels the most real. Which is different.

The upshot of all this is that I’m almost at peace now, I think, with letting this water I’ve been fighting with just be transparent and that’s that. It’s water, that’s just what it does, right?

Somewhat deliciously the water in this case is called… Realistic Water. The clue’s in the name. Ha ha. Bye.

Maybe it’s important to hate what you do?

Screen Shot 2017-02-20 at 10.43.33

Kind of hate v r 3 these days, just so you know. It’s not an uncommon experience for me with any project that takes longer than a week or so, and I think it’s probably not uncommon for many of us working on any creative project. There’s only so long you can sustain unbridled enthusiasm for your own ideas and work – perhaps especially if you work alone and thus don’t have anyone else possibly on a different oscillation of love and hate who might offset you.

One way I’ve found helpful for dealing with this, especially for v r 3 actually, has been forcing myself to kind of fall in love with all the problems by finding them “interesting”. So you may have noticed I’ve written quite a large number of words here, but also in my development diary, about how things are going wrong constantly, but how that can be seen as a kind of insight into the nature of making a videogame, or the nature of the engine I’m using, or the idea of virtuality, and so on.

That strategy worked very well for quite a long time for what has been a deeply frustrating and humbling project. But at some point you can’t keep finding all your fuckups fascinating. Sad but true. Which is where I find myself now, so it’s pretty grim folks. Now it just feels like the ground truth here is that I’m a bit of a bumbling incompetent trying to do things that aren’t very difficult and failing. Le sigh, etc.

However, some small encouragement came the other day from the excellent episode of “Abstract” about Christopher Niemann. He’s generally inspiring (and I guess daunting), but at one point he talks about how he always feels at his most unhappy working when he’s working on something important. That could just be yet another nice psychological trick, like finding hardship interesting, but it’s cheering to think that maybe if you hate what you do it’s because what you do is just SO IMPORTANT. Too important to stop doing, for example.

But then, if we’re being brutally honest, you can’t stop even if it’s not all that important, can you? You’re making the stupid thing because at some level that’s just what you need to do right now. Throwing it in the trash would be glorious, but you’d just be back a few minutes later fishing it out.