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.

star fox.png

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.

design.PNG

 

Creation

creation.PNG

Destruction

destruction

Calling from Level Blueprints

calling.PNG

Priority – Widgets

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

priority.PNG

Affecting the priority in external widgets:

other widgets.PNG

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.

mutex

Hellevator Dialogue

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

hellevator.PNG

Treachery.PNG

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.

implementation.PNG

21584109_739178676265506_509332372_o.png

Treachery

Inner damage on Cage Spikes

Final Dialogue Fix – Treachery

final.PNG

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

click.PNG

  • After

left.PNG

Heresy

Final projectile spray fix

fix

final spray.PNG

Phase 2 – Jumping fix

bugfix jumping.PNG

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)

dead bug

Greed

Dialogue bug fix in Luciferless Round

delays

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s