我們最初嘗試以手機應用程式為基礎創作演出，是從《行為淪喪》開始的。那個演出的前半段是基於手機應用程式的音頻導覽，包含一些簡單的選擇題功能。一年多之後，我們創作了《消失的海岸線》，整個演出都需要依賴應用程式運作，互動和結構也更為複雜。在製作這兩個演出的過程中，我們對於手機應用程式在劇場中的應用有了更深入的理解，能夠更好地利用新興技術帶來的可能性。
為什麼使用手機應用程式？
使用應用程式的目的是為了解決某些問題。其中最簡單的問題就是硬體成本，觀眾自帶手機就可以當作演出所需的電腦設備。當然，這一點本身並不足以成為使用應用程式的理由，如果只是需要播放一序列音頻，使用MP3播放器就可以完成，無需開發應用程式。
另一個我們試圖解決的問題是互動性。傳統劇場的互動性通常都很有限，因為同時能夠「互動」的觀眾人數受到演員/工作人員的限制。而其他形式的「技術」互動，如《Ontroerend Goed’s Fight Night》中使用的無線投票系統，可以突破這一限制，但受限於系統本身的設計，互動方式通常也比較單一，如簡單的選擇題。
我們也嘗試利用現成的應用程式(如WhatsApp等即時通訊軟體)來促進互動，這樣可以開拓更多種類的互動方式，連接觀眾之間，創造更多類遊戲的選項，甚至傳送圖像和音訊。這種方式很不錯，因為它是免費、可靠、安全，而且無需任何編程知識就能設置。但它仍然需要人工管理，最終還是受限於單一演員同時處理多少互動的能力。
要進一步突破這一限制，應用程式本身需要具備某些特定於演出的邏輯處理功能，管理在某些時間點或某些情況下應該採取的行動。這樣應用程式就可以承擔處理所有基本互動和計時，以及協調「真實」演員互動的任務，從而大幅增加可能的互動量——但這就需要開發一個定制的應用程式。
從《行為淪喪》到《消失的海岸線》的應用程式劇場
為了探索以編程手法進行敘事，我們很受到「選擇你自己的冒險」和角色扮演遊戲電腦遊戲的啟發。《行為淪喪》是這一概念的開端，建立了一個提供基本選擇題選項的機制，有點像是較線性的老派RPG。《消失的海岸線》則是在此基礎上的進化，就像RPG遊戲從線性發展到開放世界一樣。這種形式上的自由使得敘事更加具有挑戰性，需要創造的內容大量增加，同時也增加了不同觀眾可能會經歷的可能性。儘管存在挑戰，我們還是決定沿著這個方向發展，因為它更適合《消失的海岸線》的內容，該內容受到了後結構主義和元小說的啟發。
在使用新技術創作劇場作品時，我們最大的挑戰之一就是找到讓技術真正服務於演出功能需求，而不是只是表面修飾的方法。但是整合這樣的技術涉及更多的風險。如果「技術」只限於背景的投影等，即使出現故障，演出也能繼續進行，觀眾可能也不會注意到。但如果「技術」負責整個演出的結構、時間、位置和音頻，一旦出現故障，整個演出就無法進行。因此，儘管這種方式使得技術的應用更加融合和創新，但整個創作過程也充滿了恐懼。
《消失的海岸線》的開發
在開始為《消失的海岸線》進行創意會議時，我還不太確定技術上的可能性。那時我仍在計劃創造一個不需要互聯網連接就可以運行的自包含應用程式，更像是一個包含MP3和基本GPS地圖的選擇題式冒險遊戲。大約在演出前4個月，我製作的應用程式雛形還只是一種定制的谷歌地圖功能加上一些音頻能力。
然而，在創意會議中，我們一直面臨著如何組織觀眾，以確保不會有40人同時擠在一個小房間的問題。我們提出了一些涉及概率的方法來儘量降低這種可能性，但無論我們做什麼，如果手機之間沒有連接，還是會存在整個觀眾群都聚集在同一地點的可能性。
由於團隊大部分成員缺乏相關技術經驗，他們的想法並未受限於他們認為可能實現的範圍。即使我本人也有一些從《行為淪喪》開始積累的經驗，我也不太確定在短時間內我一個人就能實現什麼。一些看起來簡單的想法，如「讓手機彷彿在特定時間接到電話，並播放相應的音頻」，在我看來只是界面設計的問題，但在他們看來卻幾乎是不可能的。而一些看起來更簡單的想法，如「向離某個位置最近的4名觀眾發送通知」，實際上要複雜得多，因為要計算最近的4人，需要實時獲取所有觀眾手機的位置數據。所以我不得不建立一個資料庫來實時存儲手機數據，並確保每個人都有網絡連接。幸運的是，由於觀眾人數較少，我們能夠使用Firebase的免費版本作為資料庫，設置起來也相對容易。
有了資料庫之後，一切管理起來都容易多了，我們也能夠在不需要更新應用程式的情況下，通過從資料庫獲取數據和音頻來對演出進行根本性的變更。我們能夠在演出過程中即時觸發和調整時間，以防出現任何問題。基本上，我意識到應該先從資料庫開始構建一切，我不得不重寫到目前為止所做的所有工作。這是我的一次很好的學習經歷，不僅對於這個演出，也使我對其他應用程式產生了更多想法。但同時也很可怕，因為我是第一次學習這些，卻要立即將其應用於必須完美運行的實際演出中。
應用程式的功能
詳細介紹每個功能可能會很枯燥(或者只有少數人感興趣)，我想強調一下我認為最聰明的一些功能。
這個應用程式就像一個靜音迪斯科，每個人都同步聽到音頻(精確到毫秒)，但你聽到的內容取決於你的位置。演員在現場走動，他們的位置也被GPS追蹤。你可以在應用程式的地圖上看到演員的位置，以一個會動的有色點表示，如果你在一定距離內，就會聽到與該演員相關的音頻，音量會隨著你靠近而增大。
應用程式還有一個可交互的界面，顯示了九龍海岸線隨著填海工程的變遷。你可以滑動到不同的年代，地圖會顯示那個時間點的海岸線，以及你當前的位置。這裡有一種微妙的音景，試圖根據你與當前顯示的海岸線的距離，模擬海洋的聲音。
時間安排由應用程式負責，確保一切同步進行。觀眾會收到電話，地圖上會出現新的點，新的功能會顯露，有時這些會同時發生，有時則根據到達時間或位置而定。甚至還有一套系統，用於處理需要兩個或更多人保持在一起的情況(例如照顧者、孩子等)，可以在演出開始時設置。
所有道路上的電話號碼都可以在應用程式內撥打(它有一個類似手機的界面)，以聽取與該位置相關的音頻軌道。我們大部分是通過手工拍攝照片來收集這些電話號碼的位置資訊的，但如果有人撥打了資料庫中沒有的號碼，他們撥打時的GPS坐標就會被加入另一個資料庫以供後續檢查。這些數據之後會被添加回主資料庫，這樣我們就漸漸建立起了所有道路上電話號碼位置的完整資料庫——觀眾們幫我們完成了這項工作，而他們自己都不知道。
如果觀眾遇到問題，可以使用應用程式直接呼叫我們 - 我們也能獲得他們的GPS坐標，所以我們可以直接趕到他們的位置提供幫助。幸運的是，這種情況很少發生，除了有人要求電池充電器，或者偶爾有人second次觀看演出但應用程式沒有被正確重置。我們能夠立即趕到他們的位置，而不會耽誤他們的觀演體驗。
可以改進的地方
我們遇到的最大問題之一就是GPS的潛在不準確性。當我最初構建基於GPS的音頻功能時，我根據精細校準的距離來調整音量和方位，但在實際測試中，由於建築物和天橋的干擾，這種做法證明會造成觀眾的定向困難。這在平坦開闊的空間可能會很好用，但在香港這樣的環境就不太理想了。我不得不取消方位調整，大幅降低音量變化的靈敏度，這樣即使GPS不準確也仍能勉強運作。我考慮過其他檢測用戶位置的方式，從大量的藍牙信標到指定管理個人觀眾位置的工作人員，但最終我想我還是會轉向給予用戶更多的主動性，讓他們手動告訴應用程式他們的位置，而不是試圖完全自動化。
另一個在使用這種程度的技術時遇到的困難是時間。即使我們有超過常規排練期一倍的時間來創作這部作品，我一個人試圖完成所有的編程和測試工作仍然是瘋狂的，這意味著我無法像我希望的那樣參與更多創意內容的開發。由於技術方面和內容方面是如此緊密地相互依賴，不可能先開發應用程式再找內容填充，所以兩個方面都必須同時發展。我認為這種類型的演出會從將整個過程分散得更多中獲益，以允許在會議之間有足夠的時間進行應用程式開發，但目前針對「劇場」作品的資助/排練模式並不真正適合這種融合新技術和內容的創作過程。當然，這並不會阻止我們繼續嘗試。
未來的發展
在我們下一個製作中，我將切換到使用React Native進行編程，這樣可以保持大致相同的代碼庫來同時支持iOS和Android版本。除了讓我保持理智之外，這也使我能夠更多地將東西整合到我們的網站上，並自動化一些像票務流程這樣的東西。更多內容即將發佈。。。