HCI for Games - Changelog v1.3: Pause menu functionality and HUD advancements.

Changelog v1.3;

In a late addition to my HCI setup, with the deadline approaching fast, I have added a functional pause menu to my setup in accordance with my brief, utilising the same visuals from the main menu and options menu creation.

For engine based navigation purposes, I applied the pause menu functionality to the left alt key. As the escape key is commonly used to pause videogames on PC, but escape also closes the previewer in Unreal, so as opposed to clicking the close button each time I tested the feature, I instead simply placed the pause functionality on another key.

From the basic pause menu, I duplicated the options widgets created for my original menu and applied the necessary changes to the event graph to account for the different widgets, and different menus I would need to be accessing from the pause menu.

As a result I gained a fully transitioning pause menu, with the same level of current functionality as I have in the main menu setup.

As a final menu touch, whilst not required in accordance with my brief, I added quit and reset functionality to the menu, allowing me to pause and quit the title, exiting to the main menu, which then would allow me to quit to a theoretical operating system upon packaging of a project like this.

I had left this functionality til late on in the development process as I had deemed it would be a much tougher job than it actually was, and it has provided me with some more blueprinting knowledge, allowing me to grasp how simple some things I assume to be complex actually are.

This will help me both physically develop blueprints going forward, and possibly also mentally, instead of assuming something will be tough, potentially driving me to tackle more blueprints head on.

-------------------------------------------------------------------

As another point of reference within my brief, advanced HUD visuals were also listed, however I feel with my project as it currently stands both physically and thematically, elaborated HUD elements are not required, as I prefer to keep the setup much more simplistic. I may change these at another point in time, and in the future working on other project will almost certainly have to create custom heads up displays, but for now, I feel my HUD is fine, thus I can justify it remaining simple in its current form.
As is my personal preference, I feel the only changes I would actually make to the current HUD, comprised of the Health, Energy and Rage meters would be to make each bar simpler. I could tackle this by either leaving the labels and taking away the colours, making the bars monotone, or taking away the labels on each bar completely. I feel this way due to the amount of high end titles in the games industry these days that remove the labels, as end users are familiar enough with the setups and understand the differences in colour fairly quickly. Games such as The Witcher, Bloodborne and Dark Souls all make use of a coloured bar system, with no labels.

Going forward from here I may well elaborate on the bars for health, energy and rage at a later date, as and when I feel necessary through the development process of the game, as the visuals may possibly demand an upgrade as the rest of my visuals improve in quality and as I find a solid theme for my UI overall. I feel there is no real necessity for a visual upgrade right now, taking into account my theme and current visuals.

HCI for Games - Changelog v1.2: Character Customisation.

Changelog v1.2;

To expand on further developmental procedures which could be implemented into a HCI system in games, I have begun but not yet finished the implementation of a character customisation feature for my system.

I began by creating a simple mesh which I could add onto my character as an extra visual entity, and chose to make some wolverine styled claws. Whilst these are not appropriate for my character they were the first thing to come to mind in the short time given to think of potential items for customisation.

Upon creation of these claws, I was asked to make them somewhat 'quirky', and with that I decided to change the design of the claws to that of a cutlery set, leaving one claw in its normal, blade-like form, and changing the end of the other two claws, one into a fork, and the other into a spoon. These were all relatively low poly meshes created quickly for the purposes of importing them into the engine for functionality implementation.

I imported my claws into Unreal and socketed them to my character as appropriate, the outline of which can be seen in the screenshot below.

I began to apply this through my blueprinting code, but due to the system I have set up, was not 100% sure about how to implement this into my system. Whilst I was prepared to modify some widgets and allow for the system to be brought in at the character select transition in my menus, I was not sure about the activating and deactivating of the mesh itself, as such the mesh currently sita active on my character as he runs around the level.

I am currently at a crossroads with the implementation of this feature, as I feel it is not appropriate for my level and does not fit my character design, as such I also feel I would not plan on keeping this feature in game further down the line.

To further justify not using this within my game however, I will be leaving this within my level at the current time as a feature I intend on working on and improving for my own personal growth, and improvement in the blueprinting process.

HCI for Games - Changelog v1.1

Changelog v1.1;

Changes made -

Visuals have been added to the blocks produced by my Box Spawner, after being asked to "make it quirky" by my tutor.

HCI for Games - Summary

Through this unit, I have gained the ability to outline and create a basic menu system with some basic interactive elements entwined within. I have also utilised already existing photoshop based abilities to create visuals to add to the functionality of the menu.

Whilst different from the character implementation unit, I have learned other blueprinting methods using widgets and learned some more valuable techniques toward the workings of HCI and bringing together a menu system. With this in mind, through both my own work and any assistance gained from my peers, I feel I have learned a substantial amount again about blueprinting for menus.

I still have a lot within this system to improve upon and have much further to go to make it fully interactive and some elements will simply not work until I proceed further with development of the actual game itself. These elements include subtitles, all audio settings and some visual settings also.

I plan to make changes beyond my submission deadline, any and all changes will be detailed in the previously mentioned changelog in this dev log. If I can improve on my abilities within photoshop I may also be able to further improve my visuals.

Below are video captures of the HCI system in its current state;

HCI for Games - Peer Review cycle 1

To gain some insight on my HCI system with fresh eyes from my peers, I was to conduct a peer review session.
I would have to come up with a series of question which could give me some valuable feedback to further develop my menu system.

