Categories
Uncategorised

GD2 Blog: Week 20

Hyper Casual Game

As of the 14th of February, I’ve decided to finish adding towards my Hyper Casual Game by finally implementing a menu for it as well as a way for a game over condition that lets the player simply restart the game.

As shown in Figure 1 is a functional menu that shows up once the game is loaded, in this menu the player is able to start or exit the game. Included is also a high score that keeps track of the player’s high score throughout the game and records the highest possible one they achieve.

Figure 1 (Personal Collection)

Figure 2 shows the menu widget changing to a game widget, which displays the players lives and current score. The score system works by giving the player points with each block destroyed, bounce pad interacted with and each extra life taken – each has a varied amount with long blocks giving the player 100 score, to extra lives giving them 1000.

Figure 2 (Personal Collection)

To do this, I had to set up UMG (Unreal Motion Graphics) using one of the official Unreal C++ tutorials as linked below:

https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/UMG/

(docs.unrealengine, 2022)

This goes over how to build a basic menu system with multiple screens and buttons.

To start off, UMG is dependent on a few modules so they’ll need to be added to our project build’s cs folder and add UMG to the list of included public modules.

Within my code’s file, I modified line 11 to include “UMG” in its brackets, and then uncommented PrivateDependencyModuleNames as we’ll be using UI (See Figure 3).

Figure 3 (Personal Collection)

As the menus we create will be made from User Widgets, we’ll need to write a function that helps display and create new User Widgets. This function will be called once the game starts, it also keeps track of what we have created so that it can be removed later.

This is done by opening our GameMode class and adding in the following functions and properties for Figure 4.

We’ll be making a function called ChangeMenuWidget which removes the current menu widget to create a new one from the specified class if provided.

In our protected variables, we have StartingWidgetClass which will be used as our menu for when the game starts.

Next is CurrentWidget which is the instance we are using as our menu. Included is also ‘#include Blueprint/UserWidget.h’ in the header.

These will all mostly be Blueprint compatible, as we’ll need to use them for widgets later.

Figure 4 (Personal Collection)

Moving onto the CPP file, on begin play we set the menu widget to our StartingClassWidget. We then define how we change between menus and remove whatever User Widget is active from the viewport, if any. We then create a new user widget to be added to the viewport (See Figure 5).

Figure 5 (Personal Collection)

Finally, we need a player controller that sets our input mode. For this, we just only need to make sure it overrides the beginplay function in the header file and sets our input mode once the game has started (See Figure 6).

Figure 6 (Personal Collection)

Afterwards in the CPP file, we set the input mode to UI only once beginplay is activated.

Figure 7 (Personal Collection)

As for next, I designed the following widgets to be used in the game. Figure 8 shows the menu, which introduces two interactable buttons that trigger events on clicked.

Figure 8 (Personal Collection)

Once the start game button is clicked, an event plays which casts towards the game mode to change the current blueprint. Also included is a cast going towards the player’s paddle, which activates a function from it that is callable from the blueprint (See Figure 9).

Figure 9 (Personal Collection)

As shown in Figure 10 is in the paddle containing the BlueprintCallable function in the header file.

Figure 10 (Personal Collection)

This function essentially just restarts the players variables including Lives and Score as to start them off fresh each time the game is started.

Included is a call to a function that spawns the ball, the actor’s location is also set to their starting location in the middle of the screen.

Figure 11 (Personal Collection)

To configure our game mode to work with the current UI, we add a blueprint class based on our project’s game mode which makes it possible to set exposed variables to whatever values we want.

To see our mouse in-game, we’ll need to create a blueprint of our player controller as we did with the game mode, as seen in Figure 12 is the class defaults of the player controller with Show Mouse Cursor enabled.

Figure 12 (Personal Collection)

In our game mode blueprint, we set our starting widget class to the menu we want to display, this being our Menu_BP – The player controller we created is also set.

Figure 13 (Personal Collection)

In our world settings, we also set the game mode override to our game mode, this means our asset is now in effect on our level. Once the game starts, our menu will be loaded and use our player controller to set input to UI (See Figure 14).

Figure 14 (Personal Collection)

The second widget is our game widget, this simply just keeps track of the player’s lives and score (See Figure 15).

Figure 15 (Personal Collection)

Using binds for each text box on the bottom left and right, we are able to cast to the paddle to display their variables (See Figure 16).

Figure 16 (Personal Collection)

As displayed in Figure 17 is the game menu in action, it is constantly tracking the paddle’s variables.

Figure 17 (Personal Collection)

Within the blueprint of the game widget, is an event tick function that constantly checks whether the player’s lives have reached zero. Once reached zero, it will then decide whether to set and change the high score depending on if it is higher than the previous. The High Score is a declared variable within the game mode blueprint which changes to the paddle’s Current Score if the latter is higher (See Figure 18).

Figure 18 (Personal Collection)

However if this is not the case, the event will simply just move onto the next sequence and change the widget back to the menu and set the player controller’s input to UI only.

Figure 19 (Personal Collection)

As shown by Figure 20 is the high score being set in the menu widget after the player loses all their lives and causes a game over condition. As this is a game mode variable this is active for as long as the game mode remains.

Figure 20 (Personal Collection)

As for this, I believe my Hyper Casual Game is now within a completed state, the game now contains fully functional UI for the menu and in-game which keeps track of player lives and score.

As this is the final week before submission, I believe that I did quite well with the project with what I was able to achieve and I’m quite happy with how the game ended up.

However I do feel as if I could’ve added more to the game such as further polish, which could’ve been done by having more effects and sounds to flesh out the game.

I have mentioned in my GDD receiving feedback for the game as well where a tester asked for additional effects to help convey the ball hitting the blocks more easier by adding a brief flashing effect on collision. This is useful to know from player feedback as it is a good way to know what players need to understand the gameplay better.

Bibliography

(Docs.unrealengine.com. 2022) User Interface With UMG. [online] Available at: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/UMG/ [Accessed 16 February 2022].

Categories
Uncategorised

GD2 Blog: Week 19

Hyper Casual Game

As of the 7th of February, I’ve added some of the final mechanics towards my Hyper Casual Game.

The following that have been added are several mechanics to help aid the player such as Bounce Pads and Extra Lives to collect, the lives will serve as a goal for the player to earn so that they can continue playing the game.

In addition there is a UFO enemy in the game, using Unreal Engine 4’s socket system, this UFO moves across the screen and contains a static model with a socket attached to it – once it collides with the extra lives, it will steal them and attach said life to their socket. The UFO also has a custom 3D model that I made within Blender.

