Menu Tutorial: Cycling Blades

    I hate building Main Menus for my games. I always spend a ton of time working on game play and then months in forget that I need to make a way for players to actually access things. So, I've decided to make a flexible, and reusable menu template. Here goes the first piece, what I am calling "Blade Cycling."

    Let's start with some basics. We have a camera with a canvas attached, and set to "Scale with Screen Size" just in case I am working on a project with a different aspect ratio. That'll keep everything in the right place in the scaled canvas.

    Onto the Visual Script bits.

    This is the script for the "Start" button in the bottom middle. We have a scene variable, and Int called "Active_Blade" that keeps track of which blade on the AoT list we want to set active after the cycle. There is also an object variable attached to the Start button that contains the target blade number. In this case, 1.

    After we set the Active_Blade variable to 1, we are going to message the Controller (a script stored in an empty that controls everything) using a Custom Event Trigger block.

     And here is what it looks like inside the Controller. The keyword "Cycles" triggers the Custom Event, shooting us into a For Each Loop (everything in red) which is hooked up to the Menu_Blades (on the left) AoT. This will fire the Body node of the Loop once for every entry in the Menu_Blades AoT list. In this very early case, just twice, and since it is attached to a Set Active block, it will set each item on the AoT list as inactive.

    This leaves us with a completely blank slate.

    Now comes the Exit node of the For Each block (everything in lighter green) and actually using those earlier variables. We are pulling an item (List - Get Item) from the Menu_Blades AoT list, and specifically the Active_Blades item, which should be 1, but I forgot when I took the picture. (AoT lists start at 0. So, if we are trying to set the second item on the list as active, we would need Active_Blade to be set to 1) Then we feed that into a Set Active block toggled to active instead of inactive, like how it was used in the clearing loop.

TLDR: The script on the Start button tells the Controller what blade should be shown at the end, and then tells it to cycle. The Controller clears everything, and then goes back and sets the specific blade requested by the Start button as active.

    Long walk for a short drink of water, but hopefully I'll show you later how these scripts can be flexible and reused.

    Later. 

 

Micro Tutorial: Mass Messaging with AoT Lists

 

 

 

    As is tradition with the Micros, let's jump right into it.

     

    This bit of script sends out the message "Trigger" to every object on the AoT List named "Trigger_List" which can all be seen on the left side of the top image. I've linked up "Trigger_List" to a For Each Loop block on the input side. So, this loop will fire once for every item on the AoT list. In this case, five times. 

    It will also cycle down the list during each loop. So, you can see I've linked the output "Item" from the For Each block to the target object on the Custom Event block. This will make sure the message is getting sent to a new item on the list every time.

 

     On the other end, I have a simple Custom Event Arguments block waiting on each target object on the AoT list to receive their orders. (If you need a refresher on Custom Events, check the micro-tutorial here)

 

    If this tutorial was helpful to you, consider throwing me something on Ko-Fi or checking out some of my games. Either way, be back later with more. 

 

HORSE Tutorial: Grab

    In this tutorial, we'll go over the script that controls the grab and throw mechanics for the paper balls in the game Trash HORSE, which can be played here, or the full game package can be downloaded here.

    This portion of the script controls whether or not the player can pick up the ball. The Distance block checks the distance between the paper ball (this) and the player (player) which is a scene variable. Once we have that distance, we use the If block to check if the distance between the player and the paper ball is less than or equal to 4 meters. So, basically checking if the player should be able to reach the ball or not, so they aren't grabbing a paper ball from across the room.

    Also in this script is the On Mouse Down block. This is to say when the player has their mouse hovering above an object and they clock the Left Mouse Button, the script will fire. The object in question needs to have a collider for this to work.

 

    New stop, we have a check to see if the player already has something in their hands. So, we have a boolean variable called Holding which is a scene variable so lots of different scripts attached to lots of different objects can check and change it. We check if Holding = false, meaning the players hands are empty, and if they are empty we move on and set the variable to true, so the players hands are now full. And now even if there is another paper ball within 4 meters, the player can't grab it.

     Next, we move the paper ball into the players "hands" by making the paper ball a child of an empty object we have attached to the First Person Controller just under the camera, or where we usually see a gun held in a generic FPS. Then we set the Local Position to 0,0,0 meaning the paper ball will be at exactly the same place as the Hold_Point and change the rotation to match.

     Next we change the Object specific variable of Held to equal true. So, the paper ball is now in position and it registers itself as being held. Then we move to the Rigidbody block, Set Constraints, and freeze all, which will stop the paper ball from moving away from the players hands. After that, we turn the collider off (Set Enabled = False) so the ball doesn't smash into the players own collider and create weird problems like the player standing on what is in their own hands.