The questions I decided on were as follows;

1. Do you think the options menu covers enough aspects of the options to be utilised in game? If not, which other aspects could I add to my menu?

2. Do you feel the visuals and sounds within the menu setup are appropriate/fitting for the type of game, if not, do you have any suggestions on changes I could make?

3. Do you feel the transition from the menu to gameplay is quick enough? if not, do you have any suggestions on how to make this quicker?

4. Do you feel there is enough of an interactive flow to the HCI, whilst I feel it isn't at all appropriate for my design, I do still need an element of interaction.

The answers given were as follows;

Peer 1 -

1. Yea the menu controls are plenty and cover all the usual aspects you'd see. At a push maybe some achievement-esque type option as those are new but that's not required or needed at all (nor is the functionality for something like that)

2. Yep, they give off an arcade type vibe, like i'm about launch Asteroids or Space Invaders although technically I don't know why you couldn't use those sound effects on any general 3D sci-fi game either, it's just an association thing I guess.

3. Yea it's slick, to and from and the character camera transitions are subtle too, nice.

4. No you should make only 4, no less / no more cubes drop and make the red square catch them and change the whole idea into a super beastly game where you get score points showing up on your menu (absolutely necessary for distinction) based on how long you can keep the cubes stacked on top whilst you move around. Bonus points for speed.

----------------------------------------------------------------------------

Building on suggestions made above, I will be time crunching and making any suggested changes which are achievable within the time until deadline and subsequently detailing these changes in a changelog post.

Changes I am currently looking to make;

1. Potential addition of an Achievement/Trophy menu (This will be dependent on creating a list within the time remaining).

2. Make some visual changes to the cubes upon spawn in character select scene (Upon advice from tutor).

HCI for Games - Interactive elements.

As part of this unit, I was required to incorporate an interactive element into my HCI system, and whilst there are many, many interactive elements to provide to a player, very few of them actually fit in with a menu system.
Taking this into account, I have incorporated a simple set of blocks which can be interacted with, as the rest of the suggested elements fit even less so with my project.
The blocks are a simple setup using a gate to hold and release the actor, allowing the player controller to manipulate the blocks location in two axes simultaneously, a summary of the blueprinting method can be seen below;

The Break vector and Make vector nodes work in tandem to limit the boxes from moving on more than two axes at once, though they could move on all three if it were desired.

I have two more iterations of the box which alternate the axes on which the boxes move, one on the X and Y axes, and the other on the Y and Z axes.

I also have a simple click based cube, which moves upward on Unreal's Z axis (Normally the Y axis in modelling software). The directional axis and degree of movement for this can be changed with ease as and where necessary.

The final interactive element I have within my level is placed upon the press of the P key, this is a box spawner, which fires out boxes at a rate of 4 per second, and destructs them 3.5 seconds after spawn. 

This is another simple but regardless interactive element to my HCI system, they were specifically made to destruct after 3.5 seconds as the spawner is placed above the characters, and the boxes could otherwise build up and block vision of my playable characters in the character select system. 

This would completely break the character selection as they would not be clickable when placed behind other meshes.

A video of the spawner in action can be seen below;

Whilst I could have added some other elements to my HCI system, I feel as though 3 different types of interaction is enough. I have made this choice based on a design decision, as I feel any over the top animation elements would simply not fit the style of game I am aiming for.

From this point, I will be looking to gain some peer feedback on my setup overall, and will be conducting a peer review as such.

HCI for Games - Linking it all together

My next task was to begin linking the pieces together, and with this came a number of hurdles, as the character select had technically been set up prior to the setup of any other menu functionality.
With the order of content creation being slightly out of sync with what I would normally expect from a HCI development standpoint I did not initially find it easy to link everything together working in a backward motion, with some breaks in my blueprinting occurring.

Again asking peers for any helpful advice or tips to assist me in the linking of the menu widgets into the physical character select system, I was eventually able to weave the menus into my system, and transition the HCI to the character select setup with relative ease.
I found no issues in linking the menus themselves together, but rather in specifically linking my custom menu setup to the character selection setup.
Blueprinting is definitely something I feel I need to work on over time to fully understand and gain a broader knowledge of overall.

To transition from one menu widget to another I used a remove from parent node, followed by a create widget node and an add to viewport node. Within the create widget nodes each respective widget was assigned to the correct button click to make my menu transition correctly.
Examples of this can be seen in the below screenshot, taken from my 'Game Options' widget;

The work to make the character select fit in with my custom menus consisted of a transition I wasn't sure how to perform when the play button is clicked from the main menu. This is when I consulted my peers for any help they may be able to give me.
This was the hurdle I met, as the character select system on its own worked fine, with some minor tweaks to my existing blueprints and some tips from a peer, I was able to link it together, the resulting blueprint solution can be seen below;

When I look back at the blueprinting procedure which I undertook I can see where I was initially going wrong, and I will doubtless learn from this fix and improve over time. Whilst I do not feel blueprinting is my forte and would certainly benefit from more detailed analysis of various nodes and the intricatcies of what each of them do, this is something I will be looking into over time as I will obviously need an understanding in the future to be able to create basic game models with an eye to making more full games.

Below is a basic video capture of my menu system in action as it stands, including the visuals of my main menu framework and the character select system functioning right through to gameplay also;