堀內貴文

開發讓兒童製作互動物件原型的 VR 系統

概述

Smart Codesign VR 是一個原型平台,讓玩家在虛擬實境中製作並測試可互動的「智慧物件」。玩家從環境、輸入與輸出三類卡片中各選一張,再以身體動作定義物件何時回應、如何回應。完成後,可以把虛擬物件放進公園,測試它的行為。

本專案以米蘭理工大學 i3Lab 開發的桌遊 SNaP(The Smart Nature Protagonists)為基礎。在 SNaP 中,兒童組合卡片來構想智慧物件,再以一句話寫下設計。本專案希望將這些文字描述轉化為虛擬物件,讓兒童能透過自己的動作組裝,並與物件互動。

我們的四人團隊於 2020–21 學年度,為米蘭理工大學 Advanced User Interfaces 課程的期末專案設計並實作這套系統。預期使用者為 11–13 歲兒童,並特別考量有神經發展障礙(NDD)的兒童。原型以 Unity 和 C# 為 Oculus Quest 2 開發,支援從選卡到在虛擬公園中互動的完整流程。

示範影片。從選擇卡片、決定輸入條件與輸出行為,到把做好的智慧物件放進虛擬公園中運行的整段流程。

SNaP 與設計背景

讓孩子成為設計主角的遊戲

在 SNaP 中,二至四名兒童擔任「設計師」,成人引導者扮演「市長」。市長提出任務,兒童討論想法並組合卡片,設計能回應任務的智慧物件。遊戲旨在培養創造力、合作與表達想法的能力,也考量了有神經發展障礙的兒童使用的情況;但本專案並未評估療育或教育成效。

環境、輸入、輸出——三種卡片

SNaP的卡片有三種,各自承擔不同的角色。

環境(Environment)卡代表要被賦予智慧功能的物件:樹、長椅、鞦韆、水域、石頭、路燈、垃圾桶、腳踏車、橋、階梯或書包。這些都是公園與街道中常見的物件或景物。環境卡指定了哪個物件承載輸入與輸出功能。

輸入(Input)卡定義物件偵測或回應的事物,例如按鈕、動作、觸碰、距離、溫度、濕度、亮度、顏色、聲音、火、水位或天氣預報。它們代表智慧物件的輸入,作用類似感測器。

輸出(Output)卡定義物件的回應,例如發光、發聲、震動、移動、顯示、記錄或傳送資訊。它們代表輸出功能,作用類似致動器。

環境卡為輸入與輸出的組合提供情境。同樣以動作為輸入、聲音為輸出,垃圾桶可以在有人沒丟進去時發出聲音,路燈則可以提示有人靠近。輸入與輸出定義裝置如何運作,加入環境後,便將這種行為連結到日常生活的情境。

環境卡「Trash can(垃圾桶)」、輸入卡「Motion(動作)」、輸出卡「Make sound(發出聲音)」三張以「&」相連,箭頭指向一句話「Missing the trash bin creates a sound.(沒丟進垃圾桶就會響)」。
三張卡片的組合,構成一個智慧物件的說明文。卡框的顏色表示種類:綠色為環境,淺藍為輸入,黃色為輸出。
把SNaP的49張卡片排開的一覽表。上兩列是20張綠框環境卡,中間兩列與最下一列的左端是21張淺藍框輸入卡,最下一列的其餘部分是8張黃框輸出卡。
SNaP 全部 49 張卡片:環境卡 20 張、輸入卡 21 張、輸出卡 8 張。它們可能的組合,構成遊戲中的設計空間。

把文字構想轉化為可互動的虛擬物件

在本專案進行時,SNaP 活動以兒童寫下所設計智慧物件的描述作結。同一時期,i3Lab 也在開發結合平板電腦與 Arduino 的「實體板」,將這些描述轉化為實體原型。Smart Codesign VR 則探索另一條路,使用研究團隊當時尚未為此目的研究過的虛擬實境媒介。

VR 提供了兩種機會。首先,兒童能以全身動作製作原型:抓取、搬運、照光與用畫筆塗抹,都成為設定條件與定義行為的方式。其次,構想可以呈現為立即可互動的虛擬物件。原本的文字描述,能成為眼前有大小、有形狀的物件。

為誰而設計

預期使用者為 11–13 歲兒童,並特別考量有神經發展障礙的兒童。設計智慧物件需要一定程度的邏輯推理,因此 SNaP 與 VR 版本都以這個年齡範圍為對象。

本專案希望透過動手製作原型與互動,協助兒童表達想法。這些是設計目標,並非已證實的療育或教育成效;原型尚未由兒童參與評估。

設計舒適的空間

根據專案參考資料,我們以四個面向引導空間設計:聲音、光線與色彩、空間組織,以及材料。聲音方面,考量隔離噪音、調整音量,以及使用安靜且一致的聲音,以因應聽覺敏感。光線與色彩方面,考量以平靜、低彩度的背景為主,僅在小範圍使用明亮、高彩度色彩。清楚的空間邊界、有秩序的配置、簡單易辨識的形體與暢通的動線,也都是設計考量。虛擬環境讓設計者能控制這些面向,但本專案並未評估它們對使用者舒適度的影響。