As showcased by Figure 1, this is the 3D model I created for the UFO in Blender. This was exported as an FBX model and then imported into Unreal Engine 4 as a Static Mesh.

Figure 1 (Personal Collection)

Once imported as a Static Mesh, I was able to assign a material and socket to the model. I gave it the same colour changing material as the blocks and created a new socket for it, positioning it below the saucer (See Figure 2).

Figure 2 (Personal Collection)

The Saucer is a child of the Blocks I created before, so it inherits the same characteristics that make it move and have hit points. It however has a unique function for firing projectiles.

Within its header file I defined two functions for it, one for it to spawn the projectiles at an offset so it could spawn below the saucer rather than inside it, another is a TSubclassOf function which gets an object’s class (This being the projectile we want to fire) and assigns it as “ProjectileToSpawn” (See Figure 3).

Figure 3 (Personal Collection)

Within the CPP file of the UFO is a void function that gets called when the UFO fires a projectile, this essentially gets our “ProjectileToSpawn” and the current location of the UFO on where to spawn the projectile from.

Using this, we then set the spawn offset to appear 10 units away from the UFO as to not make the projectile spawn inside.

We then get the world of our game and then call in a struct called FActorSpawnParameters, which is passed onto SpawnActor functions – with this we can set the owner of the projectile to the UFO and set it as an instigator if it were to do damage.

“Struct of optional parameters passed to SpawnActor function(s).”

(docs.unrealengine, 2022)

We then call the projectile class and set it to be spawned into the world using SpawnActor, we also include the variable for the location it spawns in and set the rotation of the projectile to be directly downwards.

Afterwards, is a debug message to help confirm to us that the UFO has in fact fired the projectile (See Figure 4).

Figure 4 (Personal Collection)

Within game, the UFO is able to steal Extra Lives from the player. How this is achieved is by using a socket, within the code of the Extra Life is an overlapbegin function that has set triggers for certain actors like the Ball or UFO.

As seen in Figure 5, using casts, the Extra Life will call a function called “GiveLife” if touched by the ball and displays a debug message to confirm the event happening.

Afterwards is the part of the function that is enabled if the actor collides with the UFO, if it does, then it has a constant set calling UStaticMeshSocket which gets the Extra Life and Socket of the UFO’s model. Once collided with the UFO, the actor is then attached to the socket of the saucer (See Figure 5).

Figure 5 (Personal Collection)

As displayed by Figure 6 is an in-game representation of a UFO firing a projectile and then collecting an Extra Life. As the Extra Life overlaps with the UFO it is then attached to its socket.

Figure 6 (Personal Collection)

The projectile of the UFO has most of its components hard-coded, meaning that its mesh, material and movement were made within CPP.

Figure 7 shows the header file of the projectile. Contained within it is the collision component, movement component, mesh component and material instance dynamic as well as a light component.

Figure 7 (Personal Collection)

In Figure 8 is the constructor code of the projectile. At first we create the body of the projectile, then set up a UProjectileMovementComponent for the projectile which allows us to give it settings to change its max speed, initial speed and gravity – this component essentially gives us variables based on how projectiles can move in-game.

“ProjectileMovementComponent updates the position of another component during its tick.”

(docs.unrealengine, 2022)

Afterwards we include a light component to the projectile, this is so that once it is seen in-game, it is easily readable and visible for the player to see. The intensity is set to 50,000 and is given a distinct purple color.

Afterwards, we add a mesh to our projectile component. We first get the reference to the mesh we want to use in our game’s files using static ConstructorHelpers and finding the directory of the object we want to use. Afterwards we check to see if the mesh has succeeded in loading, and set the current component to the chosen mesh – we then attach this to the projectile’s collision component.

Another use with static ConstructorHelpers is that we can also get materials. For this we simply get a material called “M_ProjectileColor” and check to see if the material has been successfully loaded similar to the mesh (See Figure 8).

Figure 8 (Personal Collection)

As the mesh and material has been hard-coded, the actor shows up exactly as it would look in-game without its blueprint copy (See Figure 9).

Figure 9 (Personal Collection)

Within the game are the addition of extra lives, unlike the projectile their mesh and components were created within blueprint. Within CPP we will be calling these (See Figure 10).

Figure 10 (Personal Collection)

Using “auto”, we are able to call these components to set them up within the constructor. In CPP terms, auto is able to direct the compiler to use the expression of a declared variable and to deduce its type. In this instance we are deducing it from blueprint to our CPP code.

“The auto keyword specifies that the type of the variable that is begin declared will automatically be deduced from its initializer and for functions if their return type is auto then that will be evaluated by return type expression at runtime.”

(Vrundesha Joshi, 2018)

Figure 11 shows the beginplay function of the Extra Life, within it we are using auto to get the blueprint components and to assign functions and or materials on them. For the Extra Life, I gave the SphereCollision an overlap function and the Sphere mesh a dynamic material.

Figure 11 (Personal Collection)

The material assigned to the sphere is similar to the block one, where it as two colours linked to a lerp with a Blend scalar parameter serving to change the colours in-between each other (See Figure 12).

Figure 12 (Personal Collection)

The Extra Life uses the tick function to change this color, by getting the blend variable and setting it to a float variable that constantly changes each tick by using the time of the world.

Included is the GiveLife function mentioned earlier, which calls a cast to the paddle using UGameplayStatics to get the player pawn within the game world. This simply adds a life onto the player’s lives variable and then destroys the extra life once it is collected (See Figure 13)

Figure 13 (Personal Collection)

As seen in Figure 14 is the Extra Life’s sphere material changing colour in-game.

Figure 14 (Personal Collection)

Contained within the game, is also a new bounce pad actor. This simply has an overlap function that triggers once it is overlapped by the ball (See Figure 15).

Figure 15 (Personal Collection)

These are placed in the corners of the map, and are supposed to assist the player if they manage to hit them by giving their ball a boost to help break any further blocks.

What makes it unique is that the bounce pad extends outwards to push the ball to apply force towards it more naturally rather than through code. This is done by setting it a start location and a total distance for it to travel towards. In the header file are several protected variables that determine the direction, total distance, current distance and start location (See Figure 16).

Figure 16 (Personal Collection)

Within the beginplay function, we get our start location by getting the actor’s current location when the level begins as well as the direction we want it to travel towards – which will be going upwards from its up vector. The total distance is then where the direction’s size is returned to add up the total distance needed for the bounce pad to travel.

We also include a debug message with this variable to help specify if the amount of total distance it needs to go is correct.

We then get a normalized copy of the direction’s vector using GetSafeNormal which checks if the vector length is too small to safely normalize or not. The current distance is then set to 0.0f.

