Stoppit and Tidyup!

The title of this post is a culturally-obscure reference to a cartoon that I watched as a child in the UK about a furry red ball (Stoppit) and a purple blob shaped like an upside-down bowling pin (Tidyup) and their exploits in the the mystical land of “Do As You’re Told”. This reference is particularly salient because not only has the last couple of weeks been about taking a step back and doing a bunch of clean-up work on my game so far, but also because my big brother was in town visiting from the UK for the first time in 11 years, so I was ripe for a bit of childhood nostalgia.

Anyhow, as someone who is often visited by the squirrel of distraction, I am actually quite proud of myself for not letting my magpie-like attraction to the new and shiny get in the way of late…

Clean-Up Task 1: Layer Boundaries

This is something my husband has been gently prodding me about for a while (and not in a mean way – he really is very nice). If you imagine descending through the Earth’s many layers, you may visualize passing – at various points – distinct boundaries, where you see one rock type above the boundary and one type below. Alas, this was not how things originally were (and to be honest, it wasn’t actually something I had picked up before the husband pointed it out). In my original code, I had a simple set of nested for loops and if statements that checked to see if the elevator was at a transition depth and if it was, switched each segment of the shaft to the next rock type. As a result, every time you went through a boundary, everything suddenly and miraculously stopped being one rock type and instantly metamorphosed into something completely different.

After some deep reflection over a glass of wine and Lindt 90% dark chocolate (yum), I realised that instead of checking whether the elevator depth was above or below the transition depth, I needed to compare the depth of each segment to the transition depth and perform the texture change for each segment individually. This was actually not too challenging in the end, and just required a couple of steps:

1. Calculate the “depth” of each segment relative to the elevator’s “current depth” 

For each segment, This was simply a case of subtracting the y position of the segment from the current depth at each frame (the y-value of the elevator position is always 0)

2. Comparing each segment depth (currentDepthShaft[i]) to the rock transition depth, and switching to the new texture segment-by-segment

This required a rearrangement of the for loops and a simple replacement of currentDepth with currentDepthShafts[i]. I would love to tell you I got this right first time. I did not. Nested for loops can be a bit of a challenge for the grey matter…

But in the end, while still in my bright yellow onesie on a Saturday afternoon (a comically common sight), I triumphed (and there was much rejoicing).

Clean-Up Task 2: Whoa there, horsey – how about some deceleration!

My movement script has always been a bit on the…digital?…side: while you could change the speed, the elevator was either moving at that speed or not moving at all – going at 25 km/s or not moving at all. This made for some abrupt movements that I have wanted to get rid of for a while. I naively thought that adding acceleration and deceleration would be a 10-minute job. It was not, and ended up taking far longer than what I had expected to be the more involved transition problem. But, once again (and still in that glorious onesie), I was once again triumphant (cue the rejoicing). Hard to capture in video, but here’s a code snippet or two for posterity:

Clean-Up Task 3: Stop that Earthquake

As a teacher I quickly learned that students don’t necessarily do things the way you expect (or want) them to. The same is true for players of video games. At best, people like to go rogue and explore; at worst, they actively want to break it. So, when I started to get people into the headset, it should not have come as any surprise to me that they didn’t necessarily want to go to the first level first; sometimes they wanted to go to the core, sometimes where diamonds are made. Unfortunately, if they went off-map, they found themselves experiencing a random earthquake that started as soon as they passed 25 km, and then saw pointless menus pop up while still en route to their selected destination. Well, this just wouldn’t do! But, as with a lot of these things, a few minor tweaks to a single line of code did the trick: instead of triggering the earthquake co-routine only based on depth, I added the additional constraint that elevator should be stationary and voila – players are free to go off piste to their heart’s content (within reason…)

Clean-Up Task 4: Why is that magma crack following me? Arrrrgggggghhhhhhhhhh

The final task in my spring clean was to sort out some unfortunate behaviour that was plaguing my transitions from one level to another. Some level interactivities involve the instantiation of game objects that appear to be part of the shaft – for example, a large magma crack that forms, causing an earthquake.

Unfortunately, because the game is set up a bit upside-down – with a stationary elevator and moving background – the magma crack (because it was stationary like the elevator) appeared to follow the elevator to the next destination, like a malevolent force sent from the depths of hell (it’s really not supposed to be that sort of game). So I really needed it to move with the background. I decided that the simplest way to do this was to make the magma crack’s parent game object a child of one of the shaft segments so it would move along with it. It’s a touch more complicated than that (I had to attach it to the right segment, and get it to reset and destroy game objects before flipping back to the beginning), but that’s the basic idea. In summary:

1. When the elevator is stopped at a given level, the transform of the closest segment to the elevator is set as the “activatedActivePoint”
2. The parent game object to the magma crack (levelObjects) is made into a child of the activatedActivePoint

3. When the activatedActivePoint reaches its max/min depth before flipping, all game objects inside levelObjects are destroyed, levelObjects is removed as child of activatedActivePoint, and activatedActivePoint is reset to null

4. Simples

I am happy to report that despite some earlier bugs that turned out to be random glitches that just required a restart, I was once again triumphant in my clean-up endeavour.

I’m really glad I took the time over the last couple of weeks to knock these tasks off my list and I feel in a much better position to move forward with the fun stuff – level design and development. 

Excited to return to my bellows and mechanical press for my exploration of mantle melting!