I’ve been using Tracery over the last couple of days to build a generative grammar for this new game/thing called You are not here. It’s the second time I’ve used it in a project, the other being It is as if you were playing chess, and it really is a pretty lovely library in terms of making exactly the task of “procedural sentences” a fairly easy thing to put together. It’s quite well suited to the task because all I really need are these single, fairly blank sentences that describe some aspect of the environment like “a footprint in dirty snow” that can be easily varied to seem less repetitive. So one or two things…
Probability. One funny thing about working with this tool is how important the overall hierarchical structure of the grammar is in terms of probabilities of different sentence types appearing. For example, I had “a bird’s nest high in a tree” at the top level of the grammar alongside various actually procedural sentences, and this led to to the bird’s nest seeming disproportionately over represented, because it never varies. In a way I guess that’s the magic of the procedural – that single (non-procedural) sentences is just as likely as any of the other (procedural) sentences, but because it never varies, it’s really glaringly obvious that it’s being randomly chosen from a pool, breaking the illusion of these things being real “observations” of an environment.
Personal. It’s interesting to me how much the grammar ends up being structured according to my personal experience of the Champs des Possibles (the setting of this game thing), and in particular how even more abstract structural properties end up being inflected/infused with my take on what the Champs represents. So I have top level qualities (which are expanded by the grammar) such as “litter” and “softSurface” (code for things like ‘shit’, ‘slush’, ‘dirt’). It’s built into the structure that I saw the space as being kind of barren and dirty (in a totally positive way, for the record), despite, I think, it’s more general perception being that it’s this beautiful communal natural space.
Physics. Because I’m trying to write generic-but-detailed descriptive sentences about the space, it trends toward the description of objects, their location, and perhaps their movement. It was interesting to me how much this began to feel like designing a kind of word-based physics system for describing space. In my grammar there are things that can move ‘like paper’ (e.g. flutter, shiver, tremble), things that can ‘protrude’ from surfaces (e.g. poles, signs, sticks), and so on. I guess it makes sense that it would be designed as a kind of physical system because that somehow preserves a sense of neutrality and distance that I was looking for in the texts – and also partially gets at this idea of a ‘natural’ environment (what could be more natural than physics?). It also helpfully provides a known form of structuring information – hierarchical relationships and qualities of objects.
I’m not sure any of that makes sense, but at least I wrote words right?
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.
Work continues on v r 3, my exhibition of water. Yesterday I started actually messing around in Unity itself putting water all over the place and attempting to have it behave itself.
I’ve written about this sort of thing before, but I’m always really interested in the strange parallels that come up when you’re trying to do some sort of “job” in a game creation context. Whether it’s setting up the staging of a Eurovision show (Epic Sax Game) or doing the interior design for a non-existent institute (Digital Marina Abramovic Institute), there are always these situations where you’re trying to accomplish a task in digital space that is most often done in physical space. Setting up an exhibition of water is another example of this experience.
The most interesting thing here, of course, is the ways in which the digital impinges on the task, making some things much easier, some things harder, and some things just strange. So you can organise a gallery space by just cutting and pasting a file from a previous project, but in the same breath you might find out that light somehow shines through one of its walls which you need to fix. There have been various oddities like this that have cropped up so far in a single day of working on v r 3. Here are two.
You can’t lean over. In designing the plinth to hold the water I wanted it to be as similar as possible to the cubes in v r 2 as a kind of continuation and consistency. But in thinking about labelling and the ability to actually look at the water itself, it occurs to me that a really typical movement people perform in galleries is leaning over something that is lower down in space. The typical avatar always stands completely upright, just swivelling their neck around or, at best, doing a really weird crouch in which they lower themselves straight down in some kind of creepily smooth squat before scooting around the landscape like that. There’s no really naturalistic way to look at something from other postures. And this kind of rigid body (physics joke for you fans out there) has implications for the kind of display technology you then end up using. Maybe the plinth has to be higher so that the weirdo viewing the show is able to look clearly. Maybe the audience member has to be fitted with terrifying telescoping eyes so they can “zoom in” on things they can’t lean toward. Maybe the didact with the information about the particular piece they’re looking at has to be angled at 45 degrees to be legible, or has to be in extra large type. Etc. Consequences.
Water isn’t water. The water I’m displaying in v r 3 is obviously not “really” water, right? It’s not just a physical substance that behaves according to the laws of physics. Now, if I were having this show in reality, there would be all kinds of problems around displaying water, like the risk of it spilling or evaporating, of somebody trying to drink it or splash it, or of it leaking through the materials of the plinth, say. None of those issues are issues in a digital space, though – in those ways digital water is very neat and tidy and resistant to interaction. However, it doesn’t play nice in other ways. You can’t, for instance, take for granted that the world will be reflected correctly from the surface of the water (should you choose to enable reflections, which is a decision you can make). Instead, I fought for a couple of hours with the phenomenon of looking down into a pool of water only to see various bits of the reflective world pop in and out of existence. This does not happen, as far as I know, with real physical water. There’s lots of stuff like this. At one point I had multiple pools of water and realised they were all co-dependent – when I changed the colour of one (again, easy to do, no dye required) they all sympathetically changed colour. Not what I wanted. And on and on it goes. Currently I’m dealing with an issue where if you stand a really specific distance from the water and look into it, it refracts the world around it in a kind of scary infinite-looking regression of swirling shapes. A bit like a demon is about to swim up out of it and claim your soul. Not what I want.
So, once again I’m brushing up against all of these oddities of virtual spaces and virtual objects and virtual liquids. On the one hand they’re often very clean and simple to deal with or move around or remove or add, but on another hand they sometimes all too much like what they are, assemblages of code and assets that may or may not reflect reality.
So, physics. What’s up with that? Gravity. Ha ha, no, gravity’s not specifically ‘up’. I don’t think? Or is it? No I don’t think so.
Anyway, I have never gotten on with physics in games, it’s just not a relationship that ever seems to work out. The typical way it goes is that I spend inordinate amounts of time on things that should be easy because of physics engines, and they don’t work. We’re talking weeks or months sometimes, people. And then, admittedly, towards the end of that horrorshow I do end up with something that ‘works’, but it’s ridiculously too much effort. I’m not sure if it’s one of those things where I should just sit down and actually learn how physics (programming) works, or whether it’s someone else’s fault.
I spent some time the last couple of days trying to do the stupidly simplest thing with a BREAKSOUT game, and I never got it. And I mean simple, like getting a ball to bounce off something simple. But no. It didn’t work and it still doesn’t work and I’m mad as hell and I’m not going to take this anymore.
So I cut that game. Amazing how easy things can be. Having a hard time with your programming? You probably didn’t need that feature/game/universe anyway. Screw it. Off it goes, flapping like a rag into the abyss. That felt better, didn’t it.
Today I found myself lying on the couch feeling maudlin about sprite collision detection and resolution. It was not unlike speaking to my silent (and admittedly non-existent) therapist when I gave a small speech about how I wished I was smarter and knew how to things like collision. I fervently wished at that moment I was a mathematician or physicist or, damnit, just a better programmer! But no, I’m none of these things and so have been battling away with some collision stuff for PONGS for a good chunk of today.