Development Update – Box Acceleration and Split Depth

Box Acceleration

I finally fixed the box acceleration problem. You can now release and re-catch a box during free fall:

Previously, when you let go of a box during free fall, it would just fly up past you.

The reason why this was happening was that in a part of the code, it was setting the velocity and acceleration to 0. So the box wasn’t actually flying past you, it was having its speed drop down to 0, and so it looked like it was flying past you.

I’ve now made it so that when you let go of a box, the player passes on their acceleration and velocity to the box, so the box will continue to fall at the same speed.

Also, the box now has the same acceleration and terminal velocity as the player.

Split Depth Gif

I thought I’d try making one of those split depth gifs with one of the looping gifs:

This took me over an hour to wake – I was painstakingly drawing on each of 140 frames in Photoshop (because I had read online that’s how other ones like this were made).

Of course, as I was about to finish, I realize I could have just easily done this using a shader and a depth texture in Unity.

Basically, the shader would overlay the white bars on the camera, and any geometry whose depth is pass a certain distance, you render it above the white bars.

So yea, this realization made me feel like an idiot.

However, I can now I can create a system that will allow me to produce these gifs easily and with more accuracy.

Mechanics System Overview

I’m at a point now where I have an idea of all the systems in the game and what they are supposed to do, and it’s getting hard to keep track of it in my mind.

I decided to start writing it down, and thought I might as well share it here. That way, I don’t have a bunch of poorly named word documents cluttering my desktop.

Some of these points might seem confusing or unclear. That is because this is really more for me to remember.

Cube (Single Gravity)

