Remaking Mario in Unreal Engine 5 (Part 3)
(This post follows on from this page: https://triplehitcombo.blogspot.com/2024/07/remaking-mario-in-unreal-engine-5-part-2.html)
After breaking down a couple of really big code snippets, let's take a break and look at some smaller ones!
Clouds
The background of the level is looking somewhat drab, let's add some clouds in the background. The first step was to create a bunch of clouds in a trigger volume and set some variables.
This piece of code was done in the construction graph. a spawn area is set (the size of the trigger volume) and a For Loop is set for every instance to spawn, another is added and the transform is set as a random point within the bounds.
Instant Death
A simple one. A trigger volume and attached to it is a call for the Player Death function. This is applied at the player spawn so the player doesn't jump off the level to the left and placed above spike traps. It's so simple, you don't even need to see the code!
Goomba
Okay we have examined a couple of simple scripts but let's break down a couple of large ones! Starting off with the Goomba, the only enemy in this small project. First I set up the mesh for the Goomba and a large trigger for seeking the player and a small trigger for hitting the player, another collision was placed on top of the Goomba for the stomp mechanic. Variables for the Goomba were added. Can it move left? Does it seek the player? Variable for the flipbook playback rate was set (This is to display the animation of the Goomba moving).
The Stomp mechanic begins by squishing the enemy. A sound is played then the scale of the enemy is changed and slightly moved, then the movement of the Goomba is disabled. Then points are added to the player and the Goomba is then destroyed.
If the Goomba was to hit an asset, like a block, it needs to move either left or right. This piece of code checks to see if it hit an asset then a Do Once moves the Goomba either left or right and after a short delay the check is run again.
For the Seeker Goomba a check is made to see if the player enters its visual trigger, if it does then the Goomba moves towards the player. A gate node was used to simplify this. The gate opens if the player is in range and stays closed if it is not.
There is a final code block relating to the Fire Flower which will be tackled in the next post.
Warp Pipe
The warp pipe is an integral part of a Mario game. After setting the components, I added the necessary variables. A reference to the character, Boolean checks for if the pipe is interactable, if the player can go down it or rise out of it were set. A variable for where the pipe warps to is set as well. All of these are instance editable.
In the construction script I set up the ability to change the length of the pipe. A gate node was used, to enter the gate key events were used for up and down for pressing up or down to enter pipes. Then the open and close were set to the begin and end overlap of the trigger. Exiting the gate disabled player input and then a couple of sequences were added.
To finish, timelines were made for whether the player was coming up out of a pipe or falling down and as before, the player moved to where I specified and player input was re-enabled.
Player Controller
Let's take a second to examine the player controller. This was different to the pre-made controller and called when needed. For now, we will look at everything except the UI and hop to Ui afterwards.
First, for the Add Coins events we add all the coins and clamp that to a value of 100. If we don't hit 100 coins, we carry on. If we do we add another life and play a short sound effect and reset the value back to zero.
Then for Add Points, we increment the points, that's it.
Finally for Adjust Lives, we clamp the number of lives between 0-100 and if we hit zero, we open up the main menu (This means the player has ran out of lives).
User Interface
We have already examined the basic user widget that shows lives, points, timer, coins etc. There are a couple more UI widgets yet!
The main menu is up first as it's the first thing the player sees. In the level settings the background audio is selected. Then we set up the visual representation, the button is off screen at first and moves on screen after a short delay.
In the designer we animate the button so it moves on screen after a short delay. We ensure that when the player clicks on the button, the first level opens up as well.
After this a simple animation is made to slightly change the scale and colour of the button highlights when the player hovers or unhovers over the button.
For the end screen......well, it's just this but instead of going to the first level, it loops back to the main menu. Simple, but it works.
A pause menu was added because sometimes people need to pee, or eat, or...well do anything. The visual representation was simple. A button with a blurred background.
In the player controller the code sets the pause event to a key binding. We set the branch to follow what the UI event says above if the Pause button is pressed. If it is false (as in the widget is now showing), then the mouse cursor is shown and the game is paused. Pressing the button reverts the branch to true and the cursor is gone and the game is unpaused and the widget is removed from parent.
Comments
Post a Comment