Being a sad god, in hell in hot water

Screen Shot 2017-02-03 at 16.38.11

You probably haven’t noticed, but I’m trying to write something three times a week lately, ostensibly on Monday, Wednesday, and Friday. Some days it really doesn’t come easy though, like today. Or like almost every day, if we’re being honest. So for the moment just let me complain a little bit and be done with it.

An obvious metaphor for game development is that of being a god. You literally say things like “let there be (a directional) light”, click a couple of buttons, and light appears in the world. But almost immediately a difference appears: you don’t see that it is good. It may be bad. If you are me, it may quite often be bad. If you are me, this may mean you are quite often sad.

Light specifically is something I continue to have very little grasp of in Unity. It’s so fundamental, so important, and I should so probably read some kind of foundational text about it and just “get it”, but I never do, and so my light misbehaves. In the current project (v r 3) I’ve had my share of difficulties with light, only some of which I’ve solved. Some of it is akin to just being a bad carpenter, with light shining through apparent chinks in the walls where it shouldn’t. Sadly there’s no Grout Tool.

But there are other, more cosmic tricks of the light too. For a while a strange “reflection” of the world was appearing like a vision in the middle of the gallery, appearing to show the outside of the gallery space. It was a little bit blurry, not unlike something you might actually see in a game, I suppose, for some narrative effect – but I didn’t put it there, it just turned up. I still don’t know what I did to make it go away. I turned some lights on and off. Destroyed some lights, created others. Now it’s gone. It may be back.

Some water in my gallery seems intent on being very brightly lit, no matter what the light situation “actually” is. If I turn the lights off, the water goes black, but if there’s the slightest hint of light in the world, the merest creeping of dawn, it blares bright white. Why? I don’t know. If I make a brand new world (which I can do, sad god that I am), and put that same water in it, it behaves fine – it just looks like water. As far as I can tell all the light settings and entities across these two worlds are identical. The water just feels differently about them, I suppose. I’ll probably have to make my gallery world from scratch just to satisfy this particular water.

Despite being god, I’m at the mercy of these irregular ripples of nonsense physics; I hover over the waters like an anxious parent over a troubled child.


Definitely water

Today’s ventures with v r 3 have been largely met with deep, deep frustration trying to get various third-party waters working in my setup. There are just so many ways for things to go wrong it seems. Early in the day I was quite entertained by the bizarre shapes and contortions the water was getting itself into…

Screen Shot 2017-02-20 at 11.43.51

It sometimes even seemed to suggest whole new worlds of possibilities…

Screen Shot 2017-02-20 at 11.54.32

But by and large, as the day wore on and I was still struggling, it really did stop being particularly entertaining. I signed off at the end of the work day with roughly 10 third-party waters installed, and with about three of them barely functional. I suppose that’s not all that bad, but it felt like a tough day. Which, you know, is also interesting in its own special and beautiful way, probably, but I’ll be damned if I feel like writing about it.

‘Night.


Third-Party Water

Screen Shot 2017-02-16 at 13.23.14

Having more or less conquered Unity’s water (touch “wood” ha ha) I’ve moved on to populating the other building in v r 3 with “third party water” – that is, water I’m obtaining from Unity’s Asset Store. I’ve only installed four of them so far, but already there are interesting elements surfacing (ha ha?):

Broken water. Not unlike Unity’s water, I’m definitely running into problems with the third party water here and there, and it again reveals assumptions being made about the purpose/nature of water in videogames. One of the water’s I’m using comes with a prefab (readymade version) that is scaled to be enormous (100×100 units) which, when you place it in the world, makes it more like a reasonably large lake. Naturally that’s not the size I want in my game – I want a 0.1×0.1 scaled bit of water (1000 times smaller!). But when I scaled the water down to my size, it turns out to “break” it in the sense that all the default parameters are tuned to the water being large. It’s thus been an ongoing battle to work out how to tune the parameters to allow for the concept of a small amount of water. This water “wants” to be a lake, and I want it to be a puddle.

The people’s water. Now that I have water from multiple creators (Unity, plus each of the creators of the third-party water), you really start to get this sense I’d wanted of comparing water to water, and notably thinking of the water as something created by different people. Recontextualised as something to look at, and labelled with the creator’s name (like CruduxCruo above), the person behind the water comes more into focus and the water becomes, even more, something constructed.

Purposeful water. While the main Unity water is clearly trying more or less to look like “real water” of different qualities, it’s already the case that the third-party waters demonstrate different ideas about what water is for in a videogame environment. Notably, I have some cartoon-style water alongside some realistic water alongside some water that defaults to looking like surf rushing across sand. So we have not just the aesthetics of parameters tweaks to realism (in the Unity building), but also larger questions of how to represent water graphically.

The price of water. Most of the water on the Unity Asset Store costs money. Naturally this leads to questions of whether the water you’re looking at in the game was worth the cost (I’ve added the cost to each of the didacts). This naturally interacts with the purpose idea above. Your initial reaction might be that more expensive water should look more realistic, perhaps, but there might be other considerations that will come up through the exhibition. (There are also hidden considerations like how “easy to use” the water is, how many parameters it offers, etc.) This is also shown in a really nice way because the one free water I’m displaying also has a paid version, so there’s a direct comparison there of what added value you get when you use the paid version.

