The UI for the Unreal Match 3 sample game was constructed through UMG UI Designer and 蓝图 - 可视化脚本 . There are several different UI elements conveyed in this sample from front end menus to in-game HUDs and the approach to constructing each were designed with mobile devices in mind.
On this page we highlight each of the menus and point out considerations made during construction, discuss things to be aware of when generating art for UIs, how to approach setting up your UI to scale for different mobile devices and aspect ratios, the steps taken to optimize the UI as well as tips & tricks that were used that may help or speed up your workflow.
The setup for the Button used on the Title Screen is used quite frequently throughout the sample.
Here we wrapped a Button with a Scale Box so that we may scale the whole thing linearly. The Button itself has its Hovered, Normal and Pressed states assigned to use the green button background. We then used an Overlay wrapped Scale Box containing an Image (the icon) so that we may scale the icon independently of the overall button size.
We elected not to bake the icons directly into the backgrounds so that we can interchange them around if need be or use different backgrounds down the road which makes them more easily interchangeable.
One of the design decisions made in setting up this screen concerns how the buttons across the top and bottom are laid out.
The decision was made to use a Uniform Grid Panel to hold each of our buttons rather than a Horizontal Box (which we could have just as easily done). What this allows us to do is specify in the Details panel the amount of Slot Padding to add to each Child that is added (rather than doing so on each button that is added individually). On our Buttons, all we need to do is center them up and they will be spaced out evenly inside the grid panel.
The in-game Options Menu is one of the instances where a Confirmation Screen is used upon performing certain actions. It's usually best practice to provide a confirmation of "destructive" actions whenever you create your UI screens (quitting games, purchasing items, deleting items, etc.) to prevent users from inadvertently selecting something or performing an action they didn't mean to.
Since this screen is used quite a bit throughout the project, we've created a separate Widget Blueprint called the ConfirmationScreen (located in the Content/UI folder) that we can call to be displayed whenever we want to provide a method for the player to cancel out of an action they've selected. Below is the script used inside the OptionsMenu Widget Blueprint that creates/displays the widget and binds the Accept and Back Buttons to perform actions we want to take for the Options Menu.
The Score Board Widget Blueprint displays the game critical information such as current score, time remaining, top score and points needed to earn a medal. The Time and Score values change frequently during gameplay (unlike the Top Score or Medal Scores). For the Time display, a Size Box is used to fit the header text and time value at a fixed position. Similarly, the score display uses a Horizontal Box with the header set to Auto and the value set to Fill. The Horizontal Box itself is also set to fill horizontally which provides a fixed a layout for the varying scores that will be displayed.
Another decision that was made regarding the score board was moving the updating of information to Event Based updates rather than relying on Tick to update everything constantly. This is a huge savings as we no longer need to check every frame if the score has been updated or if the timer value has changed. To go along with this we also used an 失效框 to cache the wood background pieces. This way we draw those pieces once and cache them so that we don't have to redraw them every frame (another savings).
Regarding the handling of the Bomb Power Meter display (PowerBarHorz Widget Blueprint) a Size Box is used to override and enforce custom Width/Height values. A Material is used for the Fill Image of the Progress Bar (M_JaggedRockFire_MeshEmit_Lit located in the Content/Materials folder).
Similar to the Score Board, the Progress Meter is updated with Events rather than Tick which is more cost effective.
Filling the progress bar is done with the Set Percent function and is being set in 20% increments (retrieved from the Match 3 Game Mode).
The floating text that appears when scoring is handled through several different Blueprints. The first is the FloatingScore Widget Blueprint (also in the Content/UI folder) which handles the text displayed. The second, the FloatingScoreBP inside the Content/Blueprints folder is an Actor that is spawned which contains a 3D Widget Component based off the FloatingScore Widget Blueprint. When this Actor is spawned, a delay is performed before calling an animation to fade out the text then destroy the spawned Actor (pictured below).
Determining where to spawn the Floating Score is a combination of the GameLevel_GM Blueprint (Content/Blueprints folder) and the Tile_BP Blueprint (Content/Blueprints/Tiles folder). Inside the Tile_BP, an event is used to determine when a match is attempted. If it results in a score being awarded the location of the match is passed to the GameLevel_GM which handles the amount of points awarded before spawning the Floating Text at the match location.
The buttons that appear at the bottom of the screen are located inside the GameOverButtons Widget Blueprint. They are split off from the Game Over Screen widget so that they can be repurposed and used on other screens versus having to recreate that setup each time we need display those options to the user.
The Level Select Widget was created so that we can store all information in a single source with publically exposed variables so it is easier to add levels down the road. Doing so in this manner, you don't have to hunt through the Level Select Widget Blueprint and find where things need to go or worry about formatting anything, just provide the information directly from the Details panel of the Widget Blueprint you implement it in.
With this setup, it is open for you to use it in different ways. You could add Level Select Widgets for each of your levels, define the default values for the information to display for each level, then turn on/off the visibility of each Level Select Widget as you cycle through your menu. The other way is to have one Level Select Widget, and then through script update the information that is piped through the widget (this is the implementation for Unreal Match 3).
As an Android app requirement, being able to back out of each screen with the device's back button must be implemented for each screen. Widget Blueprints cannot directly access input functions which are typically found inside Blueprints like Player Controllers, Characters or even Actors. Therefore we use the Match3PC Player Controller (Content/Blueprints folder) where the Android Back command calls an Event Dispatcher that we can then bind to in each of our menus where we need to provide that functionality.
Be sure to set Execute when Paused to true if you want to be able to perform an Input Action when your game is paused.
Below is the script used to provide the Android Back Button functionality to the How To screen.
Here we are binding an event to the Event Dispatcher called from the Match 3 PC Blueprint when the Android Button is pressed. We then make sure that the How To screen is visible with a Branch node before setting the Main Menu Widget to visible and the How To screen to Hidden.
For additional reading topics, please see the list below:
For Scaling UI elements, please see the How-to Scale UI for Different Devices for more information.
For Optimizations with Events, please see the How-to Drive UI Updates with Events for more information.
For Best Practices, Tips & Tricks, please see the UMG Best Practices page for more information.