Now that I’ve closed the gameplay loop I realized there’s really nothing pushing the player along. Right now if I just have “go destroy this thing” the gameplay would get stale very fast. To counter this I wanted to make some kinda timer that would force the player to go out and explore/accomplish their mission. I was thinking about adding something more akin to a base that would get destroyed if you did nothing but that would GREATLY increase the amount of work here (This human npcs, animations, sounds etc.). So I started making this guy instead:
The idea is that the robots are trying to destroy the world or something and they have these devices that are slowly going to rise up then come slamming down. The player will be tasked with destroying these devices before the end of the world!
This also give me the opprotunity to break down the game into phases (like “the first slam” the “second slam”, “The final slam”) to have the map change, difficulty ramp up etc.
Or maybe I’ll have a huge lazer come out the bottom of that middle thing?. In other news:
I resurrected a double barreled shotgun I had half finished earlier and I need to get it in game. This is very rudimentary and basically doesn’t make sense design wise. For instance:
That bottom bit is all one piece, so there’s really now way to open the breach. However currently all of my reload animations are just “hide gun” “wait a second” “Show gun” so for now I think I’m good.
Also I was thinking about adding a ps1 art style in this so I started messing with texture warping (which I honestly read zero about before hand so this isn’t great).
Seems like a good way to give people motion sickness…
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.
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).
Player presses transfer button, the transfer completes which triggers an event dispatch call from the terminal
The terminal alerts the assemblers connected that the team has changed
The assembler flips the team ID’s of the bots and alerts the game mode via another event dispatch call
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
Then all of the assemblers get the direct call to alert their bots to a new target
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).
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).
I wanted to spend 30ish minutes making the alert light I talked about last post before work: here’s where I got:
At the end there the direction of the light is all wrong. Probably going to redo 100% of this later today (as it kinda looks bad anyways and a part of me wants the spinner in an animation).
It looks weird, I think its just the colors? And the proportions? And the shape?
In other news I did a bunch of backend work that isn’t pretty to look at: essentially I swapped out all of the old classes and re parented them to a generic “BlackLaceGameMode”:
This lets me make generic functions and I can pass some of the capability from the survival game mode into this new game mode (which I’m calling control).
Also performance seems to take a hit after around 20-30 bots in the world at once:
This isn’t the end of the world here (I can move a bunch of stuff into c++ and memory optimize it if I need to) but I think I shouldn’t be this bad with just a bunch of skeletal meshes. I bet if I started doing some occlusion culling (https://dev.epicgames.com/documentation/en-us/unreal-engine/visibility-and-occlusion-culling-in-unreal-engine) I would be able to get everything up to a very high fps. But I’ll punt performance optimization till after I get a game working. Next up is messing around with the terminal so it actually does something.
I think the sequence I’m thinking the player accomplishes to “hack” the system.
1.) The player clicks “transfer group id”
2.) There is then a password prompt that the player can guess or they can click “forgot password”
3.) Then a bunch of trivia pops up that the player needs to answer
4.) Then a new password is flashed across the screen
5.) The player enters the new password
6.) The player takes over the connected assemblers by pressing a button on the screen.
After #1 I think I want the turrets I made before to pop up out of the assembler and start shooting at the player, along with a bunch of red light spinners:
Another thing I’ve been diligent about is trying to make sure I don’t do anything dumb to preclude multiplayer in this game. I think getting multiplayer shipped is another animal but getting lan or local games working shouldn’t be too bad.
So like nothing is straight up crashing (which is good, also might not be too possible because I’m straight up wearing water wings by using blueprints), but you can see the bots aren’t persisted, the weapon selection isn’t persisted etc. I can poke around on getting that all working but again I think it will take away from the base “game” part of it. Definitely if I get it on steam then I think the first thing I’d try to attack is multiplayer. I’ve done that before in another game, you essentially gotta mark stuff as “replicated” or “non replicated” and if you mess it up you’re sending or recieving way to much data, oorr you’re giving control to someone who shouldn’t have it (such as giving a client the authority over where a player is located). You can also pull in achievements/scoreboards and server stuff but it required converting the game to full c++ then building in libraries that unreal cannot include normally (such as steamworks libs). So yeah, fun experiment but not doing that now.
I also added an “ai/ml” category for the site (it’s the lil brainy):
