BGP Week 1 – the adventure begins

So, here we are, finally. The last course of my studies at GAME, “Big Game Project”, or BGP for short; during which me and 4 other aspiring game designers, artists and programmers, spend 7 weeks to develop a “vertical slice” of a game that could eventually turn into a complete, sellable product.

One week has passed since our concept, currently called “Exploring Wind”, got greenlit, and we started producing. We decided early on that we wanted to *start off* by crunching, getting all the features in as quickly as we could, leaving as much time as possible to polish. Since most of us are artists to begin with, we also wanted to focus a lot on the feeling/look of the game, and keep the mechanics rather “simple”, again making sure that we could polish that instead of being overwhelmed by overscoping.

My role in this team is a mix between Technical artist, VFX artist (particles) and Character artist, as well as lead designer. This puts me in a place where I’m in charge of creating the character (modeling, uv/texture, rig and animating), programming the characters movements and powers, and doing all the feedback/particles for both the character and the world.

This first week, I focused on getting the first iterations of the base mechanics in place. You can read more about them in our GDD (WIP) right here.

In this post, I’ll be focusing on the Gust-mechanic, and how I simulate a wind current to interact with objects such as fans.

So, the Gust-mechanic is used within our game to interact with objects by blowing or sucking air in front of the character. Now, like with most things within game development, and especially within game programming, there isn’t really a way to actually simulate wind in an efficient manner; everything is faked. So to start off, I defined for myself what aspects of the wind were relevant and important to incorporate. I concluded that the primary things I needed were:

• Checking for collisions within a certain radius and length in the direction that the character was pointing.
• Give the wind a bit of “slack”, so that the collision check don’t follow the rotation and movement of the character instantly, and seem stiff. Air is a fluid, and should act as such.
• Tell the objects that are hit by the wind (collide with the collision check) the strength and angle of the wind, as well as whether the player is blowing or sucking.

I decided that, since we want the player to be able to aim and curve the wind, we needed a very distinguishable look for the wind and decided to use a mesh with a refractive material applied to it. I started by using a feature in Unreal called “Spline Mesh” (read more about it here). It allows you to stretch and distort any given mesh, along a spline. It also allows you to change the length and curvature of the spline, and in effect the mesh, dynamically in real time. By changing the tangents of the curve according to the direction and strength of the right thumbstick of the controller, I was able to make the “wind” curve, in any direction that the player wanted (but still point forwards).

This was all fine and dandy, but so far I had only created the visual look for the wind, and it had no mechanical value. I needed to check if objects intersected with the stream of air, and in that case tell that object to react to it. I figured that the best way to check for collision along a distance was to use a trace. A trace basically sends out a ray from one point to another, and checks if it collides with anything. This would work, but has the disadvantage of being, well, infinitely thin, meaning that objects would have to be all the way to the center of the wind before it would be noticed. Instead I used a nifty little variant of this that Unreal offers, called “sphere trace”. Instead of just sending out a ray, it sends out a collision sphere, with any given radius. This meant, that objects would be “noticed” by the wind, even if if was only intersecting with it slightly.

Tracing in one straight direction is easy, tracing along a spline however (since it’s curved), proved to be a little more challenging. The principle of checking something along a curve is rather simple; you simply pick points along that curve, and trace straight between these, one after the other. The problem, as it turned out, was that Epic had left out a very significant function; picking points along the spline of the spline mesh. This meant that I had to take another way around.

My first idea, was to use another similar component that Unreal offers, namely a “spline component”. This is similar to the spline mesh (as you might be able to tell from the name), but has no mesh, and is able to have more than 2 points (spline meshes only have a start and end point). I knew since before, that there were functions to get world positions along this spline, and so I figured I would tell the new spline component to simple have the same points and tangents as the spline mesh, and then get the points from that. Here, I hit the next, somewhat annoying, obstacle. You see, splines on the other hand, lack the ability to set the tangents dynamically, in the way that the spline mesh does. You are able to set positions dynamically, but not the tangents. I was in quite the deadlock here, as both the spline and spline mesh both lacked one of their own vital feature, preventing me from combining them like I wanted.

After a lot of pondering, going slightly insane trying to figure out a solution to my conundrum, I concluded that I had to do this calculation myself. I realized that the curvature of the spline mesh was obviously based on some sort of curve interpolation, so all I had to do was to figure out which kind they used, and then do the same interpolation myself, based on the information I had (position and tangents), and eventually get the points I wanted.

This turned into a somewhat tedious process of trial and error, testing different curve interpolation algorithms, until I found the correct one. It turned out that it was one called Hermite Curve, you can read about it here. I created a function according to the algorithm, taking the positions and the tangents, and returning a world position at any point along the curve ( from t(0) to t(1) ). Finally I was able to do my trace, and I was done.

Initially this was added as a component in the character pawn itself, but this resulted in it being hard attached to the characters rotation, and disabled the “fluid” draggy look I wanted. Instead I created a new Blueprint, with only the Gusts Spline Mesh and the trace functionality, and spawned it at run time. This enabled me to tell it to linearly interpolate to the desired locations, instead of instantly popping to it like before.

Conclusion; modern engines like Unreal offer many ways to get different kinds of information, and a lot of useful functions to do what you want, but sometimes, you have to get your hands dirty, and do things yourself. If you are unable to calculate things yourself, you are quite locked, and at the mercy of whatever functionality the engine offers. I should probably do some reading up on three dimensional math….

Until next time, let’s soar! // Sky OuO