WEEK 8 - 9 - PORTING TO UNREAL ENGINE 4, BLUEPRINTS

With the exciting release of Unreal Engine 4, I've spent the last two weeks making over what I've done with my crane game so far in UDK in Unreal Engine 4. In that time, I've surprisingly accomplished much more than I've gotten done all semester, and the project is starting to take form as a game!

Since this is such a short project, I've needed to allocate my time wisely towards the features that actually make the game a crane game. Until now, I've spent a lot of time on figuring out things in order and getting stuck on seemingly large problems that are actually menial in the large scheme. A strategy I've been trying to go with is hopping around a bit more and getting the less important things to a good enough level to call complete, leaving more time to focus on the highest priority features.

Although I enjoyed learning UnrealScript and programming, there was a lot of initial work to set up the coding environment and understand all of the functions, how to use them, which classes to extend, how to communicate between the classes, etcetera. The node-based visual programming system that the new engine offers, called Blueprints, is much easier to understand, get running, and test/debug (you are able to compile the graphs in engine). The architecture makes it easy to search for nodes contextually, create and access variables between classes, and reference objects that are created in engine. Essentially, it's an amped up Kismet that works with classes and not just the level's events. Overall, it makes a one semester game a bit more manageable. 

I've had a lot of success working with Blueprints so far. I remade the bounding box function to dynamically take in a bounding box mesh, get the bounding box min and max coordinates for the X and Y axes, and set the limits of the player movement to not exceed these coordinates. This was much easier to do with Blueprints than it was with UnrealScript, because it was much easier to pass the coordinate variables between the classes.

I've implemented the idea I was trying to figure out with UnrealScript, which is to constrain the claw to the mover box using a physics gun/physics handle. The content examples provided with Unreal Engine 4 are an excellent resource, so my Blueprint is just a modified version of the physics gun that the character uses in the Physics content example. At the beginning of the level, I set a timer to immediately perform a function that traces for and grabs the claw.

Key bindings are much more easily modified and set in engine as well. Previously, bindings were set by altering the DefaultInput ini file. Now there are input nodes that let you connect them to what happens when they are triggered or released. I've bound the raising and dropping of the claw to the scroll wheel of the mouse. 

Update physics handle is a function that updates the location of the physics handle every tick, and also whenever the mouse wheel is scrolled up, down, or released.

The drop and raise are essentially just changing the Z coordinate of the physics handle's location, but keeping it in sync and updated every tick with the XY movement of the mover box. The location of the physics handle is calculated first every tick, and then the drop and raise functions are performed afterwards and overwrite the Z coordinate of the physics handle. 

The camera is currently working almost completely to my liking - invert horizontal movement and look at rotation. Initially, I had tried to make the Camera component within the Character blueprint, but I realized that if I did this, the camera would always be attached at an offset distance to the player. So, I removed all Camera components from the character Blueprint and made the Camera in a Blueprint of its own and dragged it into the level. Then, I set the view target to the Camera component within my Camera Blueprint upon Event Begin Play.

Setting the default camera to the Camera component in my CGCamera Blueprint.

Construction of the camera - the world location is set to the vector variable I created, so that the initial location can easily be adjusted and not hard coded.

Updating the Camera's rotation every Tick to a combination of the Yaw from the look at player rotator and the Yaw and Roll from a predefined variable.

The camera look at rotation is updated every Tick. It takes the current location of the Camera and the current location of the player, and calculates the rotator needed to aim the start object at the end object (the Find Look at Rotation node.) I found this node by looking at Unreal Engine's Blueprint Content Example of a spotlight that follows the player. I then set the rotation of the camera to a rotator that combines the Yaw from the look at rotation with the initial rotation variable I set to have a defined, unchanging Pitch and Roll value. (The Pitch is always set to aim downward at a predefined angle that does not move, and Roll is always 0.)

Inverse movement of the camera - adds a step amount to move right every time the player movement input is < 0 (left), and adds a negative step amount to move left every time the player movement input is > 0.

