What is Injury-Aware Game Design?
Injury-aware game design is being able to craft enjoyable gameplay experiences, all while informing both the players and game designers about gaming-related hazards, promoting healthy gaming activities, and optimizing gameplay to avoid injury. In order to achieve this, 1 or more combination of these components must be added to a game:
- Player activity monitor - tracks various metrics of a player during any given session.
- Injury-aware game AI - dynamically changes gameplay based on real-time player activity data.
- Feedback - data presented to a player in relation to their session that raises awareness of gaming injuries and promotes healthy gaming activities.
REU stands for “Research Experience for Undergraduates” and is sponsored by the National Science Foundation. Each site has a certain area of study it focuses on, and 10 selected students go on to work on a research project under faculty and any associated researchers. REUs are similar to an 8 week trial run for graduate school and what to expect when conducting academic research.
Immersive Media Computing is the idea of a wide variety of technologies blending the physical and digital realms to induce the sense of immersion. Areas of study relating to IMC include: XR, Computer Vision, video streaming and networking, and many more.
More information about Georgia State University and this particular REU program can be found here.
EAI stands for “European Alliance for Innovation”, which is a non-profit organization partnered with the European Commission in order to bridge the gap between European and international research.
ArtsIT is a yearly conference focused on the impact of the arts, media, and technology.
More information about EAI and ArtsIT can be found here.
Responsibilities
- Create a spatial-temporal tool to collect player analytics.
- Make a proof-of-concept game to showcase the tool.
- Design a user study to gauge the effectiveness of the tool's usage and if people would enjoy an injury-aware game.
- Authored a paper to be submitted to a conference (EAI ArtsIT 2021).
Creative Process
Goals
Prototype a temporal-spatial tool to measure player data in real-time.
Craft a proof-of-concept game to showcase the tool.
Author a paper to submit to a conference.
Features
Outputs player data to Google Sheets in real-time.
Temporal ascpect of the tool is able to be a standalone application.
2 versions of the game: standard and injury-aware version.
Variety of items to pick up as you explore the city, each with their own pickup sounds.
Constraints
8 weeks to create the tool, game, and user studies.
Finding participants to both play the game and do the user studies.
Spatial aspect of the tool is game or mechanic-specific.
1) Prototype both the temporal and spatial aspects of the tool.
2) Create a simple proof-of-concept game to showcase the tool.
3) Design user study and process both player and user study data.
1) Keylogger and Zoning
Thought Process
The temporal aspect of the tool is a simple keylogger. Designers can select any keys or anything contained under Unity’s Input API and set a period of time to track said keypresses.
The spatial aspect of the tool is game or mechanic-specific. In the case of our proof-of-concept, we defined the spatial aspect of the tool to be a zone count, checking the amount of items in each zone that were picked up every time the data is exported. If we were to consider another game, say an open-world one, the zones could be divided up by LODs and check the interactions that happen over each period of time.
The data is ported into Google Sheets and is updated over a period of time, only stopping when the game is completed. For each new session, a new sheet is created, with each sheet being identified by the version of the game and a timestamp. The data could be reworked to fit into a JSON file so it could be inputted into a spreadsheet program of the designer’s choice.
Results
The temporal aspect of the tool is incredibly simple, modifiable, and is able to be a standalone keylogger. That being said, it is a very simplistic keylogger, so it doesn’t take into account say mouse movements or analog sticks. The way the keys are also being logged might also want to be reconsidered, as they only count the keypress in the down state, so something incorporating the down and up state would be beneficial. Another more comprehensive keylogger could be used in this toolset, so long as the data could be easily exported.
The spatial aspect of the tool is unfortunately restricted to the game or the mechanic. That being said, most games would still use a “zoning” concept, in terms of counting the amount of objects or interactions in said zone ID block. However, most of that code could still be usable for circumstances outside of this proof-of-concept, it’s just a bit less modular than the temporal aspect.
2) Katamari-like
Thought Process
In order to both make a game in the amount of time allotted to me, as well as to have a concept with minimal controls that was easy to pick up, I decided to make a Katamari-like. Players roll a ball around a level in order to pick up items; once the ball reaches a certain size, the player ends the game. Items available to be picked up are highlighted, with larger items being unlocked the larger the ball is.
The game has 2 versions: 1 where every 30 seconds you must swap between using WASD and the arrow keys (the experimental group), and 1 where you are free to use both at any given time (the control group); it’s randomly determined which version is played.
Results
Players enjoyed the game, with the average playtime for the level being about 8 minutes. While those who played Version A (the standard version) couldn’t comment on the control-switching mechanic, those that played Version B (the injury-aware version) found the control-switching to be somewhat enjoyable.
3) Forms and Plotly
Thought Process
The user study was designed to encompass a general audience, including those who played the game and those who haven’t, as well as general players and game designers. It was split into 3 sections: questions relating to the proof-of-concept, general questions relating to the relevancy of the tool’s feedback for players, and lastly questions about the relevancy of the tool to designers.
Plotly was used to interpret the data recorded from the tool. The data from the tool was turned into a heatmap to show the finger usage over time, display the hot spots of activity that could potentially retooled.
Results
Overall, results from the forms indicated that players enjoyed the game, no matter the version they played. Both players and designers entertained the idea of receiving feedback regarding their playing habits, with designers finding the idea of the tool effective at evaluating the design of a game’s mechanics or levels.
The tool acts as a successful prototype of how we can craft more injury-aware games in the future. While there could be many improvements to make the tool more modular or to remove it from exclusively being in Unity, it stands as an example that can be improved upon by other developers. The paper was accepted to a conference pertaining to gaming’s impact.
Links
Here are multiple related links to the project: