WEEK 7 – LOG, SUMMARY

Weekly Log: (35 hours)

Task	Date Complete	Time Spent	Evidence
Playertesting	04/09/17	5 hours	Link to appropriate blog post (with evidence)
Designing, creating, animating, implementing, testing new dialogue widget	10/09/17	10 hours	Link to appropriate blog post (with evidence)
Bugfixing overlapping dialogue widgets and priorities	11/09/17	2 hours	Link to appropriate blog post (with evidence)
Hellevator, Treachery, pillar dialogue widget	10/09/17	3 hours	Link to appropriate blog post (with evidence)
Heresy bugs (jumping phase 2, Phase 3 only playing once fix)	063/09/17	2 hours	Link to appropriate blog post (with evidence)
Final projectile bullet fix – Heresy	06/09/17	1 hour	Link to appropriate blog post (with evidence)
Asynchronous bugs, triggers – Treachery	11/09/17	2 hours	Link to appropriate blog post (with evidence)
Attack prompt and fix, Treachery	11/09/17	1 hour	Link to appropriate blog post (with evidence)
Treachery environment fixes	11/09/17	2 hours	Link to appropriate blog post (with evidence)
Greed dialogue Luciferless fix	12/09/17	1 hour	Link to appropriate blog post (with evidence)
Finalising GIT merge, fix conflicts	12/09/17	2 hours	N/A
Project documentation tools	05/09/17	2 hours	Taiga.io boards, Google Calendar, Excel spreadsheets
Writing my blog with screenshots and evidence	12/09/17	2 hours	N/A

WEEK 7 – DEVELOPMENT

Dialogue UI

A consistent finding in our playertesting was the difficulty players had reading Lil Lucifer’s dialogue during action sequences. These were our findings:

• That players struggled to read through the motion blur on the object
• That players spent so much time focussing on the text that they neglected the player character in game and were hit or killed
• That players gave up altogether on reading Lil Lucifer’s hints and just ignored his talking

To solve this, I am creating a new widget overlay.

Inspiration

I felt that I needed to include a small portrait of the character speaking, and I also wanted it to echo and be consistent with the rest of our UI design for dialogue widgets. I felt that placement at the bottom of the screen would be best.

Image Source: Star Fox 64

Design

I wanted the widget to be unobtrusive, as some playertesters prefer to ignore potential distractions. For this reason, the widget needed to be fairly translucent.

 

Creation

Destruction

Calling from Level Blueprints

Priority – Widgets

Lil Lucifer widget -> lowest priority (if any other widget is onscreen, do not display)

Affecting the priority in external widgets:

Priority – Asynchronous Threading and Mutex Locks

I’ve created a basic priority system using booleans, based on mutex locks, to lock shared thread resources. It checks if there is already an instance of dialogue widget displayed on screen (ie a thread actively accessing the dialogue widget resource) – basically locking the resource as long as the widget remains visible and hasn’t been ‘released’ by the thread.

Hellevator Dialogue

Similarly, I adapted the existing dialogue widget used in the Hellevator to match the format of the new Dialogue widget design.

Implementation

I needed the solution to be universally accessible for application. I also required a priority-based ‘check’ for any other widgets that are onscreen before displaying.

To make it universally accessible, I wrote the code onto an actor called ‘textscreen’ that exists in every level environment and controls the creation/destruction of character dialogue widgets. By creating a direct reference to the actor in the level, it’s ‘events’ can be accessed by level blueprints and hence the dialogue widgets can be controlled.

Treachery

Inner damage on Cage Spikes

Final Dialogue Fix – Treachery

Attack prompt (widget prompt hint for attack, instead of in-text prompt)

Before the fix, the player would be instructed on how to attack, and then have the attack mechanic enabled AFTER finishing the dialogue. However, during playertesting the players tried to attack immediately and try it out as they read the instruction. To solve this, I removed the instruction from the dialogue events and instead used a prompt widget. This allowed players to swing and try out the movement as they read the unobtrusive instruction on screen.

• Before

• After

Heresy

Final projectile spray fix

Phase 2 – Jumping fix

Phase 3 fixes

Phase 3 required several fixes. I ended up checking the state of the boss on tick for phase or death state

Death Bug (with health = 0 → need to lead frog over vial)

Greed

Dialogue bug fix in Luciferless Round

 

WEEK 6 – LOG, SUMMARY

Weekly Log: (31 hours)