The inverse movement of the Camera is calculated in the Character Blueprint, because it was the only way I found to update the location when the player had an axis input (MoveRight, MoveForward.) Using these within a class references itself, and was checking for input to the Camera when it was in the Camera Blueprint instead of the player.

This graph checks upon MoveRight input if the player is moving right or left ( > 0 or < 0 ). If moving left (< 0), it adds a step predefined in a variable to the Y axis, making the camera go right. If moving right (> 0) it adds a negated version of the step to the Y axis, making the camera go left.

The string/cable between the mover box and the claw was made easier by UE4's new Cable Actor, which fills exactly the role I needed. The cable is merely a detail between the mover box and the claw, which are attached to each other using a physics handle. The Cable Actor allows an attachment to an object (the mover box) and an end location (updates with the movement of the claw). It also enables setting the width of the cable, the material, the length, and more parameters.

The Cable Component is added in the Construction Script for CGCharacter so that it is created once on the construction of the class, and various parameters are initialized here. I added the cable component to the claw, so that its end is attached consistently relative to the location of the claw. I couldn't get the cable width to be quite small enough for my needs, so I set the material to a custom material that pushes the normals in, making it appear thinner.

This is the graph showing the end location of the cable updating every Tick. It is consistently offset by the Cable Offset in my case, since the pivot of the mover box I am attaching it to is at the top of the mesh, and I need the cable end to be pinned at the bottom of the mesh.

I created a carpet texture using SVGs in Substance Designer. I could have just as easily done this in Photoshop, but doing this all in Substance Designer allowed me to hook it up to a tile generator node, and tile my design randomly a few times, then overlay a finer noise for the carpet texture, all while still being able to easily modify the shapes, sizes, and colors I chose. My goal was to make an appropriately cheesy carpet pattern, reminiscent of arcades and bowling alleys. In a bit more time I might add some popcorn kernels and crumbs embedded into the carpet, as well as subtle hints of soda stains. For now, it sets the mood to my liking.

Arcade carpet texture diffuse.

The reference photo I took and based my carpet design off of.

I've been working with Allegorithmic's newly released Substance Painter for texturing some assets. UE4 and other engines are beginning to move towards physically based shaders. The maps I primarily need to create for assets are color, specular, normal, height, and roughness. Substance Painter allows for painting and previewing these channels real-time on a 3D mesh. 

So far, I've retopologized, UVed, baked normal maps for, and started to paint Mr. Snuggle Wuggle using Substance Painter. I am a bit behind on making prizes to populate the machine, but that's not a huge concern. One soft body prize will be good enough to use in testing my claw grab.

The initial high-poly, sculpted Snuggle. Some 600k polygons.

Low-poly Snuggle. Retopologized using 3D Coat.

UV maps, unwrapped using 3D Coat.

Still a lot more dirt and sadness to paint here, but just a preview of what I've been working on. I've been painting on the high poly version, since Substance Painter projects what you've painted to the lower poly mesh when you load it in.

 I've designed a simpler claw to save myself the headache of getting too carried away with figuring out a properly functioning, realistic mechanism before I can figure out how to get it moving around and grabbing. A simplified claw style also works a bit better with the more fun aesthetic I want to get out of this project.

The new claw design. After getting my test claw model and rig set up as a functioning Physics Asset in UE4, I decided to remodel it higher poly, with a revised scale for the new engine. 

This is my first time working with physically based shaders. The metal for the claw is basically a chrome - metallic, high specular, and low roughness. I painted the roughness map using Substance Painter to get smudges and little dings, scratches, and scuffs in the metal. They aren't highly noticeable from a distance because I didn't want it to be too prominent. Keeping the claw very reflective seems to give it a good 90's arcade feel. 

I also added in welding detail on the hinge extensions as a normal map -- a subtle detail, but all that matters is that I know it's there.