This took so much longer than I expected, so we're going to stop here and go over the next part of the script, throwing, in the next tutorial. Again, you can test out how all of this works in the web version here on Itch.io, or if you want to dive into the scripts yourself, you can download the whole package here for Unity.

Later.

 

 

Micro Tutorial: Adding "Crouch" to the First Person Controller

 

    Alright, so I recently needed to add a crouch function to the basic Unity First Person Controller for a project I'm working on. Not sure why it doesn't have one to begin with, but whatever. Here's how I went about it.

    In the red box, we have a toggle function. When the player clicks the Left Control button, the script goes to an If block and checks the players height. Notice we are getting the players height, not scale. 2 is the players crouch height.

    If the players height is equal to 2, the script registers that the player is not crouching and goes to the blue box. There, we set the players height to 0.9 with the first block, set their waling speed down to 2, and their sprint speed down to 3. It makes them short and slow, you now, like crouching does.

    If the players height is not equal to 2, the script takes us to the yellow box, sets the player back to their normal height, which is 2, pulls the players walk speed back to 5 (but in this screenshot it pulls the speed from a variable because I want the player to be able to upgrade their move speed) and sets their sprint speed back to 8. All pretty simple. 

    I've made a version of this script before and done it in some worse ways that we can go over. I originally had a boolean Object Variable that could check if the player was couched and toggle the boolean on and off at the end of each arm. This is a lot more work than we need to do since we can just check the players height to see if they're already couched.

    I also originally had the script change the players scale on the Y axis, but this change in scale also changed the scale for any child objects of the player. So, it smashed everything in their hands. Changing their height doesn't come with that same unwanted side effects.

    Anyway, thanks for reading. Hope this works out for you.

Micro Tutorial: Signals with Custom Events

 

    Custom Events are very important to my projects allowing all sorts of different triggers and scripts from all over the game to communicate specific information. So, I thought I'd go over quickly how they work.

    That red box in the first picture is just a trigger and tag comparison to make sure this script only fires when it is hit by the player. You can read more about that in a previous tutorial, then a cooldown to make sure the script doesn't fire multiple times when the player is entering the trigger once, but that's beside the point of this post. The last block is the important one here, the Custom Event - Trigger block. 

    I made this script to be flexible, as in applied to multiple triggers that will all need to send different messages to different places, which is why all the important information is in Object Variables. Being object specific, I can change the message and destination for each one without altering the original script. The message the trigger is supposed to send is connected with that orange line, and the destination where it is supposed to be sent it connected with the green line.

     In this second picture, you can see the Object Variables in the green box. So, we're sending the message "JokeTrigger" to the the target "DungeonKeeper" which is my scene manager. 

    The blue box is the receiving portion of the script in DungeonKeeper. Custom Event - Arguments is listening for a specific phrase, in this case "JokeTrigger" to be sent to it, and it will only fire the script when it receives this message. Throwing it all together, when the player hits a certain mark, a random joke is told, and with the use of Custom Events, we can have lots of those marks all around the scene all sending messages back to the main controller.

     Thanks for reading. This script-bit is pulled from Tire Fire Rally. If you want to see more, go add the game to your wishlist. Either way, come back later for more jank script tutorials.

 

 

 