Task	Date Complete	Time Spent	Evidence
Playertesting	31/08/17	5 hours	Link to appropriate blog post (with evidence)
Writing up playtesting feedback	31/08/17	2 hours	Link to appropriate blog post (with evidence)
Heresy Projectiles	03/09/17	6 hours	Link to appropriate blog post (with evidence)
Phases 2 + 3	03/09/17	3 hours	Link to appropriate blog post (with evidence)
Widgets +  animations	03/09/17	2 hours	Link to appropriate blog post (with evidence)
State control – final fix	04/09/17	2 hours	Link to appropriate blog post (with evidence)
Creating arrow objects	02/09/17	1 hour	Link to appropriate blog post (with evidence)
Arrow finterp	02/09/17	2 hours	Link to appropriate blog post (with evidence)
Fixing dialogues (levels x 3)	05/09/17	1 hour	Link to appropriate blog post (with evidence)
HUD edits (health overlay, widgets, dialogue, menus)	04/09/17	1 hour	Link to appropriate blog post (with evidence)
Finalising GIT merge, fix conflicts	05/09/17	2 hours	N/A
Project documentation tools	05/09/17	2 hours	Taiga.io boards, Google Calendar, Excel spreadsheets
Writing my blog with screenshots and evidence	04/09/17	2 hours	N/A

WEEK 6 – DEVELOPMENT

Prompt Widget

• Design

• Animation

• Code

Arrows

• Creating the object

• Creating the movement

• Gravity

Treachery State

Projectiles

• Targeting + tracking player character

• Pivoting between shots

• Firing the projectile

• Asynchronous code

• Changing Phases

WEEK 5 – DEVELOPMENT

Playertesting – Timestamping Player Actions

During playertesting, I observed the actions of playtesters and manually timestamped major in-game events in an excel spreadsheet. This created an excellent reference to understand how difficulty ranges between players, and for us to observe visually which aspects of the game were taking too much and too little time (ie were too easy or too hard).

Playertesting – Issue List

Our producer took a second set of notes during playertesting, observing player behaviour and observations. I spent several hours typing these notes up complete with a tally for the number of times each comment arose and categorising them according to the level or blueprint it directly affected, and according to whether the observation was positive or negative.

Shockwave

In playertesting we found that players continually attempted to jump over the shockwave instead of block it, as we intended for them to do.

To solve this, the height of the shockwave is going to be visibly much larger and just by sight the player will be able to realise they are unable to jump it.

Enlarging Height

As above, the shockwave grows in size as it travels. It’s height is visibly taller than the player character to discourage jumping.

Destroying on Block

Once the height of the shockwave increased, there was a problem when continuing the shockwave to expand after blocking it. The shockwave would become so big that the player character would be inside it – it’s texture would disappear, so it would seem to the player that they were out the other side, except overlapping still triggered (meaning a player that stopped blocking would then immediately be damaged).

To solve this, I ensured that the shockwaves disperse when they come into contact with the player’s block shield.

Safely Jumping Shockwave

I did find a solution to allow players to safely jump over the shockwave. It checks the jump state of the player character at crucial times – if the player character is detected to be jumping when the shockwave hits, they will be permitted to land safely. There are failsafes in place to prevent immunity from willy-nilly jumping.

Trip/Dodge

In playertesting, we were shocked to find that players barely used the dodge mechanic. When queried they replied that they were unable to judge what triggered the ‘trip’, and thus to them the perceived risk of using the mechanic outweighed the reward of success. To encourage players to use this mechanic again, I will be editing the percentage number that affects how often the player character trips in-game.

 

Dialogue Text Wrapping

One bug that continually broke immersion during playertesting was dialogue that ran off the screen.

Particle Effects

I spent time reading forums, tutorials and video tutorials to understand and implement particle effects for successful hits.

I created a mirroring ‘blood splatter’ pixel effect that is created upon successfully hitting the Heresy Boss.

Here is an example of one video I used:

 

WEEK 5 – LOG, SUMMARY

Weekly Log: (24 hours)

