Platform Games

At last, I’m CLOSE to being able to make a build that has some chance of actually running on your computer. Hopefully it’ll be done by the end of next week (he says, cavalierly). But in the meantime, I wondered if some of you who aren’t yourselves 3D programmers, might be interested in just how much stuff is involved, when doing even the most trivial and pathetic tasks in 3D…

I wanted to make a very simple cable car, so that creatures can get across from one hill to another. To be honest, I don’t even know yet whether they’re smart enough to figure out that the food or shelter they want is on the other side, and so they need to call and get into the cable car first, in order to reach it. It’s actually a very different neurological problem from ‘merely’ navigating around space on foot to get to a remembered target (which all by itself occupies a large portion of their brain circuits). But that’s a subject for another day. For now I just needed to give the creatures something to do.

I haven’t actually drawn the meshes for this cable car yet, nor textured them – I’ll talk about how all that magic is performed in another post, if you’re interested – so I simply knocked something together out of white cubes. It took all of two minutes. The functionality is what matters, for now.

The first question was how to make the cable. It would look stupid if the car ran along a perfectly straight cable, so I needed the cable to ‘sag’ in a lopsided V shape, down to the object that the car is suspended from (hereafter known as the runner) . In real life, this sag would be a fairly complex curve, because both the car and the cable would have weight, but a simple V shape looks just fine. So I added one of Unity’s LineRenderer components, to draw two connected straight line segments between the towers (white boxes at the start and end of the cableway). Then all I have to do is repeatedly change the lengths of these two lines, in order to keep the notch of the V aligned with the position of the runner. Easy peasy. LineRenderers by default use an unlit shader, meaning they don’t get darker as the light fades, so I do need to fix that, but basically it looks good enough.

I also wanted the car to dangle from the runner, so that it swings about slightly as we shift our weight inside the car, and especially as it lurches into action. For that I used the physics engine’s ConfigurableJoint component and gave the car some mass, so that it has inertia. A ConfigurableJoint, plus a RigidBody component at each end, contain several dozen parameters between them, but luckily I only needed a few of these, so I guessed some reasonable values for the mass, linear and rotational damping, set some angular limits, constrained the correct axes, etc.

Given that the car was now able to wobble convincingly without me having to write a single line of code, I thought it would be good if it could wobble in the wind, too, especially if it’s stormy weather. So I wrote some code to figure out the wind direction and speed, and add a corresponding force to the physics objects.

By the way, wind is not actually a “thing”, in a 3D simulation. In fact, literally everything inside a 3D game is numbers and arithmetic. There is no such thing as solid, or colored, or heavy, or rough, never mind such a thing as life or consciousness. All we have are numbers – billions of them. For the solid, colored, heavy parts, we simply cheat, using a wide variety of extremely clever mathematics, and assemble numbers that behave as if objects were actually solid, lit by lights, and so on. When it comes to simulating life, it’s a bit different and not so cheaty, but we’ll get to that eventually.

Anyway, to simulate wind, there’s basically just a kind of ‘compass’ (a vector – a point in space, with a direction and magnitude), which we can point in a suitable direction and generate suitably turbulent random magnitudes for. It doesn’t do anything by itself. Anything which needs to react to wind, such as the smoke from chimneys, the movement of clouds, the fluttering of fur, the bending of trees, or the swaying of millions of grass blades, has to read the current direction and speed values from this wind compass and react accordingly, using its own code. Here, I only had to add a simple force to the cable car, but in other situations, responding to the wind can be pretty complex. And of course we do need a way to decide what the wind speed and direction should be at any particular moment in the first place, so I previously had to design and build a complete weather engine, which calculates this and other factors (rain, snow, fog, clouds, sunlight, blooming flowers, falling leaves…) from a map of slowly changing air pressure and humidity. That, too, will make for an interesting blog post sometime! But luckily I’d already done this long ago, so it doesn’t matter as far as this simple cable car is concerned.

Cool. So now the white boxes dangle from the ‘cable’, and the cable shape is easy to update as the car moves. So I just needed to move the car. Conventionally, I’d use Unity’s complex and ungainly keyframe animation system to do this, because then I can animate doors, wheels and assorted other gizmos, all in exactly the same way. Unfortunately, Unity decided in their infinite wisdom not to expose the relevant parameters inside the LineRenderer, which meant that making the sag in the cable exactly track the animation would have to be done separately, in code. Since I hate the animation system anyway, and especially bending over backwards to fit in with its many quirks, it was easier just to animate the car, cable, doors, and suchlike individually, using simple arithmetic.

But the car shouldn’t start moving until we (the player or a creature) actually climb aboard, obviously. So I added a trigger collider to sense when something enters the car’s space and some simple code to check what kind of a thing it is. The way physics works in Unity is a bit weird, though, to say the least. If we step aboard and this triggers the car to move, then by default (i.e. depending on which version of PhysX they’re using this week, which new bugs they’ve introduced, and who was the last person to leave the toilet lid up), it will often just move away without us! We’d be left standing where the car used to be. Or, given that we have physical properties ourselves, we’d step into the car, it would move away, and we would fall straight down the cliff!

Luckily, I’ve already dealt with this problem, because it was needed for boats and trains and suchlike. So I created my new CableCar class in C# and simply inherited this from my already existing Platform class. I wrote Platform, partly so that it would detect when an object enters its space and make that object become a ‘child’ of the platform. Let’s not get into transform hierarchies right now, but the point is, when the platform moves, the child will automatically move with it, whatever the physics engine had in mind. Creatures can still walk around on the platform, just like someone walking down the aisle of a moving train, and the code will make their sensors measure their speed and suchlike relative to the platform, instead of the world (otherwise they’d believe they need to run backwards, just to remain upright).

The Platform class, in turn, is derived from my Zone class, which mostly deals with local environmental matters, such as how much warmer or less windy/rainy/bright it is inside this region, compared with the environment outside it, although the Zone class actually handles quite a lot of other useful things, too.

So, CableCar derives from Platform, which derives from Zone, and that derives from my quite complicated Part class and is also associated with a Root class, both of which derive from my Behavior class, which derives from Unity’s MonoBehaviour class (which in turn derives from a bunch of other Unity classes). Each class adds more fundamental properties. Without a Root, for example, we humans could see the cable car but the creatures wouldn’t see it at all. The Root is what describes it to their senses, so that they can learn to recognize it. Amongst many other things, without the Part class the cable car wouldn’t be able to emit Payloads, which often emit Signals, which are what tell the creatures that something has started making a noise, or something frightening is happening.

All in all, there are thousands of lines of my own code sitting underneath this simple cable car class (not to mention all the Unity code that renders the white box on the screen). But mercifully, all the cable car code itself needs to do is notice that someone has climbed inside it, wait for a moment, and start shutting the door. Once the door is shut, it waits a moment longer, and then starts moving towards the other side of the hill. As it moves, it has to update the lengths of the two lines that make up the cable, then stop at the other end and open the other door, and that’s about it. Oh, except that it needs to accelerate gently up to speed and slow down at the other end, or else the car will lurch around way too much, and it needs to emit various sound effects at different points, supply various signals to its occupants (so that they can enjoy or be frightened by the experience), and supply other visual and auditory signals to anybody nearby, so that they will perhaps prick up their ears and pay attention. Oh, and I still need to add some buttons that we can use to call the car towards us if it’s over on the far side when we get there.

So anyway, what I’m saying is, I’ve successfully made a little white box slide across a gap! Woohoo! And it only took me two days!!! 🙂

Hopefully, the other six tasks on my To Do list will go quicker.

Bigger version of my visually stunning ‘featured image’ here, for Mabus.