HowRU Gamified Tasks

Jake Campbell

Quincy Stokes

Phuong (Mai) Luong

Steven Gorlicki

Ethan Wood

Chris Cheng

Development Process

Working with Our Sponsor

We collaborated with Dr. Katharine Simon and the SLEEP Lab at UC Irvine to ensure our development aligned with the research goals of the study. Dr. Simon was very involved at the start of the project and helped provide us clear direction, allowing us to gain a better understanding of the problem at hand and the research restrictions we'd need to work around to have success developing within the research space. Since we initially had limited understanding of the study's scope, we took the time to learn about Dr. Simon's research background and her goals for the project. This guidance was essential in helping us translate her research needs into actionable design decisions.

Project Phases

Phase 1: Design Sprint

Our team immediately began the capstone project by conducting a Design Sprint using a FigJam Board to organize and document our thought processes as a team with no prior experience working together. The time invested in the Design Sprint enabled 3 key advantages once we began developing a prototype of the Microgame Prefab Architecture.

Shared expectations about the purpose, quality, and effects of our contributions. This includes the self-evaluated strenghts and weaknesses of members and what they wanted to get out of the project in terms of their personal development in the form of Radar Graphs (see left).
Deep understanding about the goals of the study that the application is built and maintained for, including existing challenges and architectural decisions.
Clearly documented processes on how we arrived at our solutions, including slide deck for feature pitches, and high level diagrams documenting workflows and template structures for reference when doing technical work (see below).

The Design Sprint was key in accelerating our productivity over the duration of the project. The initial work we put in to document our decision making processes made it easier to come back during retrospectives and articulate the lessons learned, specifically because we could retrace our thoughts.

Phase 2: Microgames (Initial Run, Pre-Testing)

Coming into this project we knew that the OSPAN task was not factored for games, we just didn't know how much work would have to be done to make it microgame accessible. We were able to quickly make a few microgames but found that they weren't showing up in the OSPAN task. The team found out that this was because the previous way that OSPAN was made was through a figma plugin which made everything a UI element. This took up the majority of our refactoring time and required some internal changes to the structure of OSPAN, but once that was done it was home free to make as many microgames as possible while adhering to their requirements.

Phase 3: Testing & Refactoring

After we met our requirement for a minimum viable product (30 minigames), we began an iterative cycle of testing and refactoring to improve game quality and balance to help standardize both our individual minigames, and the overarching game system. Dr. Simon conducted regular in-lab testing sessions to gather data on individual game data, difficulty, and engagement with participants.

Minigame Refinements

System-Side Improvements

Some minigames were found to be too challenging or confusing, and many balance and instructional changes were needed throughout the testing cycle. Using feedback from our sponsor we adjusted mechanics and visual cues to help balance the difficulty of our games and make them more intuitive. For example, we introduced glowing outlines on clickable objects in some of our games, or feedback animations when the user made a correct action. These small but important changes helped guide players to having a better understanding of the game and feedback that they were playing correctly.

Beyond individual games, we made several changes to improve the overall gameplay experience and clarity based on testing feedback. One of our most important adjustments was simplifying the letter screen background to reduce visual distractions during the memorization phase, as any interference could affect cognitive results.

To create a more seamless transition between letter screen and the microgames, we introduced standardized game borders that visually seperate each game from the surrounding system. This helped signal to players when a new game was beginning, while reinforcing the structure of the task.

Phase 4: Merging & Cleanup

This was the last task that we set out to do. The team knew that we wanted OSPAN to be in a better spot than when we found it. Coming into OSPAN there were over 80 branches on Github and we had to parse through the madness to see what needed to stay and what needed to leave. Part of our cleaning up process was merging our staging branch into the main branch and getting rid of unnecessary branches and making the process to edit OSPAN much more streamlined.

Design & Implementation

A small selection of the 44 total games we produced during this Capstone project.

Challenges & Solutions

Addressing Technical Debt

The team inherited an overwhelming code system, made up of more than 150 different working branches. We resolved to work on one unified branch (IAmFineStaging) in order to minimize contributing to additional overhead. All personal test branches initiated off of the unified branch were reviewed at the end of the project and deleted.

