[Intro Here]
With a project full of empty blueprints its a good idea to start adding some simple shapes and colours that represent where future assets will be so in the top level parent class "Unit Base" I added a cylinder and a new material which is just a colour value into the "Base Colour" parameter, that I then made different material instances of varying colours to represent the party characters and the enemy characters in this early stage of the battle stage level.
[Battle Level]
In a large amount of RPG the battle area is greatly limited (newer 3D based use a small range of movement) with the classic turned based ones simply picking a camera angle and spawning the characters involved in specific locations on screen, I am going to choose that method for this project as I am not going to allow the player control over the party characters movements while battling and they will be stuck navigating different menus with moves/magic & items listed to choose from.
[Unit Battle Positions]
To make the designers (and mine) life easier I have made a modular actor blueprint which will decide who and where a character spawns on screen once the battle stage has begun. This actor can be placed anywhere in any level and will function perfectly for the new environment. The designer can choose which enemy(s) will take part in this particular battle and how strong those enemies will be during the battle, this allows for 1 enemy to be wandering the overworld stage while having 3 or more enemies compete in a single battle.
[Camera Position]
Now that the character positions have been sorted its time to setup the camera view that the player will be seeing from, this is done with another modular template actor blueprint that any designer can place within the "Battle Stage" level/world and can rotate/move around to their liking making sure that the player can see all the details the designer wants in the background as well as all of the enemies on screen.
[Player Battle HUD]
Since the player will lose access to movement controls during this "Battle Stage" environment they still need a way to interact with the game and give the party characters instructions on how to defeat the enemies they have come across, the player will accomplish this by navigating through a menu that features a list of all the currently possible actions and by using a confirm button the action will be issued to the party characters as a command they can execute on their active turn time.
The most essential parts of this HUD is the current information on the party such as their health and magic points and the section of the screen that contains all their possible actions. Since I do plan to give the player a rather large set of actions the actual lists will be contained in other "Widget Blueprints" in an attempt to keep my player facing UI simple and organized.
[Adding Children to UI]
As the lists containing the performable actions are in "Child" widgets they do not appear on screen immediately or when the level blueprint creates the "Main HUD" widget and adds it to the player view, to make these extra lists of actions visible to the player I add them as a child of a size box (which decides where on screen the child widget will appear as well as how large) and change their visibility upon the button press of the corresponding menu item that is contained within the "Main HUD", for example, Attack will then add the "Target Select" child widget so the player can choose which enemy to focus attacks on while Magic will add a child widget asking whether or not the player wishes to see a list of black magic or white magic.
[UI animations]
Watching squares with words suddenly appear and suddenly disappear is a bit jarring to the player so with the widgets existing and functioning they need animations that show them smoothly entering or exiting the screen view when appropriate. I have got character animations working in previous projects but I have never previously touched this area of animation before. The animations for widgets are added to the editor timeline as collapsible elements containing 3 tracks of movement, 1 track for screen position, 1 track for rotation of the element and 1 track for the size (scale) of the element. Along these tracks key frames can be placed and the engine with fill in the in-between frames with the transition between the two (or more) chosen positions.
For my Battle HUD I have chose to edit the values along the position track, scale track & opacity track. Each of my list widgets that contain actions will fade in from the left and then fade "backwards" as a fade out of sorts. By changing the values on the scale track at specific key frames I can achieve that "Backwards" animation only by editing the size of that element on screen giving the impression that it is moving away from the player.
[Event Dispatchers]
It's all well and good having pretty animations of the additional child widgets however I need a way for the "Main HUD" to communicate with those child widgets and activate those animations as well as populate those lists of actions, removing any actions that cannot be performed before giving the player a chance to select this. With my previous blueprinting knowledge this would be achieved by casting to the child widget and setting a local reference to it then manually specifying which event/function of the child (populate possible actions & remove invalid actions) I want to fire once pressed but this can be computationally expensive, however, there is a behaviour of unreal engine of which I've heard about before but not worked with and I have heard can achieve the result I am looking for. This engine behaviour is called "Event Dispatchers" and it is used in the tutorial I have found in my research and continue to reference throughout this project, An event dispatcher will cast out to all other active blueprints at run time and will check if they have a specific event such as "End Turn" or "Populate Target Select" and it will have that secondary blueprint run their code once the primary blueprint has finished its line of code. Once the parent "Battle HUD" widget has created the child "Target Select" widget then played animations it can be bound to the sub-event "Populate Targets" that's found within the "Target Select" widget. This means every single time the Attack action is picked the game will also write the list of available targets and remove any invalid targets before the animation for adding the "Target Select" window is finished, stopping the player from seeing an empty list but also allowing me to re-use the "Populate Targets" event inside the "Target Select" widget with minimal additional code or changes on each of the differing actions the player can eventually choose from.
Another great example of Event Dispatchers in use is how my battle stage system organises character turns. A character can "request" a turn which will add them to the queue and once they are the next in the queue the "Bind to event Begin Turn" node will activate the "Battle HUD" widget which will set what action the character will perform and then at the end of that specific action event it will "Bind to event EndTurn" allowing the queue to move on through all the characters.
Comments
Post a Comment