I added in rain and some mood lighting. There were also a bunch of other smaller changes but this is where I’m at.

It’s very dark and the rain kinda looks like pills falling so I’ll probably need to do another pass here. I’m happy with the water material I setup here:

Essentially its just a blue matte material with a sphere mask. The sphere mask just tells unreal what to make translucent instead of blue. Going back to my last game post (the one about how compiling materials is horrible). I made a generic rain material instance where I parameterized the rain settings:

Which it’s not crazy impressive but I used to modify the material directly so I’m happy with my personal progress here. I also started making a larger landscape for game and I think I have a better idea of how I want a real level to be shaped.

The rain itself is attached to the character. Which I honestly kinda hate, I could add another ray trace to check if the player is inside, but I’m trying to limit the amount of work I do in the tick functions.

I also moved the whole project up to unreal 5.6 from 5.3

This has a better setup for first person games where it renders the gun ontop of everything else so I don’t need to do as many weird tricks to make the gun not clip through walls.

Example:

Finally I added a zoom with right click:

I’m leaning towards making larger maps so I wanted to add in things to facilitate that. Currently my focus is on making said “Larger Map” which I think might take the majority of my time from the game here. The only thing that might be required to make a map like that work is a vehicle system, which I think shouldn’t be horrible to make as unreal has a bunch of templates for that. The map itself however I can see easily making the game zero fun, so my primary goal is to really just start pumping out levels to see what works.