VR 的限制與風險

本專案也考量 VR 的限制與風險:硬體成本、暈動症、頭戴裝置重量造成的頭頸負擔、裝置遮蔽實體環境而引發的意外、長時間使用造成的眼睛疲勞,以及過度沉浸可能帶來的依賴問題。

這些考量形成三項設計決定:互動保持簡單,同時保留足以支持學習的挑戰;視覺與聲音清楚明確,但不過度刺激;體驗具有明確終點。當原型製作與公園中的測試完成,活動就結束,而不鼓勵使用者無限期留在 VR 中。


原型:體驗與實作

體驗的四個階段

應用由四個場景構成:待機畫面、卡片選擇、原型製作,以及在公園中的操作。

1. 待機畫面

App 啟動後顯示標題畫面,等待玩家按下控制器按鈕才繼續。這個刻意安排的停頓,讓玩家能先戴好頭戴裝置、調整姿勢,再開始主要體驗。

2. 卡片選擇——抓起來,放進箱子

玩家抓起各張卡片對應的物件,放入相應的箱子,從環境、輸入與輸出中各選一張。抓取與放置的操作運用了 VR 的立體空間。三個箱子都填入物件後,語音提示會引導玩家進入原型製作階段。選卡順序不限,但三張都選好才能繼續。

VR空間中的卡片選擇畫面。排列著卡片的看板前方並排放著三個寫有input、environment、output的半透明箱子,一隻手正抓著擴音器形狀的物體。
卡片選擇的場景。前方的三個箱子分別對應環境、輸入、輸出,把抓起的物體放進去即確定選擇。在這一階段無法使用的卡片會以淡色顯示。

3. 原型製作——用身體決定條件與行為

原型製作是系統的核心。玩家定義所選輸入卡的觸發條件,以及所選輸出卡的回應。每張卡片都有自己的互動方式,運用需要六自由度追蹤的身體動作。

例如,輸入選擇「天氣預報」時,手邊會出現分別代表晴、陰、雨、雷、雪的物體。抓起其中之一,把從它延伸出的光線對準目標物體,條件即告確定。輸出選擇「發光」時,則抓起畫筆,把筆尖浸入各色顏料罐,再塗抹到對象上,以此決定發光的顏色。想擦掉塗上的顏色時,把筆浸入「水」罐再塗一次即可。

一項關鍵的實作決定,是讓同一物件支援多組輸入與輸出配對。原先只允許一條規則,例如「晴天時發紅光」;支援多組配對後,同一物件便能對不同條件做出不同回應:晴天紅色、下雨藍色、下雪白色。玩家可以在確認前測試每組配對,並視需要返回編輯。

原型製作畫面。左側是輸入卡「Weather」的操作說明面板,中央是寫著「When it is about to be sunny/rain/snow」的三個對話框,右側排著輸出的對話框,前方有樹的物體和顏料罐。 同一畫面從右側看去。在塗成黃色的路燈物體左右,輸入與輸出的對話框成對排列,最右端是輸出卡「Light up」的操作說明面板。
2021 年原型截圖。編號對話框將輸入條件與輸出行為配對。加號按鈕新增一組,減號按鈕移除一組。輸入面板顯示「Maximum number of instances: 5」(最多五個實例)。

4. 公園:測試物件

確認物件後,玩家進入虛擬公園,放置物件、觸發已定義的輸入條件,再觀察回應。物件成功運作後,慶祝動畫標示體驗結束。

整體流程

把以上內容整理成UML活動圖,即下圖所示。上段是整體流程,下段兩幅分別把「天氣預報」卡與「發光」卡的操作細緻展開。選卡之後經指示可以退回重選,確定並試運行之後可以返回重新編輯,這些都各自寫成了分支。

UML活動圖。上段的「Overall Activity」展示了從待機畫面、選擇三張卡片、接受指示、定義輸入條件與輸出行為、確定、確認動作,直到在公園中操作的全過程。下段左側展開天氣預報卡的操作,下段右側展開發光卡的操作。
使用流程的 UML 活動圖。由於各種卡片使用不同操作,整體流程與卡片各自的互動細節分開呈現。

裝置與工具

原型為 Oculus Quest 2 開發。它的六自由度追蹤支援轉身、移動與操作虛擬物件。由於反覆動手操作是體驗的核心,團隊排除了只有三自由度追蹤的手機式頭戴裝置。

App 以 Unity 與 C# 開發。Oculus Integration 套件負責連接 Quest 2,並提供 VR 攝影機行為、繪製與控制器輸入的 API。

四個場景與13個類別

系統按Unity的場景分為四個,正好對應體驗的四個場景。類別共13個,其中3個是抽象類別。

標題場景只有TitleSceneCore,按下按鈕即切換到下一場景。

