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].

Leave a Reply

Your email address will not be published. Required fields are marked *