One of my projects from last year tasked me with creating a first person game in Unreal Engine’s node-based Blueprint. I decided to create a game set in space, where the player must navigate the environment by pulling themselves onto objects using a tether gun.
The finished product
With this in mind, I tackled movement of objects and the player by using vector maths and linear interpolation (lerp). I then plugged all this information into the Set Actor Location Node. To stop the boxes dropping like a lead balloon, I turned off physics (more on this later!).
That lovely tick box “Sweep”, located on the Set Actor Location node, was an answer to a big problem: “how do I make an object understand that it’s hit something, and that it needs to bounce away from it?”. Due to the actors moving on a timeline, I needed to find a way to stop it by recognising a collision event. I also needed a trigger for the bounce away from the said collision location. In the way that I had already set for this to work, all I would need to do is use the same maths that I created for the tether on the player, but just do it in reverse. Job’s a goodun!
The boxes bounces off the wall. “Sweep” has saved my bacon.
Doing it this way meant that I had to do various checks and balances on each object that interacted with another. For example, the initial bounce of the tether projectile should be different to the bounce from the player. The previous movement timeline needed to be stopped too, again increasing the amount of checks and states that each interaction needed to enter. Although it all started to get quite complex, I thought I had everything I needed at this point.
So, I tested it, realising there was more.
I had the boxes moving on a rotating movement component, so, what would happen if they rotate through a wall?
You guessed it! It passes right through due to the lack of sweep!
I tried repeating the same steps with a Rotation Node, adding sweep in the process. You would think that would work, right? Well, it doesn’t! Even though there is a tick box for it (as it can be seen above). There is a support ticket here for this exact issue.
I tried everything in regards to this setup and I could not get it to work. I eventually decided to remove boxes from inside the space station and disable the tether once the player entered that space – an attempt at a work around. I had the boxes bouncing off each other, so I thought perhaps for an early version of this demo, players would not see this glaring omission. I had thoughts on how to fix this, but with the current time frame, I didn’t have time to do it.
So, as unhappy as I was with the final state, I submitted it as it was.
I returned to the project over summer and practically started from scratch. I wanted to try some other approaches to the problems I was facing.
I knew that simulating physics could be a way to get the desired effect, so I deleted all of the Blueprints in their current state, and started by switching physics on and gravity off. I placed a physics material on them too; this was to add an element of realism to each and to control how I wanted them to move in relation to any forces applied.
I used the same maths that I used in the first version, but plugged it all into the Add Impulse node instead. For the push, I left it as a positive, and the pull I flipped it to a negative.
And everything just worked, straight off the bat… Collision worked on rotation beautifully.
It could’ve been so simple!
On reflection, I found it highly amusing that by making one small decision, I pushed a project in such a direction that it couldn’t be rectified later on. I feel that I had licence to make this mistake for now, being a student and new to Unreal, but I know for the future that the approach to challenges should be explored more deeply. Knowing the limits and options of the engine will always be a hurdle – it’s a little like going into a tool box and using a screwdriver as a hammer because it’s the only way you know to get the job done. If you don’t know the hammer exists, then you will always be using the inefficient tool.
There is always a personal silver lining: by creating in two different approaches, there is a lot that can be learnt by doing so. The first version had far more control in terms of the linear direction the player could move in, and if that was a requirement, then perhaps that would’ve been better.
I guess this is a result from always learning!
Sonny Matthews 