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;

HCI for Games - Character selection system.

To add to the standard menu implementations I created a character selection system, this required a dummy third person character to be created in order to obtain a moveable camera for character highlighting purposes.

The dummy character blueprint was placed in front of two clickable meshes, and then making use of a 'set view target with blend' node I allowed the camera to transition to two independent cameras using a flipflop node, which allows the camera to zoom in and out on the physical click of each character, allowing them to be selected and deselected.
The flipflop node can only be accessed after a level has been selected however for streamlining purposes and to avoid potential errors in level selection within my HCI setup, using a branch and boolean 'level is selected' setup.

When a level is selected and a character clicked a new widget is added to the screen on click, detailing each character and assigning a 'Go' button to my default playable character to load my game. For the time being I have simply added "Character not available in this build" to my secondary character, as he does not currently function and is not implemented, unlike my main character.
As stated, once the 'Go' button has been clicked on the widget highlighting my currently playable character, this will load my level.

HCI for Games - Creating custom visuals

To take my menus further and add aesthetics to the functionality, I was required to make custom visuals to be applied to the buttons.
Having checked the pixel size of my buttons, I opened an identically sized document with a transparent background.

I chose a font and created a layer for each piece of text I would need for my menus, applying layer styles and duplicating where necessary. I created a simple piece of text for the standard image to be used in-engine, and a bracketed version to be triggered when the button is scrolled over.
I assigned a layer style to one layer and copied it to the rest, making use of a drop shadow, embossing and inner/outer glow techniques.

Once I had each visual element in place on their own respective layer, I made sure each one was centred both horizontally and vertically within the canvas and exported the visuals in PNG format to retain the transparency, so the visuals would be seen as only text.
An example of the visuals created can be seen below;

I didn't create a third iteration for the image for the interaction on click as this is easily obtained in engine with a simple change of brightness, lowering the brightness on click, returning the brightness to it's initial point on release.
I began implementing each of the elements into Unreal Engine 4 menu by menu to gain a proper visual representation of my system and once complete, added a logo also.
Below are a few of my different menus included within the system;

I chose to keep a basic font for the inlaid text for all options screens aside from the menu selection itself to break some repetition and to make each option potentially easier to read for any end user, as though I myself do not have any issues reading the font in use, there is no guarantee of this for each and every person who may lay eyes upon my menu system.

In addition, I have also added some royalty free sci-fi type sound effects to my buttons on click, to add an audible notification that a user is travelling forward or backward within my menu setup.

Were I to produce this game and bring it to market, I would obviously create my own sounds for each aspect of the title, but whilst this is a simple prototype, I will be using royalty free sound effects.

HCI for Games - Translating Wireframes to UE4 Widgets.

To begin transporting the base wireframes into Unreal Engine 4, I created multiple widgets, each with an image positioned centrally, filling the entire widget.
I then layered buttons on top of the image, in accordance with the placements on the placeholder image from Axure, and made any adjustments I felt necessary. The only changes necessary at this point were slight placement differences and the changes made are quite clearly visible in the widget screen captures below.

Beyond the, a few simple preparations were made in that I added the 'OnClicked' events for each respective button within the widget graph, with a view to being ready to link each widget together, and get them working in as little time as possible.

HCI for Games - Wireframing my menus

Building on the pre-production process, my next challenge was to begin creating wireframe images, to layout a general menu system to be used in game.
To create these I used Axure, a software I have used before for plotting UI designs prior to creating the visuals for these.

I began by with a simple background image placeholder at 1920x1080 pixels and began to build upon it for varying menus with varying amounts of interaction through navigational buttons.
To make the menu system functional within Axure I parented each menu with appropriate children and assigned menu options taken from my mind map and mood board to each page within my menu setup.
This was to be the base of my menu system, and the beginning of making it function within Unreal Engine 4.
Below is a screen grab of the software in process and a shot of each page developed in Axure.

My next step is to transport these layouts into Unreal and build on top of the layouts, with buttons, images and interactions, both scroll over and click based.

HCI for Games - Pre production: Forms of feedback, Control setups, Mind Mapping and Mood Boarding.

To begin building a HCI system for my project, I first needed to do a little research into HCI within current games on the market, no matter the genre and no matter the platform.
I would be looking into layouts, options and features within HCI systems in games.

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

I began by quickly assessing the different sorts of control methods which are in use across many platforms as this plays into the construction and functionality of the menu systems found in HCI. Control setups can utilise Mouse and Keyboard and also various types of controllers, which can usually be used on both PC and Console platforms besides portable consoles which tend to have their own built in controls. Where more mobile devices are concerned, floating joysticks are used predominantly in mobile games, utilising touchscreen technology to map functionality to the controls.

As the project which I have been building on this year has been aimed solely at PC, I decided I would need to implement control functionality for both Keyboard and Mouse based controls, and Controllers also, taking into account the design of my game and the menus prior to creation.

As a point of research, I thought of the features I wanted in my menu system and features I may like to implement at a later date, in terms of forms of feedback, and referred to them with an industry example.
I decided that I would like both visual and audible feedback within the menu system to alert the user to menu selections, these can be seen in the below video, a menu walkthrough taken from Id Software's 'DOOM', released in 2016;

The visual feedback would com in the form of different button transitions being designed, with normal, hovered and pressed variants being implemented, and the audible feedback would come from sound effects to signify a forward and backward movement within my menu setup.

Whilst I have decided that to start I would utilise a simple menu setup comprises of buttons which are scrolled over using the mouse, I would like to look into a special cursor setup, similar to that which can be found in Destiny, created by Bungie and released in 2014, the style of the cursor and selection setup within their menus can be seen below;

Adding to this, there are two more features I would like to implement as and when they are necessary, further in the production pipeline, starting with haptic feedback via controller vibration. To note, this is not usually found in menu systems, but in games themselves and is an inclusion for any game which can be played with a controller in this era of games development.
Taking that into account, I will be looking to add vibration into the functionality of my level, but this will come at a later stage as extra functionality on top of the core control setup once the core is complete.

I would also like to add a colourblind setting allowing for easier viewing of the UI for colourblind end users, though I do not have the first idea how to go about this, whether it is a simple process or a strenuous one, as with an increase in UI elements, surely comes an increase in work required to make a colourblind setting a possibility. Again taking this into account, this will more likely be a function I will aim to add in much further into the development pipeline, once I have the core of my project complete.
There are examples of the colourblind setup in many games, but for this purpose, I will be using the below example, once again taken from Destiny.

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

Following the research into control methods and forms of feedback I began mind mapping elements which are usually included within a menu system, originating from both the main menu and in-game pause menus and also elements which can be found in a heads up display.
My mind map can be seen below;

Following this, I began searching for images of menus already existing in video games, and types of menu navigation which I may like to implement into my system at any point. I created a mood board which can be viewed here;
https://uk.pinterest.com/plissken1989/unit-79-human-computer-interfaces-for-games/

To accompany my mind mapping and mood boarding I would need to assess which elements I would need in my menu system and create a flowchart to reflect the way in which the menu would operate, my flowchart can be seen below; Note that the arrows between the options tabs are to imply that the options widgets will be capable of transitions to and from one another, and each options tab will be reversible, to return to the previous screen, signified by a double headed arrow, pointing back to its previous tab also.