Top Down Tank Tutorial: Health and Death

 

    I think this is the last piece of the code for the tank, all taking damage, gaining health, and dying. Let's get to it.

     The tank has two main colliders, one regular physical collider with a rigid body, and then one slightly larger set as a trigger zone. Things that can hurt the tank like bullets, explosions, enemy shells, all have their own assigned tags. When they cross into the tanks trigger zone, that first bit of script in front of the "If" function is checking the tag to trigger the according health loss. One thing I always forget, and it takes a very long time to debug if you're sleep deprived, the Collider from the On Trigger block needs to be hooked up to the Compare Tag block with that elusive green line.

    After the compare/if bit, you can see the Get Variable block pull the tanks current health, subtract the Enemy_Bullet_Damage, and then it feeds that up to a set variable block to update the tanks health.

     The next bit is updating the players health in the UI. This bit is also called On Start (top block) so that the UI shows the players health as full. When the player takes damage, this bit updates the Public_Player_Health and then sends a message (Custom Event) to the scene controller (Dungeon Keeper) telling it to set the UI health to be the same as the Public_Player_Health.

    This next block I call "popping" the UI, which I go over more thoroughly here. Basically changing the color and size of the UI element just for a moment so the player actually notices something has updated.

    This last bit, since Top Down Tank is but a simple game, checks if the players health is less than or equal to zero, and then sends the player to a scene that just says "You Died" if the math checks out. So, now that we have covered losing health and death, I'll show you the whole script and then we'll move to gaining health.

    Crash course, the crate in the ruins in the cover image is a health pick up. It has a trigger with a check looking for collision with the player character. When it gets that hit, it sends a message to the dungeon keeper and the player to update their health records, and here's how it goes.

    The first block is a Custom Event waiting to receive the message "Health40" from a crushed crate. Now comes the tricky part. We don't want the player to raise their health past the tanks maximum, so we first have a check to see if the players health is at least (Less or Equal) 40 points less than full. This game (unfortunately for me) let's the player select from a number of different tanks with different levels of health, all of which are stored in a list called T6_UpgradeList (Get Variable) from which we are pulling the first slot (List - Get Item - 0) because this tank is not upgrades. If they had two health upgrades, we'd be pulling from Index: 1.

    Once we have the health, we subtract the potential health boost (40) and then check if the player has taken at least 40 points of damage. If yes, we just go ahead and add (Set Variable - Add) the 40 points back to the players health.

    If the players health is less than 40 points from being full, we just go back to the upgrade/health list, pull the maximum recorded health, and set the player back to full. This sounds annoying and fiddly, but it's very easy to slip up and allow the players health to grow forever line they're the blob.

     Anyway, thanks for reading. Maybe next I'll go more in-depth about how pick ups work. If this is helping, maybe throw me something on Ko-Fi, or buy a Kaiju game. I'll probably keep making these either way.

    Stay fresh, cheese bags.

Top Down Tank Tutorial: Mouse Tracking

 

    Now for a very important piece of the top down tank, the jank way I make the turret track the players mouse. We'll start from the simple bits and get more fiddly from there.

    I think I've mentioned this method before in the NPC Turret Tutorial, but we'll go back through anyway. There is an empty object attached to the tank called the Sight. It's only job in the world is to look to where the mouse beacon (Mouse_Sight) is in the world at any given time so the turret can get the coordinates. So, On Update -> Look At: Variable - Mouse_Sight. All simple and good.

    Just like the sight, we're having this chunk of script fire every update because we want the turret pointing constantly at the players mouse. We're grabbing the rotation (Get Rotation) from the mouse sight from the panel just above (Object Variable: Sight) and then taking only the Y and W coordinates from that rotation data. The turret in this game is essentially 2D and stuck on the Y axis. No need for Z and X.

    We're taking the Y and W to create a new, more basic rotation and then forcing the tank turret (Set Rotation) to adopt that rotation. Still pretty simple.

     So, with this we are essentially treating the view as a 2D image, getting the position of the mouse on the screen, and the projecting that (Physics - Raycast) down until it hits something (Raycast Hit - Get Point). There is an invisible object in the game we mentioned earlier called the Mouse_Sight that this script is attached to and this script is constantly moving the object to where it thinks the mouse should be landing in the scene so the turret can track it. It's sort of a pain in the ass.

     Last an most important bit, you need to set the Field of View in your camera to 20 or higher. The higher that number, the broader the plane from which your mouse can project and the more accurate the mouse tracking will be. It is lower than 20 by default. So, make sure to fix that.

     That's it for now. I'll try to have what I expect to be the last part up next week. If this is helping, maybe throw me something on Ko-Fi, or buy a Kaiju game. I'll probably keep making these either way.

 

