Jehan has put together a [partially cheesy] mid-development production review for this week’s blog post based on a process and scope review team meeting.
Monday marked the beginning of our 9th week of development, and the first day back from spring break! A majority of us were too afraid to stay in Pittsburgh by the wintery weather… except for a single brave programmer and creative director who endured.
Both of them took time over the week to begin early compatibility testing of our build and experience in the actual hardware in the Kenner room, especially how our experience looks and feels using the three projector array. We now have the basic pipeline established for regular on-site testing in the Kenner Room, and have confirmed that our volumetric capture hardware works will with the computer it will go live on. like the ideal positioning of virtual cameras, and methods to seamlessly render objects in motion between two projectors, and how the different visual and particle effects feel– Thanks Wei and Ju!
On how technology affects the style of the experience, and Old v New Render Pipelines, Unity HDRP.
Our first priority moving forward is to migrate our current project into a new version of Unity (HDRP) that supports much more because using the new pipeline will affect the visual/audio aesthetic of our experience: not only how the “Stranger” is ambiguously represented in particles, but also it will affect the overall visual language of our experience, like the interface, shapes, and even typography. By the end of the week we’ll know which pipeline (old or new HDRP) is most feasible and best-fit for us, and will be able to build out a unified visual language from end to end.
The team has also pivoted our main focus from designing a system based mostly on user generated content towards one in which an initial pool of known individuals are permanently embedded within the experience, with user generated content “sprinkled” on top. This eliminated a great deal of design constraints we had centered around structuring meaningful question sets and types that could allow for random user input.
Consequently, researching and sourcing the initial pool of humans (the “OGs”) will go hand in hand with refining the final question and answer sets that we present to the guest. We need to ensure that the OGs are a diversified mix of individuals of multiple ages, genders, backgrounds, and cultures. Finally, by pivoting towards pre established pool of diversified individuals, we avoid potential complications associated with systems relying on User Gen content (i.e. the same person going through the experience multiple times) as well as production heavy tasks like database management of user gen content and balancing for the player experience over time.
Moving forward, our next priority is nailing the right user journey and setup to successfully land our takeaway message. this is suuuper important to consider sooner than later, especially because the team doesn’t have a solid grasp of what what the end of the experience will look and feel like and we are quickly approaching the end of development. This message is also dependent on the visual style of the new render pipeline system and the OG pool of participants/associated questions and answers.
And then there’s audio. So far, no audio has been integrated into the experience because we haven’t had the time to produce it in-house. Fortunately, a good friend that I’ve worked with and fellow ETC student Kristian has agreed to do sound for us. He will be working on the SFX and BGM through the remainder of the semester.
Design will be looking into new or variant interactions with the user within our experience, like the like the confidence circle/zone our client has brainstormed before spring break, where users can place assumptions they are more sure about in a “very confident” zone as opposed to less sure in a somewhat confident zone, etc.
For install, fabrication of the camera and mic housing will take no longer than a week once we are settled on a visual theme, which I’m personally very excited about.
Documentation for the client, including general contents were also discussed at the meeting. 8 is doc for client which we should be mindful of moving forward (do they have enough info to keep it running after the handoff)
On the future production schedule:
If we are able to get a content and feature lock (for interactions, basic visual language, the final OG pool, final question/answer sets), by April 22nd, we can use the remaining two weeks of the semester on QA, bug testing, polish, and our final install. This means we have just a day or two over a month to wrap on our main production phase and lock design and content… these next few weeks are gonna be really busy.
Thanks for the read,
Team Kaleidoscope