Each tick, we then set the current distance to our actor’s current location minus the start location. If the current distance is less than the total distance whilst bounce is enabled, then the actor will move towards their targeted location. Else if the current distance is higher, we then revert the location of the actor to the start location as it has finished reaching its total distance (See Figure 17).

Figure 17 (Personal Collection)

As for my progress made for this week, I feel as if I did a good job getting the final mechanics for my game in. I’ve also tried further learning how I could utilize actor components that were created either from blueprint or hardcoded in CPP with what I’ve done with the Extra Life and Projectile.

Creating a 3D model especially for the UFO was a fun task as assigning it a socket to help attach an extra life gave me some experience has to how the process of using sockets worked when using entirely new custom models. I hope to expand on this in the future with more complex models.

What needs to finally be done is to implement a basic menu which allows the player to restart and exit the game, it will need a proper game over condition for when the player fully runs out of lives as well.

Bibliography

(Docs.unrealengine.com. 2022) FActorSpawnParameters. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/Engine/FActorSpawnParameters/ [Accessed 11 February 2022].

(Docs.unrealengine.com. 2022) UProjectileMovementComponent. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/GameFramework/UProjectileMovementComponent/ [Accessed 11 February 2022].

(Joshi, V., 2018) What does an auto keyword do in C++?. [online] Tutorialspoint.com. Available at: https://www.tutorialspoint.com/What-does-an-auto-keyword-do-in-Cplusplus#:~:text=The%20auto%20keyword%20specifies%20that,return%20type%20expression%20at%20runtime. [Accessed 11 February 2022].

(Docs.unrealengine.com. 2022) UGameplayStatics. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/Kismet/UGameplayStatics/ [Accessed 11 February 2022].

Categories
Uncategorised

GD2 Blog: Week 18

Hyper Casual Game

As of the 31st of January, I’ve added much more towards my Hyper Casual Game. The game now features a lives system, as well as infinitely spawning blocks.

There is also some optimization measures included, such as an actor that helps set the boundaries of where objects can exist and be deleted if outside of – this is so that the infinitely spawning blocks won’t take up too many resources if they leave the game area.

As represented by the highlighted box, this is the boundary area all in-game objects will be in (See Figure 1).

Figure 1 (Personal Collection)

The code to do this was fairly simple, using an OnOverlapEnd function, we can determine when an object is no longer overlapping the boundaries and thus we can get rid of (See Figure 2).

Figure 2 (Personal Collection)

There is also a debug message that displays using an FString which allows us to take the value of the OtherActor and insert it into an %s parameter, we then print this off using FString (Figure 3). This debug message helps keep track of what actor goes off-screen.

(docs.unrealengine, 2022)

Figure 3 (Personal Collection)

I’ve also added a child class to the blocks, being a faster and more smaller version of it.

Going over several changes since last time, the blocks main variables that determine their amount of hit points and speed are now changed into virtual variables in the header file as to make overriding them in the child classes much easier (See Figure 1).

Figure 5 (Personal Collection)

On the left of Figure 5 is a child class of block. By overriding the virtual variables from the parent class as identified on the right, I am able to change their speed and hit points (See Figure 5).

Figure 5 (Personal Collection)

Within the Block.cpp, I added in in a new variable called BlockHP which replaces the original hit points variable. This essentially sets its health of the block to whatever the amount of hit points are declared by the virtual variable (Figure 6).

Figure 6 (Personal Collection)

Whilst creating a blueprint class of the child blocks, I’m also able to set and change their own meshes within the blueprint.

This is done by having a setting their UPROPERTY to be visible anywhere and also be writable in Blueprints, this is as so to make adding and resizing meshes to the actors much more faster and efficient. Figure 7 shows the class of UStaticMeshComponent being mentioned in the header file of the block.

Figure 7 (Personal Collection)

As our new block type is a child of this parent actor, this carries over into their blueprint and thus requires no need to rewrite the function in their header file (Figure 8).

Figure 8 (Personal Collection)

For the game, I’ve also implemented some actors to the sides of the level which spawn in the incoming blocks – essentially acting as the block spawners (Figure 9).

Figure 9 (Personal Collection)

This is done using “TSubclassOf”, which enables for us to assign an actor for our spawner to spawn.

“Let’s imagine that you are creating a projectile class that allows the designer to specify the damage type. You could just create a UPROPERTY of type UClass and hope the designer always assigns a class derived from UDamageType or you could use the TSubclassOf template to enforce the choice.”

(docs.unrealengine, 2022)

Within the blueprint of our spawner, we’re also able to set which type of actor the spawner will use (Figure 10).

Figure 10 (Personal Collection)

Within the CPP code of the spawner, a looping timer is set as soon as the game begins to start.

The amount of time for each loop is taken from the virtual float BlockSpawnFrequency, once the timer is up it will activate our BlockOnSpawn function.

This then calls our SpawnBlock function which actually gets the spawn parameters of our actor and spawns it at the following location – those of which being from the spawners current location and rotation (Figure 11).

Figure 11 (Personal Collection)

As shown by Figure 11, there are two spawners on either side of the level. Both are pointing in different directions as well as to which way the direction of the spawned blocks will move.

Figure 11 (Personal Collection)

Figure 12 shows what this looks like in-game, as the blocks spawn, they are able to travel towards the direction the spawner was facing. Spawned blocks also become deleted once they are no longer overlapping the level boundary as shown by the debug code.

Figure 12 (Personal Collection)

Using a bit of blueprint code, I’ve also created a type of material for the blocks using a blend parameter which will change depending on the amount of health left in the block. Figure 13 shows me connecting two color parameters to a lerp, which is also connected to our blend.

Figure 13 (Personal Collection)

In the blueprint code of the blocks, there’s an event tick function that will automatically change the blend parameter of the material to the corresponding block, this is done by using a Set Scalar Parameter on the material and naming our Blend.

We then get the block’s health variable for the value of the parameter, it is also multiplied by a float which makes the colour changes more drastic (Figure 14).

Figure 15 (Personal Collection)

In-game, once the blocks lose health, they will dynamically change colour as shown in Figure 16. This is a visual guide to help the player to discern how much health a certain block has, and makes it overall easier to track which blocks to go for.

Figure 16 (Personal Collection)

One instance I did not detail before was that the player’s pawn was controlled by using a PawnMovementComponent.

To get the player character’s paddle moving, I used one of the official Unreal Engine 4 C++ tutorials as a reference for this – This tutorial being called Components and Collision:

https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/Components/

