Week 4 began with going over the feedback received during quarters. We took their suggestions and clarified our game mechanics and went deeper into the exploration.
We wanted to understand better how we could capture analytics and what questions are we trying to answer with these analytics. We proposed that these analytics would be best acquired through a minigame.
Since analytics were being provided through a minigame, there was a further exploration on how we could get that minigame into our main prototypes. The prototype we wanted to further explore was the bull prototype.
We created a storyboard for this new hybrid game called “Hero Bull”. The game proposes a transition phase into a minigame to better collect those analytics.
In terms of analytics, we need to solidify more on what we could do and couldn’t do to get useful and insightful analytics.
Our first step was to understand the definition of each of the analytic and what it meant for our project.
We had the following propositions to the client on what those analytics meant to us. In addition, we built a few prototypes for how these analytics might be collected.
- Accuracy:
- How close you can get to a point?
- How many objects gazed at out of total?
- Gazed at object?
Client Response: How close were they to the centroid of that object?
The prototype for analytics:
- Are you looking at the correct object?
- Number gazed at / number of gazable objets
2. Precision:
- Can they get to the same point multiple times?
- What is their Repeatability?
Client Response: How clustered are there attempts? How true are these attempts to themselves? [Standard Deviation]
The prototype for Precision:
- Show the same pattern multiple times. What is the deviation from their prime pattern
- Force Gaze Away and Gaze back to where they were
Left Cube: Seen once, Top Cube: Seen 3 times, Bottom Cube: Seen 3 times
Format– Object: number of times looked at it
3. Smooth tracking:
- Can they follow a path?
- How deviated from the path are they?
- Can they follow an object?
Client Response: How close are they to following a path? How similar are there attempts to the dedicated path?
Our Prototype for Smooth Tracking:
- Time Taken vs. Expected Time to follow path
- Compare Gaze point Trajectories Vs expected trajectories. (Shape Matching)
- Follow a moving object. Time on Object/Total time spent
Each object has to be accessed sequential to count it as a valid move(turn into green). The size will decrease in the future so that it is harder.
4. Reaction Time:
- What is the time to get to an object?
- What is the time to click when on object?
Client Response: The Client was satisfied with these propositions
Game Implementations and troubles:
- Time to reach a Gaze Aware object
- Time to click that Gaze Aware Object: Not applicable to all of our prototypes or intial ides
- If we did the shoot via how long someone “dwells” on an object, we wouldn’t be able to get the time it took to shoot that object
- If the button just toggled the shooting, we wouldn’t be able to get that time to shoot either.
Iterations on Original Ideas
We expanded on the two ideas that the client expressed interest in. The bull and pilot ideas were expanded and playtested to understand what worked and didn’t work.
- Pilot
In the Pilot Idea, we explored different ways we could fire the asteroids coming at us. This was an exploration on what could be the best use of the click mechanic
- Toggle Fire
- Dwell fire
- Click fire
- Lock Fire
Toggle Fire
The player would need to press the button to toggle between firing and not firing.
Playtest Feedback:
- No one liked it
- Unsatisfying
- People tried spamming click anyways
This was wonderful since the analytics for reaction time would have been difficult to achieve for this case.
Dwell Fire
Firing would only happen if you stared at the asteroid long enough.
Playtest Feedback:
- The dissonance between “close enough” and missing
- Disconnect between action and reaction
- Difficult as targets moved on-screen
This was a proposition from the client that could replace the click function in case there was no way the users could “click”. This gave an initial idea of what the fallback might be for this kind of interaction.
Click Fire
We also tried the classic click to fire. We had an initial understanding that this would be the best proposition especially for collecting reaction time analytics.
Playtest Feedback:
- Rewarding but tiring
- Framing helped
- Very familiar or easy to learn
Lock Fire
This was a mechanic where the guest just clicked to lock the item they had.
Playtest Feedback:
- Generally most satisfying
- Intrinsic motivation: Lock all targets
- Liked the strategy aspect
- Fewer clicks, and more power
Lock to fire was an interesting mechanic but it was also much more complex to develop. There was a debate whether it would be worth pursuing a more complex and non-intuitive mechanic.
2. Bull
For the bull we decided to see if flinging in an arena would have been fun.
We understood that flinging was enjoyable so we thought it was important to show those flings and have the ability to fling multiple objects in the player’s perimeter