Making the Game: The Work Continues
Another week (almost) over, another update! This week I tackled mapping out the game's rooms, creating the very first hazards to the player and some HUD updates.
Remember the shockwave charge bar I initially made when I developed the gun? Well, forget all about it! I used my moderate Illustrator skills to whip up nice new crosshairs which change gradually with the amount of charge the gun currently has!
I added them to the HUD Widget I made before as an Image. I bound its Slate Brush to a simple "GetCrossHairImage" function that returns a Make Slate Brush node based on the current "Charge" value read from Robotrooper. Oh, and the "Charge" variable is now a float instead of an int.
Of course, the player's current amount of remaining lives is also displayed as part of the HUD now. A very simple binding to the current "Lives" value.
And that does it for this post, folks! Until next time!
The Room(s)
Having finished the primary game mechanic, I was quite ready to layout rooms beyond the first two. I got up to room 6 (out of a planned 10 or so). Here's a small preview of what some of the rooms look like so far!
For the floors I use the Floor_400x400 included with Starter Content, textured with the M_Tech_Hex_Tile material. For the walls I use Wall_400x300. They are outfitted with the same material. I did make some wider walls of my own as well!
A Hazardous Life
As you may have noticed in two of the images above, some of the rooms now have bright red floors. Coming in contact with these is bad news for Robotrooper, as they will reduce his amount of lives by one. Originally these were just bottomless holes in the simulation, but upon the lecturer's suggestion I made them stand out from the environment a lot more. I think they look really good this way, wouldn't you agree?
So how did I go about implementing these Hazard Floor Blueprints? To begin with, I used the standard Floor_400x400 static mesh. I textured it with a Material Instance of the Glowing Light material I made for my lights (see Making the Game: Adding Style). Instances are basically a way to slightly modify an already existing material without having to create a completely new one.
That's it for the appearance, but what about the functionality? I added a trigger box on top of the mesh and created an On Component Begin Overlap event. I dragged out the "Other Actor" pin (as in, the actor that's overlapping this component). First, I Cast this actor to the FirstPersonCharacter Blueprint. This will check whether the "Other Actor" is a FirstPersonCharacter. If it is, I call a custom event I made on the character called "Lose a Life". If the cast fails instead, I try casting again, but this time to a Cube. If "Other Actor" is a cube, I call the cube's "Reset Position" event instead.
Lose A Life
The event called when the player comes in contact with the Hazard Floor. First it checks if a cooldown boolean is true or false. If it is true, the event stops execution. Otherwise, a variable called "Lives" will be detracted by one and the player's location and rotation will be set to that of their Latest Checkpoint variable.
Hang on, checkpoints? Yes, I've added those too! At first I was going to just put them on the existing Door Blueprint, but I realized that I might not always want a checkpoint to be right on the door, so I opted to make them their own blueprint. These are mainly a huge trigger box that, when entered by the main character, runs a series of checks; one IsValid check and two Branch checks. They check if there is a door associated with the checkpoint first. If there is, the checkpoint will only activate if that door has been opened by the player. If the door has indeed been opened, and the checkpoint was not previously activated, then the player's "Latest Checkpoint" variable is set to be this particular checkpoint. Pretty nifty, huh?
Reset Position
Anyway, back to the effects of the Hazard Floor. When a Cube Key comes into contact with one, its "Reset Position" event is triggered. This checks whether a key is currently "snapping" or is already "in place" at a Cube Button slot. If neither of those are currently happening, all of the Cube Key's physical velocity will be nullified. This is done by invoking Set All Physics Angular Velocity in Degress and Set All Physics Linear Velocity. Then, the Cube Key's position is set to its "Initial Location" vector variable. This variable is set in Event BeginPlay (equivalent to Start() in Unity).
In Other News
Remember the shockwave charge bar I initially made when I developed the gun? Well, forget all about it! I used my moderate Illustrator skills to whip up nice new crosshairs which change gradually with the amount of charge the gun currently has!
I added them to the HUD Widget I made before as an Image. I bound its Slate Brush to a simple "GetCrossHairImage" function that returns a Make Slate Brush node based on the current "Charge" value read from Robotrooper. Oh, and the "Charge" variable is now a float instead of an int.
Of course, the player's current amount of remaining lives is also displayed as part of the HUD now. A very simple binding to the current "Lives" value.
And that does it for this post, folks! Until next time!












Comments
Post a Comment