This tutorial shows you how to connect specific components towards your actors or pawns, in this instance I created a Pawn that utilized a PawnMovementComponent for its movement and collision settings (Figure 17).

Figure 17 (Personal Collection)

The reason why you’d do this is that the component already has built-in features that you could utilize, for optimization purposes having components separated from the main Pawn also reduces the amount of clutter in the main Pawn’s code.

“Pawn Movement Components have some powerful, built-in features to help with common physics functionality, and are a good way to share movement code between many Pawn types.”

(docs.unrealengine, 2022)

The code in Figure 18 is our customized Pawn Movement Component, this makes sure that the Pawn will move smoothly around the world, sliding off surfaces and having a maximum speed of 1300 units.

The features present in this component are; ConsumeInputVector, SafeMoveUpdatedComponent and SlideAlongSurface.

ConsumeInputVector reports and clears the value of a built-in variable used to store movement inputs.

SafeMoveUpdatedComponent uses physics to move the Pawn while respecting solid barriers.

SlideAlongSurface handles calculations and physics involved with sliding smoothly along collision surfaces.

Figure 18 (Personal Collection)

In order to use the custom component, we add a variable to the Pawn class to keep track of it – alongside this are also other components that define the paddle’s mesh and collision body (Figure 19).

Figure 19 (Personal Collection)

We then create the Pawn Movement Component and associate it with our Pawn – alongside this are also many of the other variables being set up. In my constructor this is identified as PaddleMovement (See Figure 20).

Figure 20 (Personal Collection)

Pawns have a function called GetMovementComponent, these are used to enable other classes in the engine to access the Pawn movement Component that our Pawn is using.

The function will be overridden as to return our custom Pawn Movement Component inside the header file (Figure 21).

wordpresssucks
Figure 21 (Personal Collection)

In our CPP file, we then add the definition of our overridden function as shown by Figure 22.

Figure 22 (Personal Collection)

As shown by Figure 23 and 24, this is how the player input is affected by the paddle movement. Figure 23 sets up our PlayerSpeed variable to the current AxisValue inputted by the player (This can range from 1 if going right, -1 if going left or 0 if nothing is being inputted).

Figure 24 takes place within the tick function of our paddle, so movement is constantly being applied. Our paddle movement uses acceleration, and is clamped to go only inbetween -1.0 and 1.0 for its full values. These values are slowly added or decreased up by the player acceleration in order to create movement that feels weighty – this all depends on which direction PlayerSpeed is moving in.

Figure 23 (Personal Collection)
Figure 24 (Personal Collection)

For this week, I feel as if I’ve learnt to implement some useful methods into Unreal such as using Blueprints alongside C++ and having separate components to apply to my actors. I feel as if the game is almost near a complete state as well, and I hope to add in some more mechanics and necessary features such as a menu and score system.

Bibliography

(Docs.unrealengine.com. 2022) FString. [online] Available at: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/StringHandling/FString/ [Accessed 4 February 2022].

Docs.unrealengine.com. 2022. TSubclassOf. [online] Available at: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/TSubclassOf/ [Accessed 5 February 2022].

Docs.unrealengine.com. 2022. Components and Collision. [online] Available at: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/Components/ [Accessed 5 February 2022].

Categories
Uncategorised

GD2 Blog: Week 17

Hyper Casual Game

As of January 24th, I’ve decided to rework my Hyper Casual Game into something different as I wasn’t too confident in the earlier idea for it. For my Hyper Casual Game, I’ve now produced a game similar to Breakout.

This was an arcade game with a very simple gameplay premise similar to most Hyper Casual games on the mobile market, the gameplay input only involves moving a paddle left and right.

“In Breakout, a layer of bricks lines the top third of the screen and the goal is to destroy them all by repeatedly bouncing a ball off a paddle into them.”

Wikipedia (2022)

So far I’ve managed to get the fundamentals of the game working, there is a controllable paddle, a ball and several blocks to break (See Figure 1).

Figure 1 (Personal Collection)

How my game differs from Breakout however is that the physics of the game has changed, rather than the ball bouncing in diagonal lines it uses real simulated physics.

This is done by giving the ball itself a physics material with a high restitution setting – this gives it a stronger bounce when it hits objects.

“Physical Materials are used to define the response of a physical object when interacting dynamically with the world.”

docs.unrealengine (2022)

As shown by Figure 2, this is the custom physics material I’ve applied to the ball.

Figure 2 (Personal Collection)

However, to make sure the ball bounces more high enough to hit the blocks more consistently, I’ve added an overlap function to the paddle which will bounce the ball upwards by calling a function within it that adds an impulse going upwards.

It also takes the current force of the player’s right/left velocity to apply to the ball’s added impulse as well, this is so that when the player is moving left or right and hits the ball, it will bounce off in the corresponding direction as well (See Figure 3 & 5).

Figure 3 (Personal Collection)

Included in Figure 3 is also a boolean that briefly disables itself once the overlap function happens. This boolean is part of the condition where if the ball hits, PaddleBounce has to be true as well.

Figure 4 (Personal Collection)

This is to ensure that the overlap function only triggers once the PaddleBounce boolean is active as to avoid the ball having more than one impulse, at the end of the function a timer is set to re-enable the boolean via a seperate function after a second (See Figure 4).

Figure 5 (Personal Collection)

As shown by Figure 6, this is what it looks like in-game. I’ve also added in some lines to demonstrate what forces are being shown.

Figure 6 (Personal Collection)

The blocks in the game that the player destroys by propelling the ball towards has two important variables, a movement speed and a total of hitpoints (See Figure 7).

Figure 7 (Personal Collection)

The speed is used as to determine the actor’s movement speed, this is in the tick function so the actor is moving every tick. In this function, we get the actor’s location and add onto it with the actor’s right vector multiplied by their speed – the new location is then set using this.

Another void displays a function which determines the condition on whether an actor should be destroyed or not, this is done very simply with an If and Else statement which will delete the actor if the amount of hitpoints is less than 1 – otherwise it will subtract the total by 1 (See Figure 8).

Figure 8 (Personal Collection)

The destroyblock function is called within the ball’s code, using an OnCompHit function the ball is able to interact with any objects it hits. Using this, we cast to the block and check to see if the current component being hit is a block – if so, we then call the destroyblock function with the current block the player is colliding with (See Figure 9).

Figure 9 (Personal Collection)

Included is also a debug message that gets the current name of the block hit by the ball, this is just to confirm to us that the OnCompHit function has worked (See Figure 10).

Figure 10 (Personal Collection)

So far I managed to create a decent foundation for my game as of now, although it is not a complete game yet, I will need to set certain win and lose conditions.

