Development Blog

Week fifteen update:

As the semester comes to a close, we have spent the majority of our time this week finishing up our documentation, polishing the build, and preparing our project to be shown in final presentations/walkarounds.

Our tech team has been working on ironing out small quality of life changes to the final build before we submit it, mostly to ensure that Jess H. will have an easy time using it in the future. In addition to this, we showcased our (almost) final build at the ETC fall festival, getting around 50+ guests stopping by to try our experience! Things went relatively smoothly for those demos, and it was a great opportunity for us to test the robustness of our build.

As far as documentation goes, we have been organizing and uploading the final pieces of our data inventory to Box and plan to send it out to faculty before our presentation on Monday to give them a little bit of extra context to our work. We’ve also been working on filming our demo video, trailer, and finishing up our post mortem for ETC archives.

We plan to practice our slide deck for final presentations on Sunday when our teammates get back from SIGGRAPH Asia, but in the meantime, we have been finalizing content and formatting so everything is ready to go when they hit the ground in Pittsburgh.

In the coming week, we will be wrapping up the project semester and we plan to continue this project in the spring through helping our client, Jess H. write a research paper. In addition to this, we plan to submit our project to CHI to demo it in the coming year.

This concludes project Abode’s fall semester!

Week fourteen update:

In week fourteen we have been busy showing our project to faculty for soft opening. In addition to this, we have been tweaking the build based on softs feedback, started work on our finals presentation, and have been testing the most recent entry/exit systems on Wednesday, and Friday.

Our feedback from soft opening was mostly positive. Faculty were able to understand the experience and what we were designing for in entry/exit systems. That said, we could do a better job of showing faculty how exvitation works – due to limited time in the soft opening presentations, we decided to run the experience in a more guided manner rather than organically letting exvitation happen. In addition to this, we need to emphasize that we’ve been testing this product by setting up scenarios between playtesters, which can contextualize the use of this product in the future.

Looking forward to finals, we need to keep in mind the softs feedback with regards to how we present our project. This means that we need to take the time this week and next to refine our finals presentation in a way that is clear, concise, and understandable. We also aim to share our documentation with faculty before finals since it’s such a large part of our deliverables, as well as to provide them further insight into our project.

Week thirteen update:

This week a couple of us have been out of town for the Thanksgiving break. That being said, development is still happening.

Our tech team is working hard this week to get a build ready for softs that has our menu UI implemented as well as a couple more entry/exit prototypes to test. These prototypes include: Magic Wand, an improved Elevator, and a more refined Level Streaming.

The design team has been working on starting the documentation of our design process this semester – detailing out our decisions from the first prototype up until the end of the semester. This will ensure that we don’t have to rush documentation, especially since it’s one of the big parts of our team’s final deliverable.

In addition to this, our researcher has been prepping for scheduled playtests of the Magic Wand and Elevator prototypes over the weekend before softs. This will be an IRB certified playtest, so testers will be signing consent forms and the data will be kept private. That being said, we plan to share general learnings with the faculty on Monday at soft opening.

Week twelve update:

This week we have been doing some catch up while our programmer is out. Thus we have been working on fixing up quality of life changes for our experience: re-aligning the Vive space, improving the visuals in the garden space, etc.

Our UI system has been implemented, and we are currently working this Friday to get Level Streaming, and Elevator systems implemented for our first set of IRB testers.

Responses thus far have been fairly decent, in checking up on the flyers we posted many tabs have been taken, and we’ve gotten 6 replies to the vrhome email address. We’re looking forward to testing our new entry and exit systems with them.

Looking into Thanksgiving week, we will be team partial – however our programmers will be around, polishing the build to a presentable state for softs on November 26th. We plan to have Level Streaming, Elevator, Magic Wand, Virtual Virtual Reality, Magic Door, and Hot Air Balloon ready to show for softs. A couple of these are likely to get pushed to after softs, but this next few weeks we are going to delve into development.

Week eleven update:

This week we have been working on our new entry/exit prototypes in anticipation of our programmer being out for interviews. As mentioned in last week’s blog post, our designers have been creating implementable prototypes of Elevator, Level Streaming, and have started on a Magic Wand prototype.

Magic Wand involves using a wand prop as an invitation, and giving more agency to the guest to create the portal/mode of transportation into the host’s space.

We plan to implement these in week 12, and test them when our programmer comes back.

In addition to these prototypes, we have made progress towards our final deliverable. We have set up a UI framework to allow the client to choose between different entry/exit methods so they can get a good overview of the project.

This will also allow us to make our experience more hands-off which will help with playtesting, reducing user buy-in to the experience.

We have also started recruiting playtesters from outside of the ETC via flyers. We are hopeful that by getting good outside users we will be able to collect more useful IRB certified data.

