Thesis: GUR Tool Development

Platform: PC · Engine: Unreal · Team Size: 1 · Timetable: Six months

As a producer, I identified the need for my capstone team to have analytics tools. After some research I found that there were no heat map tools available for independent or student developers. For my thesis, I decided to do research into the field of Games User Research (GUR), specifically for tool development, and generate a list of best practices. With this list of best practices I designed and created a data collection / heat map tool for the Unreal Engine. The tool was integrated into three different student projects at SMU Guildhall. I held user tests to collect data, and received feedback from developers using the tool.

My biggest learn from this project is directly related to one of the best practices I identified. The sixth best practice was that all data collected should be targeted and actionable. The idea behind this axiom is that collecting all kinds of data throughout the whole process can become very cumbersome. Developing a research question or hypothesis early lets you understand the data collection and analysis processes better and make decisions faster, because you're expecting results to either confirm or deny the hypothesis.

Sticky_FullColor_Emerald_1x.png

Contributions and Tools

Role: Researcher, Programmer

My Contributions:

  • Researched best practices for tool development in GUR
  • Identified list of best practices
  • Used best practices for initial tool design
  • Facilitated integration into three games
  • Received feedback from developers and iterated tool
  • Evaluated best practices list
  • Programmed using C++ and Blueprints for Unreal
  • Documented tool
  • Wrote research paper outlining development process
  • Presented findings at several milestones
  • Defended thesis to a panel of faculty and peers

Tools I Used Daily:


Documentation and Downloads


Images


Risk Assessment/Management

ASSESSMENT: Moving uassets to another project

MANAGEMENT: Implement method to move assets or downscope project

Method: Research methods, implement plug-in in Unreal

The Unreal Engine makes it easy to move assets from one project to another by exporting the assets. Exporting requires both projects to be open on the same computer, which doesn't work for distribution of a tool. I researched other options and found Unreal plugins as a method to move these assets. Moving the project to the plugin was difficult due to a lack of documentation, but the move was successful and the tool became much easier to distribute.

 

ASSESSMENT: Collecting/storing data between levels

MANAGEMENT: Save data to PERSISTENT game object

Method: Write custom game instance to store data 

While collecting data using the BFL, the data needs to be stored somewhere. The most obvious solution was to save on the game instance. I researched the best way to save the data and I found that creating a custom game instance in C++ would allow me to get the functionality I needed while being able to talk to the BFL easier. I wrote the custom game instance and it is now used to store the data being collected.

 

ASSESSMENT: Poor communication of project goals

MANAGEMENT: practice/rehearse project goals

Method: Clarify goals, change method of presentation, practice

My initial thesis pitch presentation went poorly. I presented all of my information on a single slide like a poster as was required. I did not do a good job of communicating my plans and goals. To respond, I worked to clarify my project goals and moved my presentation to a more traditional slide deck. I rehearsed the power point presentation and a demonstration of the tool and performed very well at the next round of presentations.

ASSESSMENT: Project requires outside developers for feedback, scheduling problems

MANAGEMENT: SCHEDULE meetings, leave room in schedule

Method: Leave buffer room, stay fluid for developers' Schedules

I realized early the difficulties of working with developers on different game projects. Since their schedules were tough to work around, I left a buffer room in my development schedule for things to go wrong, and to schedule follow-up meetings if necessary. This padding came in handy as things invariably went wrong and things needed to be rescheduled. Due to the padding I ended up finishing the tool according to my initial deadline.