I will need to implement a system which gives the player a set amount of lives and possibly a high score for how many blocks they destroy. I plan for the game to go as long as the player is able to play, once they run out of lives then the game will simply restart.

Bibliography

(En.wikipedia.org. 2022) Breakout (video game) – Wikipedia. [online] Available at: https://en.wikipedia.org/wiki/Breakout_(video_game) [Accessed 2 February 2022].

(Docs.unrealengine.com. 2022) Physical Materials. [online] Available at: https://docs.unrealengine.com/4.26/en-US/InteractiveExperiences/Physics/PhysicalMaterials/ [Accessed 2 February 2022].

Docs.unrealengine.com. 2022. FTimerManager::SetTimer. [online] Available at: https://docs.unrealengine.com/4.26/en-US/API/Runtime/Engine/FTimerManager/SetTimer/4/ [Accessed 4 February 2022].

Categories
Uncategorised

GD2 Blog: Week 16

Unreal Hovercraft Game

As of the 17th of January, I’ve decided to redo the hovercraft game from before but in mostly C++ this time instead. I’ve also added a level and some simple mechanics (See Figure 1).

Figure 1 (Personal Collection)

The objective of the physics game is very simple, in that the player is given the task to collect 10 cube pickups as hinted at by the game’s hud. The player must traverse through the obstacle course using the hovercraft to find these.

To help assist the player throughout this course, I’ve included details such as this one in Figure 2. On the hovercraft are back and front lights, the back lights of which turn on as a bright red from the player moving backwards – similar to how a car works.

This is to help the player to discern what type of direction the hovercraft is pointed towards, as its fairly simple shape might disorient players on which way it is facing.

Figure 2 (Personal Collection)

Within the constructor code of the hovercraft, I’ve created several properties that attach themselves to the front and back of the hovercraft – these being spotlight components.

The backlights start with an intensity of 0 as to look turned off (See Figure 3).

Figure 3 (Personal Collection)

In the player input functions, going backwards sets the light’s intensity to 10,000, and once released sets it back to 0.

Included are also several debug messages from GEngine to help notify me whether the inputs go through or not (See Figure 4).

Figure 4 (Personal Collection)

As the game is based around a hovercraft, physics is simulated on the player. How the player moves around is by using forces to push it around, this is done with several float variables to determine the speed (See Figure 5).

Figure 5 (Personal Collection)

These floats as seen from earlier on Figure 4 are changed depending on the player’s inputs, if the hovercraft goes forwards or backwards it moves forward by an applied force – once released however it gets set to 0.

How it starts to move is that within the tick function, there is a constant force being added every frame. This takes the force from our variables and multiplies them with the actor’s forward or up vector (See Figure 6).

Figure 6 (Personal Collection)

GetActorForwardVector just simply gets our actor’s forward vector within the world space, this means that the force will be applied to whichever way the actor is facing.

“Get the forward (X) vector (length 1.0) from this Actor, in world space.”

(docs.unrealengine, 2022)

Our GetActorUpVector is quite similar, in that it gets our actor’s Z position, we apply our turn torque force to this as to get it to rotate.

“Get the up (Z) vector (length 1.0) from this Actor, in world space.”

(docs.unrealengine, 2022)

One problem with being physics simulated however is that the player is liable to fall over onto their side (See Figure 7).

Figure 7 (Personal Collection)

To help solve with this I have a simple input that allows the player to restart their current rotation and immediately stand the hovercraft upright.

As seen in Figure 8 I have created a function that once pressed sets the hovercraft’s relative rotation to reset every axis but their yaw – this is just to not reset which direction the player is facing.

Figure 8 (Personal Collection)

Spread around the course are also pickups which once collided with the player simply add up to the pickup count and disappear.

Figure 9 (Personal Collection)

Within the code, this is done using casting. The hovercraft is referenced in the Pickup’s header file alongside with a void created for the overlap event (See Figure 10).

Figure 10 (Personal Collection)

As shown in Figure 11 is the cpp file of the pickup, within the constructor a UBoxComponent is created for the hitbox of the pickup and has their collision set to “Trigger” – also included is a function to allow the hovercraft to overlap it.

As the game begins, it instantly casts to our hovercraft, once it overlaps we check to see if it is the hovercraft and call a function within it to take up the pickup. The pickup is then called to destroy itself as to appear as if the player is taking it (Figure 11).

Figure 11 (Personal Collection)

Once this function is called, it simply adds a total of plus one to our player’s pickup total and displays a debug message to confirm that the call worked (See Figure 12).

Figure 12 (Personal Collection)

Within the widget blueprint of the game, there’s a binding attached to a number counter which displays the same variable (see Figure 13).

Figure 13 (Personal Collection)

Within this binding is a blueprinting function that casts to our hovercraft and simply gets the total pickups variable to display onto the return node (See Figure 14).

Figure 14 (Personal Collection)

This newer and current version of this hovercraft mixes in both C++ and Blueprinting code from the previous version, I think with what I was able to translate and convert from the tutorial into C++ wasn’t too bad.

Although only the hover components themselves are blueprinted the exact same from the previous game, I was able to get blueprints and C++ code working together – this could potentially be a useful and versatile skill if you were working in a group with non-programmers as to allow them to edit your game easier.

Bibliography

Docs.unrealengine.com. 2022. Get Actor Forward Vector. [online] Available at: https://docs.unrealengine.com/4.27/en-US/BlueprintAPI/Utilities/Transformation/GetActorForwardVector/ [Accessed 23 January 2022].

Docs.unrealengine.com. 2022. AActor::GetActorUpVector. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/GameFramework/AActor/GetActorUpVector/ [Accessed 23 January 2022].

Categories
Uncategorised

GD2 Blog: Week 15

Physics Essay

As of the 10th of January, I’ve conducted further research for my physics essay. One of the game’s I’ve chosen to research is known as Asteroids, I’ve specifically chosen this game because of its age and being one of the earliest known games to implement physics into its gameplay.

Developed in 1979 for the arcades made on a digital vector generator (Known as DVG), which was known to save a lot of memory as well as providing a higher resolution than raster graphics – although at the cost of colour.

“These lines were super-crisp compared to the blocky lines drawn on low-resolution raster displays. The vector display doesn’t need much memory — just a list of lines.”

computerarcheology.com, 2022

Although it was only capable of displaying a few lines using the monitor’s beam, the image was very crisp and clear As shown by Figure 1, the image of the game looks sharp and clear.

Figure 1 (retrogamedeconstructionzone.com)

Asteroids was a challenging shooter known for its complex physics, as the game is set in space the physics relies on mostly the acceleration and deceleration of the player’s ship that they control.