Task	Date Complete	Time Spent	Evidence
Playertesting	25/08/17	5 hours	Link to appropriate blog post (with evidence)
Writing up playtesting feedback	25/08/17	3 hours	Link to appropriate blog post (with evidence)
Dialogue bug-fix	27/08/17	1 hour	Link to appropriate blog post (with evidence)
Shockwave -> block -> height -> jump -> textures	28/08/17	4 hours	Link to appropriate blog post (with evidence)
Particle Effects for hit feedback	28/08/17	3 hours	Link to appropriate blog post (with evidence)
Trip percentage fix	27/08/17	1 hour	Link to appropriate blog post (with evidence)
Heresy code logic	28/08/17	1 hour	Link to appropriate blog post (with evidence)
Finalising GIT merge, fix conflicts	29/08/17	1 hour	N/A
Project documentation tools	22/08/17	2 hours	Taiga.io boards, Google Calendar, Excel spreadsheets
Writing my blog with screenshots and evidence	28/08/17	2 hours	N/A
Notetaking for critique feedback, typing up	28/08/17	1 hour	N/A

WEEK 4 – LOG, SUMMARY

Weekly Log: (24 hours)

Task	Date Complete	Time Spent	Evidence
Creating the cage – actor	20/08/17	1 hour	Link to appropriate blog post (with evidence)
Creating the cage – blueprints	20/08/17	2 hours	Link to appropriate blog post (with evidence)
Dialogue cycling	22/08/17	6 hours	Link to appropriate blog post (with evidence)
Improving fault lines, rocks	/08/17	2 hours	Link to appropriate blog post (with evidence)
Bug fixing state control	/08/17	2 hours	Link to appropriate blog post (with evidence)
Recreating asynchronous flow according to Producer designs	/08/17	3 hours	Link to appropriate blog post (with evidence)
Attacking rocks	/08/17	1 hour	Link to appropriate blog post (with evidence)
Finalising GIT merge, fix conflicts	/08/17	2 hours	N/A
Project documentation tools	/08/17	2 hours	Taiga.io boards, Google Calendar, Excel spreadsheets
Writing my blog with screenshots and evidence	/08/17	2 hours	N/A
Notetaking for critique feedback, typing up	/08/17	1 hour	N/A

WEEK 4 – DEVELOPMENT

Allocated by Producer:

Treachery

• Attack and block movement collisions – cage

I ensured that overlap events were set to true, that collision preset was set to blockall so that the object became solid and then I create the ‘on attack’ collision code to destroy the cage spikes.

When the cage is broken, Lucifer has something to say. I needed to detect when any of the cage spikes were destroyed, and then make sure his dialogue event was only activated the first time.

• Treachery dialogue – Press enter to cycle through dialogue, rather than timer

This dialogue was exceptionally tricky as I didn’t want to put any code onto the player character blueprint.

Dialogue arrays are initialised at startup.

I started by completely rewriting the event for dialogue. As event calls cannot take arrays as parameters, I had to create a second event handler to process dialogue.

Then came rewriting the dialogue widget event to draw from these dialogue arrays, according to keypress.

This was used to cycle through lines of dialogue, after the initial frame:

At the end of a conversation, a separate event was called to handle closing down the dialogue.

I realised then that because of its dependency on a trigger to continue, nodes after the dialogue event call no longer played organically. I had to separate triggers into Parts A and Parts B, called before and after dialogue events.

I also completely reworked the flow of the level in accordance with the producer’s flow plan and professional script.

Additionally:

• Attack and block movement collisions – rocks

Disable collision once rock is ‘destroyed’, so player character does not collide with empty space.

• Develop in-engine effect for fault lines (particle effects or material)

• Fault line effect

WEEK 3 – LOG, SUMMARY

Weekly Log: (24 hours)

Task	Date Complete	Time Spent	Evidence
Greed research, planning and diagrams	13/08/17	4 hours	Link to appropriate blog post (with evidence)
Treachery, Hellevator Bug fixes	10/08/17	3 hours	Link to appropriate blog post (with evidence)
Loading screen fixes	10/08/17	2 hours	Link to appropriate blog post (with evidence)
Working on main menu	13/08/17	2 hours	Link to appropriate blog post (with evidence)
Controls menu	13/08/17	3 hours	Link to appropriate blog post (with evidence)
Technical Widget Research for blueprint implementation	13/08/17	1 hour	Link to appropriate blog post (with evidence)
Researching and taking notes for GUI design	13/08/17	1 hour	Link to appropriate blog post (with evidence)
Finalising GIT merge, fix conflicts	15/08/17	2 hours	N/A
Project documentation tools	08/08/17	2 hours	Taiga.io boards, Google Calendar, Excel spreadsheets
Writing my blog with screenshots and evidence	15/08/17	3 hours	N/A
Notetaking for critique feedback, typing up	15/08/17	1 hour	N/A

Summary

This week I completed all tasks assigned to me on our sprint board and also began researching what elements of a game create level flow and GUI design.