There’s bound to be more as I proceed, but it’s kind of amazing to me just how generative this stuff is in terms of really thinking about how videogames are constructed, how game engines work, and so on. I’m quite pleased with it.


Water as Time Dilator

Screen Shot 2017-02-10 at 18.11.43

Just some brief words this evening since I’m kind of weary and forgot to write anything while I was more coherent earlier in the day. Still working on v r 3, still running into frustrating but simultaneously interesting technical issues.

So I have finally, finally managed to put different kinds of Unity professional water into all my plinths. This included editing the water script itself and doing a little big of shader debugging, neither of which I envisaged needing to touch when I started the project. However, it now turns out that if you have all (or many) of the plinths in your visual field while playing the game (at least on the MacBook Air that I do everything on), the framerate drops significantly and everything gets a bit dodging-a-bullet-in-the-Matrix.

Clearly the work of rendering all these different planes of water at the same time is kind of killing the performance, which I guess is fair enough? I wouldn’t know. I think there’s already something strange and intriguing there, right? That water, ostensibly this innocuous physical substance can slow time itself is pretty remarkable. Game engines just do the darndest things. So water turns out to be, in some sense, expensive for the graphics rendering of the game, especially when you have the game rendering 24 different planes of different water, animating them, presumably performing reflection and refraction calculations etc. etc. Perhaps that’s just more than one should expect. So the water does time dilation. Fine.

Some investigation showed that even water that isn’t actually visible to the camera is still being rendered, which is a pain. It would be nice if the computer didn’t have to grind away on all the computation required to display water I can’t see. This led me down the rabbit hole of looking at occlusion in Unity thanks to Ben Gattet, and we managed to get these cool visualisations of what the avatar (camera) can see and what’s being rendered and so on. Water is definitely being rendered even when it’s technically not visible. And this is apparently because the things hiding it (e.g. the sides of the plinths) aren’t big enough to be considered for “occlusion culling” (the process by which the game engine decides whether or not something is hidden from view and thus doesn’t bother rendering it at all).

I tried a few tricks in this world, notably trying to define a much smaller definition of what could count as occluding something else, but that started to crash my computer and generate insanely large files storing all the data, so it doesn’t look like that’s a winner. In my daydreams I’ve been thinking about writing a custom script to hide all water a certain distance from the avatar, but I don’t know if that would work or just look horrible.

Which all leads to a question about the overall exhibition of water itself. If the idea is to demonstrate Unity’s professional water set up with different parameters, and if the act of doing so causes the game to slow down, am I right in trying to “fix” that problem, or is that actually part of how the water is experienced? Just as much as some water is see through and some is opaque and some is red and some is pixellated, isn’t it also the case that, as an overall exhibition, the water just happens to slow down time? Maybe that’s just a “physical” property of water in this setting. It definitely has the benefit of drawing attention to the technical status of the water, for one thing, which is kind of the core idea behind the show. Nothing says “this water is constructed from code” better than “the water code is not performing well right now”, right?

Wheels within wheels. Water within water. Though perhaps not the later, might crash the world.


My digital water’s like a swamp, full of bugs

Screen Shot 2017-02-02 at 14.43.28

Oh hi, I’m still working away on v r 3 at the times when I can do that, and it’s been quite the ride of highs and lows. Sometimes I’m really, really pleased with the overall idea and how I think it will look and feel when it’s done (and yes, I know this feeling may be limited to me and like two other people), and other times I’m feeling really, really down.

Because it turns out to be inanely difficult to put water in a bunch of plinths in a virtual gallery. It sounds easy, but it ain’t. As I’ve said before, a lot of it is fairly easy in terms of the basic physics of putting objects in a virtual space etc., in ways that would be hard to do in regular old reality. But it’s the weird technicalities that are proving remarkably resistant to my “vision”.

As I work with Unity’s free “professional water” more and more I’m getting considerably deeper into thinking about what it is and how it works, because I just keep running into incredibly frustrating mistakes and, perhaps, bugs. It’s really interesting to me that there’s this process of needing to understand what’s going on at lower and lower levels of this piece of technology (and, of course, that the water is a technology in the first place). It’s not enough to just grab a “prefab” (a pre-build example of water that comes with the software) and drop it into the gallery, because I have a bunch of constraints. The chief of which is needing multiple instances of water in my environment, rather than just the usual single body of water (like a lake or whatever), and importantly that those multiple instances explicitly need to have different parameters set on them (reflective, refractive, or not, etc.).

Because of my requirements, which make total sense to me, I’m having a lot of difficulty. It turns out, at least to this point of my knowledge of Unity’s water, that the water doesn’t seem to “want” to exist in multiple configurations in the same space. So if I make some water that’s only reflective, and some other water that’s both reflective and refractive, they will enter into some sort of weird “possible universes” situation where, depending on how you look at one of them, it will flip between being reflective or refractive and back again. Not the ideal behaviour for water. I’ve now reached the point of going all the way down to reading the underlying code that defines the water itself to try to figure this out, without too much luck as yet.

A weird addition to all this is that of course I could at some point choose to exhibit these weird behaviours as part of this “show” of water, or even a separate show of things that don’t work the way they’re meant to? On and on it goes…