Parker English

Lesson 1 – Games User Research

Our first lesson of Week 4 was on Games User Research, or GUR.

What is GUR?

GUR is essentially research into understanding player motivations & actions as well as finding new ways to capture and use data about players to aid game design.

GUR merges fields such as:

• Psychology
• Human Factors/Sociology
• Ergonomics
• UX (User Experience)
• Interaction Design

Considerations

When designing a game, multiple things need to be considered. The first is existing rules such as Nielsens 10 Usability Heuristics, which was detailed in my blog last semester. However, there are also other concerns such as:

• Do players understand the game rules and core mechanics?
  • Do teaching scenarios work effectively?
• Are the game’s controls/UI supportive/easy to use?
  • Can players utilise core mechanics?
• Is the experience as emotive as intended?
  • Is the pace, balance and challenge in line with design intent?

Playtesting

To get a taste of the playtesting process we would have to perform on our own games, we first looked at a strategy deck-builder farming game on mobile called Harvest 101.

Some initial issues were things such as:

• UI design is inconsistent in parts (text size)
  • Larger buttons to accommodate larger fonts based on screen size
• Event (selling bread) seemed to not have any result?
  • More visual feedback to effects of events
• Unsure of use of some of the resources at first
• Not sure what “foundry” card does
  • Clarification in description text

Lesson 2 – Accessibility

Our second session of the week centred around accessibility as well as creating verbose bug reports for our playtests in Week 5.

Accessible Design

Focusing design around accessibility is extremely important for games, as it is necessary for a wide range of users for various reasons:

• For use by gamers with disabilities
• For use in hospitals
• For users rehabilitating due to health concerns or otherwise
• For users taking time off work

We were directed to an amazing resource, the Game Accessibility Guidelines, which has a very well-organised list of possible concerns to avoid and features to include in games in order to meet these guidelines.

Some features that we identified as being very much possible for Oh, Rats were:

• Controller Remapping/Sensitivity Controls – at least 3 days of work
  • In some early playtests we had already had some comments on the sensitivity of the camera, so this was definitely a high priority.
  • However, this would take some work as creating UI for remapping the controls and getting it to play nice with Unity’s Input System would take some time from all members of the team.
• Fullscreen Toggle/Window Resolution settings – at least 2 days of work
• Clear Tutorials – at least 4 days of work
  • This is also a very high priority for the game as while the controls should feel intuitive, there is a lot to introduce the player to, so a tutorial would be extremely helpful.
• Clear Subtitles – At least 2 days of work.
  • This is already included in our game somewhat as most dialogue is handled via a dedicated dialogue system (Yarn Spinner), but creating dialogue pop ups for in-game sounds (and maybe even directional audio UI) would be extremely nice to have for gamers hard of hearing.
• Voice Acting – At least 3 days of work.
  • This would be great for gamers who have trouble reading dialogue but it would have to be recorded to a high standard of quality.

Another change we realised we could immediately implement was changing the button to sprint on controller. Before this it was set to clicking the left stick in, in a fashion similar to a lot of FPS shooters. However we realised that this would be very fatiguing on peoples thumbs if they wanted to run a lot, so we instead set this control to the left trigger for ease of use.

Bug Reporting

To get some practice on bug reporting we looked at some of the games we submitted to the Global Game Jam. The layout of a professional bug report is as follows:

• Summary Line/Description
• Background Details
  • Version
  • OS
  • Part of game
• Steps to Reproduce
• Actual vs. Expected Results
• Other Relevant Information
• Date/Priority

Our chosen game was The Ancient Art of Stewcraft, made by Aiden and Jaydn in third year.

Bug 1.

• Summary: Game UI elements do not scale to window size/Window should not be scalable
• Details: Version 1, Windows 11 64-Bit
• Steps: Resize window to any other size than default
• Expected Results: UI elements should scale and move to sides of window, or window scaling/aspect should be locked.
• Actual: Window expands beyond limits and exposes background/void.

Bug 2.

• Summary: Ingredients are sometimes moved to unexpected positions when placed inside wall collider
• Details: Version 1, Windows 11 64-Bit
• Steps: Repeatedly click on walls of bowl until bug occurs.
• Expected Results: Ingredients should not spawn when clicked inside wall, or move inside bowl.
• Actual Results: Ingredients move randomly to either inside/outside bowl or to far away positions outside game bounds.
• Notes: Seems to increase intensity closer to edge of collider, maybe due to pushing force.