I have very little experience rigging, but this is my simple claw rig. Basically there is a joint at the very top of the claw, a center "null" joint (not weighted to anything, just an intersection), which branches into the joints that control the rotation of the three claw fingers (a, b, c.) 

The base is all one mesh, and each of the claws are one mesh, but for rigging I Mesh > Combined them all into one. I soft bound the joints to the mesh, but since it's mechanical, I paint weighted each part 100% to its respective joint, and 0% to everything else. This ensures there's no weird, organic bending happening. In order to help me select the individual mechanical parts for paint weighting, I selected the UVs on the UV layout, converted the selection to vertices, and flooded the value of those vertices with the paint weight value I needed.

The base is all one mesh, and each of the claws are one mesh, but for rigging I Mesh > Combined them all into one. I soft bound the joints to the mesh, but since it's mechanical, I paint weighted each part 100% to its respective joint, and 0% to everything else. This ensures there's no weird, organic bending happening. In order to help me select the individual mechanical parts for paint weighting, I selected the UVs on the UV layout, converted the selection to vertices, and flooded the value of those vertices with the paint weight value I needed.

 

 

I then exported this rig and its mesh as an FBX, and imported it to UE4 as a Skeletal Mesh. I created a Physics Asset of the Skeletal Mesh. The new PhAT editor in UE4 is much more intuitive to use, though it was nice to have the background of working with it in UDK. I set up the claw rig with bodies in UE4's PhAT Editor. I essentially needed each claw to be constrained like a hinge, swinging only on one axis. 

I then exported this rig and its mesh as an FBX, and imported it to UE4 as a Skeletal Mesh. I created a Physics Asset of the Skeletal Mesh. The new PhAT editor in UE4 is much more intuitive to use, though it was nice to have the background of working with it in UDK. I set up the claw rig with bodies in UE4's PhAT Editor. I essentially needed each claw to be constrained like a hinge, swinging only on one axis. 

The overall look of the game has come a long way in the past week or two, and I'm pleased that it's starting to resemble my initial concept art. This is still a WIP and by no means final. There's lot more fixing and tweaking to do with the textures, shaders, and lighting. I'm still figuring out how to get the glass material set up to reflect the scene. I'd like for the glass material to have plenty of fingerprints and reflections of neon lights in the arcade. I also plan to have arcade machines to the left and right of it, with flickering light changes on the screens. At this point, I might keep the crane machine up against the wall, but I plan to come up with something visually interesting - either a fun wallpaper or posters, or both.

The approach I want to take for grabbing with the claws is to import animations for each of the claws that would move it in to its fullest extent, and combine that with a physics blend, so that the claw animation is stopped by physics forces when colliding with another object. This is the next hurdle I'll be focusing on in the coming weeks, which is why you see the claws not yet properly functioning in the picture. 

Video to come shortly!

Week 5-7: HIGH PRIORITY ASSETS, PHYSICS, GAMEPLAY MECHANISMS

ASSETS

I've modeled the high poly version of the crane game exterior, UV mapped the low poly, baked down the normal maps to the low poly, and began to texture it based on my reference photos.

I sculpted two of the stuffed animals I've designed. I started completely in ZBrush from ZSpheres to create the base armatures. I decided to begin these by sculpting, as it helps to achieve subtlety and a more organic, plush feel. I'll be retopologizing these, UVing, rigging, and texturing them to be put in engine and testing soft body physics with. The sculpt will be used to bake the large detail normal map. I'll also be creating a finer procedural normal map for the cloth material, as well as combining procedural textures and hand painting for the diffuse.

MR. SNUGGLE WUGGLE

BUBBA BLUB BLUB

GAMEPLAY (UNREALSCRIPT AND PHYSICS)

Here are some simple mechanisms I've been testing out with UnrealScript. I have been working mostly with placeholder meshes and cubes for the time being, just to get the principles down.

RECOGNIZING IF THE PRIZE IS IN THE CLAW'S GRIP

