{"id":316,"date":"2024-03-22T17:11:45","date_gmt":"2024-03-22T17:11:45","guid":{"rendered":"https:\/\/projects.etc.cmu.edu\/questure\/?p=316"},"modified":"2024-03-25T20:42:26","modified_gmt":"2024-03-25T20:42:26","slug":"week-9-mar-22-2024","status":"publish","type":"post","link":"https:\/\/projects.etc.cmu.edu\/questure\/week-9-mar-22-2024\/","title":{"rendered":"Week 9 – Mar 22, 2024"},"content":{"rendered":"\n

Design Challenge<\/h2>\n\n\n\n

Last week, we faced the challenge of balancing an engaging game experience with the research needs specified by our client. On one hand, we aim for a game that keeps players engaged and facilitates sign language learning through enjoyable experiences. On the other hand, our client prefers to minimize variation in individual experiences for more controlled data collection and analysis.<\/p>\n\n\n\n

We’ve developed two strategies to accommodate both gameplay and research objectives:<\/p>\n\n\n\n

A Toggle Between Normal and Research Modes<\/strong><\/p>\n\n\n\n

In agreement with our client, we’ve decided to keep the research and gameplay aspects separate, connecting them with a unique user code. <\/p>\n\n\n\n

This way, for research participation, our client can direct users to a Google Form survey. Completing this survey grants users access to the game and a user code. By default, our game operates in normal mode, but there will be an optional input box for users to enter a code if they have one. When they start the game and input this code, the game switches to research mode, automatically transmitting their gameplay data to our backend server for research analysis. Another benefit of this approach is we can track data for each user, regardless of the number of times they access the game, as each player is assigned a specific code. <\/p>\n\n\n\n

Additionally, our client has clarified how the data should be stored. We will initially save the CSV file on our localhost and then upload it to his Google Firebase server.<\/p>\n\n\n

\n
\"\"
Collected Research Data Example<\/figcaption><\/figure><\/div>\n\n\n

Parametric System<\/strong><\/p>\n\n\n\n

To address the distinct needs of research data collection and engaging gameplay, we’ve identified the necessity of different variable settings. For instance, in our second mini-game, the track speed was designed to fluctuate within a range, slowing down when players miss a letter to reduce frustration. However, from a research standpoint, a variable speed curve dependent on player performance and lacking consistency does not facilitate result gathering. So our client preferred a continually accelerating track without any slowdowns.<\/p>\n\n\n\n

To resolve such discrepancies, we’ve decided to implement a parametric system within our game. This system allows us to extract specific parameters (e.g., hold time, track speed increase rate, timer, elements on & off, etc.) for control. We could create a specific set of parameters tailored to research purposes, which our client can also adjust for future studies. Meanwhile, we could have another set of parameters with a gameplay focus, aimed at encouraging players to persist in playing and learning the ASL alphabet.<\/p>\n\n\n\n

Our client has agreed with this strategy and suggested a list of variables to control, including:<\/p>\n\n\n\n

    \n
  1. How many letters\/words people play with (all games)<\/li>\n\n\n\n
  2. Gesture hold time to move onto next trial (for all games).<\/li>\n\n\n\n
  3. Whether hint is provided or not provided (for all games)<\/li>\n\n\n\n
  4. Initial speed for game 2.<\/li>\n\n\n\n
  5. Amount of speed increase for correct trials (game 2)<\/li>\n\n\n\n
  6. Amount of speed decrease for incorrect trials (game 2)<\/li>\n\n\n\n
  7. Whether to show the hand landmarks on the screen (all games).<\/li>\n\n\n\n
  8. When to show the hand landmarks on the screen (all games).<\/li>\n\n\n\n
  9. If data is saved or not saved (all games).<\/li>\n<\/ol>\n\n\n\n

    We’ll finalize more details during next week’s meeting.<\/p>\n\n\n\n

    Model and Hint Image Iteration<\/h2>\n\n\n\n

    This Monday, our team conducted a workshop where each member recorded our gesture signs for every letter, creating new training data. We captured screenshots of our hands, converting each into a single line of landmark data. In total, we amassed over 140,000 new data points, adhering to strict standards for each letter. This will help establish a solid ground truth for our model, allowing us to incorporate more tolerance cases after playtesting.<\/p>\n\n\n

    \n
    \"\"
    Landmarks<\/figcaption><\/figure><\/div>\n\n
    \n
    \"\"
    Landmarks Data<\/figcaption><\/figure><\/div>\n\n\n

    With our model newly trained on the latest data, we’ve also updated the hint images to ensure they align with the model’s results. We opted to present all signs from a consistent front angle, showing the perspective of a player looking into a mirror. For letters with critical details visible from other angles, such as “G” and “H,” we’ve included smaller images to highlight these specifics, as demonstrated in the right-hand version examples.<\/p>\n\n\n

    \n
    \"\"
    Hint Images – Right-hand Version<\/figcaption><\/figure><\/div>\n\n\n

    We will create two sets of hint images, one for the right hand and another for the left hand, essentially mirroring each other. To ensure accuracy in shape and direction, we took screenshots of ourselves performing the signs and then traced the outlines in Adobe Illustrator.<\/p>\n\n\n\n

    \n
    \n
    \"\"
    Trace Process I<\/figcaption><\/figure><\/div><\/div>\n\n\n\n
    \n
    \"\"
    Trace Process II<\/figcaption><\/figure><\/div><\/div>\n<\/div>\n\n\n\n

    Mini Game 2 Update<\/h2>\n\n\n\n

    Environment Layout<\/strong><\/p>\n\n\n\n

    In response to last week’s feedback on the environment in mini game 2, we explored three approaches to align the setting more closely with our narrative.<\/p>\n\n\n\n

    Firstly, we adjusted the proportions between the cat and the buildings to enhance the miniature effect, moving away from a realistic city appearance.<\/p>\n\n\n

    \n
    \"\"
    Approach I<\/figcaption><\/figure><\/div>\n\n\n

    Secondly, we experimented with procedural modeling in Houdini to create the ambiance of a Lego block city.<\/p>\n\n\n

    \n
    \"\"
    Approach II<\/figcaption><\/figure><\/div>\n\n\n

    Lastly, we introduced real-world objects like toys and bottles into the miniature environment to disrupt the realistic vibe. The proportions shown in the following image will also be refined.<\/p>\n\n\n

    \n
    \"\"
    Approach III<\/figcaption><\/figure><\/div>\n\n\n

    Upon review, we believe the third approach may offer the best outcome and is the easiest to implement. We plan to update the skybox and introduce an intro animation that sets the scene with the cat dreaming about racing through the miniature world.<\/p>\n\n\n\n

    Track Speed<\/strong><\/p>\n\n\n\n

    As mentioned in the first section, we will implement two different sets of parameters for the track speed change rate, each set corresponding to either a research focus or a gameplay focus.<\/p>\n\n\n\n

    Demo<\/strong><\/p>\n\n\n\n