Weekly Learning

My learning this week revolved around the new techniques I used in implementing my bugfixes and learning how to further use widgets onscreen.

Accessing Widget Components in Blueprint

To refer to a widget component in the blueprint, the ‘is variable’ box must be checked in the design view.

Greyed out Widget Components (Image)

This one was a little more obscure – I found that the image I had created in the widget was greyed out during play. I tried several things to fix this including manipulating the material and texture of the component, but found in the end that it was due to the ‘is enabled’ box under component behaviour being unticked.

Leaving this box unticked essentially ‘disables’ widget components and greys them out to show this to the player – it would be a useful tool for options in widget menus that required unlocking or were temporarily unavailable due to the state of play.

WEEK 3 – DEVELOPMENT

Treachery

• [Bugfixing] Rolling over lines

This was a bug that had given me some trouble, especially seeing as I didn’t want to have to further edit or add to the player blueprint.

I was able to recreate a similar effect by creating a check against the boolean variable ‘can roll’  in a reverse-logic kind of way. If the player ‘can dodge’, then he is not dodging at that moment – thus, ‘is rolling’ becomes false. If the player is unable to dodge then he is dodging at that moment.

Menus

• [Bugfixing] Main menu

Our producer wanted to remove the player character model from the main menu. I could not find code referring to or casting as the player character so I had to do some digging. Eventually I found that the main menu was an overlay on an ’empty’ level – removing the instance of the player character from this physical level solved the problem.

Fixed menu:

• Controls menu (keymapping picture)

Firstly, I created a keyboard map in photoshop that illustrated the key bindings for our game:

I then added the file to the game files and imported is as a texture onto an image in the menu widget.

To control the menu screen navigation, I used Blueprints.

Finished product:

• [Bugfixing] Loading Screens

I ensured that the loading screen displayed for all levels after exiting the Hellevator (there are currently 3 instances of the Hellvator level):

Research on menus and widgets:

https://answers.unrealengine.com/questions/591019/how-to-set-widget-component-visibility-to-use-widg.html

https://answers.unrealengine.com/questions/365455/when-adding-objects-they-turn-gray.html

Hellevator

• [Bugfixing] Lil Death’s health, stamina bars

In the same level blueprints, I created code to reset the player’s health and stamina to their maximum value.

Greed

For Greed, I was tasked with creating level cohesion and flow. To do this, I began by researching how game developers design signposting in their games to deliver a sense of progression and reward to their players.

After my research, I felt that persistent visual cues that reacted directly to the state of play were the most effective way to signpost level progression for the player.

I implemented this research in the following sequence plan that I designed to mimic the format of blueprints code:

• Trigger
• Event
• Response

ENTER LEVEL [GREED]:
Freeze player
[INTRO SCENE]
Display Header Text: Defeat 3 enemies

~..*..ROUND 1..*..~
ON TEXT FADE: (round 1 start) 
 Unfreeze player
         Start round timer
Display round timer on screen
         Display objective on screen
ON ROUND COMPLETE:
 Trigger 5 second breather

~..*..ROUND 2..*..~
ON TIMER END– (round 2 start)  
 Display Header Text: Defeat 3 enemies
ON TEXT FADE:
Start round timer
         Display round timer on screen
         Display objective on screen
ON ROUND COMPLETE:
 Trigger 5 second breather

~..*..ROUND 3..*..~
ON TIMER END– (round 3 start) 
Display Header Text: Defeat 3 enemies
ON TEXT FADE:
Start round timer
         Display round timer on screen
         Display objective on screen
ON ROUND COMPLETE:
*Baby screaming sfx* 
 Trigger short timer

~..*.END LEVEL..*..~
ON TIMER END
Freeze player
         Camera pan to baby having tantrum
         [END SCENE]
~..*.LOSE ROUND..*..~
ON PUNISHMENT ROUND:
*Baby laughing sfx* 
         Freeze player
         Pan camera to baby
         [Lil Lucifer is stolen in bubble]
         Return camera to player
         Unfreeze player
         Start round timer
Display Header Text: “Survive till time runs out”
         Display round timer on screen
ON TEXT FADE:
Display objective on screen
ON ROUND COMPLETE:
 Lil Lucifer returned to player
 Trigger 5 second breather
ON TIMER END – (round X start)

Research

Greed – Level Flow

