育心文具行

標籤: 活動心得

  • 全 12 活動紀錄

    全 12 活動紀錄

    全 12 是「中華民國童軍第12次全國大露營」簡稱。

    藉由中華民國童軍第12次全國大露營（以下簡稱大露營）的辦理，呈現我國新世代童軍的創意與活力，透過大露營的宣傳和活動，鼓勵全國青少年能親近大自然，讓童軍活動受到全國青少年的喜愛，提供國內外童軍交流互動平臺，以促進我國童軍和世界各國童軍的互動交流，強化童軍實作技能，提升童軍合作學習，以發揮童軍運動精神。

    在白天有提供給童軍伙伴跑站的活動，其中我的任務是在其中做一份簽到簽退系統。讓工作坊可以提供給學員打卡，除了回報給學員的分團支外，也提供紀錄、展示等用途（笑）。

    真的做了好久阿，去年年末到現在。這算是一份發願，看能不能給自己一個交代，於是最後產出了這份專案。

    GitHub – lazyjerry/scout12-20240711-20240715: 中華民國童軍第12次全國大露營-簽到簽退系統

    github.com

    中華民國童軍第12次全國大露營-簽到簽退系統. Contribute to lazyjerry/scout12-20240711-20240715 development by creating an account on GitHub.

    內容包含：原始碼、技術結構、優化清單、部署介紹。

    無論如何也算是得償所願吧，接下來看有誰要接下去做了。

    其中有許多需要優化修改的地方，參考這裡。

    可怕的是在活動前開始感冒，營隊幾天就咳嗽幾天，至今鼻涕和喉嚨還不太安分。而待在家參與活動這幾天，貢獻算是遠端提供協助並定時提供紀錄報告。於是趁這段時間寫了一份紀錄。

    — 寫於 2024-07-13 至 2024-07-16 , 板橋—

    Hi, this is Jerry.

    這個系統做得有點坎坷，需求和規劃並非一帆風順，而童軍運動也不是有給付薪水的工作（笑），針對吃程式設計這行飯的前後端人手似乎不太好找。這次的實作算是花費了 2024 上半年的很多時間，從一開始需求不清晰到開始找大流量的結構、研究比較服務、前端到後端實作在到配套規劃，中間也是吵吵鬧鬧的，所幸算是還拿的出來一個堪用的東西。未來如果童軍伙伴有需要使用，可以參考部署流程架設，或是想要自己實作的話，也可以抽換裡面的結構來做。 

    就希望這個作品當作一個拋磚引玉的作用吧。希望玩童軍的程式設計師都能有錢、有餘裕再回頭貢獻。

    規劃階段

    這系統原本是從 2023 年底以票務股開始，後來票務股給其他伙伴負責，轉變以數位系統實作為主。原本資訊混亂不清的時候，有滿多各種考慮和作法。

    這是開會筆記，滿多廢話的：https://docs.google.com/document/d/1htCP7UVHd2ug3Fjpj6QJhn2q84CZnRYljaCYXn-KxWo/edit?usp=sharing

    後來隨著資料明確，約 2024 年年初開始明確系統的用例，和大致上的需求規格，當時規劃的規格式：

    1. 參與工作坊的學員+其他人人數需滿足 8000 人規格
    2. 工作坊約 100 個以上。
    3. 4 天活動、一天活動 4 場。
    4. 場地（走馬賴）網路環境正常
    5. 配套規劃：網路壞掉、下雨、設備壞掉、操作有問題
    6. 工作坊有些不熟悉 3C 產品的伙伴，儘量減少操作錯誤的機會。

    於是開始規劃數位系統的結構和用法，因為預算有限，所以針對高併發的需求採用 cloudflare 的服務，後台系統使用現有的 production server 架設 LEMP 結構的前後端分離網站。製作有幾個目標：

    1. 降低未來前端、後端與第三方服務的耦合，使用 Restful API 溝通。
      1. 未來其他伙伴開發可以使用自己熟悉的語言替換。
      2. 服務有更好的替代方案也可以儘量以最少的修改替換。
    2. 不會與全 12 的活動過度綁定，更換為其他活動可以儘量最少的修改。
    3. 能夠防呆的 UX 設計就儘量做上。

    最後決定最佳解是：

    1. Cloudflare 付費方案（每月 5 美元），於六月底開始，預計七月中結束停用。
    2. Production Server 因原本內有現有服務運行，所以先調整規格，活動結束後再確認是否需調降。
    3. 現場運作後台的伙伴之外，配套規劃中安排

    最後除了程式之外，也產出一份包含配套方案的單項計畫書：

    scout12-20240711-20240715/文件/簽到簽出單項計畫書.docx at main · lazyjerry/scout12-20240711-20240715

    github.com

    中華民國童軍第12次全國大露營-簽到簽退系統. Contribute to lazyjerry/scout12-20240711-20240715 development by creating an account on GitHub.

    該單項包含了針對活動前幾天可能天氣炎熱、下雨等配套再另外調整，例如考慮到紙本潮濕等規劃用手機拍攝照片，再另行處理等動作。

    題外話，有一件令人費解的事情： Cloudflare Worker Service 提供免費的即時監控功能，在活動前以及撰寫本文的當下（2024-07-13) ，除了伺服器發出的同步流量支外，會查到來自非台南地區的流量（高雄、台中、台北）。

    2024-07-13

    全 12 運作第三天，今天休息，結束前兩天活動。

    有幾個狀況：

    1. 後台系統在現場只有宗翰有權限，不過宗翰太忙了，後續請沈俊達沈校長協助操作後台。
    2. 第一天發現一個 bug：工作坊登入以後，簽到一次離開再回來，場次的選項會消失。
      1. 發現是尚未測試出來的 bug ，已修復。
      2. 這 bug 在開發時，和後續大家一起測試時都沒發現，會需要檢討以後開發與測試的流程。
    3. 工作坊工作人員訓練量不夠，有人並非工作人員，或是工作人員並非參與前期測試和教育訓練。導致訓練不足，第一天時操作狀況頻發。
    4. 「簽出」這個詞彙不是正確的，應該要是「簽退」；「營本部」這個詞彙應該要改成「組本部」。這也是測試的時候沒有發現的狀況，「簽出」有被工作人員誤會成「登出」的動作。
    5. 工作坊時間安排，學員進場時間不一定，導致如果只有 1 人的工作坊，簽到和活動會兼顧不來。
      1. 按原規劃：如果找不到人支援，前後放時作為緩衝在一起開始會比較好。
      2. 原則上有遇到簽到問題，可以先用紙本簽到，有空時再操作。
      3. 沈校長也提議：先把學員護照收起來，中間空檔在再掃描送出。結束時歸還護照。
    6. 老闆面板（展示簽到人數的網頁）有一度統計數字壞掉。
      1. 該網頁是活動組長委外請人協助，後續溝通完成修復。 按：此為因為添加了測試用工作坊的關係，測試工作坊不顯示於系統導致壞掉。
    7. 參觀旅行有一位工作坊工作人員無法掃描學員編號的 QR Code，但透過提供現場 QR Code 的照片來測試掃描正常。可能是手機問題，當下提供幾個作法：
      1. 換台手機掃描。
      2. 先紙本簽到，事後有空時輸入編號。
      3. 手動輸入編號。
    8. 會有需要定時匯出簽到簽退資料的需求。

    另外也有一些和規劃不同的改動：

    1. 榮譽卡和簽退的行為重疊，後續取消簽退動作。
      1. 影響到系統部分判斷的流程。但不難處理，統計上已調整不特別判斷指定單一條件。
    2. 改為榮譽卡作為領榮譽章標準，不從系統上撈資料。
    3. 有部分工作坊不願意配合簽到簽退，第一天晚上即改為不強制操作。
      1. 可能會影響到即時追蹤（包括老闆面板）的需求。
      2. 未來如果依然有統計需要，必須要透過規範讓工作坊確實執行。

    於是經過兩天活動，系統作了一些修改：

    1. 修復工作坊網頁場次的 bug。
    2. 修復工作坊紀錄可能會出現空的學員編號問題。
    3. 修復後台操作時發現的 bug。
    4. 修改老闆面板、學員場次統計的簽退條件，改為有紀錄（無論只有簽到還是簽退）就納入紀錄。
    5. 修改擷取頁面。
      1. 場次簽到簽退會有重複、簽錯的行為，必須要開啟指定四個場次時間的頁面。
      2. 改為不指定日期，依照當前日期判斷。
      3. 活動結束關閉，早上再開啟。
      4. 這操作必須要優化才行。

    大部分都是第一天活動出現的狀況，第二天活動運作較為正常。除掃描問題以外大多為偵測到簽錯場次的行為。簽錯場次問題可考慮以下修復步驟：

    1. 查找資料庫，找到錯誤的紀錄場次與工作坊編號。並且查找錯誤的紀錄應正常屬於哪些場次。
    2. 於資料庫中查找正確的場次，確認該工作坊是否有補輸入學員編號。
    3. 登入 Cloudflare 後台 KV 頁面，確認該筆 KV 欄位（ key 值：signMWS_{{工作坊}}_{{場次}} ），點開 json 檔案確認要移除的資料。
      1. 只需移除不需添加，添加資料於後台動作即可。
    4. 如果工作坊於正確場次沒有輸入學員編號。
      1. 於資料庫中把錯誤場次的紀錄修改為正確場次即可。
      2. 後台操作中補輸入正確場次的學員資料。 並確認資料庫刪除錯誤場次的資料。
    5. 如果工作坊已經有補簽到（部分的）學員編號。
      1. 於資料庫中刪除錯誤的資料，修改沒有補簽的學員場次。
      2. 後台操作中補輸入正確場次的學員資料。 並確認資料庫刪除錯誤場次的資料。

    2024-07-14

    活動倒數第二天。明天就先收工。

    目前看起來結構算是穩定，吧？今天理解沒錯的話，應該工作人員操作也會上手了，先撇除掉操作錯誤的選項，針對數字有問題的內容做確認調整。

    滿有趣的是因為第一天晚上先取消了不強制簽退的動作，所以後面的工作坊單一場次的紀錄，有些會只有簽到，有些會只有簽退，也有些會想要兩個都做但是有一次簽錯場次。 這對統計並沒有很大的影響，但是對老闆面板的展示數量的 API 倒是有差，主要糾結在時間跨度很大的工作坊（參觀旅行）在展示數字上即便往後的場次也要照常顯示，而一般單純沒有該場次的工作坊，如果沒有簽出（或是取消簽出判斷），就很容易被當作是有跨度需求的工作坊，而顯示在其中。

    這個規劃可以看成是一個規則怪譚的遊戲，一個人玩真的不太好玩。嘗試把他列出來，邀請有興趣的伙伴可以試試看如果先規劃藍圖，能夠畫到多細，得以滿足所有規則和規格。

    —

    場景（需求規格）：

    1. 工作坊： 100-140 個。
    2. 場次數量：切分成 4 個場次，上午 2 場，中午休息，下午 2 場。
    3. 使用人數： 8000 人。
    4. 活動 5 天，中間休息 1 天。
    5. 目的：統計參與人數、展示正在活動（簽到）人數。
    6. 必要功能：
      1. 簽到、簽退。
      2. 後台匯出統計完成一定場次以上數量的學員。
      3. 需要有一個展示頁面展示當前於各個工作坊的活動中的學員人數。

    功能：

    1. 工作坊
      1. 簽到與簽退：輸入工作坊編號、場次編號、學員編號送出。
        1. 紀錄以下欄位：簽到/簽退、當前時間、工作坊編號、場次編號、學員編號。
      2. 讓工作坊自行檢查是否輸入正確。
    2. 後台
      1. 簽到簽出資料查詢。
        1. 查得到對應學員、工作坊資料。
      2. 指定條件的簽出簽到資料匯出。
        1. 必要搜尋欄位：場次編號、工作坊編號、學員編號。
      3. 編輯簽到簽出資料
        1. 必要可編輯的欄位：場次編號、工作坊編號、學員編號。
      4. 指定條件的學員匯出。
        1. 滿足滿 N 個活動完成的學員，做為獎章頒發依據之一。

    規則：

    1. 未必所有工作坊一天都是 4 個場次。以下列舉狀況：
      1. 30 個工作坊他們是整天的活動，所以只會有一個場次簽到。
      2. 有工作坊場次不會連續。
      3. 工作坊會有臨時關閉與臨時開啟的狀況。
    2. 簽到簽出速度 / 流程儘量快。
    3. 因腹地廣闊，學員移動速度有限，可能會陸陸續續到工作坊，差距最長約 30 分鐘。
    4. 需要解決/修復資料與確認配套的狀況：
      1. 發現某個工作坊應該有資料卻沒有資料。
      2. 發現某個工作坊數量異常多或異常少。
      3. 不熟悉操作（通常發生在第一天）導致速度太慢影響活動時長。
      4. 場次可能會輸入錯誤。（填錯場次）
      5. 學員可能會輸入錯誤。（學員跑錯場）
      6. 設備、載具有狀況等無法正常使用系統。
    5. 現場網絡環境與流量頻寬的承載量未知是否能承載學員上網。
    6. 活動的各項決議可能導致確認完整規格離第一次測試時間約 1-2 個月。
    7. 工作坊現場活動的人數需有一個展示頁面。
      1. 必要欄位：工作坊、工作坊活動人數、當前日期、天氣。

    —

    有興趣可以可以規劃看看。

    2024-07-15

    活動倒數最後一天（對我來說）。營期幾天就感冒了幾天，結束我要去吃火鍋。

    這樣的系統目標是放在商業運作，我還是那個理念，無論怎麼想，有獲利的營運有機會是進步的動力。然而這套系統離商業運作還有一段路要走。觀察下來應該要克服幾點：

    1. 專業團隊組成

    我一直認為軟體設計一個人製作如果不是用時間和財力去堆積的話，成果有限。我認為技術團隊可以透過現有的服務或是外包來搭配，像是購買版型套版來減輕或是取代美術需要製作的工作時數、快取服務架設成本太高則找適合的雲端服務來頂著。但是其實這取代不了團隊最核心的優勢就是從不同角度的討論和溝通，以及互相 cover，我會認為如果團隊組建得宜，同樣的開發時間和同樣的需求，應該會做得更加細緻而且體驗更好。

    1. 使用者溝通訓練 vs. UX 規劃

    這應該不能算是一種糾結，簡單講是因為自己不是專業於 UX 設計的人，導致這塊表現平平甚至不佳，所以某種程度上只能寄情於希望給使用者的訓練能夠完善，這滿好笑的。總歸是能力不足，解決方式還是看能不能團隊中有企劃能夠針對活動內容做設計調整吧。

    1. 儲存結構調整

    這塊應該多花一些時間規劃的，像是把 KV 換成 D1，或是 KV 設計的結構上有成本考量、開發考量以及功能考量，但真的運用在活動時，覺得可能換成 D1 也許是用錢來換命的好方法。然而也可以考慮自架伺服器的方式，最大的難點應該是如何實作快取服務了，我想快取的資料還是用拉取的方式會好一點，無法主動掌控同步時機有點兒危險。

    1. 更多的應用

    我認為在推廣新的概念新事物上，賣方市場創造應用是很重要的。如果連應用都沒有，挖掘需求的目的就是從一開始就不存在的。可以用到的創意太多了，像是鼓勵工作坊的競爭、鼓勵學員回饋、提供給營報/媒體新聞素材等等，接不只直接的創造了統計分析的需求，甚至會需要因應適合的 KPI 設計，添加了一些新的欄位。而且以數據科學的角度，應該要從這些數據發現：「活動該怎麼改善」這是一個重中之重。

    其實很需要人阿。

    –

    另外機會難得，我得把 Cloudflare Worker 的統計資料抓出來。 

    * 不同顏色表示不同版本，營期前半個月之後原則以修復 bug 為主不新增功能，所以看到顏色變化，即是當下有發現問題緊急修復。
    * 以小時為單位採樣。

    另外我得記得收尾的工作：

    1. 整理原始碼，打包開源（記得刪掉沒用的 code）
    2. 把 API 文件打出來，提供開發規格。
    3. 寫心得。
    4. 把 Cloudflare 付費停用。
    5. 把擷取頁面的 windows 主機停用。
    6. 調降 Production Server 規格。

    希望我感冒趕快好。

    這篇獻給李宗翰，他真的很辛苦，而且開會時一直被我嗆又要張羅一堆事情。
    也感謝沈俊達沈校長營期時大力幫忙，還有許多配合的工作坊伙伴和其他伙伴。


    希望軟體圈子文人相輕的文化這時可以發揮功用，看不下去的就出來做吧。

    —

    2024-07-26 update

    整理了一個新解，紀錄一下：

    流程上修改

    1. 工作坊場次之間預留間格，約是最長路程的 3/2 的時間作為「路程時間」。例如這次活動路程最長約半小時，抓 20 分鐘作為場次與場次之間的緩衝。
    2. 訓練工作坊「必須最早簽到時間」為場次開始前 1/2 的路程時間，不得提早。
    3. 如無必要，取消簽退動作。

    系統上修改

    1. 工作坊介面移除場次選項，改為自動判斷。抓取時間作判斷。
    2. 工作坊介面移除確認動作，解開單一裝置登入行為（因為不會有循序的問題），即掃即輸入，加快掃描速度。
    3. 除了第一場以外，其他時間為場次開始前後 1/2 路程時間判斷。
    4. 如果該工作坊沒有上一場的場次，則計算為下一場。
    5. 如果超過 10 分鐘沒有連續打卡會跳場次提示的警告。
    6. 快取服務如果依然選用 Cloudflare 處理， key 值改為「前綴_場次_工作坊編號_學員編號」，顆粒切更細。
      • 需要修改工作坊的清單介面，採用 list 方式取值。
      • 注意使用上因為大量採用 list 取值，費用可能會增加，需精算。
    7. 如果有預算，考慮 Cloudflare 使用 D1 服務作為快取+後台的永久儲存機制，可以實作關連式資料庫，簡化快取服務實作。
      • 注意 D1 服務是付費服務，需確認預算與限制。
    8. 如果採用自架的伺服器，請務必考慮到工作坊介面 requests 的峰值數量，或是有需要能夠透過流程或系統實作分流的動作。

    判定上/同步處理

    1. 場次填錯的話，如果只是需要判定場次數量則不用特別去修復（頂多會填成上一個場次）
    2. 同步簽到紀錄行為上，添加一個只能由後台/開發人員動作的「該筆記錄作廢」的 flag 欄位，作為手動處理同步資料作廢用途。
      • 如果作廢的話，資料則不顯示在後台、API 上。
    3. 如果需要在意場次：同步簽到上著手，判斷學員編號有同一個場次、不同工作方的簽到時依照簽到時間自動修正
      • 修正使用的邏輯是「作廢舊的且錯誤的紀錄、添加新的正確紀錄」，避免同步錯誤。
    4. 同步行為如果依然選用 Cloudflare 實作快取服務，採用 list 操作，抓取「前綴_場次_工作坊編號」動作為佳（考慮 list 長度以及抓取時間的平衡）；如果自架服務，則需考慮同步抓取的資料量大小與完整同步一次的時間做平衡。

    以上。

    —

    最後放一些做封面圖時生成的圖片，滿好看的，有需要請自行取用。

  • 《如怨以償》沉浸式娛樂 心得

    今天參加 4/9  晚上《如怨以償》的沉浸式劇場體驗。最近很愛跑沉浸式的劇場活動，先說對於「沉浸式」的定義，我的概念是：「消除舞台的邊界的劇場，或是意圖模糊觀眾角色定位的演出。」這齣《如怨以償》是的確符合的。而在宣傳的命名上是避開了「戲劇」相關的詞彙，稱之為「沉浸式娛樂」，我以為這應該是想要開一個新的分類，未來可以有更多元的形式來處理劇本，也是考驗編劇和導演在除了傳統劇場訓練之外另外更多新的演出形式、互動編排。

    事實上也的確在《如怨以償》中有許多除了演員演出與角色互動之外的橋段，而且互相編排滿巧妙的。在多人的沉浸式劇場中以分小隊的框架來處理不同支線劇情，也透過觀眾選擇來決定預排好的支線路線，這非常考驗活動企劃（或是編劇？）對於人數與劇情的安排，我覺得在這方便編排的很是不錯。後期搭配一齣小舞台的戲對劇情作交代，最後回歸「個人」對於「怨念」的處理，我也認為在處理「怨念」的橋段上，深淺是合理且妥當的。其中也能看出活動企劃意圖想讓觀眾二刷的野心。

    先講結論：

    1. 我覺得沉浸式體驗的劇場想讓觀眾二刷是困難的，這是值得挑戰的課題。
    2. 不太劇透劇情，但他利用了桌遊、觀眾互動遊戲與最後守靜等橋段，與劇情的結合很巧妙。
    3. 劇情是完整的，觀眾的參與是深層的，而結尾的處理我認為很可圈可點，但略微可惜。
    4. 民俗信仰偏向道教，但偏向架空的神佛地獄設定，這是可惜的。
    5. 活動互動與即興互動的環節很棒。劇中大姊很可愛，二哥很帥。

    我發現在沉浸式的劇場中，大多因為人數問題，會需要以分隊進行的，再視情況進行各小隊分合的處理。在進場之後，我們會預先在一張「符籙」上，填寫之前在網路上填寫的「怨念」，這算是一個角色設定的儀式，也是依據符籙上的編號作為分隊的方法。分隊之後，首先會進行角色的設定和前置的劇情，在這裡開始就很容易讓不同的分隊對於劇情有不同的理解，導致劇情容易每個人認知有缺少。不過這齣劇應該有對人數對應做好安排，在銜接到劇情推進的大戲上安排的很妥當（這應該是單劇情多支線多結局的處理模式），接著利用「怨念堂的培訓與篩選間諜」為目的，作為劇情需求，在中間穿插了一些桌遊和觀眾彼此之間的互動遊戲，其中也透過互動遊戲，讓觀眾整理自己在符籙上填寫的怨念/ 解方。

    後續在經過最後一場揭露間諜的戲之後，輪到玩家怨念的結尾了，這裡我在參與中一直很好奇應該要怎麼處理。意料之外的，最後是再次將小隊打散，回歸到個人上。利用劇情中的橋段，讓觀眾做抉擇，並且讓觀眾進行守靜（我的理解源自於童軍儀典，參考這裡）的橋段，讓觀眾自行抉擇並且利用錄音帶錄下自己關於自己的怨念，怎麼想，該怎麼做的一段獨白。

    依照個人不同的選擇（或是某部分的運氣），在互動環節上會有不同的角色、後續劇情，大抵前面是單一劇情的推薦，不過在最後因為對怨念抉擇的不同，最後劇情的橋段會有差異，我個人看來最後的個人劇情偏向是一個沉浸式角色抽離的儀式，有趣的是這些成為厲鬼的怨念我後來發現其實都會匿名出現在官網上，這也是滿猛的，可以感受到想要擴散討論的目的。

    感受上可以從怨念觀察、分隊互動、戲劇內容與觀後心得幾個分類來描述心得：

    ⠀怨念觀察⠀

    「怨念」的設定是一個很有趣，也是吸引我的地方，我自己寫了一個對於別人來說也許是很小的事情，不過自己在填寫的時候才發現，是一個記得住二十幾年的事情。因為要求要把對方的名字寫上，我也毫不客氣的把對方的全名和事情完整寫上了。整整把符籙寫到了背面。心裡在想著不知道他們開檢討會會不會拿我的怨念出來討論（笑）。而我對怨念的提出的解方（劇情需情）也是先準備好的。在守靜時需要用錄音帶錄下解方，我提出的是：「我想要忘記對方，但是希望他永遠記得我，而且這輩子帶著愧疚。」這和怨念堂設定的「執念」是一個矛盾的存在，不過很明確的，不想釋懷。對於這種違背邏輯的神秘學處理，滿期待他們之後改版會不會有這類狀況的處理。

    ⠀分隊互動⠀

    分隊互動上，我認為基本上偏向娛樂性的處理，與讓觀眾加深對演員的角色刻畫，對劇情推進較無太大幫助。但我認為很棒的是，分隊互動對劇情雖然沒有推進，但是帶上了串接的動作。因為在第一次分隊活動中，有選出幾個較為個體較為特殊的角色（猜測應該是怨念十分特殊、觀察到入戲太深的觀眾，或者也許只是要安排參與演出的觀眾），第二次的分隊觀眾互動遊戲上，應該對該角色們有特別的互動，在後續的大戲上有特別安排這些角色出現參與演出，而大戲後的最後一次分隊活動中，我們這場演員與大家互動中有特別點出幾個怨念的附和，隱約可以聽出來是真的滿大個仇恨。

    ⠀戲劇內容⠀

    戲劇部分我認為可以分為有劇本的戲和沒有劇本的劇情，沒有劇本的劇情偏向分隊活動。劇本的互動是小型舞台劇的形式，觀眾的角度近似 360 度圍繞演員進行的。分隊活動上偏向是角色扮演的大地活動，角色的扮演在無劇本的演出上真心佩服，因為我自己在互動上常常不自覺因為遊戲帶入會開始思考策略，導致會瞬間出戲，甚至自我角色錯亂，有一度還小聲質問演員到底誰才是大魔王（我是想要配合演出啦），不過演員十分敬業融入在角色之中，應對的行為也貼合後續劇情的演出的內容，有些愧疚自己給演員帶來麻煩，希望不會被寫在怨念的符籙上，雙手合十。

    原本我並不期待這齣戲所準備的怨念內容會對自己有成長，預期只是戲劇需求的道具之一，但令人意外的其實在整理過程中，除了發現自己竟然記得對方的名字，而且在怨念堂的劇情引導下，演員角色會「部分分享」彼此之間的怨念，原本認為這對於認真寫怨念，而且又十分投入的觀眾是一件非常危險的事情，但可以看得出來劇情安排上有試著讓觀眾投射進角色放下執念的意圖，也似乎在其他分隊互動環節上有額外的處理（有針對玩家角色做獨特區分，這我沒有參與到），最後守靜的環節，用錄音帶錄音錄下自己的怨恨與報仇方法，也聽了一段結尾語錄音的劇情，頗有意圖解開或是化解的意味。可惜的是最後一場互動環節中，因為酒醒了，所以在錄音室中有一段劇情完全沒有記憶，後續二哥帶的詢問我自己完全記不起來，甚至連我錄音講了什麼我也記不住。回到家後發現，我拿的是錄音帶阿！誰家還有卡帶錄音機？這故意的吧這是。

    有劇本的戲中，後段有一個是分隊形式演出的，可惜當時因為不勝酒力，有點小暈，並不是看得非常理解，有點偏親情類的詮釋。我認為這應該是補足角色層次的行為，對劇情沒有太大影響。

    ⠀觀後心得⠀

    容我分段敘述：

    這次的活動意外的男女比大約是 7:3 ，很符合陰間的設定。我猜應該大多是感情因素，就我隔壁和後續分享的特殊觀眾都是感情上很大的怨念而來的人，很多人平時可能很正常，但每個人其實或多或少都帶有一些秘密和過去，也許有來看戲的，也有多少帶著來解惑心思的，真心希望他們回去都能有一些能夠化解的作法。

    ⠀⠀⠀

    我認為我是認真寫怨念的觀眾，可惜遊戲的時候有點太放飛自我了，投入的狀態不夠，要不應該能夠成為演出很棒的一部份。滿幸運的因為男女比的關係，整場戲無論分隊或是大戲身邊大多都香香的。恩，也許這是分心的原因？  我覺得角色刻畫最深刻的是大姊，劇情部分就不贅述，我覺得可能是因為他是裡面需要詮釋比較多個性，也擔負一個帶領觀眾走向「另外一條路」的角色，所以整體覺得對他印象最深刻，而且他很正。

    ⠀⠀⠀

    裡面角色名稱有四個，最終我只能用輩份來記住每個人，分別是大姊、二哥、三弟、四妹和奶媽（應該沒錯吧？）每個人有分別對應的能力，本來以為在互動上會有類似操作，但可能是劇本和時間的需求，這塊在戲中並沒有強調出來，反而互動時帶開的設定又是另外一個新的，我覺得這部分略微可惜，但瑕不掩瑜。我認為在演員如果在最後無論是哪個分支劇情能不只是二哥與觀眾參與互動的話，或是在後續在多推進一些劇情，讓劇本在之後個人反思的部分結束後，有一個完整個結束的話，可能會讓觀眾更有完整的體驗的感覺，但是實際上要如何進行會變的十分困難，包含時間掌控以及劇情的編排都是相當的挑戰。

    ⠀⠀⠀

    這齣劇是可以感受到希望觀眾參與第二次的，但是我發現沉浸式的演出似乎某些程度上要讓觀眾二刷，會需要更多的誘因？我覺得這齣劇的拉力在於：

    1. 最後獲得一份個人化的紀念品（錄音帶）
    2. 與不同角色的互動劇情
    3. 與不同玩家的互動

    而推力在於：

    1. 劇情互動無法隨心所欲選擇
    2. 戲中個人撰寫的「怨念」，對於現實中心裡層面的影響
    3. 不確定是否劇情會變化？熟悉劇情以後抽離感會更深。

    我會滿在意熟悉劇情這件事的，也許在活動中喝酒是有目的性的更容易忘記劇情？會期待在之後劇情可以做一些改版。值得一提的是，可能是因為高估了自己膀胱和低估了自己代謝能力，雖然已經盡可能排開了水分，但是在活動後段還是超級想上廁所，還好後段在進錄音室之前有一個空檔可以趕緊去上廁所，覺得人生太難了，差一點錄音內容就會一直提尿急的事情。

    ⠀⠀⠀

    劇中的地獄與神佛的概念，據我瞭解是一個架空的世界觀，有一個滿有趣的小地方是，因為我分組互動是由三弟帶領的，三弟一直認為我是「上面派來的間諜」（這是劇情的一部份），最後還被上了銬。後面在即興的互動中他說我看我的臉我是「福德神」，我一開始還以為是土地公，套用土地公設定，土地公妻管嚴應該是瘦的，我肯定不是。後來發現，不是，跟劇情世界觀不一樣，瞬間 emo 了。

    ⠀⠀⠀

    覺得演員很厲害，奶媽有一段京劇演出、大姊角色變換、二哥的形象還有三弟與四妹的好幾場互動，覺得身歷其境（廢話）的同時，又因為是沉浸式的形式，在各種狀態下能激發不同的可能，演員除了演出之外也要有很強大臨場反應和配套的作法，這也除了需要考驗演員本身演技之外，也很挑戰編劇或企劃的設定。我覺得這也可能是安排錄音間的設定，如果後期演員需要面臨能量過於強大的觀眾的話，可能已經不只是演技上的需求了，還會需要某些心裡諮商上的訓練？在回家的路上我也在思考，觀眾適合收的點是不是可以在往後多一些？是不是有可能把情緒再釋放多一些？如果成本允許的話，是不是能夠結合戲劇治療，讓觀眾在最後一場戲上釋放足夠的能量和情緒？或是這樣的場景和劇本，是否後續會成為戲劇治療的元素之一呢？ 這不是我能考慮的，也許就想想過個乾癮吧！

     

  • 〈三小時異性戀思辨聯誼〉聯誼活動心得

    距離上次參加聯誼應該有四五年了，上次還是在上班時公司舉辦的聯誼活動過去當暗樁，活動結束後還跑去和主辦人分享活動心得。這次是線上課老師推坑臨時參加的，因為自己工作的關係，基本上已經成為聊天機器人一般的存在，難得有主題的聊天，還能認識朋友的活動，心頭一熱就報名了。

    按照慣例，心得怕忘記所以寫下來。沒有要捧活動的意思，但是這樣的活動很有趣，有種 UGC 的感覺。

    自己覺得文末最一句滿帥的，是心底話也要記得，永遠少年，保持真誠。

    —

    這週日臨時報名一個聯誼，是七日戀人舉辦的 4/2 〈三小時異性戀思辨聯誼〉活動，主要是討論愛情觀，然後最後聯誼配對。滿有趣的，應該算是出社會以後就沒有一次多人的價值觀討論。自己有兩個期待：

    1. 是期待能配對到一位價值觀很合的對象
    2. 趁這個機會多瞭解其他人目前的想法，與整理自己的價值觀。

    先講結論：

    1. 配對沒有成功，不過有加幾個人 IG ，男女都有，有收穫的。
    2. 前幾個晚上再填寫問題表格時，也一邊在看心得與整理問題的答案，滿開心的，這是一種價值的梳理。
    3. 覺得很慶幸，自己價值觀滿完整的。
    4. 後來結束後有一票沒有配對到人揪坐捷運就先離開了，覺得滿可惜的。

    活動分成兩個部分：最後的配對環節，以及前面價值觀討論。

    —

    ⠀先說配對的過程⠀

    配對的過程，是除了自己的號碼之外，填寫兩個有意願的對象號碼，如果兩邊都有互相填寫到，就配對成功。

    我猜可能無論是女生還是男生，配對填寫應該會以外表為第一考量，推測判斷的邏輯應該會是：

    1. 價值觀 ok 的作為門檻，不 ok 的剔除。
    2. 挑外貌最好的。評估標準：顏值、身材、身高、氣質談吐。

    這是我猜的。可惜沒辦法拿到票數分布，如果猜測準確的話，票數應該會集中落在 2-3 人左右。

    配對的流程是事先不會知道的，對配對沒什麼特別的想法，甚至在配對前也沒想過什麼策略。不過沒有配對成功，心理到也是小失落的，有種可惜我還沒好好認識大家，以及大家還不知道我很想認識大家的遺憾感。但現實如此，恩恩，借用余自摩的話：

    我將在茫茫人海中尋訪我唯一之靈魂伴侶。得之我幸，失之我命。

    唉呦好文青。

    —

    關於價值觀討論的部分，依照時間軸分成三塊，分別是「活動前的準備」、「活動中的對談」、「活動後的想法」。

    ⠀活動前的準備⠀

    慶幸的是，在準備時越來越感覺自己自身價值觀是完整的。對於表單上，需要填寫問對方的問題，我能夠抱持一個好奇的態度，並且自己能夠很快速明確的回答內容。在活動前好幾個晚上也在梳理自己關於感情上的態度和想法，的確自認為對於情感的態度沒有太大的問題，價值觀也沒什麼互相矛盾的地方，簡單來講，單身憑實力。

    值得一提的是當時在想，真的配對到了要怎麼辦？會要單獨約會？還是一起參加活動比較好？會考慮到面向就不只是價值觀的部分了，這倒是沒有一個好的解。

    ⠀活動中的對談⠀

    印象滿深刻的是，除了有一位跑馬拉松的老師之外，發現其他人的興趣或是工作，自己在過去大部分是求學階段都有接觸過相關的領域。看到有人帶鼓棒來時格外覺得懷念，雖然以前自己打的滿很爛的，不過當天回家還特別翻以前演奏過的曲目。 聽到別人介紹工作時，也會在心理不禁驚呼：「耶！那你有看過 XXX 嗎？」這類的造樣造句。很有趣，可惜時間不是很多，主題也不是聊天活動，要不有種渴望和大家多聊一些，無論是興趣或是工作時有趣的經歷。

    滿遺憾的是這次活動只有三小時，有幾輪對話常常沒有辦法完整到每個人都有發言的時間。不過三個小時的參與，結束後就感覺到略微疲憊，很難想像如果是六個小時的活動應該要如何適當分配精力。也許這也是某種觀察和篩選？

    對話的部分，原本期待大家會準備好上來侃侃而談，可惜是發現有許多的發言花了滿多思考的時間，略微感到不耐。突然發現這是自己一個滿大的缺點，也發現大家都非常有耐心而且和善，提出不同的意見，對於沒有結論的發言也不會打斷或是協助加速。

    其中有一個滿有興趣的話題，是整個活動快要結束前我們討論的。題目是「你能接受一週有幾次性行為？」後來聚焦在「一週最多幾次、最少幾次」。意外的發現大家的回答和期待的數據完全不同！ 原本我期待男生會滿高，女生會偏少，不過大家的回答發現其實似乎女生的最少次數也不會只有一兩次甚至沒有。 可惜的是這題目也因為時間關係，後來沒有辦法完整結束。

    值得一提的是，雖然活動沒有配對成功，但是活動後有加了幾位朋友 Instegram ，這是非常超值的一件事，有隱私概念相近的工程師、在國家音樂廳演出過的研究生、跑馬拉松但是來不及分享如何獲得長輩緣的數學老師。

    滿可惜的是後來有一票人應該是要揪坐捷運，所以一起先離開活動場地了，而我在等待「搭訕對象」中，也就沒有跟著大部隊移動。後來在活動結束後有遇到其中一組配對成功的「七日戀人」在外圍比肩散步聊天，經過時不自覺露出姨母笑，看起來很聊得來，真心祝福。

    ⠀活動後的想法⠀

    回去時朋友關心打來電話，在一一報告心得的時候，突然想到：「我參加的目的，是聯誼還是思辯？」好似策略上是衝突的：如果是聯誼的話，這場活動在思辯的發言中應該要迎合自己心儀的對象才對，甚至不應該發言；而如果是思辯的話，作自己就好，更應該把自己完整展現出來讓別人來攻擊和檢視。

    朋友回覆的是：「可是這不就是要找和自己價值觀相近的對象聯誼嗎？」目光拉回現實，沒有配對成功的，的確就是沒有相近價值觀的對象，也無法左右別人的想法，而這種活動也不太適合為了實驗而參加，如果真的配對到，反而對對方是種罪過了。

    而如果之後有機會有時間的話，會更期待能夠多瞭解其他人真實的過去的經歷，以及他們曾經做的事情。深知很多想法和態度，最終也只會停留在「我是這麼認為的」這個階段，真的遇到了，在有壓力的現實下，未必會同自己之前所想的做。面對假設的問題，保守的回答，或是直覺說不知道是沒有錯的。我們能做的，也就是確保自己是個言行合一的人就是。

    我也是一直很努力的成為言行合一的人，不是指「說到做到」，而是我清楚我是怎麼樣的人，我會這麼做，所以這麼說。