The game simulates how the player’s mass moves around zero-gravity, as the player accelerates forward by force, the ship will keep moving until an external force collides and pushes it into the opposite direction – this is essentially a concept of inertia.

“Every object continues in its state of rest or motion in a straight line unless acted upon by an external force.”

Chris Deziel, 2018

A common approach to doing this would be to keep track of the player’s angle, position, velocity and force components (X and Y directions). You would then at each step calculate the acceleration components and increment the velocities first and then the position of the player afterwards.

As Figure 2 shows, these are the formulaic approach that could be used towards determining the new velocity and angle of the ship as the player goes forward towards a new angle to simulate internal momentum physics.

Figure 2, JAlex

The post as shown goes into detail about how a force can be applied towards an angle along the components of X and Y, acceleration is also being applied to the mass of the object alongside its forces. The acceleration is then applied to the inertia and torque.

Although there is no exact clear documentation on the original game’s code, there have been many replications of it online via fangames or recreations. It would be likely that this is the exact same or similar theory of physics the developers of the based their game off of, within my essay I’ll be documenting at least methods that’ll relate to how the game works.

Bibliography

Physics Stack Exchange. 2021. Internal Momentum Physics Question in recreating an Asteroids Video Game Experience. [online] Available at: https://physics.stackexchange.com/questions/618052/internal-momentum-physics-question-in-recreating-an-asteroids-video-game-experie [Accessed 16 January 2022].

Retrogamedeconstructionzone.com. 2019. Asteroids: By the Numbers. [online] Available at: https://www.retrogamedeconstructionzone.com/2019/10/asteroids-by-numbers.html [Accessed 16 January 2022].

Computerarcheology.com. 2022. DVG. [online] Available at: https://www.computerarcheology.com/Arcade/Asteroids/DVG.html [Accessed 16 January 2022].

Rochon, M., 2017. What is Inertia?. [online] Sciencing. Available at: https://sciencing.com/what-is-inertia-13712449.html [Accessed 16 January 2022].

Categories
Uncategorised

GD2 Blog: Week 14

Analytics for games

As of the 3rd of January, we researched how analytics affect games. We’ve had several lectures before as to how this is achieved with mobile games, this blog will be talking about data and marketing analytics.

In relation to customer analytics, a term applied to datasets whose size is greater than traditional databases that capture is known as “Big Data”.

“Big data is a term applied to datasets whose size or type is beyond the ability of traditional relational databases to capture, manage and process the data with low latency. Big data has one or more of the following characteristics: high volume, high velocity or high variety.”

IBM, 2021

What this data is typically used for is that it is able to help the developers track trends and problems within their games by following it.

This is considered to be quite valuable as it is able to give developers important feedback about specific parts about their game, and what players enjoy or don’t enjoy about it.

“In gaming, big data is particularly important for tracking trends, diagnosing problems, and improving game design.”

Indicative Team, 2021

An example of Big Data being utilized would be of a game using feedback from detecting problematic gameplay moments.

Candy Crush Saga’s developers detected that they were losing user retention during a certain level in the game due to a gaming element that stopped players from progressing.

“Users were massively abandoning level 65, reasons unknown. With 725 levels in total, for Candy Crush Saga such a tendency was quite a trouble. King turned to data analysts to reveal that most people were abandoning because of a particular gaming element that didn’t let users make it past level 65. The element was deleted, and user retention got moving again.”

Kseniya Yurevich, 2019

Once the element was removed from the game, players managed to regain interest and kept playing the game. This data was able to help the developers to understand what works well for their audience.

Another thing analytics can do for games is to see what helps boost monetization and how companies can adjust their strategies to further help business, analytics can help show what sells well within the game.

Many games, especially mobile ones, choose to have in-app purchases. These games tend to have a free-to-play model as well – non-gaming apps also may have in-app purchases.

“According to Business of Apps, 79% of gaming apps currently monetize via in-app purchases, while 50% of non-gaming apps do the same.”

Silvija, 2021

In-app purchases can allow free-to-play games to still thrive and make money, many users tend to spend plenty in app stores already and are predicted to be spending more within the future.

“If you want to make your mobile game free to download, but still make money from it, in-app purchases are the way to go. According to AppAnnie, by 2022, users will spend 156.5 billion in app stores.”

Andrea Knezovic, 2020

How you can implement these into your game is to give the player the option to pay for additional content, such as extra lives, in-game currency, etc.

Although these wouldn’t be completely necessary, they would provide a massive benefit towards helping the player.

For example, many freemium games tend to offer starter packs to newer players to help them progress through the game more easier and much faster as shown in Figure 1.

Pin on Game Shop UI
Figure 1, Jho Casaje

The freemium mobile game model tends to be very successful and generate a lot of revenue.

As a recent survey made in 2021 has been shown, the mobile games market’s revenue has risen to generating 16.8 billion more since 2018 (See Figure 2).

Figure 2, J. Clement

“The global free-to-play mobile games market was estimated at 73.8 billion U.S. dollars in 2020, and this figure is predicted to rise to 75.6 billion U.S. dollars by 2021.”

J. Clement, 2021

These analytics show as to why there are so many freemium games within the mobile market that use similar strategies such as in-app purchases to generate revenue, it is a successful model and many companies follow.

I feel as if analytics can very much guide developers on how to better structure monetization around their games, for my hyper casual game I may want to consider the possibilities of how I could add optional ways that can focus on aiding players – whilst not being necessary to win the game to keep fair.

Bibliography

Ibm.com. 2021. Big Data Analytics. [online] Available at: https://www.ibm.com/analytics/hadoop/big-data-analytics#:~:text=Big%20data%20is%20a%20term,high%20velocity%20or%20high%20variety. [Accessed 8 January 2022].

Indicative. 2021. Gaming Analytics: How to Leverage Your Customer Data for Sustained Business Growth – Indicative. [online] Available at: https://www.indicative.com/resource/gaming-analytics/ [Accessed 8 January 2022].

Yurevich, K., 2019. Data Analytics Streamlines Gaming Industry. Here’s How. [online] Datanami. Available at: https://www.datanami.com/2019/08/29/data-analytics-streamlines-gaming-industry-heres-how/ [Accessed 8 January 2022].

Knezovic, A., 2020. Mobile Game Monetization Trends: Best Strategies to Monetize Your Game in 2020. [online] Medium. Available at: https://medium.com/udonis/mobile-game-monetization-trends-best-strategies-to-monetize-your-game-in-2020-fe2de42d4463 [Accessed 8 January 2022].

