After our team made DesktopBuilder, we were all able to improve our development process. This was a fairly simple project to create, since some basic code was provided to us by the instructor.
Here’s our lessons learned:
What worked well
- Simple Programming Architecture
- We used some base code provided to us by the instructor, and the rest of the systems could all be made separately and integrated at the end: the Dog Counting System, the Dog Video System, and the Sound System were all only integrated at the end with very little effort. There was limited user interactivity, so we didn’t need to worry too much about bugs from unexpected player behavior.
- Gear 360 Camera was easy to use
- After we downloaded the app onto our phone to take pictures, taking pictures with the Gear 360 camera we were using was a snap (pun intended.) The app just worked, and being able to view our pictures and video after we took them to make sure we got what we wanted came in handy when sometimes we realized the picture or video wasn’t exactly what we wanted, so we could go back and take it again.
- Took all Videos/Audio/Pictures in one take
- We were able to knock out all the pictures and video we needed in one 3-hour afternoon, which meant we weren’t spending time doing reshoots. Getting the pictures and video we needed on the first take meant we could focus on doing the programming and testing the virtual tour experience.
- 360 Video Files are HUGE
- The file sizes for the 4 dog video files were massive: 15 seconds of video came out to around 100 MB. We had 4 total videos, so our final file size was enormous. Most applications that do 360 video stream the video from a cloud system rather than storing it on-device. Had we encountered any more dogs, our file size would easily have reached 1 GB or more, which is a lot to ask Android users to download onto their devices.
- Test Cardboard Build Setup Up Front
- On the final day, when everything was working perfectly fine in the Unity editor and the project was exported, the android phone wasn’t picking up the actual head rotation, completely breaking the game. After doing some emergency adjustments on build settings, we got the project working, but making sure that exported builds worked on android devices was something we should have tested earlier on in the development process.
- Unpredictable subjects can be difficult to photograph
- We had scheduled 3 hours one afternoon to go take pictures of dogs that were walking along the Lake Audubon path. However, there was construction happening on one end of the path and it was blocked off, so we only found about half as many dogs and walkers as we were expecting to find. To make a project on a short time frame, it might have been easier to take pictures and videos of subjects we could control.
- In addition, it was difficult to get the magic 15 seconds of the dogs standing just far enough away from the camera to be visible, but not too far away for them to be hard to see. We found they would take a sniff of the camera and then walk away, so you had an intense close-up of the dog, and then they would be disinterested and look elsewhere.
- Changing height of camera in VR can be disorienting
- It made sense to film the dogs at the ground level so you could see them better, but playing the experience in VR and shifting down to dogs’-eye view felt disorienting with the VR headset. Either all the photos should be taken at the dog’s eye view, or some kind of shift transition would have been helpful, rather than directly teleporting the player to the ground-level view.
These types of experiences are easy and fun to make, and although it might remind someone of a slideshow or short video, the interactivity adds a whole new flavor to the experience, making people feel like they are “really there.”