選卡場景使用 CardSelectionSceneCore 與 CardSelectionDetector。前者建立三個偵測器實例,分別對應環境、輸入與輸出箱。每個箱子會吸入附近的卡片物件,並將該類別標記為已選擇。三項都選好後,場景將選擇寫入靜態類別 SmartObject 並進入下一階段。SmartObject 在場景切換時保留資料,將四個場景串成連續的體驗。

原型製作場景中,PrototypingSceneCore 協調整體流程。卡片行為以繼承階層表示:Card 是基底類別,InputCard 與 OutputCard 繼承自它,再由 Weather、Fire、MakeSound 與 LightUp 等具體類別實作各種互動。由於只有具體子類別執行原型製作操作,Card、InputCard 與 OutputCard 均設為抽象類別。

PrototypingSceneCore 分別維護輸入條件實例與輸出行為實例的清單。如果所選卡片為「天氣預報」與「發光」,清單就分別包含 Weather 與 LightUp 實例。開始時各建立一個,按下新增按鈕便再建立一組。系統每一影格評估輸入條件,並呼叫對應的輸出行為。使用者確認物件後,isConfirmed 設為 true,組合好的行為資料寫入 SmartObject 的靜態屬性。

互動場景只包含 InteractionSceneCore 一個類別,負責在公園中放置物件、測試已定義的條件與回應,以及最後的慶祝動畫。

UML類別圖。畫出了Title Scene、Card Selection Scene、Prototyping Scene、Interaction Scene四個套件,以及它們所參照的靜態類別Smart Object。在Prototyping Scene內,抽象類別Card之下有Input Card與Output Card,再由Weather Card、Fire Card、Make Sound Card、Light Up Card繼承。
系統的 UML 類別圖。四個套件對應 Unity 場景,中央下方標為「Smart Object」的靜態類別在場景之間保留資料。為方便閱讀,圖中的屬性與方法已簡化。

成果與尚待完成的工作

49 張卡片中已實作九張

原型實作了九張卡片。核心功能已可運作:選卡、定義條件與行為、管理多個實例,以及在場景間傳遞資料。這為增加更多卡片打下基礎,但仍需進一步實作。另有六張卡片完成設計但尚未實作,其餘 34 張則仍需設計互動方式並實作。

原型中的實作狀況
狀態卡片
已實作(9張)環境:樹、路燈、道路標誌、垃圾桶、橋
輸入:火、天氣預報
輸出:發出聲音、發光
僅完成設計(6張)輸入:按鈕、速度、聲音
輸出:移動、震動、傳送
尚未著手(34張)環境卡15張、輸入卡16張、輸出卡3張(顯示、啟動、記錄)

尚未進行使用者評估

原型未經使用者評估。開發期間正逢 COVID-19 疫情,團隊採遠距參與,無法安排配戴 VR 裝置的實體工作坊,也未能安排遠距替代方案。本專案展示了所設計的體驗可以實作為可運作的原型;對兒童的易用性,以及在療育情境中的價值,仍未經測試。

未來的評估將探討介面在原型製作上的直覺程度。可能的指標包括完成時間、最終智慧物件與參與者原始構想的吻合程度,以及非預期按鍵的次數。活動後以系統易用性量表(System Usability Scale,SUS)為基礎的問卷,可提供額外量化資料。未來也可考慮在取得同意並遵循適當程序後,錄影觀察參與者的動作。2021 年專案提出的評估對象年齡為 13 歲,以符合 SNaP 預期年齡與當時引用的 Oculus 指引。任何未來研究,都需要依適用指引與研究計畫重新評估參與資格。

後續工作

後續開發首先需要改善 UI 與 UX。時間與經驗限制使大部分精力投入卡片組合的運作,視覺、聲音與觸覺設計仍不夠成熟。VR 中的文字角色也需重新考量:原本為平面設計的資訊,或許更適合以空間使用者介面(SUI)呈現。語音互動也是值得為預期使用者進一步研究的方向。

專案提出三個研究方向。第一是與 i3Lab 開發中的實體板比較。既有研究曾報告,同一款合作遊戲在虛擬環境中比在實體場域引發更多對話,因此值得比較這兩個平台。第二是多人同時參與,呼應「Codesign」之名,讓兒童能在 VR 中共同製作物件。第三是建立智慧物件描述的標準格式,讓設計能在不同平台之間轉移。

小結

本專案建立了製作智慧物件原型的環境,將 SNaP 的三類卡片轉化為組成單位:物件、觸發條件與行為。玩家透過抓取、指向與塗抹把它們連接起來。可運作的原型將文字構想轉化為可互動的虛擬物件,並以可在場景之間傳遞的資料表示其行為。

Takafumi Horiuchi, Paul Cozma-Ivan, Elmira Katsajeva, and Olivia Ludkiewicz,“Design and Implementation of a Smart Object Prototyping Platform in Virtual Reality for Children with NDD,” Advanced User Interfaces (A.Y. 2020–21) Final Exam Project,米蘭理工大學,2021年2月。