UNIT 79: HCI PROTOTYPE
Unit 79 - Human Computer Interfaces for Computer Games
Learning Outcome 3 - Be able to prototype interfaces for games using human computer interface techniques
Learning Outcome 4 - Be able to evaluate own human-computer interface production work
Introduction: In this project, I will be planning and creating a Scoreboard display for the end of a round, the purpose of this scoreboard is to display to the player how much health they have remaining and score remaining, Due to this game not having a HUD at all, this scoreboard is a nice way to give the player an idea of how well they did during the level. Furthermore I also intend to have a LEGEND screen on the main menu which informs the player what the different pickups are as well as what they do.
Influence of my ideas:
Throughout the designs I came up with, the ones I settled on were based off of a couple of images I found from the internet on games I have heard of, but never played myself, their scoreboards and upgrade screens helped a lot in the design process of the main LEGEND screen and the SCOREBOARD.
What I wanted to make initially was a scoreboard design fit for purpose and themed around the Jungle based level, I did also want to make multiple screens to appear at the end of each level and they would be differently themed based on the level they belonged to.
When planning initially for the different levels, I wanted to combine some of my initial ideas together and hope that what I proposed from these two sketches would help me in the long run when creating my HCI prototype scoreboard. Although this was in the very early baby stages of the process I had high ambitions for the scoreboard/leadboard.
These two images of sketches above are a couple of the initial level designs for the game Primate Planet. These were to give a general idea of how the levels were going to be layed out from a top down perspective, the game itself isn't top down and is rather a more 3D side scroller type brawler , where each level has a story behind it and each level has themed items and assets commonly found there.
Above you can see some initial sketches that I brainstormed and formed when deciding on whether I should stick to one leaderboard across all three levels or one scoreboard for each level themed appropriately based on the level that was being played at the time. I settled on making one Leader Board in place of a scoreboard because at least then I could use the BOT's (AI) i set up earlier as an example of how I could tie it into the basis. Further down in this project, I'll explain the process focused on the HCI prototype itself.
The platform it will be played on:
The target platform that we have in mind is both tablet/phone platforms and PC platform since the original build of the game that these U.I elements will belong to originate on the PC. There has been discussion of moving over to a console port, but that is far off just as VR is as well.
The visual style of the game:
The visual side of the game takes a very pleasant and cartoon base style in that it is sort of bright and colourful, much like that of crash bandicoot was. Here is just an in image of the menu to give an example of how to visual style makes the game appealing.
As you can see from the menu, this visual style is very bold and in your face evident from the different colours and graphics used.
In the transition to the above image, I had toyed around with different placements of buttons and images for the main menu until I was happy with what the menu was supposed to be. In the development vlog videos you can see how different the menu was initially and it sort of kept with the simplistic layout.
The audio style of the game:
Please refer to the soundscape project below as it ties in with this project and outlines the sort of audio style I am going for.
The core game mechanics needed:
HEALTH & SCORING - The main reasoning why these two pieces of functionality are key is because the player won't know their score or their health remaining until they are displayed on the end scoreboard system. I have already managed to implement a successful system that adds and subtracts health and points based on performance in the level and below explains how it works.
These two functionalities work hand in hand together and are based off of a pickup code that I wrote and blueprinted to work correctly. These two functions work off of the pickups I created from a generic pickup controller which allowed me to use models and textures created by the level threes, but revamped by myself in order to create a visual enticement for the player to go for if they require points or if they want to top up their health. All of these functions run off of an event tick node which essentially means that these functions are called into action from the get go when the game/level is loaded.
Input devices/control system to play the game:
Control Systems I have come up with, coded and implemented into my game level.
There are many different control systems existent within my game level and I will be going into more vivid detail about these on Learning Outcome 2, However for now I'll be going over what I had planned and what I wanted to added initially in terms of game-play functionality for my level.
Player Controller functionality:
Health & Points: These two functionalities work hand in hand together and are based off of a pickup code that I wrote and blueprinted to work correctly.
Boundary Boxes: These neat little, yet simple touches are what allow me to ensure the player doesn't escape out of the playable area unless otherwise specified to do so. I put invisible boundaries around the back and sides of the level meaning if the player wanted to escape the level, it would result in their doom. They would be able to escape at the front of the level and fall down the waterfall.
Artificial Intelligence: I managed to create a VERY basic but working artificial intelligence system meaning that my level has a lot of potential when it comes to offline play vs A.I.
Beginning with the pause menu blueprint, I set up in my level. The pause menu functions as a way to stop the game entirely if the player requires without actually exiting the game. The pause menu was a rather straight forward system with little to no problems on the ethical side as It was very easy to pickup which type of nodes I required to make the functionality for it. Furthermore I set two instances, Once instance resumes the game as evident by the ONCLICKEDBUTTON node, which branches off into a complicated string of other functions which ultimately fire off to pause the game in the end. However I also setup a second state which allows me to set the game to QUIT the game entirely without saving (I have had intentions to set it to work by returning to the main menu but that is something I have yet to fix.)
Finally I enabled a third action which allows the pause menu to be gotten rid of with either a mouse click input or a button click input the mouse click being the player clicking on the resume button itself which is visible in the game, OR by pressing the ESC (Escape) key which also as a result un-pauses the game and resumes where the player left off.
Artificial Intelligence: I managed to create a VERY basic but working artificial intelligence system meaning that my level has a lot of potential when it comes to offline play vs A.I. I created a basic blueprint which turned out to be far more complex for something super simple as this. I went about creating different nodes which would create check markers for a blackboard script. I create one for the distance, aggro and movement and all of these in turn would work together to move the A.I towards the player if they're a certain distance away, using the navigation meshes I placed down at the beginning of the level it allowed them to navigate the self made props and displacements in the level.
It all stemmed from three different blueprints to construct a working and smoothly flowing behaviour tree An AggreoCheck blueprint, An RapidMoveTo blueprint and an CloseEnough blueprint, all blueprints that will be explained as we go through how the artificial intelligence works.
This at first may look dawnting, but once I have explained how this lengthy blueprint works in an easy to understand manner, you'll know what it does.
So essentially what this blueprint does is through various different nodes. checks to see if the A.I placeholder character is aggressively searching for the player in order to move to their location. The end result allows the artificial intelligence to lock onto the player and move closer to them. Aside from that this also enables the bots to pickup different items as well.
So this is the second blueprint that makes up the behaviour tree and this is known as the CloseEnough blueprint which checks for the AI and how distant or close they are from the player. Once they have confirmed how many units(feet) they are away. the AggroCheck blueprint you saw earlier allows the A.I to lock onto the player.
The third and final blueprint that completes the behaviour tree is known as the RapidMoveTo blueprint and what this blueprint does is it gives the A.I the movement capabilities which are inherited by the parent controls logged by the player character that was set up initially. After this blueprint has been called to run, the other two blueprints, AggroCheck and CloseEnough work with the RapidMoveTo blueprint in order to successfully relocate the A.I bot to where the player is located.
The end result of the different blueprints that I went through earlier are what construct this, the Behaviour tree and this is what it looks like when the game is running, this is working silently in the background to ensure the functions are correctly working.
In other projects, You might have seen me show off my point scoring system and here we have a different type of point scoring system, one specifically tied to counting the scores for the leader board, the reason I had this on the back burner when I made my HCI prototype was so I could ensure that it wouldn't conflict with any other of my point systems, essentially how this works it calls forth from the original score blueprint what score that got and replicates that in this blueprint to be printed on the scoreboard.
Below further down in the project, is the HCI Prototype in action, scroll down to see that and also be sure to watch the videos that show the progress of the level and HCI production.
Any different game modes/levels/difficulty settings that you might use:
After extensive planning and agreements, The game is to have three levels a Jungle level, A snowy level and a Sci-Fi level. Below are images of these levels as they currently stand in the development process and do note that these are subject to change, we currently have one working level and that level being the Jungle one where all the core functionality is in play as listed above this section.
There was never any plans to have difficulty levels or different game modes since we just wanted to get down to basics first and that is taking longer than we'd like, however it is great to know that we're close to tying together the other levels to make a functional game.
Game resources/assets required:
The game includes a lot of scenery assets and I have composed asset spreadsheets to keep track of what we have, what is being worked and what needs to be done. Take a look at just a couple sections on things that have been done.
Player actions required:
There are various inputs required from the player in order for the HCI to function. A lot of it falls down to the point and click aspects of the menu system to navigate successfully to the start game screen.
As mentioned above, A lot of this is player driven in terms of the interaction aspect of the game, there is always something required of the player and I'm going to link a couple of videos I made showcasing the HCI of the game below.
Game feedback:
Connor Cottam:
When you stand on the apples, they invert the controls. Also add collision to fruit.Sort out the scoring system. After a player dies in the game, have a score that pops up.
Daniel Lynch:
The HCI is good but I think you could do with some sort of health bar in the level for the character. You could also consider creating a blueprint for the player to take damage when walking very close / touching the fire.The level design is good but the floor on the level could do with possibly some more being added to it like grass to make it seem more detailed but this is optional.
Rowan Linden:
The overall design of the HCI is very neat and clean apart from there being no borders on the snow and sci-fi level compared to the jungle level, it kind of over shadows the other two levels.
< >The overlapping of the HCI is bothersome.The overall design is good.
Nathan Lockett:
The design of the game so far is good, the menu system is very well set up, easy to navigate and if you don’t know the controls you can find them through the main menu.
< >The textures that have been used look ok, there could be a bit more detail added to the floor like some grass, you have managed to create a waterfall animation which fits well with the rest of the environment.The characters could have skins so that they all look different from each other so that it adds a bit of variation. You can only view the controls from the main menu, this means if you forget something you are going to have to exit the game to look at the controls again, you could make it so that you can view the controls whilst playing the game.
HCI Prototype Showcase: CONCLUSION
This is what the leader board looks like when you click the little Trophy symbol in the bottom right of the screen, it brings up the names and values of the players involved, In this case I have set it to the four AI visible in the game level. When one of them picks up the Banana, which is used as a point scoring pickup, the value changes based on how many points they have accumulated.
These are the four different AI, But one is controlled by the player. However I have set the name value to be that of a BOT and this BOT that the player controls is known as BOT_SPIDER MONKEY and when the BOT_Spider Monkey or other BOT's pick up the little bananas they score 1 point and each point is represented on the score board. So this is pre-banana pickup, score is currently 0.
As you can see this is post-banana pickup and you can take note of the Score being acknowledged as increasing by 1 point, now that text draw function is then fed to the Leader board for this particular match, the Board updates and resets based on the match in question. This match only had 1 score for 1 BOT. That being the Player controlled BOT.
Through the Player Score system I put in place, the engine calculates how many points each player in the match had, as you can see BOT_SPIDER MONKEY scored one point that match. The leader board for the matches resets when a new match begins and the new scores are totaled up.
SIDE NOTE: Currently for testing purposes I only had the score go as high as one, but I'll be increasing this to the amount in the level and hopefully implement a pickup respawn refresh rate when further developing my level.
Self Evaluation
Throughout this project, I have had many different and initial concepts and ideas, but only a few really made the cut. As you've probably seen many of the concepts we're originally supposed to be themed around the level they were going to represent. Unfortunately due to the time constraints there have had to be some cut backs to the designs and what has been added currently. I'll outline the details of what I have done for this project as well as what I could've done better and perhaps suggest ways in which it could have been done far better.
After beginning on my research and inspirations, I decided that it would be nice to get a couple of drawn plans out for the level concepts which would definitely help when it came to the placement of the menu and HCI capabilities of the Unreal Engine. After drawing out these plans, As you can see earlier in the document, I felt it was worth annotating where everything will go.
Though this did help in understanding what I was getting at, a lot more could've been done, digital drawn ups could've been made to better represent what my visualization was going to look like.
Something that I could have done to better represent my initial concept would've been to create a basic test level with the functionality to outline the idea specifically.
From the peer feedback I received when IO had people review what they thought, A few of their gripes with it were the fact that the options weren't view-able from the pause menu, something that they should've been in order to provide a much more position for ease of access. There were also some aesthetic changes that could've been made like 3D foliage to the main platform of the level and they're correct, it could be, Another suggestion I have in mind is environmental hazards from the sides of the level that would often pop-up and attack the player for getting to close.
In terms of the control system, There was a slight bug concerning player positioning and their rotation since one of the pickups would clip the player meaning that it would change their direction and position which would invert the controls depending on which ever way the player controller was facing at the time. A easy fix for this would be to add a no-collide collision condition to the particular pickup that was causing this slight hiccup.
Addressing the Feedback
Throughout this project, I received a lot of critical feedback and comments related to how I should go about making the level even better and as well as that the main menu functionalities and such. I'll be addressing the feedback of my HCI prototype here and suggesting possible ways I can build upon this crucial feedback from what my peers have stated.
Firstly to begin with it was noted that the collision boxes were not turned off meaning that if the player collided with a pickup it could and would end up re-orientating their stance and controls. This was of course bad as inverting the controls can make it very difficult to handle the character you play as, so to combat this issue I believe it'd be sensible to disable all collisions that are bounding box based which would allow the player to walk through and still obtain the benefit from the pickup itself.
Secondly it was mentioned that perhaps there were a lack of environmental hazards and they'd be correct, during the process I was far more focused on getting the background mechanics working instead of the gameplay mechanics but later down the line I managed to get a small float system working on the river, it would slowly drag you down the river towards the cliff. However the fire had no bounds box that if I had set one up would be linked to an "IF" variable that would determine if the player is within range to where they could take damage from the fire. I believe this would mean players had to be more careful around the level if this sort of thing was implemented in the first place.
Thirdly a complaint was made in regards to my HCI lapping over itself during the main menu selection and the person that pointed this out saved me a lot of bother because the reason this was happening was because I forgot to set "IS VISIBLE" modifiers in the blueprint to ensure that when one button s clicked to bring up one window, the previous window is supposed to hide itself until such time as the player selects the close or back button, had I added this it would've made the process far more easier to deal with and wouldn't be frustrating to close all the windows.
The fourth and final piece of feedback I received concerned the aesthetic of the level and how there was a big presence of empty space and in level design you always want something going on in the level, To combat this I propose the addition of foliage to really give the floor a different feeling to the natural border to the level and allow for the hidden idea of traps. Long and short grass could be used throughout the level grounding. A second piece of critical feedback was the lack of character models in the level, In a defense for this they were in the works of being made, however due to time constraints we only had two different character models which could've been put into the level itself. But if I were to act upon that feedback, I'd have imported the model mesh and replaced the default mesh with the primate one.