This week I was tasked with creating ‘flow’ for Greed – creating direction in the gameplay and keeping the experience engaging for players. To achieve this, I wanted to understand flow in videogames and the ways in which players are affected by it.  My goal is to be able to produce a mechanically superficial layer on top of the existing system to improve user experience but without touching any underlying mechanics.

Signposting

Greed Level Design –  Flow Chart

Credit: Bob Cuthbert

Feedback in the form of signposting is used to alert and update the player to the current state of the game in order to generate an exciting play where which the overall outcome remains uncertain till the very end.

The second use of  feedback is positive or negative feedback, to reward or punish the player. Feedback can be used in this way to engage the player in the game by directly enticing them and rewarding engaged behaviour using ‘rewards’.

Although these ‘events’ and ‘triggers’ exist in the code, they are invisible to the users with feedback. Visual feedback should be used in parallel with changing game states to alert the player to the current state of the game and to provide reward to them through the GUI.

Flow Theory

Flow in videogames not only refers to game design, but also to the state of immersion.

When a player is completely immersed in a video game, they come across a phenomenon known as ‘flow’ – experienced as losing track of time and forgetting external pressures. The total immersion of ‘flow’ is valued by gamers to the point that most users will value or devalue difference games based on whether or not those games can provide immersive flow experiences.

Flow Theory

Conditions that must be fulfilled to enter ‘flow’ state;

1. You must be performing a challenging activity that requires skill.
2. The activity must provide clear goals and feedback.
3. The outcome is uncertain but can be influenced by your actions.

Other prominent effects of being in the ‘flow-state’ include:

• Concentration on immediate tasks: complete focus.
• Distorted sense of time

Learning a new skill – by being given a challenge that forces you to try hard and increase your skill level – is one of the prerequisites for putting players in a flow state.

Take-home Notes

• For the player to feel progression they may need visual cues and reminders [flow theory – clear goals] 
• Effective flow immersion creates a distorted sense of time – thus any countdown timers must be displayed on screen for a visual cue of time with the potential to further create audio cues. [flow theory – distorted time]
• External objectives and changing game states must be tracked for the player as flow immersion created a consuming-concentration on the immediate tasks (and not on tracking objectives). [flow theory – concentration]
• Players should be reminded of all win-conditions and lose-conditions so they don’t feel cheated by the game if either one takes them by surprise [flow theory – clear goals]
• Players need immediate feedback for their decisions, such as a visual cue updating on screen,  else game progression cannot be felt [flow theory – feedback]
• Introducing new challenges or mechanics engages the player and increases flow [flow theory – learning a new skill]

References:

https://gamedesignconcepts.wordpress.com/2009/07/20/level-7-decision-making-and-flow-theory/

Click to access Flow_in_games_final.pdf

http://www.randygaul.net/2010/05/10/game-design-positive-and-negative-feedback-flow-control/

GUI

On my producer’s advice, I began by researching dialogue-centric GUIs of classic games.

Banjo Kazooie

Like most games, the dialogue in Banjo Kazooie is triggered by in-game events. Primary dialogue is displayed in a semi-opaque widget at the bottom of the screen with an icon representing the speaker. In some scenes (especially those featuring conversation between two characters), the widget is displayed at the top of the screen instead.

Spyro

Following in the vein of 3D dialogue-heavy games before it, Spyro too uses the traditional GUI widget at the bottom of its screen to display its dialogue. An interesting note to make here is that the design is consistent with the rest of the graphical user interface, such as its pause menu and the small onscreen widgets that display score count and such. Speakers are identified by name in a small ‘tab’ like area above the dialogue widget.

Super Mario 64

Immediately, the flaws of this widget design are apparent compared to the previous two games. However, like the two previous games Super Mario 64 uses a semi-opaque widget overlay on the player’s viewport. The overlay is positioned in the main viewport area, obscuring action and creating more visual ‘noise’ beneath the semi-opaque widget (making it more difficult to focus on the words). The text is far smaller and thinner than the previous examples, again making it more difficult to comprehend. The text’s design is inconsistent with other onscreen widgets and visual design (which are otherwise blocky and colourful).

Take-home Notes

• Consistently, dialogue widgets are presented at the bottom of the screen.
• They are themed consistently to match with the rest of the GUI components.
• The widget window is a semi-opaque black colour, sometimes rounded for softness or kept straight for visual effect.
• Speakers should be identified by name or by icon.
• Onscreen widgets should not take up the entire space of the screen – rather, it should be presented as an overlay with an area smaller than the screen.
• Text design should be user-friendly.