-   Is active when player is on its respective gravity
-   Is inactive when player is not on its respective gravity
-   Player can lift it up and place it above things
-   Materials change depending on whether it is active, inactive, or illuminate (when it’s on an appropriate trigger – has active and inactive states)
-   Cube is illuminated when placed on trigger.
-   When cube is removed from trigger, it is no longer illuminated
-   Must fall downwards when player lets go
-   Must fall downwards when player tries to switch onto another wall while carrying object
-   Cube does not rotate
-   Player needs to be able to carry box through portal
o       Utilize phantom box renderer (that moment where the box goes into the portal first before the player
-   Player needs to be able to hold onto box while falling, even when going through the recursive world teleporter
o       Also phantom box renderer (that moment when the box goes through teleporter before player does, it will disappear)
-   When player lets go of box mid-flight, the box should fall at same speed as player
o               When player drops box, just take the velocity and acceleration of the player and apply it to box, so if player is stationary, box starts at 0 velocity. If player is falling, box will then fall alongside player
-   Cube should snap to grid (0.25 units)?
-   Cube should grow from trees
-   Cube + water + soil  = tree
-   When a cube is taken from a tree, the tree grows another cube
-   But when you take that new cube from the tree, the old cube is destroyed
-   Need a way to keep track of which cube is from which tree and if it has been destroyed or not

Development Update – Falling

Working on getting player falling and object falling to feel right.

For player falling, this is the code I’m using:

if (GetComponent<Rigidbody>().velocity.sqrMagnitude < terminalSpeed * terminalSpeed)
gravityVelocityChange += gravity * myNormal * -1 * Time.deltaTime;
GetComponent<Rigidbody>().AddForce(gravityVelocityChange, ForceMode.Acceleration);

As long as the player’s falling speed is less then the terminal speed I’ve set (70), the acceleration will be applied to the player.

ForceMode.Acceleration applies a continuous acceleration to the rigidbody, regardless of mass.

All in all, this feels pretty good. When the player initially jumps off a ledge, the fall speed is slow, and then the player accelerates and picks up speed, until the player is traveling at terminal velocity. More or less what you’d expect.

Now, with boxes, it’d be natural to think that it would just fall at the same speed as the player.

However, the problem for me is that in RELATIVITY, when the player switches to another wall while carrying a box, I need that box to drop and fall all the way to the floor. I do that by having the player drop the box turning the rotation, and not switching off the gravity for the box until the player has completely rotated onto the new surface.

When using ForceMode.Acceleration, it’s a little too slow. I can tweak the gravity value to make it faster.

Or I can switch to using ForceMode.Velocity.

The problem with both these solutions, however, is that if the player is falling while carrying the box, and lets go of the box, then the box will fly away.

In Portal, this doesn’t happen – the box actually falls at the same speed as the player, if you let go of it mid-flight.

The thing is, this isn’t actually game-breaking. The important thing is that the player can carry the box while falling, and this already works. It does bother me though.

Development Update – No EGW or Rezzed

Yesterday I found out RELATIVITY was not selected for the Experimental Gameplay Workshop at GDC.

This morning I got an email saying that RELATIVITY did not get into EGX Rezzed Leftfield.


Not going to lie, I’m pretty disappointed. I had applied for both of these events last year, and I thought I had a pretty good chance this time around considering how much the game has changed and improved.

Oh well, there’s not much that I can do. It’s always disappointing to get rejected for something, but you just have to keep trying.

Like my old high school chemistry teacher used to say: “Somedays you get the elevator, other days you get the shaft.”

Development Update – Level Design Resources

Still very busy with admin and logistical stuff lately. However, I recently came across some really useful level design resources. I shared them on twitter, but thought it would be really helpful to have a list with them altogether. This way, I could just link people directly to this, instead of having to track down each item separately.

Level Design Resources

This is a list of talks, articles, and other resources that I have found to be incredibly helpful in thinking about level design for RELATIVITY. Hope you find it useful as well.

Portal 1 & 2 Developer Commentary - I highly recommend playing through both games with developer commentary on. Lots of useful tidbits like how they god the player to look in certain direction, the reasoning behind the sequence of puzzles, and how each puzzle was iterated on.

30 Flights of Loving Developer Commentary - The developer commentary alone is worth the price of the game. Lots of fantastic information, especially with regards to how architecture is used to guide the player. A hallway is placed a certain way, facing a certain direction, with a certain angle of curvature, in order to guide the player to see a specific thing.

Devs Play – Doom with John Romero - John Romero plays through Doom and comments on the level design in all the levels. Do watch all 10 episodes. Totally worth it. Lots of useful tidbits like avoiding symmetry, using contrast, and utilizing loops effectively. Very fascinating.

Antichamber: Three Years of Hardcore Iteration - Alexander Bruce talks about all the refinement and iteration that went into Antichamber. Really fantastic.

Jon Blow playing through Braid and commenting - Shaky camera, but totally worth it.

Wayfinding and Signing Guidelines for Airport Terminals and Landside - 200+ page PDF explaining wayfinding and signage design at airports. Absolutely incredible resource. A must read for all level designers. Seriously. It’s a gold mine of useful information.

Walk This Way - Podcast interview with professional wayfinder and co-author of above document, Jim Harding.

How To Make An Attractive City - I don’t know how valid this is from an actual urban planning standpoint, but for level design, there’s lots of useful tips, like balancing chaos and order to create variety.

Everything I Learned About Level Design I Learned from Disneyland - I’ve heard from multiple sources that theme park design has lots of valuable lessons to offer level designers. This talk by Scott Rogers covers a lot of that stuff.

Development Update – Triangle, Wrist and Shoulders

Triangle Update

I’ve been quite busy with logistical and administrative side of things these last two days, so haven’t done a lot with respect to development.

One thing I did change is the shape of the triangles on the sides of the cubes. They used to be equilateral, but now it’s an isosceles triangle.

The reason is because I noticed that with equilateral triangle, a lot of playtesters didn’t realize that the triangle was supposed to be pointing in the direction of the cube’s gravity.

Some people thought they were supposed to match the triangle pattern with something.

I think this is because equilateral triangle seems too neutral?

An isosceles triangle seems to be more deliberate, like it’s actually pointing at something. I’ll have to playtest this and see.

I did get rid of the grid pattern on the cube, which I should have done a long time ago.

Wrist and Shoulder

My wrist and right shoulder had been bothering me quite a bit about a week ago. Pretty sure it was because I was spending way too much time in front of the computer.

Anyway, I finally decided to do something about it.

I started doing yoga again on a daily basis (had been doing it quite a bit during the summer, then stopped for a few months because I was traveling so much). By the third day, most of my shoulder pain was gone.

I also ordered a pair of SoftFlex computer gloves. I had seen a few other game devs wear them, and decided to give them a try.

I’ve only just started wearing them, but have definitely noticed improvements. There are cushions on the bottom that really help support the wrist when typing and using a mouth (or in my case a trackball).

I’m also just trying to limit the amount of time I spend in front of the computer in general.

Development Update – Game Feel Improvement: Object Carrying

Object carrying is one aspect of the game that has had some problems for a while. I decided it was finally time to sit down and sort it out.


The object carrying script I’ve been using up until now was written about two years ago when I first started working on the project. I’m calling it the spring method because it uses a spring.

The gist of it is that when you find a box to pick up, i create a spring between the player and the box.

The values I use for the different spring properties are:

strength: 100
dampen: 5

I also set these properties on the rigidbody of the box:

drag: 15
angular drag: 15

(These values aren’t actually that important. Putting it here more for myself to remember, should it be necessary in the future).

There are several things that I really like about the spring method.

1) It feels great 


The feel when carrying the box is really nice. There’s a slight delay between the movement of the box and when you move the camera or the player. While carrying a box, if you move backwards, its distance to you gets stretched a little longer, and when you move forward, the distance gets smaller. There’s also a slight bounce at the end of a movement before it settles in its position. It’s very tactile and really nice.