Udonis. 2021. In-App Purchases Guide for Mobile Game Monetization | Udonis. [online] Available at: https://www.blog.udonis.co/mobile-marketing/mobile-games/in-app-purchases [Accessed 9 January 2022].

Casaje, J., 2022. Pin on Game Shop UI. [online] Pinterest. Available at: https://www.pinterest.co.uk/pin/389631805252208220/ [Accessed 9 January 2022].

J. Clement, Statista. 2021. F2P mobile gaming revenue 2021 | Statista. [online] Available at: https://www.statista.com/statistics/1107021/f2p-mobile-games-revenue/#:~:text=The%20global%20free%2Dto%2Dplay,billion%20U.S.%20dollars%20by%202021. [Accessed 9 January 2022].

Categories
Uncategorised

GD2 Blog: Week 13

Physics Essay

As of December 27th, I’ve decided to conduct some research for my physics essay. For our essay, we have a choice to examine at least 4 unique games that simulate physics in interesting and novel ways.

We have to explain how the physics operates within the context of the game and as to how it contributes as a key mechanic to the game, we will be conducting research into how these physics are achieved to enhance the gameplay experience of these games.

I’ve decided to research the classic Sonic The Hedgehog games using an online physics guide which accurately describes the mechanics of the Classic Sonic games:

http://info.sonicretro.org/Sonic_Physics_Guide

These games rely on the physics of momentum and speed for their core gameplay mechanics, levels are designed around this by featuring plenty of slopes and loops as well as seen in Figure 1.

The Physics Behind Sonic the Hedgehog - Charged Magazine
Figure 1, Charged Magazine

One way in which the momentum in the game is used, is for “Centripetal Forces”.

“A centripetal force (from Latin centrum, “center” and petere, “to seek”) is a force that makes a body follow a curved path.”

Wikipedia, 2022

Before Sonic enters a loop in-game, he first has to build enough momentum to stay with him when he enters the loop.

The change in direction comes from the contact force of the player’s feet, as it will face perpendicular from the track and point towards the center of the loop which follows the circular path – this would be our centripetal force as represented by Figure 2.

“This force is the centripetal force, and it allows our blue friend to stay on the track because of the enormous momentum that he built up before entering the loop.”

Lindsay Rogers, 2020

Centripetal force - Wikipedia
Figure 2, Wikipedia

As the Classic Sonic games run on the Genesis, they work quite differently compared to modern game engines. An example of this would be how Genesis games don’t use real decimal values, and instead rely on pixels and subpixels instead.

Pixels act as a cell in a grid, whilst subpixels act as a fractional part of the position. Decimal values can be translated into subpixel amounts by simply multiplying them by 256.

“Each pixel is effectively split into 256 slices along both axis and this means the finest fidelity available for movement is 1/256th of a pixel (aka 0.00390625).”

info.sonicretro, 2022

How this is done in-game is that a character has both a pixel and subpixel position, then both are added together to find the real position – the subpixel’s position would have to be divided by 256 first.

Whether the pixel portion is negative or not, the subpixel should always be relative to the left within the pixel, and is then added to the pixel position. You could think of the pixel value to be the object’s position but rounded down.

“If, for example, Sonic’s X pixel position is 50, and his X subpixel position is 48, the real/decimal X position is 50 + (subpixel / 256) which results in a final xpos of 50.1875.”

info.sonicretro, 2022

This principle can be applied to speeds as well, where they all have a pixel or subpixel component.

If the value is less than 1 pixel per frame then it does not need to have a pixel component and is considered just the subpixel amount as a single variable.

Although there is still a lot more to cover with how the physics work on a technical and theoretical level for the Classic Sonic games, I feel as if it is interesting to find out how older game engines tried to emulate physics as well as they could.

As many people online like to create ROM Hacks of the game, there is plenty of documentation online as to how people have researched the game from modifying its code.

Bibliography

Info.sonicretro.org. 2021. Sonic Physics Guide – Sonic Retro. [online] Available at: http://info.sonicretro.org/Sonic_Physics_Guide [Accessed 6 January 2022].

Charged Magazine. 2020. The Physics Behind Sonic the Hedgehog – Charged Magazine. [online] Available at: http://chargedmagazine.org/2020/04/the-physics-behind-sonic-the-hedgehog/ [Accessed 6 January 2022].

En.wikipedia.org. 2022. Centripetal force – Wikipedia. [online] Available at: https://en.wikipedia.org/wiki/Centripetal_force [Accessed 6 January 2022].

Categories
Uncategorised

GD2 Blog: Week 12

Unreal FPS part 2

As of the 20th of December, I continued to work on the last half of the Unreal tutorial for making a first person shooter in C++.

What’ll be covered in this part will be how to create projectiles, and then adding in character animations briefly using the animation blueprint which will control the animation of the skeletal mesh we attached to our character – this is done using graphs which can help to control the bones and via blueprint logic.

“Graphs are edited inside of the Animation Blueprint Editor, where you can perform animation blending, directly control the bones of a Skeleton, or setup logic that will ultimately define the final animation pose for a Skeletal Mesh to use per frame.”

docs.unrealengine, 2021

To set up projectiles for our player to fire, we create an actor that will use a sphere component for collision.

Figure 1 shows the following code being added to the constructor of our actor, this is where we make the collision component into a root one – included is also where the sphere component is defined in the header file.

Figure 1

In our header file, we define several more components for the projectile. As seen in Figure 2 we’re setting up functions for the projectile’s movement, mesh and material.

Figure 2

The below code shows setting up the projectile’s movement and mesh components.

“ProjectileMovementComponent updates the position of another component during its tick.”

docs.unrealengine, 2021

The projectile movement component is what we’ll use to update the position of our projectile each tick, using the Unreal Engine documentation we can choose to edit several variables under this function such as setting the max speed as seen in Figure 3.

The mesh is an imported sphere which is what the projectile will be represented in-game as, as soon as the actor is constructed the static mesh is set to the sphere.

Figure 3

Next up is implementing the initial velocity of the projectile as seen in Figure 4. The header file’s code will be responsible for launching the projectile, and then the launch direction is supplied in the cpp file.

Figure 4

After adding in an input for firing in our Character, we add a way to define our projectile’s spawn location on them as well.

First we create a few functions in our header file, the first which will be our MuzzleOffset which uses the camera-space offset vector to determine the location (See Figure 5), the next will set up a projectile class within our character’s blueprints to know which projectile to spawn using “EditAnywhere” in our definition (See Figure 6).

Figure 5
Figure 6

After including our projectile header in our character’s code, we set up the fire input’s code.

