I got a bunch of the animations for the enemy (now I’m calling a “patrol bot”) together to handle it’s movement.Then while I was on a role I threw in some basic AI. Essentially what the robot does is:
Looks for player (not implemented)
Runs towards the player
Starts shooting
Moves around to random points in a circle around the player (Within 20 deg of where it currently is, assuming the player is the center of this movement circle) That white ball is a quick representation of where the robot chose to move next.
Nothing to crazy here, the bigger issue (like most of unreal) is knowing what won’t back you into a corner and force you to undo everything you’ve made. Here I have two custom tasks and one custom decorator. The “PatrolBotShoot” task was originally executing a fire function but I flipped the bot to a simple “if Has target then shoot every 1 seconds” mechanism to allow for firing at any moment. The “PatrolBotStrafe” Selects a random point around the player and keeps the patrol bot focused on the player as it moves around. The “PatrolBotKeepFacingTarget” decorator does exactly what it sounds like.
The animations are still the hardest part of all of game dev in my opinion:
The sequence below took five individually made animations (The strafing still looks too timid to me) and pushed the limits of my patience when dealing with imports to unreal (unreal seems to have weird issues if you import ONLY the animations from a .glx file).
In other news I also started reworking the muzzle flash for weapons but I’m still working the kinks out.
My goal here (if I didn’t say it before) is to swap in the rifle on the back of the robot for different weapons, then I dont have to do any more work on animations and I can just focus on environment art (which I’m sorely lacking experience for) and gameplay.
Woo! Got some animations in game, I made the mistake of thinking that Unreal engine control rigs were actually something useful for what I’m doing. Once I found that out I just gritted my teeth and did the whole animation process in blender and transferred it over into unreal.
These animations will definitely need to be remade at some point but I’ll punt on that until I think I have a level of robot shooting going on.
I tried being clever and pretty much wasted 6 hours….
I spent a bunch of time rigging up this model, a large portion of the time was spent undoing the dumb modifiers I put on the legs. Specifically I used array modifiers and mirror modifiers to generate the legs after making the first one.
Using this technique ensures that when you finally go to export you need to manually re-assign origins somewhere on the model which is something you really need to keep track of when rigging properly.
This all went good but I decided to put the bones 90 degrees offset because I thought it would make it nicer to manipulate. Which I would say is true if I was going to manually manipulate the bones. However, I tried getting smart and moving into unreal engine control rigs: https://dev.epicgames.com/documentation/en-us/unreal-engine/control-rig-in-unreal-engine
Which in theory should let me animate in unreal, which would save me an export/debug step which I normally have to do from blender. However I kept hitting weird issues with setting up controls and having unreal auto-recognize things… Then I noticed the issue once I tried testing the physics asset:
So that isn’t good. Essentially unreal makes a set of simple geometric shapes that it glues onto your model when you import to try to get a good collision box setup. In this case me twisting the bones make the system give up and just surrounded the body with a capsule and legs with one big box:
So I attempted to fix this (which looked good)
…But then I hit the next problem…
What’s going on here is that there’s a parenting loop going on. Looking back at the original model I put the bones 90 degrees offset from the mesh (again because I think I’m smarter than how everyone does stuff).
With the bones offset from the mesh I had to apply the physics geometries to the mesh itself rather than the bone. So then unreal was trying to modify the position of the mesh, but the bone had no constraints to the physics so it tried putting the mesh back, then the physics manipulated the mesh, then the bone manipulated the mesh, then the physics manipulated the mesh, then the bone manipulated the mesh….So that comes out with the result you see above which is everything kind of giving up. The fix here is to re-orient the bones so I can attach the physics geometries to the bone….I basically wasted my morning setting myself up for failure. However this is the first complex mechanical mesh I’ve ever done so it’s still a learning experience in my head.
Remade the robot for the game. This one has some more real world inspiration and is quadruped which I think should make some of the animations easier (easier in concept not really execution).
There’s still some work I might do on the front (there’s that blank space) but I might just stick with this one to rush it in game.
In my head this is a converted cargo type robot, and I wanna keep the same idea where a new magazine shoots out of the back and the robot has to catch it. I keep having this idea that the player should be able to identify this and can shoot the magazine before it gets to the rifle.
Spent some time today setting up and rigging an assault rifle for the game.
It’s still kind blocky but any more effort on this would end up being on details that are un-needed. My main goal with my current modeling streak is to rush a bunch of stuff in game to make a simple fps.
It seems to be looking fine in unreal also.
Now that I have two bonified animated weapons in game (I’m aggressive not doing any reloads, just goldeneye style hide weapon reloads) I can start working the enemy side.
I have some ideas but mostly I’m thinking some kind of drones rushing you and moving in inhuman ways. I have a start here but I think I need to redo the legs/locomotion of this guy.
Maybe not so in execution but definitely in concept. I could take down some of the work I need to do if I just re-use models on the enemies. If I get a good single enemy variant down I can just throw other weapons on top to provide differing variety of enemies.
I made a knife in blender and pulled it into unreal.. Haven’t rigged it up yet but the plan is to get a skeleton on it sometime tomorrow and throw it in the game. Maybe at some point I’ll start making the “game” but right now I’m just living off of this new .gltx high.
There’s probably some huge gotcha with the .gltx that I’m not seeing because this has been some of the easiest imports I ever did.
Even the sizing was easier. Man why did anyone ever make tutorials using .fbx?
This morning I put some more effort into the glock. Added a 3 bone skeleton + 2 quick animations. My goal here was to rush into unreal to get a good feel for things. On that front also I’ve realized I have been making a mistake for the better part of 5ish years. I’ve been exporting as .fbx because I assumed that was an industry standard, but I soon realized from looking at a few blender forum posts: https://devtalk.blender.org/t/fbx-binary-file-format-specification/20814
The reason .fbx is so damn buggy is not because a general “asset pipelines are hard” it’s because the damn thing is a reverse engineered shit show. I always assumed there was no way to get blender materials and shaders into unreal but if you dump everything into a .gltf then EVERYTHING GETS IMPORTED.
Only downside is that your scale factors dont transfer over and 1.0 unit is always going to be 1 inch. But honestly that’s soo much easier than memorizing the settings for unreal (scale: 0.01, units cm if you were wondering).
Now with that I setup the ol’ unreal animation pipeline. This always feels like a chore to me, I should really package up a template for this character pawn and the animation blueprint into a package at some point and maybe distribute it on the store. Maybe I can save a younger dev on going through the same crap that took me a few years to understand. To re-iterate the process
1.) Import all of your animations (INCLUDING AN IDLE OR T_POSE ANIMATION), ideally you would make the model + rig in one file and throw animations in the other. Then upon import click your pre-made skeleton from file A and then only import animations from file B (makes life so much easier).
2.) Make a new animation blueprint, open it, go to the “AnimGraph”. Right click on the grid, type “state machine”, click state machine, drag a line from state machine to the “Output Pose” block.
3.) Double click the state machine to start editing.
4.) Right click, hit “add state” name the state “Idle”
5.) Right click, “add state” name the state, “Fire”
6.) Drag lines from “Idle” to “Fire” and from “fire” to “Idle”
7.) Double click your “Idle” state to open it.
8.) Right click and type the name of your idle animation and the one that says “play animationName” click it. In my case my idle animation was called “glock_idle”
9.) Drag a line from your idle animation to the output pose so it looks something like this:
10.) Now repeat steps 7-9 with your fire animation (use the top bar to back out back to the state machine)
11.) Now add a new variable called “isFiring” to your animation blueprint (make it a boolean) and make sure it’s a public variable (make sure the eye to the right of isFiring is open)
12.) Double Click the symbol above the arrow that points from “idle” to “Fire” (I’ll call this the “Transition Symbol”
13.) Get isfiring and drag it to the “can enter Transition”
14.) Back out to the state machine and click the transition symbol for the arrow that goes from “fire” to “idle”
15.) Make this blueprint (“fire_001” is the name of my animation).
16.) Now go back to your “firing” state, click your firing animation and scroll down to “isLooping” , hit the bind drop down and select “isFiring”. (If your making a fire firing gun you wont see any difference in this step, but for a pistol it will clean up the transitions in and out of the “firing”state”)
17.) Now click “Compile” in the upper left, then at the lower right check “isFiring” and your weapon preview in the upper left should start playing the firing animation. (Make sure you have “edit selected instance” checked when you mess with this. “Edit Defaults” sets what value “isFiring” is when the blueprint starts, you want that to be false.)
17.) (Optional Step) By default the blending mode when transitioning states tries to blend from idle to fire instead of just hard stopping. The default settings should be good for most people, but if your seeing your gun half shoots, then keeps shooting try this out. Go back to your state machine: Single click the top transition symbol, in the “details” tab set duration to 0.0. This should prevent any gross slides from your idle pose to your fire pose.
19.) In your character blueprint class add your weapon as a skeletal mesh to the camera. After adding setup the skeltal mesh to use your imported mesh, and set the animation settings to use your blueprint.
20.) Add this to your event graph.
Where “IA_Shoot” is the name of the enhanced input event that I made and added to the enhanced input objected use for this character
“Gun” is the name of the skeletal mesh that I added to my camera in my character
” Glock_animBP” is the name of my animation blueprint class.
The print string block is for safety, if you see “BAD CAST” pop up on your screen you’ve messed something up.
21.) Go back in game and now when you shoot you’re animation will play:
22.) Now to add sounds+particle effects. Navigate to your fire animation in the content browser and double click it.
23.) There will be a playback line scrolling from left to right on the bottom, find the Time that you want to play a sound, right click on the horizontal bar that starts with “1”, right click > Add notify > play sound
24.) Now click the new sound notify and in the details tab in the upper right corner choose your sound:
25.) Back in the timeline section, next to the #1 on the left click the track dropdown and select “insert notify track”
I really thought it would take me 10 minutes to list out what todo but it took me the better part of an hour.
Anyways as you can see the glock animations seem to be fine (I’m probably just going to do goldeneye style reloads) the sound and the muzzle flash kinda suck so that’s probably the next thing to do.
I decided to forgo the attempts in substance for now and just make a minimal (lazy) textures that can be used in a game quickly if needed.
Geometry is pretty much the same minus the slots on the side and the newly added mag and slide release. Still kinda skinny if you ask me but good enough for majority of uses in my opinion. I’ll probably animate it and get it into unreal over the next week just to tell myself it’s “done” for now.
Still probably the best thing I ever made in blender in my opinion.
I started grey boxing a glock type pistol to put in unreal. It went much smoother than I guessed it would. This was my first time trying to go from zero to 100 with using primarily reference images instead of just throwing things into blender to see what happens.
Now there’s a bunch of things missing, mostly in the controls side but I think I got a base to keep going and properly zone out each region to eventually add animations.
The biggest problems are: 1.) The back grip looks kinda bad and flat. 2.) There are no grip plates on the sides which I’m not a fan of. 3.) There’s no rail up front for mounting flashlights are whatever. 4.) the bottom and top slide don’t fully touch so there’s a small gap:
What’s straight missing is: Slide release, mag release, any text indicating what the gun is, and finally I didn’t make the mag this time around.
I think there’s also some more beveling I can do around the edges of the top slide to get things cleaner and smoother looking. But to be honest starting this surprised me, I didn’t think I had it in me to get a recognizable glock modeled, let alone getting UV’s reasonable enough to pull into substance. Definitely I’ll try to keep on this to get a base weapon into unreal.
Answer: A bunch of number keys and a non-de-script knob
Past week I spent time making a keypad for the doors in one of my previous posts. This guy took some doing: specifically because 1.) I didn’t know that grids in blender existed and 2.) the coloring on the keys made me anxious every-time I tried to make something.
Here’s the greybox:
I had a bunch of iterations here but the three main things were having a keypad, a indication LED and a screen. My hope is to hook this baby up to the doors i made previously to have a quick key code minigame thing in unreal.
By far the hardest part was making not the keypad keys but the plate that would go in between the keys and surround them. One of the biggest things I always try to prevent when using blender is having any issues with normals. Usually it’s hard to come by them if you model in a proper manner (which can be summarized to: always make quad faces.). However, in this case I thought I could use a boolean modifier to make the plate which turned out pretty bad:
You can see here the whole face is messed up however in blender things were looking fine. I don’t have an image for what it looked like but basically it was the keyholes with a subtraction modifier then beveled. Here’s quick demo of what I did:
Now there’s some disconnect because if you pull this into substance (I didn’t do this with the demo) all hell breaks loose and your normals are thrown into a rock tumbler to get that keypad image above.
However I got past it by using the now holy grid:
Which is a bit more painful for inital creation because you have to line it up with your keys but once you do it’s just a quick insert faces, then delete command.
But anyways It seems to look fine in game:
The knob doesn’t have the notches I want, but I can easily make the screen look like it’s on with emissives:
Pretty cool, now I gotta hook it up and import the new doors to start fleshing out this building.