Week ten update:

This week we have spent time taking in feedback from halves and developing groundwork to launch us into finals. Now that we have an idea of what we want our final product to look like, we brainstormed some quick ideas of what entry and exit systems we still haven’t tested. This week we have selected a few of the ideas to begin implementing: Elevator and Level streaming.

Our tech team has been working on overhauling our multiplayer framework. Previously our prototypes ran two different scenes for the guest and host, and when the guest connected they would be loaded into the host’s scene. Now, this is how it would ideally work in the future – but we have been running into a lot of problems with the loading times for the guest that detract from our experience. In addition to this, running everything in multiple scenes makes it harder for the designers to create features in a single player environment and send them off to the tech team to get implemented. Thus, we are rebuilding our framework to have both the guest and host in the same scene, just in different parts. When the guest accepts an invitation, they will be moved to the host’s area of the scene.

This overhaul will greatly help our designers create single player prototypes for entry and exit that can then be used by our programmers as reference for implementation in the networked build.

In addition to creating these single player prototypes, our design team has also been working on refining the garden space. This is the first virtual space that our team has built from the ground up, and we have been testing variations internally among the team to iterate on the comfort and layout of the space. By early next week, we hope to begin testing entry and exit methods in it.

Speaking of playtesting, we have after halves begun to pursue conducting research under IRB certification so our client can reference the data we collect. Most of our playtesting and data collection thus far has been formative for us, informing our design process rather than being ultimately useful for formal documentation.

In addition to this shift in our playtesting, we have gotten started on documenting our work up until this point. We have created a folder on CMU’s Box to afford us security for playtest information, and have begun organizing work and documents into a master data inventory for ease of use.

Moving forward, we hope to finish our next testable build midweek next week and start testing in earnest that weekend.

Week nine update:

This week we have spent most of our time preparing for halves and formatting all of our information in a concise, easy to read fashion.

In addition to prepping for our presentation, we have also crystallized a lot of concepts that we formerly worked off of as assumptions. For example, our master diagram:

As well as illustrations on how the host and guest spaces match up conceptually:

As far as feedback goes from our halves presentation, we felt like we did a decent job showing off our progress so far, and we got a lot of useful feedback:

Plus:

• Seemingly simple, but important topic in this area.
• You’re exploring some interesting VR etiquette issues.
• Door mechanics is very neat, well thought out.
• Srujani’s dress is fire 100% (Sahar)
• Good choice putting portal outside.

Minus:

• The current avatar choices seem like weirdly blended gender characters that don’t quite read well. (Could go more simple, think of Nintendo Miis)
  • Your avatars aren’t diverse, they all look like boys with lighter skin tone; how are you addressing identifiability and avoiding uncanny valley?
  • Avatars don’t address customization or personalization features – are you doing lip sync too?
• Could explore more general social cues on how you cue people it’s time to go.
• Portal outside of the door seems like a problematic choice in terms of interactions; coming and going is tricky.
  • Could also use lighting to reinforce the exit rather than a timer.
• Explore roles of host and guest more (i.e. family, strangers, neighbors, etc.)
• The context for having conversations doesn’t always seem considered well.
• Need to explore how MMO’s explored these issues.
• Not clear on playtesting data.
• Seems hard to test exvitation when your playtesters don’t have a task they are planning to do after the guest leaves. Maybe introduce a scenario?
• How do you plan on having a guest know that they should leave? What if they miss the exvitation clues? What if the host/guest do not want to stop interaction on exvitation?
• Are the notes too text-heavy or hard to read?

After compiling this feedback, we decided to sit down and outline what we want our final product to look like at the end of the semester:

Documentation of playtests:

• Playtest data (raw data)
• Conclusions/Observations from each playtest (per prototype or per test??)
• Video Archives
• Transcription of interviews?
• Refined timeline/master diagram of entry/exit.
• Archive of design artifacts.

Final Product:

• Host has a list of methods that they can choose for entry/exit of the space as a showcase.
  • Categorize them based on different aspects – asynchronous, or best for family/close friends, or non-committal visits, etc. Think difference between letter/text/phone call.
• Host can choose which environment they want to be visited in – garden or hearth space.
  • We can use this to investigate the different social dynamics surrounding entry/exit of spaces of varying privacy.
• Guest should have a distinct home space to start from.
• Additional part of our timeline that is missing – gifting.
  • Props that can be picked up and rearranged – persistent in both spaces?
• Users should be able to tell what objects are actually in the physical space.
• Interactions: Decide something and stick with it.
  • Interaction doesn’t have to be meaningful – it just needs to contextualize the exit.
  • Keep 36 questions.
  • Scrapping garden interactions.