Top Down Tank Tutorial: Firing

 

    Now for a very important bit if you're making a tank, firing.

    Firing, as you might have guessed, is tied to the left mouse click, which according to Unity is Mouse 0. Right after the On Keyboard Input block, we're going to a Cooldown set to 0.5 seconds. So, the player can only fire a shell every 0.5 seconds at the most. In other games, I've implemented an ammo counter and I would also have a check after the cool down to see if ammo is greater than zero, but this is a nice simple tank game. Just a cooldown for this one.

     The Get Variable block is here to orient the shell. The tank has an invisible little object attached to the barrel of the tank just beyond the box collider so the shell doesn't collide with the tank and explode right at spawn. This spot is the BulletPoint. We've attached the Variable Block to a Get Forward block so the shell knows which and then multiplying the forward force by 3 all across the board. So, Get Forward multiplied by a Vector 3 with all slots set to "3."

    Now we're finally spawning our shell into the world with an Instantiate block. The Original slot is tied to a prefab of the tank shell. You can see a Get Position and Get Rotation block on the left side feeding into the Instantiate block. Those two are tied back to the Get Variable: BulletPoint block from the last slide. So, the shell spawns in at the Bullet Point and facing the right direction, which is away from the tank.

    Then we finally move onto the Add Force block to get this shell moving. The little green line between the Instantiate and Add Force is hooked up the denote the force is being applied to the rigidbody of the newly created object. (Note: Your ammo will need a rigidbody if you want this to work. Play with the mass. It can be fun) The force Mode is set to Impulse because I wanted this to mimic a firing round and lose momentum after a bit, and the Force input comes from the Multiply block in the last slide.

    So all the blue square was us figuring out what direction to push and how hard to push it, and then we dump all that information into the Add Force block to actually execute it.

    Also I have this bit because I wanted the tank to make noise when it fires. The position is also set to the BulletPoint. And just below this is a zoom shot of everything so you can reference how it all hangs together.

     That's it for now. Come back soon to learn more about how this tank works. Maybe throw me something on Ko-Fi and I can justify making some more Visual Script write ups, or buy a game. I have a lot of other half-baked scripts to share.

 

 

Top Down Tank Tutorial: Camera Controls

 

    Second bit of the tank tutorial, let's talk very quickly about how the camera is controlled. So, first of all, the camera isn't free floating or attached to the tank. It's instead attached to an empty object that follows the tank around, which let's me also detach it and move it around to see points on interest. 

    The empty object has this little bit of script that keeps it over the player when it isn't going after a point of interest. Every frame (On Update Block) the script grabs the position of the player (in this case called Player_Head) and sets its own position to match. Pretty simple.

    Then we have rotation controls. Anyone who read the last post will recognize these as copies of the rotation controls from the tank, but linked to the Q and E keys instead. Again, using rotation based on the self in the Rotation block. 

    I know this tutorial was a bit short, but the camera controls aren't all that complex, and do they really need to be?

     That's it for now. Come back soon to lean more about how this tank works. Maybe throw me something on Ko-Fi and I can justify making some more Visual Script write ups. I have a lot of other half-baked scripts to share.