The borderlands 4 issues with unreal (see: https://www.pcgamer.com/games/fps/borderlands-4s-latest-patch-triggers-a-flurry-of-performance-complaints-but-gearbox-says-new-stuttering-problems-should-resolve-over-time-as-the-shaders-continue-to-compile/ ) made me realize I was doing all of my materials wrong.

Originally the way I pulled in 3d meshes generated a material of each slot in the mesh. So I thougth I was being clever by using material slots to determine colors (so I didn’t have to texture paint), however the issue above made me actual look into things. So I was taking materials for granted as things that were inherent to unreal, however materials themselves are nothing more than giant HLSL files (see https://en.wikipedia.org/wiki/High-Level_Shader_Language). This means that every material I made has to be complied for whatever graphics hardware the user is using (which is the borderlands 4 problem from the article above.) The solution is to use material instances (see https://dev.epicgames.com/documentation/en-us/unreal-engine/creating-and-using-material-instances-in-unreal-engine)! These are parameterized unreal materials which allow for the developer to expose parameters into compiled base materials so we dont have to deal with as much shader compiling.

Sooo from just imports and optimized development had 30-40 plus materials which would come from asset imports, most I could categorize into:

-Painted Metal
-Exposed Metal
-Wood
-Plastic
-Rubber
-Concrete
-Brick
-Glass

So instead of 30-40 compilations for all of the materials I could whiddle things down to 8 compilations to save myself from making the user wait with no colors on their screen. After 30 painstaking minutes I was able to remove all other materials (minus a few specialized ones) to the 8 materials above and instances thereof.

Now things look a little shinier and more visually consistent

The side effect that I wasn’t expecting is that the game is now BLAZING FAST. I went from around 60-70 fps on light load and 40-50 on heavy load on average to pretty much locking to 120fps in light load and 80fps in high load. I had plans to re-write how I handle some of the animation data transferring but I’m thinking now that might not be needed.

I also did some work on the ai so they stayed a bit more mobile. I also added recoil to the bots

Also bots now have a pitch when aiming:

Finally I added in weapon switching via the num keys:

I want to add a half-life style cross selection bar but that will probably happen later with another hud pass.

The gameplay test map has now gone from a placeholder dev map to a low effort source engine map:

The whole level I would argue is pretty bad for gameplay also the only thing I want to add is some rain effects just to get a vibe then I’ll move onto a kind of multi-lane style of map.

Here is the first full(ish) gameplay demo for this game mode (gotta use youtube because of WordPress size limits)

Big things that changed:
I added a bit more to the test gameplay map:

Including a quick fence model:

Also I put lights ontop of all the bots to indicate what team they’re on. Blue=player team, red = enemy team.

I also added hit reactions (animations for when the robot gets shot) to the bots to make things less…robotic:

I also added that red flash. I wanted to do for a while now to get a bit more zelda-y vibes. I also fixed up some problems with the shooting mechanics. Turns out I was making a ray from the center of the screen to the place where the tip of the gun was pointing rather than making a ray from the center of the screen forward, then making a ray from the tip of the gun to that location.

There was also some work done on how bots engage/disengage. I need to do more work there, everything right now is copied in the tick function which is bad. Also the pawn controls everything which is also bad (Controllers are more easily replicated for multiplayer).

Also unreal’s detection of source control stopped working so I gotta do everything manually in git bash. Not the end of the world but still, kinda weird. EX:

I broke something but I’ll punt on this for now. Finally I think I’m going to remove any bot types outside of the gun bot. They’re really unbalanced right now and kinda buggy, I’m thinking I’ll try to diversify the bots based upon different attack types (gun, motor, close range, AOE). I also included unreals crowd avoidance systems (see https://dev.epicgames.com/documentation/en-us/unreal-engine/using-avoidance-with-the-navigation-system-in-unreal-engine) , which all…kinda work?

More polish to do in general though I want to make that test map a city style map to try honing in on what I want the game to look like.

I added in a bunch of stuff but showing off is kind hard right now…

Gotta add in damage multipliers based upon difficulty level.

I closed the “Game Loop” by adding announcements to the hud and creating a “OnGameModeAnnouncement” event that huds can bind to:

The look isn’t ideal but I’m working through it.

In addition when I flipped things to “Standard” game mode (which has pretty much all of the bot types) my fps went from like 60 to 20 very fast. On my machine thats pretty bad. I went through the profiler (https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-insights-in-unreal-engine) and got these results

The top is the important part (lower is better)

The red portion is steadily growing as the game goes on, then once I kill the death box you see it viciously drop to zero because it cleaned up all of the game time actors.

Looking at the timing data you can see that the large majority of the time is done handling the Lazer for the rocketeer, skeletal mesh of the patrol bot, the Tick function and the Hud.

I can immediately get 11.7ms back by just moving the Rocketeer_Laser from cpu to gpu:

With that small fix I went from 19 fps at max events to about 35 fps. However, I should be getting around 100 fps with my computer most of the time if the game (aka. I if I did) isn’t doing something dumb (which it probably is)

• i7 3700k
• ASUS prime z790-p
• 32 gig of DDR5 @ 2400 MHz
• NVIDIA RTX 4090 24Gb of VRAM

The character models seem to be high on the list still, which I expected so I’ll need to remake these bots again. I feel like I should go about this differently this time and try to get some control rig action going, which I feel would be much more optimized and would hit my goal of getting hit reactions in. Also A low poly-ier feel might add to the experience? In addition moving stuff OUT of tick functions might be a smart move, I have things in there that really shouldn’t be and should be pushed to async events. Work for later this week.

Had a few learning experiences with Unreal when working on the global game mode settings stuff (Also I used the term “group ID” in the game but I call it “team ID” randomly so bare with me here and assume they’re the same thing).

1 – Event dispatchers kick off before the game tick (which I really should’ve known from the start).

If you’re interested in what I mean by event dispatchers see (https://dev.epicgames.com/documentation/en-us/unreal-engine/event-dispatchers-in-unreal-engine)
The way I have the transfer from the terminal originally setup was:

1. Player presses transfer button, the transfer completes which triggers an event dispatch call from the terminal
   
   
2. The terminal alerts the assemblers connected that the team has changed
3. The assembler flips the team ID’s of the bots and alerts the game mode via another event dispatch call
   
4. The game mode (which is bound to all team ID change events) receives the event call and then alerts all of the assemblers the last location of the target
   
5. Then all of the assemblers get the direct call to alert their bots to a new target
6. The bots then get the alert for the new target

The problem started at step 3. The way I setup the patrol bots was that they would essentially copy their state from the actor into the control, then into the blackboard (see https://dev.epicgames.com/documentation/en-us/unreal-engine/behavior-tree-in-unreal-engine—quick-start-guide ) every tick (which is horrible and I need to fix. The controller should own the pawn and the pawn should be only relaying sensor-ish info back to the controller). In addition the way team swapping works on the patrol bot is that the bot will end it’s current engagement, then flip its internal team variable. Finally the patrol bot is alerted while its engaged it will NOT change its current target and will continue the engagement.

So the problem with that is that Steps 4-6 would execute before the next tick after step 3. Therefore the bot was alerted BEFORE it stopped its engagement and ignored the new target location. So from the game perspective the bot would stop what it’s doing then start walking to the last player location that was reported by the bots. The reason 4-6 executed is because it was a chain of event dispatches that lead to a function call. If I wasn’t using blueprints I probably would have gotten a segfault, however in this case what happened is that the tick was delayed until the event was finished.

This was fixed by changing how the controller worked so that when you get an event that stops the engagement you flip the value in the blackboard on the same chain that changed the team id. Therefore when the alert comes along the patrol bot is not engaged and the new target location is updated accordingly.

2-The there’s two functions to get a reachable point within a circle on the nav mesh and the one that works changes upon the context:
– Random Reachable Point In Radius – When you’re in an actor
– Random Location In navigable radius – When you’re calling from an AI task

I had the 2nd one swapped for the enemies so the only thing that would get a valid location was something directly on the nav mesh. I didn’t notice until I stopped putting stuff right where I wanted the bots to move to.

OTHER STUFF

Also I added a placeholder for the thing the player needs to destroy called

THE DEATH BOX

Which is just a box with health and a teamid.

This is the thing that gets targeted once the assembler gets its group id changed. There’s some other stuff I poked at, the AI had issues which I touched up. Difficulty gets set and propagated through the game mode down to the assemblers which sets the bot types and quantity.

Generally the bare bones “Game” part is working, I need to make a kill screen but basically we’re looking good. Here’s like 2ish minutes of gameplay (I had music playing from abelton while this was going but it wasn’t captured for some reason, abelton might have winsound trickery happening in the background…or obs isn’t as great as I thought) so its kinda quiet. But things to look out for:
1.) I start, the bots are shooting at me. I press the transfer button, the bots stop shooting at me and start walking towards the death box
2.) I press transfer on the second console and the transfer bar comes up and finishes, which causes nearby bots to stat shooting at the death box.
3.) The bots at the end just stop moving for some reason (Need to fix).

I was also looking at this: https://trello.com/b/dmIooAod/blacklaceworking-board and most of these are gonna be deleted. The woes of working with non-concrete plans..

But in general I would say the main things left for this game mode are to integrate those lazy turrets I made a month or two back and ensure there’s a good death screen. Then from there the majority of the work will be aesthetic and polish (and a new gun or two).