A few weeks have passed, and I wanted to wrap up the work we did on Ter(li)minal from September!
Our end result was a space in which we sought to place the participant in a liminal space, forced into a sense of waiting. You are constrained by lack of movement and lack of activity, only able to observe by looking around and rotating your head. Upon starting the application, the user sees a space sparsely populated by seated and walking figures. As you wait, small changes begin to occur. Once empty seats are filled with figures. Seated figures may change positions when you look away. The departure board gains more and more red delayed flights as time passes. Babies scream, planes take off, the space becomes more chaotic and crowded with each delay announcement. Figures began to break away from their straightforward march along the walkway and defy gravity, floating through the ceilings and moving sideways out to the planes landing. Finally the scene calms as the boarding call is made, and the player is allowed to move on.
In the process of development, I learned a lot about linking layered timed events in Unity. Once the sightline script was functional and able to be applied to multiple objects, it became a matter of making sure these events were allowed to occur at the proper times in the application. I had to go back to the basics: public booleans and instantiations. The sightline function ended up working out due to a tip from Alan to use Transform.InverseTransformPoint instead of the function with the frustrum planes. I was able to get the function working that same day and then it all became about timing. Sara made a rhythm chart for the project that I based all of the interactions on:
Some critique points that came up:
Move camera back. The player’s face is too far forward over the model, and it’s nearly impossible to see the models placed nearby.
Add interaction to the models around the player. The boarding pass, phone, and books around the player were actually supposed to be moving. I ran out of time and just didn’t make it around.
The departure board is very hard to see. In our presentation, we talked a lot about being able to see these subtle changes in the environment around you. But the departure board was placed so far away that it was difficult to read and see these changes as they occurred. Moving it to one of the pillars by the player might be more effective.
Animated figures- be more intentional. Some technical issues came up with the loops on the animations and timing them out. While the number of figures does increase over time, it’s difficult to see once they start walking through the floors and ceiling. This happens fairly quickly- waiting for more time to pass and spacing out these occurrences would make it feel like less of an accident (although… to be honest… it definitely was an accident).
Line renderer on the objects seems to glitch a lot as they walk, gets confusing and difficult to see the figures.
Audio. Needs to be louder overall- very hard to hear on the phone even with headphones.
Overall I was very happy to learn the process for android development and get to work a bit with the Daydream. It was much easier than expected and very quick to prototype. I would like to revisit this in the future and make adjustments, though that may be more of a Christmas personal project. Learning about the sightlines is going to be especially useful for our 10 Week Ruby Bridges iteration that Tori and I are currently getting started- but the journey for that so far deserves its own post. More soon!