This is where the character will fire their current selected projectile, it gets the camera’s location and spawns the projectile slightly in front of the player.

It then transforms the muzzle offset from the camera space into the world one, and skews the aim upwards by adding onto the rotation’s pitch.

The projectile is then spawned into the world as an actor, which starts at the muzzle of the player. It is then fired in the launch direction we wrote earlier (See Figure 7).

Figure 7

Now to set our projectile’s collision by creating a custom collision channel, to do this we go into the project settings and head towards the collision settings under engine.

We then create a new object channel under the default response “Block” as seen in Figure 8.

NewChannel.png
Figure 8

We then create a new preset and use our created object channel as our “ObjectType”, we then set it so that overlap collisions are enabled for pawns (See Figure 9).

NewProfile.png
Figure 9

This makes it so our collision profile specifies that our projectile will be blocked by static and dynamic actors, as well as one simulating physics, vehicles and destructible actors.

Within our projectile’s cpp file, we set our collision component’s collision profile to the one we just created as shown in Figure 10.

Figure 10

To set up our projectile’s collision, we add an OnHit function that will respond to collision events as seen in Figure 11.

Figure 11

We then add the function of when this activates when it collides with another actor and adds an impulse onto it – the projectile will then destroy itself.

Figure 12

In our constructor, we also add this. Which will call our OnHit void if our projectile collides with another instance (See Figure 13).

Figure 13

As shown in Figure 14, this is how the projectile acts in-game once fired. If it collides with a physics object then the impulse will be inflicted onto it, the projectile will then destroy itself afterwards.

Figure 14

As you can see, several animations have also been imported into the game alongside an animation blueprint (See Figure 15).

Figure 15

Here in the animation blueprint, you can see where I’ve added variables for state transitions in the bottom left, these are booleans which will activate upon certain circumstances on whether the player is moving or in air.

I’ve also got several different states already built depending on the player’s movement and jump.

Figure 16

In the event graph of our animation blueprint, there is a cast to our character which gets our current velocity and sees if it is greater than 0 to see if they are running, it then gets the movement mode to enable the falling boolean if the player is currently falling (See Figure 17).

Figure 17

In between states are transitions, these transition between certain animations depending on variables.

Figure 18 shows an example of how a player can transition between an idle and a running animation shown from two different transitions – this is done in a similar manner for most of them.

Figure 18

This is practically where the tutorial is done, and I am free to add onto it if I want.

I feel as if this tutorial helped me to better understand how to create a simple projectile firing system that could use different types of projectiles by using classes, if I were to expand upon this project I could try to implement some more different weapons using sockets and arrays that could store different types of projectiles within them.

Bibliography

Docs.unrealengine.com. 2022. Animation Blueprints. [online] Available at: https://docs.unrealengine.com/4.27/en-US/AnimatingObjects/SkeletalMeshAnimation/AnimBlueprints/ [Accessed 28 December 2021].

Docs.unrealengine.com. 2022. UProjectileMovementComponent. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/GameFramework/UProjectileMovementComponent/ [Accessed 28 December 2021].

Docs.unrealengine.com. 2022. First Person Shooter Tutorial. [online] Available at: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/FirstPersonShooter/ [Accessed 28 December 2021].

Categories
Uncategorised

GD2 Blog: Week 11

Unreal FPS part 1

As of the 13th of December, I’ve started following one of the official tutorials on using C++ with Unreal to help familiarize myself with navigating the documentation of the engine.

The tutorial I’ve been following is for how to implement mechanics for a First Person Shooter game.

You can find this here: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/FirstPersonShooter/

First off, these are the inputs we will be adding to the project.

Figure 1
Figure 2

Movement is straightforward, as the values from the input scales are put towards movement input functions.

Figure 3

As for mouse movement, this is also fairly straightforward as we just set our mouse axis to the functions “AddControllerYawInput” and “AddControllerPitchInput”, which allow the player to rotate their view on the X and Y axis.

Figure 4

The tutorial also followed with us importing a mesh for the player and setting up a camera component, this is done by expanding our list of included files in the header file of the player character – this allows us to access more camera related functions.

“This will allow your code to access more camera-related functions, and will ultimately allow you to manipulate your camera placement.”

docs.unrealengine, 2021

Figure 5
Figure 6

Once we’ve added our new components from our header file, we’re able to modify them in our cpp file like so.

As seen in Figure 7, we create the camera component and then attach it to the capsule – we also allow the player pawn to control the rotation of our camera as well.

Included is also a mesh component which we added by using a USkeletalMeshComponent, we set this to be seen only by the owner and attach it to our camera so it follows where it goes.

Figure 7
Figure 8

This was the final result, we had a character that was able to move and look around including having a mesh and camera.

To add onto this tutorial, I decided to try and add one mechanic on my own – I tried to implement an input that would let the player crouch, which is not covered in the tutorial.

https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/GameFramework/UCharacterMovementComponent/

Using this documentation, I was able to gather a bunch of useful functions that worked in making the player crouch fairly easily.

Figure 9

Unreal has both a Crouch and Uncrouch function, which request the player to start or stop crouching respectively, they also call two other functions called “OnStartCrouch” and “OnEndCrouch” which I will be using.

Figure 10

Using a virtual void, I called these two useful functions which help detect when the player starts and stops crouching, so far these will be used to simply change the camera position to be lowered.

Figure 11

Using one of the variables, I’m able to set the height of the camera to be the half height of the capsule once crouching is initiated.

“HalfHeightAdjust: Difference between default collision half-height, and actual crouched capsule half-height.”

“ScaledHalfHeightAdjust: Difference after component scale is taken in to account.”

docs.unrealengine, 2021

Figure 12

When crouching is ended however, I just set the camera’s position to the BaseEyeHeight of the character’s capsule.

Figure 13

In-game, when the player pressed CTRL, then their capsule size would half and the camera drops down with it – the player would also be small enough to fit under objects they wouldn’t be able to pass through if they were standing.

I feel as if this was a good way to get myself more familiar with the Unreal Engine documentation, as it contains many helpful C++ tutorials as well as containing many references to functions used within them.

Bibliography

Docs.unrealengine.com. 2021. First Person Shooter Tutorial. [online] Available at: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/CPPTutorials/FirstPersonShooter/ [Accessed 13 December 2021].

Docs.unrealengine.com. 2021. UCharacterMovementComponent. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/GameFramework/UCharacterMovementComponent/ [Accessed 13 December 2021].

Docs.unrealengine.com. 2021. ACharacter::OnStartCrouch. [online] Available at: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Engine/GameFramework/ACharacter/OnStartCrouch/ [Accessed 13 December 2021].