• Entry/Exit
  • Should work for both spaces.
• At least one environment that is very well refined.
  • Refined hearth/garden space layout: consider angle, position of chairs, host/guest dynamic, etc. How to highlight what exists in which physical space.
  • Aesthetic presentation, things that guests can look at and talk about.
  • Potential Question: “How will users in the future sync up with each other, etc?” At the very least, we make the assumption that people will have a chair in the space.

We have a lot of work ahead of us till finals, but we feel confident that we can pull through.

Week eight update:

This week we have been gearing up for halves presentations. In addition to this, we have worked on running a couple last minute tests on polished aspects of Hearth.

With our Hearth prototype, we have been testing the new UI system involving the television, giving agency to the host to summon portals that provide access in and out of their space. With the addition of portals in this week, we have also been testing whether or not portals inside the home space or outside the door feel more comfortable to users. Most of our conclusions about the invasiveness when teleporting were proven correct by these playtests – even if the teleporter asset is present in the space, it doesn’t provide enough feedback for users to understand when guests were about to enter the space.

Putting the portals outside the door made more sense overall – they added a layer of privacy and especially in the exit sequence, helped users understand that it was the boundary/gateway for the space.

In addition to this, we have our first draft of the garden space up and running, and tested it on Friday for comfort and how users felt in the space.

In general, there is a bit of work that needs to be done to refine the garden as a space that people would want to occupy for long periods of time. This is something that we believe we would be able to do mostly internally for now.

Week seven update:

Week seven we have been taking some time to re-establish our lines of communication. We realized after meeting with faculty for Quarters that we have a lot of opportunity to streamline our development process. So moving forward, we have developed a master diagram to keep everybody on the same page regarding the experiences and tests we plan to run as part of this project. In addition to this, we have established more concrete methods of communication regarding accountability and task responsibility, as well as who to talk to when work is blocked.

(Purple is part of the experience guided by the host, pink is for the guest, and blue is when both users are involved)

Our design team has been working in tandem with our programmers to get the teleportation in and out of the VR space implemented to a testable state for us next week. This idea is based off of the concept of making the foyer (defined as space in between the guest’s home and host’s home) more permanent and defined. In a way, the teleporter as an object in the virtual space establishes a more clear threshold between virtual spaces, providing a definite beginning and end to the home experience.

We have also begun to get our first art assets in from the outsourced artist:

For our virtual prototype, coming up on the end of this week we have been working on implementing a simple UI system as an invite mechanism; a television that goes above the fireplace which the host can use to invite a guest. This will not only consolidate all our UI into one area, but will also be more immersive than floating text in the space. It also provides us with the opportunity to display messages “in-context” to the users.

This week we have also experimented using the Vive Wireless Adapter for our experience. After taking a little time to set it up (it requires a separate network card), we tried running both Beatsaber and our two player Hearth experience in it. Overall, the Wireless Adapter is a huge plus for convenience and comfort, but it detracts too much from the resolution and framerate of our experience for us to justify using.

Week six update:

This week we have really focused on honing our non-virtual experience prototype for the next sprint. Our designers have come up with a system that they want to test, primarily using a virtual TV that will display information on the inviter’s side. For the invitee, they will be pinged with the use of a watch, and if the invitation is accepted, they will be transferred to the host’s room via a teleportation beam. Instead of a knocking entry system, the system will play a sound effect to notify the host that the guest has entered the space.

Once in the space, the guest and host will have one simple interaction: 20 questions. This will be initiated via the TV – one person will see a word/topic, and the other person will see the number of questions they have left to ask. This is intentionally left free-form to allow conversation to take place around the various topics.

With regards to exit, we plan to have two indicators of the passage of time: the weather and a grandfather clock. Exit will be handled in the same way that entry of the space was – the guest will step into the teleportation beam and if they stay in it for more than 3 seconds, will be teleported back to their space.

On the tech side of our project, we have made good progress with our basic groundwork moving forward. We now have two separate spaces for the guests to start in – the host starts in the hearth, and the guest starts in a version of the meditation room. Currently our invite system is a little hacked, where we notify each other during the playtest that the host has sent the invite and one of us pushes space to pop up the invite for the guest. Knocking is still being tested in our virtual prototype as well, and we have the addition of a simple ball object that the two users can interact with.

Continuing off of the ball interaction, we have also made interesting observations from our playtests this Friday and Saturday. Most notably, the addition of the ball has resulted in the two users having a common interact-able object in the space, and in a lot of the playtests the hosts (who were able to spawn the balls) would gift the guest the ball on their way out. Another interesting observation regarding the ball is that even if it reinforced exit rituals, it also became a magnet for the majority of the conversations in the hearth space.