Dr. Simon and the SLEEP Lab were notified of the excess working branches at the end of the HowRU project and will independently resolve the branch overhead. Future development teams will likely inherit a much more lightweight and streamlined code system.

In addition, a standardized BaseMinigamePrefab Unity game object was created in order to enforce consistency and unification within the minigame development process - it consists of a standardized Canvas object that holds an Instruction Text, Gameplay Holder, and UI Holder. Development of a new minigame always begins with duplication of a BaseMinigamePrefab, which helps to greatly reduce game development time.

This architectural decision was solidified early in the development process, and now allows any future Capstone team to immediately jump into the Unity project and continue to make additional minigames at once.

Learning Unity as Team

Most team members were new to Unity at the start of the project, making even simple implementation tasks challenging.

We used a gradual approach to learning, starting with pair programming before shifting to solo game development. Senior game development team members, as "flex" members were always available for help.

All team members gained confidence and experience with working with Unity.

Game Balance

Although it was a challenge to develop games that maintained research validity while engaging our users, we managed to complete multiple rounds of user playtesting in order to revise the minigames in line with our sponsor's feedback.

The SLEEP Lab will continue to refine game balance during Summer 2025 and beyond, such that Dr. Simon's envisioned goal of playability (and thus researchability) for kids as young as 5 years old is truly realized.

Designing with Research Constraints

At the outset of the team design sprint, it was clear that games needed to be short, but variable length (3-10 seconds) and of similar difficulty. In addition, we were working in the context of a limited input scope, because tablet input only allows finger taps and swipes.

We settled on designing and deploying infinite single-mechanic minigames that directly engage user active memory in diverse ways without completely distracting the user from the letter memory task at hand.

On top of all of this, the gamification of the task couldn't influence user behavior. In the original memory task, users solved math problems, but were not informed whether they were accurately solving them or not in order to not influence their behavior. In order to preserve this aspect of the study when mapping it to a video game, this means that games could not contain a win-state or a fail-state.

Why Microgames?

During the Design Sprint, the team was able to leverage the domain expertise of the capstone partner, Dr. Simon, to gain further insight on potential solutions for gamifying the original memory task. The task needed to be an interfering task, similar to the Math-based interrupting task, so a simple video game would not be a valid solution, as user participants would recognize patterns in game mechanics, and ultimately learn how to complete them through muscle memory. In tackling this issue, as well as identifying the key goals of the team, we identified 5 main objectives our solution needed to meet.

Following these objectives, the team arrived at WarioWare Microgames because it met a lot of these objectives, and even achieved a few more interesting goals of replacing the original task.

In the event that a single microgame was not challenging enough to exist as an interrupting task on its own, its implementation in a queue with varied mechanics meant that the recognition of the mechanic being required of the player served as another layer of a distracting task.
Team members that did not have experience with Unity could learn and get experience in an environment where failure had lower stakes. This was possible because smaller games are quicker to prototype, develop, and test than a solution that involved a single, more complex game with multiple mechanics.

Evaluation

Testing

Playtesting officially commenced on INF 191B Week 5 under Dr. Simon's coordination. Multiple child playtesters were able to play multiple rounds of that weeks' newest game build. Afterwards, lab team members asked for feedback on each game and accumulated the results for further review.

Dr. Simon relayed said playtest feedback to the development team, and minigames were revised accordingly.

The feedback contributed important test data to the team's development progress - multiple games that seemed intuitive at initial deployment would later require additional revisions to ensure kid-friendliness.

It was a constant battle to find the correct middle-ground- it turns out that college students developing minigames for players as young as 8 years old is not as easy as it sounds.

Findings

Conclusion: Consistent User Performance between Original and New OSPAN Versions

As expected, preliminary test data demonstrates a corresponding decrease in letter recall percentage rates between the Original and New OSPAN versions.

Test data also shows a slight increase in recall percentage rates between the Original and New OSPAN versions, validating the use of video games in the context of maintaining user interest within broader academic research studies.

Final Product

HowRU Deliverables Plan

We were awarded the Informatics Division 2nd Place!

Pictured from left to right: Dr. Simon (Team Sponsor), Steven, Ethan, Chris, Quincy, Jake, Dr. Bietz (Team Instructor), Mai

Page updated

Report abuse