The claw spawns an invisible box mesh that surrounds it at level start. This box is hard attached to the claw and moves with it. Whenever a prize is inside this box, checked by a Touch event every tick, a timer starts. If the prize leaves the box, the timer is cleared. Once this timer is running, I can check to  see when the timer hits a certain time and initiate functions at that time. For instance, I might want a prize's specialBehavior() function to run whenever the prize has been grabbed by the claw for a certain amount of time. After being held for 5 seconds, Mr. Snuggle Wuggle might just start falling apart.

BOUNDING BOX

I need to dynamically determine the bounds in the X and Y coordinates that the Pawn is allowed to move. The claw needs to only be able to move to the extent of the walls of the crane game machine, with some padding. However, I didn't want to hard code the constraint to specific coordinates. I want to be able to get the bounding box coordinates of a mesh and set the min and max values for the X and Y coordinates to the min and max X and Y values of the bounding box.

Since I would like to be able to choose which actor the bounding box is based on an instance placed in the level in engine, I made a custom Kismet node which takes in an Actor input. Here is the basic structure of my class for setting up the Kismet node with a basic in, out, and input variable.

class SeqAct_BoundingBox extends SequenceAction;

var() Actor ABox;  // ABox is a global Actor variable that stores the input taken in by the Kismet node. 
                               //The () following var signify that it can take in an input in Kismet. My Kismet node is an Action.

defaultproperties
{
ObjName="SeqAct_BoundingBox"
ObjCategory="CraneGame Actions"

InputLinks(0) = (LinkDesc = "In")
OutputLinks(0) = (LinkDesc = "Out")

VariableLinks(0) = (Expected class'SeqVar_Actor', bWriteable = false, LinkDesc   = "ABox", PropertyName=ABox)
}

When activated, I get the bounding box of the input Actor and store it to a local Box variable called BBox.

function Activated()
{
local Box BBox;
ABox.GetComponentsBoundingBox(BBox);
}

I then need to pass the Bounding Box coordinates stored in Box BBox to the Pawn class, where I can check if the Pawn's coordinates are within the bounding box coordinates. I had a ton of trouble accessing other classes, like my custom Pawn class. In the Kismet node, I found that I was able to use this function to get the active Pawn from the local player controller. 

local CGPawn CGP;
CGP = CGPawn(GetWorldInfo().GetALocalPlayerController().Pawn);

I made a function in my Pawn class that takes in a Box variable. Inside that function, it stores the information of the coordinates in Box BBox to a variable that is global within the Pawn class. The function in the Pawn class is called P_BBox (for Pawn BBox).


var Box P_ClawBounds;  //global variable at the top of class, for Pawn Claw Bounds


function P_BBox(Box BBox)
{
P_ClawBounds = BBox;
}

In the custom Kismet node under the Activated() function, I finally call the function I made in the Pawn class to pass the Box BBox variable over. 

CGP.P_BBox(BBox);

In the Pawn class, every tick, I check to see if the Location of the pawn is >= the max X and Y coordinates and <= the min X and Y coordinates. If it is below or above the min and max coordinates, I set the pawn location back to the min or max. I grab the Min and Max float values from the P_ClawBounds variable that stored the bounding box information from the Kismet node. I set up a temp vector variable called tmpLoc, which is set = to the Pawn's location at the time the tick function is called. I use the tmpLoc then to perform calculations on for the duration of the function, and then at the end I use SetLocation(tmpLoc) to set the location of the Pawn to the updated tmpLoc. 

simulated function Tick(float DeltaTime)
{
local vector tmpLoc;
local float Max_X;
local float Min_X;
local float Max_Y;
local float Min_Y;

super.Tick(DeltaTime);

Max_X = P_ClawBounds.Max.X;
Min_X = P_ClawBounds.Min.X;
Max_Y = P_ClawBounds.Max.Y;
Min_Y = P_ClawBounds.Min.Y;

tmpLoc = Location;

if(tmpLoc.X >= Max_X)
{
tmpLoc.X = Max_X;
}

if(tmpLoc.Y <= Max_Y)
{
tmpLoc.Y = Max_Y;
}

if(tmpLoc.X <= Min_X)
{
tmpLoc.X = Min_X;
}
if(tmpLoc.Y <= Min_Y)
{
tmpLoc.Y = Min_Y;
}

SetLocation(tmpLoc);

}

