{"id":241,"date":"2026-03-20T18:00:00","date_gmt":"2026-03-20T22:00:00","guid":{"rendered":"https:\/\/projects.etc.cmu.edu\/big-picture-studio\/?p=241"},"modified":"2026-03-27T20:34:35","modified_gmt":"2026-03-28T00:34:35","slug":"devlog-week9","status":"publish","type":"post","link":"https:\/\/projects.etc.cmu.edu\/big-picture-studio\/devlog-week9\/","title":{"rendered":"Week 9 – Creating the A\/B Tests for Navigation"},"content":{"rendered":"\n

This week, after 5 of the teammates returned from GDC, it’s time to mock-up our final gameplay! <\/p>\n\n\n\n

From last week’s game design in Pittsburgh, we got a final scheme to build up the full game structure. Our goal this week, is then to gray-box everything.<\/p>\n\n\n\n

<\/p>\n\n\n\n

The structure in detail<\/h2>\n\n\n\n

What is our game structure? Essentially, our main character Naiad, losing consciousness, in her ghost from, navigates loose structures of a hub-like space that gains access to both the spaceship and metaphorical realms. In the spaceship, she would collect items from an extended space from the picture frames depicting both hers and the earth’s pasts, and in the end, having unlocked inaccessible areas through the items collected, she would enter the final stage, where her relationship with the items and the other character (the robot) gains its emotional climax. <\/p>\n\n\n\n

The great thing about having things in the current structure is that it allows for emotional storytelling moments – each item, each frame, and even the character exploration, deepens the players’ understanding and relationship of the characters and story. <\/p>\n\n\n\n

This week, we refined the ending so it fit more tightly with the hub structure, so that the final experience development could be motivated by that ending, instead of the ending emerging from the development, which would be much less intentional in design, a stray from our goal to utilize our medium well.<\/p>\n\n\n\n

\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n

<\/p>\n\n\n\n

A\/B Testing<\/h2>\n\n\n\n

The team is enthusiastic and excited to build up this structure, so we can focus on polishing it as fast as possible. However, while building the navigation mechanic, where the main character moves around in our defined space, we felt the need to explore two drastically different ideas. It’s sort of like the two ends of a spectrum. Our hypothesis is: once we test the two in full, we’ll get an understanding of what balance of connection and rotation, as long as the amount of controller and display phones, would be best for our intended players.<\/p>\n\n\n\n

Prototype A: This focuses on rotation<\/strong> as the base mechanic, where phones act as controllers to the display phone, and alter some state it has. Here, one controller phone controls the orientation of the display phone’s camera, and a second controller phone dictates the zoom (only certain items are zoomable). Upon zooming in on an item of interest, a picture frame puzzle moment or a narrative focal point moment would be triggered. Connection is not abandoned, but is used to connection picture frames, instead of extend the space. (Yet!) We realized this never allows for change of controller \/ display phones, as the main content will stay on one phone. We also realized that this currently does not showcase the wow factor of seams blending together. However, this solves a core problem we had from our before-halves prototype — the player action is now much less choreographed<\/strong>, instead of us fixing their pinching order, the interactions with the contents on the phone is much more fluid. <\/p>\n\n\n\n