To be honest, I haven’t seen object carrying done quite like this in other games before.

2) “Natural Physics” effects


You also get really nice “natural physics” effects, like when a box catches on a wall, it’ll get hold up a bit and the distance will stretch, before it bounces back to the player. When you push a box against wall, it’ll have a slight bounce back as well.

3) You can place the box on a ledge very easily


Placing objects on ledges above you is a really important game mechanic. With the spring method, it feels like a very natural, and is easy to do.


1) You can’t fall while carrying an object


Part of the problem here is that the acceleration of the box is different than that of the player, but the spring is still a significant problem. At the values I’ve set it at to make it feel good, the box gets too far away from the player to feel right.

Even if I get the terminal velocity correct, there still is this weird freakish effect that happens when falling:


2) Unpredictable Freakout 

Sometimes this happens. This is what happens when drag is 0. The drag on the box is not 0, but I’ve seen it happen every now and then when you’re walking around with the box. It’s a really hard bug to replicate so I haven’t been able to debug it.


After playing around with different values of spring strength and drag, I decided to get rid of spring and physics altogether.

Instead, I just have the renderer of the box (let’s call it the Phantom Box), with no collider or rigidbody on it, and have it parented to the player.

The position of the Phantom Box is set using raycast.

I had a single raycast coming from the center of the camera straight out a certain distance (what the length of the spring would have been). If the raycast hit a wall, it would get the point it hit the wall at, as well as the surface normal of that wall, and then position the Phantom Box 0.5 units away from the wall, so that it was aligned right up against it.

If felt pretty good, except sometimes the box would go into an adjacent wall:

You can get a better view in this image below:

The issue is that the raycast is only looking at the wall in front, but we have no idea that the wall on side exists, so the box is being drawn into that side wall.

This is no good.


I’m calling this method center raycast method because it uses 6 raycasts, one coming out of each face of the cube, from the center:

Basically, what I do is I send a single raycast forward. I use the end of that raycast (whether it hits a wall or not), as a point from which to draw 6 raycasts (I call these secondary center raycasts).

I use the secondary center raycasts to detect walls and figure out location of cube.

At first it seems movement is good:

I can place the box on a ledge:

BUT, if it’s in the corner, the box can go into the wall:

Since the rays are coming from the center of each face, none of the rays are detecting that adjacent wall, hence the box is drawn over the wall.

No good.


I tried using a SphereCast next. According to the Unity docs, it’s sort of like a “thick raycast”

I was putting the sphereCast sphere inside the box, like this:

At first, it seemed to work quite well. The box was no longer going into the wall:

However, I then found a major problem: it’s almost impossible to get the box on top of a ledge:

I believe this is because of the size of the sphere, it isn’t able to spherecast over the lip of the ledge. Well, this isn’t going to work then.

Also, while we’re being nitpicky, it does dig into the wall a little bit (because of the curvature of the sphere at the edges of the box):


This should probably be called Center + Corner RayCast method. It’s like the center raycast method, but I also raycast from each corner.

So each face actually does 5 raycasts.

So along with the single raycast shot at the beginning to determine where to place the secondary raycasts, I have 31 raycasts:

Here’s a sketch showing the different raycasts from the different faces a little better:

It works really well!

The box doesn’t go into the wall at any point, and it’s also easy to place the box above a ledge!

Oh, and check out what it looks like when you fall while carrying a box this way:

Aw yiss


Now that I’ve laid out my problem with carrying objects, what do you guys think of this the corner raycast solution? Is there a more efficient or better way I could have done it?

If it isn’t too expensive performance-wise, I’ll probably just leave it for now. It doesn’t feel *as good* as the spring method, but it doesn’t have any of the game-breakig bugs that the spring method had. It’s also way more reliable.

Development Update – Game Feel and Motivation

Unity 5

Continuing to work with Unity 5. All in all, I think a lot of the changes that have been made are for better programming reasons.

However, it does take a bit of getting used to if coming from Unity 4.

For example, if you want to access canvas elements (the new UI system), you’ll need to use the namespace:


at the top of your script.

Game Feel


Continuing to work on game feel. I’m now rewriting the carrying object system and the box system.

Terminal velocity of boxes falling is now equal to terminal velocity of player falling, so that’s good.

Once that is done, players should be able to carry boxes while falling, which is a pretty important mechanic.

MotivationI have to admit, I’m having a pretty hard time finding motivation to do this stuff. I think it’s because I already did this about 2 years ago, and I have to read through a lot of old code in doing this. I’ve also gotten so used to working on designs at such a high level that’s it’s kind of annoying to have to come back and deal with basic physics and UI issues.

But such is the game dev life.