RAISING AND DROPPING THE CLAW / PHYSICS GUN CONSTRAINT

A major part of making this game is to create realistic physics driven movement. I've determined that the Pawn mesh should actually be, what I'll refer to as (bare with my little knowledge of real life mechanics), the sliding mover box at the top of the machine. This is where the movement of the crane originates from. There is a string that feeds into this box that holds the claw up, and can be dropped down to drop the claw down. 

I've been doing a lot of testing with all of the different physics features in UDK that I knew nothing about before this project.  I've thought through several possibilities for how to make the claw attached onto the string which is attached to the mover box, and how to make the string lengthen and drop down. Here are the conclusions I came to.

The claw mesh is a rigged SkeletalMesh with a PhysicsAsset. Each separate, individually moving mechanical piece of the claw is vertex weighted to its own bone. The PhysicsAsset sets up the correct constraints between the bones (i.e. hinge) and allows physical impulses to be enacted on it. Controlling the grabbing of the claw with this rather than a baked matinee animation will allow for the physical interaction between the collision of the prize and the claw grabber, so the grabbers stop when they collide with a prize. 

This all sounds good in theory, and I believe it's what I need to make happen, but experimenting with this stuff has been extremely frustrating, to say the least. Here's dismal picture of my progress, a broken claw with improperly functioning constraints lying on the cold, hard ground of the UnrealPhAT Editor. 

 

We'll see what happens as I keep working with this. If necessary, a simpler claw model may be in the works so that things have less interdependence and chance of breaking. 


The claw PhysicsAsset is then attached to a rigid body SkeletalMesh string with a PhysicsAsset instance (since soft bodies cannot hold up meshes), modeled to the length of the longest it will need to drop. This string is then fed up through the box and the top of the machine, which will be hidden to the player and so it won't matter if it clips through the top of the machine. This string would be pinned straight by surrounding collision boxes until the point where it originates from the bottom of the mover box - that way the swing pivot is at the bottom of the mover box.  The string's X and Y coordinates would be locked with that of the mover box, but not the Z. The string drop, and the drop of the claw by proxy, will be controlled by a variable that determines the current Z coordinate. This variable would be clamped at the max and min height position - so that the claw can go no further up than the mover box and no further down than to the platform the stuffed animals are on. This variable would be modified by a key binding (initiated to start dropping by a key press, and an automatic raise after a designated wait time (2 seconds or so) that allows for grabbing prizes at the extent of the drop. 

The downside of this method is that the string would be stiffer looking, since it is a rigid body. The string may bend more angularly at joints as it swings. The string would clip through the top of the machine, which isn't a huge deal but it's a bit of a drawback if I want to zoom out from the machine at any time. Finally, it might give less control to have a three layer dependency between the mover box, the string, and the claw. Each would be based on the physics driven movement of it's parent, which could cause inaccuracies and glitches.

The second method is a bit of a workaround but may prove to be more reliable and give more control. The mover box, as the Pawn, has an invisible Physics Gun "weapon" that is always aimed downwards 90 degrees. This Physics Gun would be constantly firing, and traces to a specifically designated actor (the top bone of the claw.) This way, the movement of the claw is bound to the movement of the mover box, which is player controlled. The string is a soft body that is attached as a detail between the two at its two end joints. It is modeled to its shortest length and, because it's a soft body, will stretch to the extent that the claw is dropped.

I have been working with this method the most, and have got it mostly working. The things I'm figuring out right now are how to make the weapon constantly fire, and how to trace to one specific actor to ensure that the claw is the only mesh that is picked up by the mover box. The advantage of this method is again, the direct link between the mover box and the claw, removing the room for error of the string. Already implemented with the Physics Gun is the sway and interpolation of the object that is being grabbed. Additionally, I've found a modified version of the Physics Gun code that allows for a Push and Pull function that changes the hold distance between the Pawn and the object grabbed, which is essentially the claw drop. It can be bound to the scroll wheel of a mouse, which may be a more fun and interactive way for the player to handle claw drop (using the claw more like a wrecking ball than a static, timed drop.)

WEEK 4: PROGRAMMING CAMERA/PLAYERCONTROLLER AND PRIZE CONCEPT ART

This week I focused on hammering out how to constrain the movement of my Pawn and continued developing the camera. I also worked on prize concept art!

UNREALSCRIPT

My game type is currently extended from UTGame. I had originally extended from UDKGame, but found that my camera was most closely based on a third person camera that pivots around the Pawn (the claw.) The built in SetBehindView in UTGame is helpful for getting a third person camera working in this way. I need to remove the default HUD from UTGame, but I don’t see this as posing too huge of an issue.

My camera is based loosely on this third person camera code. The camera height and offset from the location of the player are global variables with values editable in the defaultproperties of the Pawn class. The CalcCamera() function uses these to calculate the position and rotation of the camera relative to the player.

In my version of this camera, I’ve frozen the rotation of the Pawn, but not the Player Controller, and so the camera moves based on mouse input but the Pawn mesh never turns. In the UpdateRotation() function, After getting the rotation from the mouse input and feeding it into the ProcessViewRotation() function, I clamp the resulting Yaw rotation value. This is because I don’t want to have a full view around the crane game machine – just enough to pivot and give the feeling of peeking inside the machine left and right.

My code right now allows the camera to move in location in the X and Y axes along with the claw Pawn, which is something I need to fix. This makes the camera much too active for my taste. I would prefer it to be very subtle, and for the rotation of the camera to correspond to the X movement of the crane.

I was able to constrain the movement of my claw in the X and Y axes in the PlayerController class in the tick() function. A tick is one frame, so whatever is inside the body of the function is calculated each frame. I simply grabbed the location of the Player to a tempLocation vector (X,Y,Z). I then used an if statement to check if the location in each axis was above or below my max or min values. If it was, I set the tempLocation equal to the min or max value. Then, I called SetLocation(tempLocation) to write the tempLocation to the location of the player.

I attempted to do the same on Z axis, but just set tempLocation.Z to one value, like 100, so the player would stay afloat at 100 units in height. The problem with this was that the built in gravity kept taking effect. I figured out that the best option would be to set the Pawn’s physics to PHYS_Flying. This can be done in the default properties by simply saying Physics = PHYS_Flying, or even changing it from a dropdown in editor in the properties of the Player Start. Even setting the physics to flying didn’t seem to work though – my player kept falling.

After a lot of fooling around, I ended up calling the SetTimer() function in the PostBeginPlay() function of the PlayerController, essentially causing a delay and allowing the PHYS_Flying to be calculated before the player is initialized.

CONCEPT ART

I’ve designed several prizes that are going to populate the machine. Although it’s not a priority to outline every single prize, I found designing them to be a good reminder of the tone of my game. Some of these are cameos from other works I’ve done, others are new ones designed while referencing cheesy and overly sweet stuffed animals from my reference photos.

I’ve found the prizes have helped me come up with some ideas for added functionality I might want in the game. If each prize could have an individualized behavior, there would be a lot of potential for very humorous surprises with each prize you pick up. For example, the sad teddy part might fall apart in a variety of morbid ways whenever it is touched, making it impossible to save. The bubble gum fish might be extremely sticky — and hard to get off of your claw when you want to drop it. And the toilet paper – maybe you need to pick it up in the right way – over or under? By time you get it right you may have unraveled the entire roll.