基於空間創用的隨境遊戲-以政大校園為例 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University 碩士論文 Master’s Thesis. 立. 政治大. ‧ 國. 學. 基於空間創用的隨境遊戲-以政大校園為例. ‧. y. Nat. Development of a Pervasive Game Based on the. n. er. io. sit. Produsage of Space: A Case Study of NCCU al v i n Ch engchi U 研究生：曾文志指導教授：陳. 恭. 中華民國一百零五年四月 April 2016.

(2) 基於空間創用的隨境遊戲-以政大校園為例 Development of a Pervasive Game Based on the Produsage of Space: A Case Study of NCCU. 研究生：曾文志. Student：Wen-Chih Tseng. 指導教授：陳恭. Advisor：Kung Chen. 立. 政治大. 國立政治大學. ‧ 國. 碩士論文. 學. 資訊科學系. io. sit. y. ‧. Nat. A Thesis. er. submitted to Department of Computer Science. n. a. v. l C Chengchi University National ni. hengchi U. in partial fulfillment of the Requirements for the degree of Master in Computer Science. 中華民國一百零五年四月 April 2016.

(3) 基於空間創用的隨境遊戲-以政大校園為例. 摘要. 隨著智慧型手機的普及，混合虛擬世界和現實世界的手機遊戲變得容易實現，一般稱這類遊戲為隨境遊戲(Pervasive game)。現今最. 政治大. 有名的隨境遊戲為 Ingress，是一款由 Google 所屬的 Niantic 實驗. 立. 室開發的適地性(Location-Based)社群遊戲。Ingress 將現實世界. ‧ 國. 學. 的地點轉換成虛擬世界的據點，玩家分成兩個陣營，遊走於現實世. ‧. 界的地點對虛擬世界的據點執行任務要求的操作。過程中同陣營可. Nat. io. sit. y. 相互合作，對立陣營則彼此競爭。符合資格的玩家還可以制定任. al. er. 務，賦予地理空間新的意義，指引其他玩家執行這些任務。本研究. n. v i n Ch 稱此功能為空間創用，一般而言，具有空間創用性質的遊戲對於玩 engchi U 家會有較高的黏度。本論文為政大資科系與社會系所合組的跨領域團隊的研究成果之一，我們進行”遊戲人”研究，並師法 Ingress，開發出一款具有空間創用性質，但不是單純兩軍對抗為主的隨境遊戲 APP-暗黑帝國。本研究之隨境遊戲 APP 採用敏捷的方法開發，並透過徽章機制實現空間創用性質及增加黏性。我們藉由招募受測者的方式取得回.

(4) 饋，初步結果顯示，玩家會對於具有空間創用性質的徽章會引起他們的興趣。. 關鍵詞:空間創用、隨境遊戲、遊戲人。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(5) Development of a Pervasive Game Based on the Produsage of Space: A Case Study of NCCU. Abstract. With the increasing computing power of a smartphone and the popularity. 政治大. of its users, it becomes easy to mix the virtual world and the real world in. 立. a game. This kind of game is called pervasive game. Nowadays, the most. ‧ 國. 學. popular pervasive game is Ingress, created by Google’s Niantic, Inc.. ‧. Ingress transforms a real-world landmark into a virtual object called. Nat. io. sit. y. portal. Players are divided into two competitive armies and do specific. al. er. operations defined by the missions at real-world landmarks to attack or. n. v i n C h portals. Missions defend the corresponding virtual e n g c h i U in Ingress give real-. world space new meanings, and this study call this property Produsage. It is commonly held that games with Produsage have the higher degree of Stickiness for players. This thesis presents a pervasive game with Produsage that utilizes the NCCU campus and provides game elements that go beyond competition between two armies. As this is a joint effort with colleagues from Sociology department, we follow the agile development method to.

(6) develop the game iteratively. A distinguished feature of our game is the badge mechanism to realize Produsage that aims to increase the degree of player stickiness. We recruited volunteer players to play the game and got feedbacks from them. The preliminary result shows that players gets the sense of accomplishment when they are collecting produsage of space badges.. 立. 政治大. ‧. ‧ 國. 學. Keyword: Produsage of Space、Pervasive game、Homo Ludens.. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(7) 誌謝詞. 兩年多的碩士生涯即將到了尾聲，今天能夠順利完成學業，首先要感謝陳恭老師的悉心指導。謝謝老師這兩年多來，在專業領域上的教導、如何面對未知問題與處理以及對人處事的方法。另外，也要感謝口試委員王有禮老師與廖峻鋒老師在口試時給予的提醒與指教，讓我能順利完成論文。感謝這兩年一起進行研究討論的合作夥伴們，謝謝社會系黃厚銘老師以及黃老師帶領的社會系團隊夥伴們，宜杰、冠廷、若想、昀霆以及協助進行訪談. 政治大. 的社會系同學們，除了一同進行研究外，也藉由社會系的觀點讓我了解看待事. 立. 情的新角度。. ‧ 國. 學. 再來要感謝實驗室夥伴們的協助。首先，謝謝阿悟學長、佐玄學長、家宇學長對於研究生的經驗分享。謝謝同屆的奕凱與祐甫，一同討論解決課業上遇. ‧. 到的知識。感謝小 Q 與士亮協助我解決程式技術上的問題。謝謝翌君、如意、. y. Nat. sit. 書昭、聖文、銘泉的加入。因為 PLSM 的大家，豐富了我在實驗室的生活。. n. al. er. io. 要感謝父母與妹妹在這段時間對我的支持與鼓勵，我才能無顧慮的專注在. i n U. v. 課業研究上。再來感謝大學的朋友們，謝謝祥綿，從大學一直以來各方面的協. Ch. engchi. 助、幫忙與建議。謝謝郁婷，每次聊天總是能點出我沒觀看到事情的另一面。謝謝芷榕，一同去造訪有特色的小店、景點，為我的研究生活添加了樂趣。謝謝大一認識到現在的祐誠，偶而聚會總是會想起大學時期的種種事情。謝謝一同打球的 LuLu、Trino、泰權，運動真的是釋放壓力的最好方式。然後感謝我高中的同窗好友昌澤、子瀚，每次去昌澤開的店聚聚聊天，是我在研究生活中調劑的最好方式之一。最後感謝政大網球社的大家、校務研究辦公室的同事、政大資科的所有老師、助教以及同學，謝謝大家。 2016 4 月曾文志.

(8) 目錄第一章緒論................................................................................................................ 1 1.1 研究背景........................................................................................................ 1 1.2 研究動機........................................................................................................ 2 1.3 研究目的........................................................................................................ 3 1.4 研究成果........................................................................................................ 3 1.5 論文之章節結構............................................................................................ 4 第二章相關理論與技術背景.................................................................................... 5. 政治大 2.2 相關理論背景................................................................................................ 7 立 2.1 研究方法........................................................................................................ 5. ‧ 國. 學. 2.2.1 Produsage of Space ....................................................................................... 7 2.2.2 Homo Ludens ................................................................................................ 8. ‧. 2.2.3 Pervasive game ............................................................................................. 9. sit. y. Nat. 2.2.4 Alternate reality game ................................................................................. 10. al. er. io. 2.3 相關技術...................................................................................................... 12. v. n. 2.3.1 Model–view–controller ............................................................................... 12. Ch. engchi. i n U. 2.3.2 Model-view-presenter， ............................................................................. 13 2.3.3 Object Relational Mapping ......................................................................... 13 2.3.4 Representational State Transfer .................................................................. 14 第三章系統架構...................................................................................................... 15 3.1 系統設計考量與目標.................................................................................. 15 3.2 系統架構概觀.............................................................................................. 17 3.3 系統主要元件介紹...................................................................................... 18 第四章系統實作方法.............................................................................................. 20 4.1 資料庫設計.................................................................................................. 20.

(9) 4.2 REST API 設計............................................................................................. 24 4.2.1 REST API 設計理念................................................................................... 24 4.2.2 REST API 設計內容.................................................................................. 25 4.3 MVC 實作....................................................................................................... 26 4.3.1 View ............................................................................................................ 26 4.3.2 Controller .................................................................................................... 29 4.3.3 Model .......................................................................................................... 29 4.4 獎勵制度設計.............................................................................................. 30. 政治大 4.6 前端手機 APP............................................................................................... 32 立 4.5 遊戲機制變更與系統的擴充修改性.......................................................... 31. 第五章系統測試與回饋.......................................................................................... 39. ‧ 國. 學. 5-1 使用者測試方法.......................................................................................... 39. ‧. 5.1.1 使用者測試環境模擬與參數設定............................................................ 39. y. Nat. 5.1.2 測試流程.................................................................................................... 40. er. io. sit. 5.1.3 受測對象.................................................................................................... 42 5.2 前測結果與修改........................................................................................... 43. al. n. v i n 5.2.1 後端 Server 與前端 C APP ........................................................................... 44 hengchi U 5.2.2 測試流程與訪談........................................................................................ 44 5.3 使用者測試回饋.......................................................................................... 44 5.3.1 遊戲機制.................................................................................................... 45 5.3.2 操作體驗.................................................................................................... 46 5.3.3 介面設計.................................................................................................... 46 5.3.4 故事意義與遊戲動力................................................................................ 47 5.3.5 受測者建議增加與修改的功能................................................................ 47 第六章結論與未來展望.......................................................................................... 57 6.1 結論.............................................................................................................. 57.

(10) 6.2 未來展望...................................................................................................... 58 參考文獻...................................................................................................................... 60 附錄.............................................................................................................................. 62 附件一、訪談大綱.............................................................................................. 62 附件二、訪談操作流程 A 組.............................................................................. 65 附件三、訪談操作流程 B 組.............................................................................. 66. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(11) 圖目錄 Figure 1.1 Ingress 開啟畫面.......................................................................... 2 Figure 2.1: The data modeling porcess.[18]。 .............................................. 6 Figure 2.2:Entity-relationship diagrams[5]。................................................ 6 Figure 2.3: 設計隨境遊戲的 User Story。 .................................................. 7 Figure 2.4: Ingress 遊戲畫面。 .................................................................. 12 Figure 2.5:MVC、MVP 架構。 ................................................................. 13 Figure 3.1:系統架構概觀 ............................................................................ 16. 政治大 Figure 3.3:系統元件流程圖。 .................................................................... 18 立 Figure 3.2:系統架構圖。 ............................................................................ 17. ‧ 國. 學. Figure 4.1:APP 流程圖(打卡)。 ................................................................. 21 Figure 4.2:APP 流程圖(獲得徽章)。 ......................................................... 21. ‧. Figure 4.3:APP 流程圖(計算 Keeper)。 .................................................... 21. sit. y. Nat. Figure 4.4:流程分類。 ................................................................................ 22. al. er. io. Figure 4.5:Logical data model。 ................................................................. 22. v. n. Figure 4.6:Check in 流程圖。 .................................................................... 24. Ch. engchi. i n U. Figure 4.7:Controller 程式示意圖。.......................................................... 26 Figure 4.8:USER 資料管理頁面。 ............................................................. 27 Figure 4.9:APP 地點頁面。 ........................................................................ 28 Figure 4.10:APP 徽章畫面。 ...................................................................... 28 Figure 4.11:API 回傳 JSON 資料(徽章頁面資訊)。 ................................ 29 Figure 4.12:APP 徽章設計。 ...................................................................... 30 Figure 4.13:地圖頁面根據 JSON 資料產生據點旗幟。 .......................... 33 Figure 5.1:A、B 組測試流程。 ................................................................. 40.

(12) 表目錄 Table 4.1:TEST API 設計範例。 ................................................................ 25 Table 4.2:REST 風格 URL 與傳統 URL 的差異。 .................................. 26 Table 4.3:REST 風格 URL 與傳統 URL 差異(本論文例子)。 ................ 26 Table 4.4:手機 APP 畫面與功能。 ............................................................ 34 Table 5.1:使用者測試參數設定。.............................................................. 40 Table 5.2:操作任務指令。.......................................................................... 41 Table 5.3:訪談大綱。.................................................................................. 42. 政治大 Table 5.5:B 組受測者資訊立 .......................................................................... 43 Table 5.4:A 組受測者資訊。 ...................................................................... 42. ‧ 國. 學. Table 5.6:前測問題與修正方式。.............................................................. 43 Table 5.7:使用者回饋整理。...................................................................... 45. ‧. Table 5.8:訪談內容整理。.......................................................................... 48. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(13) 第一章緒論本章介紹本論文之研究背景、動機、目的、成果，對本論文內容及章節架構有初步的說明。. 1.1 研究背景. 政治大. 傳統的遊戲大都是在固定地點遊玩，像是家中、網咖…等地方，而在智慧型手機. 立. 流行之後，隨著智慧型手機的運算能力不斷增強，手機上也裝有各式各樣的感測. ‧ 國. 學. 器，地點不再是限制人們玩手機遊戲的因素。. ‧. 過去遊戲是建構在虛擬世界進行，必須在固定地點遊玩，但由於手機的易於攜帶性使得混合虛擬世界和現實世界的遊戲變得容易實現，這一類的遊戲被稱為. y. Nat. io. sit. 隨境遊戲(Pervasive game)[9]，隨境遊戲是透過結合適地性服務(Location. n. al. er. based service) 、另類實境 (Alternate reality) 、擴增實境（ Augmented. Ch. i n U. v. Reality）…等技術,使得虛擬世界裡跟現實世界融合，現在最著名的隨境遊戲是. engchi. 由 Google 推出的 Ingress，如圖 1.1。. 1.

(14) Figure 1.1 Ingress 開啟畫面. 立. 1.2 研究動機. 政治大. ‧ 國. 學. Google 所屬的 Niantic 實驗室所推出一款具有 Pervasive game 特性的遊戲 Ingress，結合 Location based service，玩家需要在現實世界中移動去探索. ‧. 虛擬世界，也因為 Ingress 混和了現實世界與虛擬世界，使得虛擬世界中角色. Nat. sit. y. 的關係影響到了現實世界，舉例來說 Ingress 的陣營分成藍軍和綠軍，原本沒. n. al. er. io. 有特別含意的顏色，卻因為台灣政治特性，讓部分遊戲玩家會根據自己的政治. i n U. v. 立場而選擇對應的顏色，加上的 Location based service 特性會讓玩家在現實. Ch. engchi. 生活中碰面，甚至有玩家會因為朋友選擇的顏色而疏離。另一方面 Ingress 中有所謂的任務，玩家根據任務指示去造訪相關地點進行操作，而當符合條件時玩家也能自行創造任務，透過這個特性，黃厚銘老師在 Ingress 創造了一個豪宅開放空間的任務，試圖促使玩家去踩踏被非法封閉起來的豪宅開放空間，透過任務的方式進行空間創用，去重新賦予現實空間意義，將遊戲與社會運動進行了結合。對於遊戲中的陣營關係影響到現實世界，遊戲與社會運動的結合，黃厚銘老師提到，荷蘭思想家的 Huizinga 提出了人是遊戲的(Homo Ludens) [6]。遊 2.

(15) 戲人的主張，遊戲是一種人類社會的現象，不是生理也不是心理反應，而是一種有意義，創造文化的功能，像是神話傳說，就是人類充滿幻想的行為，充滿著遊戲的精神，而現今人類文明生活中的各個活動，像是戰爭、科學、商業、藝術…等.都可從神話或者宗教儀式中找到根源，因此文明跟遊戲彼此是密不可分的 [3]。. 1.3 研究目的本研究目地是與社會系團隊跨領域合作，共同設計一款具有空間創用性質的隨境遊戲(Pervasive game)，試圖再現 Ingress 中空間創用與增加黏性的過程。. 政治大. 此隨境遊戲由本論文負責實作，透過結合適地性服務(Location based. 立. service)、另類實境(Alternate reality)三種性質的遊戲 APP。這個 APP 命名. ‧ 國. 學. 為暗黑帝國，並且先以政大校園為主體，結合校園各個實體建物以及具有意義. ‧. 的雕像、石碑、故事或者裝置藝術。我們設計了一個徽章機制，探討徽章機制是否會影響玩家對於遊玩隨境遊戲的動力，並期許玩家透過隨境遊戲給予的協. y. Nat. n. al. er. io. 1.4 研究成果. sit. 作環境去改變或充實遊戲架構，甚至創用出遊戲中的遊戲。. Ch. engchi. i n U. v. 本研究展示一套不同背景的人合作流程，透過 User Story 的方式將彼此的抽象概念轉化為文字與圖像，藉由 Data model 逐步將概念建立成程式所需要的內容，並透過設計之系統架構，提供一個快速因應需求更改的環境，用以快速展示實際應用程式給予使用者了解。此外，本研究開發之 APP 將日常空間變成遊戲空間，並利用徽章機制進行了對空間重新賦予意義，並為玩家進行空間創用提供了範例，透過訪談得知玩家會對於收集徽章這件事情感到興趣，即便玩家不會從收集徽章的行為中獲得任何實質或是遊戲中的利益，如同 Huizinga 在遊戲人理論中對於遊戲的見解，遊戲是一種非理性，人玩遊戲並非從遊戲中獲得任何利益，僅僅是因為有趣。 3.

(16) 1.5 論文之章節結構本論文接下來的章節架構分類如下:第二章為相關理論與技術背景，講述研究方法以及相關的理論技術，第三章為本論文的系統架構，講述整體系統設計，從後端到前端的考量以及設計的目的，第四章為系統實作的細節，第五章為系統測試與回饋，透過訪談方式來了解本論文開發之隨境遊戲是否有達到預期的目的。第六章為結論與未來展望。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 4. i n U. v.

(17) 第二章相關理論與技術背景本章介紹本研究運用到的個中相關理論背景以及技術。包含空間創用、遊戲人理論、隨境遊戲以及另類實境遊戲，以及實際開發使用到的軟體工程相關技術。. 政治大. 2.1 研究方法. 立. 由於是兩個不同背景的團隊合作(資科系和社會系)，所以在用詞跟觀念上具有很. ‧ 國. 學. 大的差異，因此與社會系團隊討論暗黑帝國時，使用了 Data Model 的方式，. ‧. 用做暗黑帝國的實體關係討論，討論出 conceptual data model，資科系團隊再並透過 Data Modeling 的過程來逐步建立資料庫系統所需的要求， [5,16]。. y. Nat. io. sit. Data Model 主要可分成三項 conceptual data model、logical data model、. n. al. er. physical data model，圖 2.1[18]。 . Ch. i n U. v. conceptual data model: 根據用戶需求討論出來最初的要求跟規範，常用. engchi. 實體關係圖（entity-relationship diagrams，簡稱 ERD）來描述重要實體之間的關係，如圖 2.2。 . logical data model: 將資料的細節表達出來，包括所有實體的屬、關係和主鍵（primary key），以及用以連結實體關係的外來鍵（foreign keys）。. . physical data model:將邏輯資料模式依實際運作上的考量，在特定資料庫系統上實現的結果，包括資料表、欄位、鍵值、資料型態、儲存程序、存取限制等。為了讓社會系成員能更具體的表達讓資科系的成員了解跟討論，也讓資科系. 的成員能表達程式設計上的限制，使用 Agile software development 常用的 5.

(18) user story 方式(圖 2.3)，將社會系團隊設想的 ARG APP 需求，用文字跟圖像的方式表達出來，藉此判斷哪些功能是 APP 的核心價值，使得社會系跟資科系兩個團隊的人，有了互相溝通的依據，也用來排定功能或設計上的優先次序。User story 是一段簡單的功能描述，以使用者的觀點，寫下有價值的功能，不同於製作詳細的規格書，只是代表使用者的一個需求而已，通常使用者不會明確的知道他們要的是甚麼，且開發者跟使用者的認知，理解上往往會有一定的落差。. 立. 政治大. ‧. ‧ 國. 學. n. Ch. engchi. 圖 1 entity-relationship Figure 2.2:Entity-relationship diagrams[5] diagrams[5]。. 6. er. io. al. sit. y. Nat Figure 2.1: The data modeling porcess.[18]。. i n U. v.

(19) 政治大. Figure 2.3: 設計隨境遊戲的 User Story。. 立. ‧ 國. 學. 2.2 相關理論背景. 本論文研究在此章節介紹相關的理論背景以及設計系統有關的技術方法。理論. ‧. 背景講述空間創用(Produsage of Space)、遊戲人理論(Homo Ludens)、隨境遊. Nat. sit. y. 戲(Pervasve gam)、另類實境遊戲(Alternate reality game)，而關於系統設. n. al. er. io. 計的技術，介紹 Model–view–controller、Model-view-presenter、Object. i n U. v. Relational Mapping、Representational State Transfer 四種方法。. Ch. 2.2.1 Produsage of Space. engchi. 創用(Produsage)是 Axel Bruns 所創造的一個混成詞，由 produce 與 usage 兩個字所組成，是指現今網路社群的發展，使得傳統的生產者、消費者之間的關係變得模糊，如同維基百科，不再是由一群專家去生產內容，一般民眾去閱讀內容，而是任何人都可以為維基百科進行內容撰寫、修改，打破了生產者與消費者之間的分野。[2] 創用有四個的特點，開放參與與發展、各階層人才的流動、持續不斷的內容製造、共同財產與個人獎勵。 1. 開放參與與發展:透過多個用戶協作來創建完成內容，而非經由單一作 7.

(20) 者完成，越多參與者可以提升內容的品質。 2. 各階層人才的流動:沒有明顯的階層關係以及中心管理者，但是在單一主題下依然有管理員，但管理員不是為了控制其他參與者，而是為了協調彼此意見。 3. 持續不斷的內容製造:Produsage 的內容並不會完成，而是隨著時間前進，用戶們可以不斷對內容進行增修改寫，並且允許用戶可以追朔過往的修改歷史。 4. 共同財產與個人獎勵:內容是由所有的參與者共同創造，因此創造出來. 政治大益，如內容的貢獻度。立. 的產品是參與者之間所共有的，但各個參與者仍然能從中獲取個人利. 空間創用(Produsage of Space)，是將創用的概念與空間做結合，對現實生活. ‧ 國. 學. 空間進行創用。原本現實世界的空間是經由該空間的擁有者來賦予其意義，而. ‧. 藉由適地性服務將現實世界與虛擬世界的空間重疊在一起，使用者可以透過虛. y. sit. io. 2.2.2 Homo Ludens. er. 伸甚至取代。. Nat. 擬世界來對現實世界的空間重新賦予意義，使得現實世界空間原本的涵義被延. al. n. v i n Ch 自從希臘哲學家 Aristotle 將人稱為理性的動物，傳統上西方思想的主流，即 engchi U 嘗試把人類定義為為智慧人(Homo Sapoens)，但隨著工業科技的發展，人們發現人類的本性似乎不是那麼理性，因此又有人是工匠人 Homo Faber 的說法，嘗試以客觀角度來對人類的特質加以描述，但其他動物也有者製作工具的能力，在這個定義下似乎無法凸顯出人類的特質。而早在 1938 年，荷蘭思想家 Johan Huizinga 就已經寫《遊戲人》（”Homo Ludens”）一書，挑戰長期以來諸如 Homo Sapiens 或 Homo Faber 的想法。關於人類遊戲 Huizinga 認為有以下形式特色[3]: 1. 遊戲是一種自由自主自願的活動 8.

(21) 2. 遊戲的活動是有意要在日常生活之外，成為一種非嚴肅的活動 3. 從事遊戲的人通常是高度專注的 4. 遊戲是一種與物質興趣無關的活動，從事遊戲時不會獲得任何實質上的利益 5. 遊戲是在其固有的時間、空間下進行，有著固定的規則，並有秩序的遊玩 6. 透過遊戲會促成社會群體的產生，這個社會群體有著自己的秘，會透過. 政治大. 偽裝或其他方式強調與整個公有世界的差異。. 立. 從上述特點可知，遊戲是在例行時用的日常生活中獨立出來的時空場域，. ‧ 國. 學. 沒有實用、功利性目的以及無所為而為是其特徵，因此 Huizinga 的遊戲人概念主張遊戲是人類生為人類的關鍵特質，人從來都不是那麼理性的，凸顯的是非. ‧. er. io. sit. Nat. Huizinga 認為遊戲是文明進展的關鍵力量。. y. 理性的重要性，而非理性的動力也經常不亞於、甚至是超越理性的，更進一步. 2.2.3 Pervasive game. al. n. v i n Ch Pervasive game(隨境遊戲)是指混和虛擬世界與現實世界場域的遊戲，相較傳 engchi U 統遊戲，隨境遊戲強調的是使用者在現實環境中進行遊戲，虛擬世界與相關技術是用來支援與輔助的。[10] Kalle Jegers 對於隨境遊戲提出三個特點[7,8] 1. 在任何時間地點均可以進行遊玩: 由於隨境遊戲的時空特性，使得玩家不再拘限於電腦或電視遊樂器前，可以在任何時間地點進行遊戲。 2. 真實世界與虛擬世界的相互交融: 隨境遊戲是在真實世界中進行，透過行動載具，各種相關技術延伸虛擬 9.

(22) 世界到現實世界中，遊戲世界是由真實世界的環境與虛擬世界的元素一同構成的。 3. 遊戲本身驅使玩家與玩家互動: 隨境遊戲提供基本的規則與主要任務，但實際遊戲核心是透過玩家與玩家間的互動所構成的，玩家間互動不僅僅是人際上的交流，而是包含玩家一起完成各個遊戲任務。另外隨境遊戲可以從 Spatial expansion、Time expansion、social expansion 三個面向來看[4]:. 政治大隨進遊戲玩家不僅僅是在虛擬世界遊玩，而是現實世界成為遊戲世界的立. 1. Spatial expansion:. 一部分，通過在現實世界移動的方式抵達虛擬世界的地點或者透過真實. ‧ 國. 學. 世界的操作與虛擬世界互動。. ‧. 2. Time expansion:. y. Nat. 隨境遊戲打破了時間與空間的藩籬，遊戲進行的時間不受限於單一玩家. er. io. sit. 加入退出，而是隨時有玩家加入遊戲就會立刻進行，不再有所謂的休息時間，可能是在上課中、搭車中、睡覺時都有可能是遊戲進行時刻。. n. al. 3. Social expansion:. Ch. engchi. i n U. v. 由於隨境遊戲會在真實世界中進行遊玩，玩家可能會把非進行遊戲的旁觀者，認為是遊戲中的對象，如 Ingress 中，你佔領的塔被攻擊，可能會去猜測周圍任何有拿手機的人是攻擊你的對象。. 2.2.4 Alternate reality game Alternate reality game(另類實境遊戲) [1,17]的故事情節可以被參加者的想法或行動改變。另類實境遊戲需要玩家的大量參與，劇情的發生是即時的，並會受到玩家反應的影響。相對於傳統電玩中，角色是被遊戲中的人工智慧所控制，在另類實境遊戲中角色是被遊戲的設計者所控制的。玩家們直接與另類實境遊戲 10.

(23) 中的角色互動，一起解決設計好的挑戰或是謎題，也經常以一個社群的方式來分析劇情並協調現實生活與進行中的活動。早期著名的例子是 2001 年，電影《A.I.人工智慧》（A.I. Artificial Intelligence）是由史蒂芬•史匹柏導演的，史丹利•庫柏力克參與製作的一部電影，Microsoft 的團隊設計 The Beast 這款 Alternate reality game，運行了 12 個星期遊戲，重點圍繞在一個複雜的謀殺案，雖然 The Beast 只運行了三個月，卻引發了玩家間的高度組織化，跟社群間的活絡。而現今有名的 Alternate reality game ，Ingress 是由 Google2013 年發布. 政治大某種神秘的能量 XM（Exotic Matter），這一能量的來源和用途無人知曉，研究人立. 在 IOS 和 Android 平台的手機遊戲，遊戲的故事背景是一群歐洲科學家偶然發現. 員認為可以開發並善用這能量，但另一方面卻擔心這樣的能量會影響人們的思考. ‧ 國. 學. 甚至被能量本身奴役。. ‧. 遊戲中玩家被分成兩派，一派是綠色陣營(Enlightened)另一派是藍色陣營. y. Nat. (Resistance)，在 Ingress 中，玩家被稱作為探員(Agent)，兩個陣營的目標均. er. io. sit. 是爭奪塔(Portal)，Portal 是現實世界中可以被公眾探訪的地點，像是建築物、雕塑、繪畫塗鴉…等，在台灣被審核通過最多的 Portal 是變電箱上的繪圖，每. al. n. v i n 個變電箱都是由早期電影看板畫師去特別的去彩繪的。Portal 被占領後會根據 Ch engchi U. 陣營顯示對應的顏色，如圖 1-1 中，藍色是 Resistance，綠色是 Enlightened，白色則是目前不屬於藍軍或者綠軍的 Portal。由於 Ingress 在遊戲中只有提供簡單的聊天室功能，因此各地的社群大都是透過 Google 的 Hangout 來聯絡，並且由高等玩家帶領新手和舉辦活動。. 11.

(24) Figure 2.4: Ingress 遊戲畫面。. 立. 學. ‧ 國. 2.3 相關技術. 政治大. 2.3.1 Model–view–controller. ‧. MVC(Model-View-Controller) 是軟體工程中一種軟體架構模式，由 Trygve Reenskaug 在 1978 年提出，由把軟體系統分成 Model、View、Controller 三個. y. Nat. io. sit. 部分，目的是實做一種動態程式設計，使得後續開發對程式的修改跟擴充功能簡. n. al. er. 化，並且使程式具有重複利用的可能性，Model、View、Controller 三個部分代. Ch. 表的意義如下，圖 6[11,13]。 . engchi. i n U. v. View:讀取 Model 的資料進行畫面顯示呈現。將 Model 裡的資料做有目的的顯示，通常不包含程式邏輯，僅僅只是顯示，而為了實作 View 的重新整理功能，需要存取監視的 Model，並註冊。. . Controller:負責處理使用者在 view 請求，並對請求做處理。主要用於控制應用程式的流程，處理使用者行為、應用程式事件及資料 Model 並做出回應。. . MODEL:負責管理資料庫以及應用程式邏輯與規則主要用於封裝應用程式邏輯相關資料以及對資料的處理方法，擁有對 12.

(25) 資料庫的存取權，Model 不依賴 View 跟 Controller，意即不關心如何被顯示或是如何被操作。. 立. 政治大. ‧ 國. 學 ‧. Figure 2.5:MVC、MVP 架構。 2.3.2 Model-view-presenter，. y. Nat. io. sit. MVP(Model-view-presenter)是以 MVC 軟體架構模式為基礎，所延伸提出的一種. n. al. er. 模式，跟 MVC 最大的不同是分離了 Model 與 View 的關聯，均須透過 presenter. Ch. 來進行事件處理跟取得資料，圖 6[14]。. engchi. i n U. v. . Model:定義 View 所需要被顯示的資料。. . View:進行換面呈現，用以表現來自 Model 的資料，將使用者行為，傳遞給 Presenter 進行處理。. . Presenter:包含各個事件處理，從 Model 中取得所需資料，並將取得的資料轉換成所需要的格式傳遞給 View 呈現。. 2.3.3 Object Relational Mapping ORM(Object Relational Mapping)，用於實現物件導向編成語言裡不同類型系統資料之間的轉換，開發者不需要直接撰寫 SQL 對資料庫進行操作，而是透過物件的方式對資料做處理。物件導向是從軟體工程的基本原則耦合、聚合、封裝的基 13.

(26) 礎上發展的，而關聯是資料是從數學理論發展出來的，兩套理論存在著顯著的區別，為了解決這個不匹配的現象，ORM 的技術相應產生，ORM 即是透過映射關係，把資料庫的操作對應成物件使用[12]。. 2.3.4 Representational State Transfer REST(Representational State Transfer)，是 Roy Fielding 博士在 2000 年提出來的一種軟體架構風格，相較於其他複雜的 SOAP、XML-RPC 更加簡潔 Rest 是一種設計風格，主要是從三個方面定義:[4,15] 1.使用直觀簡短的資源地址，來對資源傳輸與操作，即資源是透過 URL 指定。. 政治大 3.對資源的操作對應 HTTP 協議所提供的 GET、POST、PUT、DELETE 方法。立 2.傳輸的資源是 Web 接受與返回的網際網路媒體類型，如 JSON、XML 等。. ‧ 國. 學. REST API 是基於 HTTP 協定，使用 URL 來對資源作操作，實作 CRUD(Create、 Read、Update、Delete)對應於 HTTP 協議提供的 GET、PUT、POST、DELETE 四種. ‧. 請求方法，由於前端跟後端往往是交付由不同人開發的，一個簡單易讀的 API 可. sit. y. Nat. 以減輕開發上的困難，而符合 REST API 設計的 URL 具有簡潔直觀的特性，以圖. io. er. 六為例，針對 user 這項資源使用 GET 方法時，後端會返回 user 的清單以及詳細資訊，而在 URL 後面加上編號，則是返回該編號所對應的 USER 資源，表 1。. n. al. 表 1. Ch. engchi. i n U. v. HTTP 請求方法在 REST API 中的應用[15] GET. http://example/book. PUT. POST. DELETE. 列出整組更新整組增加整組刪除整組資資源. 資源. 資源. 源. http://example/book/119 列出特定更新特定增加新的刪除指定資資源. 資源. 14. 資源. 源.

(27) 第三章系統架構此章節描述本論文系統架構設計。首先從概觀的角度出發，講述隨境遊戲的特性，再介紹系統架構的考量與設計目標，最後在介紹架構中各個主元件所負擔的功能。. 3.1 系統設計考量與目標. 立. 政治大. 由於隨境遊戲不像傳統遊戲是在固定地點遊玩，是深入現實生活環境中，以及. ‧ 國. 學. 手機 APP 的特性是需要時常即時的修正錯誤跟維護，因此整個系統設計上目的是能具備易於維護、修改的特性。. ‧. 整個系統設計分為前端和後端兩個部分，如圖 3.1，前端分成管理資料的. sit. y. Nat. web 介面，以及用於體驗遊戲的手機 APP，後端主要分成應用程式介面 API、. n. al. er. io. 主程式以及資料庫管理三個部分。. Ch. engchi. 15. i n U. v.

(28) 學. ‧ 國. 立. 政治大. Figure 3.1:系統架構概觀. ‧. y. Nat. 手機端設計考量手機 APP 必須時常進行功能增減、除錯等的程式修改，由於. er. io. sit. APP 是安裝在各個使用者手機中，要進行版本維護等工作，是較為困難的，且改版過於頻繁會給使用者不佳的體驗，因此目的是盡量減低手機端 APP 的修改. n. al. 機會。. Ch. engchi. i n U. v. 在後端系統上，應用程式介面 Application Programming Interface，考量前端有 web site 跟手機 APP 兩個部分，以及手機端 APP 不易維護的特性，在面對前端的部分，要具有一致性，即 web site 跟手機 APP 使用的 API 是同一種設計風格、思維，易於維護性，功能修改或是錯誤修正時，盡可能不需要修改到前端應用程式。在程式邏輯運算上，減低每項對應到 API 功能運算間的耦合性，提高程式碼的的可重用性，以減輕維護修改上的負擔。在資料庫管理上，程式邏輯運算層不直接撰寫資料庫的操作，而是建立一個程式邏輯跟資料庫中間的中介，目的是當資料庫有所更動時，程式邏輯層不需要隨之改變。 16.

(29) 上述是本論文系統設計的考量與想達成的目標，下面會開始對系統概觀的描述和系統元件的設計概念。. 3.2 系統架構概觀本論文的系統採用模組化的設計思維，以高聚合、低耦合為設計原則，用以達到程式碼易於維護即修改的特性，整個系統規劃採用 MVC 的架構，用以減輕系統維護難度與頻繁更動的需求，由於 MVC 架構是 Controller 接收 View 的請求後，轉道 Model 去進行程式邏輯運算，在經由 Model 返回給 View，而本論文系統為了更確實的分層設計，實際上設計更接近 MVP 的架構，即 Model 返回透過 Controller 在給予到前端。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 3.2:系統架構圖。 17. i n U. v.

(30) 圖 3.2，為本論文系統的整體架構圖，分成三個主要部分前端、後端主程式以及資料庫，以及兩個連接介面，前端與後端主程式的應用程式介面 API 是採用 REST 的設計風格，後端主程式與資料庫的溝通是採用 ORM 的方式。. 3.3 系統主要元件介紹圖 3.3，為本論文的系統主要架構流程，由前端、主程式、資料庫組成，前端分成 Web Site 和手機 APP 兩個部分，Web Site 負責系統的管理維護，手機 APP 是主要的遊戲操作，主程式是由 Controller、Service、Dao、Model 四個元件組成。整個系統流程，是由前端發出請求經由 Controller 轉到對應的 Service，經過. 政治大. Dao 向資料庫取得所需要的資料，在依序將結果返回前端。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 3.3:系統元件流程圖。 18. i n U. v.

(31) 以下對主程式的四個元件作介紹。 Controller:負責前端與後端的溝通，實作應用程式介面(API)的部分，所有前端與後端的資料傳遞都需要透過這個元件做處理，同時也包含著大多數的程式運算邏輯。 Model:定義系統所需要的物件，即資料庫所對應的 TABLE。 Service:是程式的主邏輯，根據需求設計對應的服務。 Dao:主要負責跟資料庫的操作，將和資料庫操作有關的都撰寫在這個元件上，未來資料庫有更換的話，只要對這一層作修改。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 19. i n U. v.

(32) 第四章系統實作方法此章節主要在描述本論文系統架構時做的細節，重點會從資料庫設計出發，藉由 Data Modeling 的方式，解釋如何從和使用者討論的抽象概念一步一步轉化成本 API 的設計方式，再帶入實作 MVC 架政治大. 論文的程式系統，負責前後端溝通的 REST 構的程式的實作細節。. 立. ‧ 國. 學. 4.1 資料庫設計. 從 USER STORY 討論開始，將預計 APP 的使用情境按照流程繪製出來，以確認想. ‧. 法，然後按照 Data Modeling 的流程先從 USER STORY 中去提取實體，繪製. Nat. sit. y. conceptual data model，如圖 4.1~4.3 所示，這個 APP 運作的主要流程有三項，. n. al. er. io. 第一項是 USER 根據地點打卡，並且將打卡紀錄存入資料庫中，第二項是根據第. i n U. v. 一項產生的打卡紀錄去計算出這個時間下的 KEEPER，並將每一期的 KEEPER 存入. Ch. engchi. 資料庫中以供查詢使用，第三項是根據上述兩項 USER 產生的打卡紀錄、KEEPER 紀錄，根據設定好的徽章條件，去計算 USER 是否取得這些徽章。藉由上述三項流程，可以歸納成三類，如圖 4.4，最基本的實體資料 USER、 PLACE、BADGE，屬於程式邏輯的動作狀態打卡、計算 KEEPER、計算徽章，以及根據動作衍生出來的資料打卡紀錄、獲得徽章、KEEPER 紀錄，再來將上述實體結合 USER STORY 中的程式流程繪製 logical data model，將資料的細節表達出來，包括所有實體的關係跟程式邏輯。. 20.

(33) Figure 4.1:APP 流程圖(打卡)。. 立. 政治大. ‧. ‧ 國. 學. Figure 4.2:APP 流程圖(獲得徽章)。. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 4.3:APP 流程圖(計算 Keeper)。. 21. i n U. v.

(34) Figure 4.4:流程分類。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 4.5:Logical data model。. 22. i n U. v.

(35) 圖 4.5，是本論文系統程式的 logical data model，這個 Pervasive game APP 的主要核心是 USER 的打卡紀錄，像是 KEEPER 以及 USER 獲得的徽章都是經由打卡紀錄所產生出來的，而為了提高程式效能在設計上，會把原本動態產生的資料，實體化成資料庫中的 TABLE，像是 KEEPER 是由特定期間內的打卡紀錄產生，產生這一期的 KEEPER 後，就存入另一個 TABLE，這樣要查詢過去歷史的 KEEPER 時就不需要再從打卡紀錄中提取出來，而另一個提升效能的例子是 USER 的徽章紀錄，從流程上出發，徽章是由 USER 的打卡紀錄中去尋找是否符合獲得徽章的條件，符合才授予 USER 徽章，這其中需要跨越多個 TABLE，像是打卡、USER、. 政治大效能以及對資料庫存取的工作，因此將 USER 已經獲得的徽章額外建立 TABLE 做立 PLACE、KEEPER、BADGE…等，由此可知計算 USER 是否取的該徽章是件需要大量. 存取，不做重複的計算工作已減輕後端 Server 的負擔。. ‧ 國. 學. 而在 physical data model 的部分，由於採用了 Object Relational Mapping. ‧. 的架構，TABLE 的建立是在透過程式中 MODEL 的部分去操作，且為了增加彈性以. y. Nat. 及維護性不實際賦予 Table 與 Table 間的主從鍵值關係，即每張 Table 在資料庫. er. io. sit. 的層級都是各自獨立的，而圖 15 中的關係，則是藉由程式邏輯層再賦予 Table 間的關係，以 USER、PLACE、CHECKIN 這三張 TABLE 為例，在資料庫的層級，都. al. n. v i n 是互相獨立的，刪除任一筆資料皆不會對另外三張表有所影響，而要在 CHECKIN Ch engchi U 建立打卡紀錄資料，是從 USER 以及 PLACE 取得相關欄位值，結合時間資訊存入 CHECKIN，如圖 4.6，也由於這個設計方式，在程式邏輯上要考量到表之間不會有相依的關係，表與表的關係僅是查詢作用，即刪除一筆 USER 資料，必須不會對程式造成錯誤。. 23.

(36) ，. 立. 政治大. Figure 4.6:Check in 流程圖。. ‧ 國. 學. 而在設計上第一層的實體，USER、PLACE、BADGE 是不被刪除的，而是採用狀. ‧. 態管理的方式決定是否停用，並不實際刪除該筆資料，其他的動態資料以及歷史. sit. y. Nat. 紀錄，都是向第一層的實體進行查詢。. n. al. er. io. 4.2 REST API 設計. Ch. i n U. v. 這個章節是說明前端與後端溝通的應用程式介面 API 的設計，說明為何採用 REST. engchi. 風格設計，以及實際設計的想法跟概念。. 4.2.1 REST API 設計理念應用程式介面（Application Programming Interface），是為了在系統不同組成部分相互溝通時的接口，由於現今軟體系統規模越趨複雜，需要把複雜的系統依照需求規劃分割成各個部分，為了降低系統各個部分的相依性，API 的設計就越趨重要，好的 API 設計可以提高各模組的內聚性，降低彼此的耦合程度，用以提高系統的維護跟擴充。為了降低 API 的獨立性，以及避免網路所造成的錯誤，前端所設計的每個動作，都只會對應的一個 URL，而不會是一組 URL 來完成動作。 24.

(37) 由於 REST API 只是負責轉送請求跟返回所需資料，API 介面和後端資料是分開的，只要事先設計好 API 的 URL 以及返回的內容，並準備好測試資料，前端就能先行執行測試，而後端再依照各個 API 需求把程式完成。使用 REST API 另一個好處是，只要功能不改變 API 就能提供給不同的前端重複使用。. 4.2.2 REST API 設計內容在本論文系統中前端分為兩個部分，一個是負責管理資料庫的 Web Site，另一個是提供給使用者的手機 APP。 Web Site 是用來管理資料庫中各個 table 的資料，由於資料庫會隨著系統. 政治大名的錯誤，且對於非開發者而言也不易於維護，透過 API 的方式，可以事先規劃立的開發，以及未來功能的擴充而越趨複雜，直接操作資料庫可能會造成系統上莫. ‧ 國. 學. 管理者的對於資料庫操作，管理者只能在程式有開放的功能去管理資料庫裡的資料，不僅可以避免管理者對資料庫進行錯誤操作，也由於採用 REST API 的方式，. ‧. 可以使用瀏覽器就能對資料庫進行維護。. sit. y. Nat. 在手機 APP 上，API 會同時提供給 IOS 以及 Android 使用，資源的傳遞是. io. er. 採用 JSON 的方式，手機端只要使用 GET、POST 使用 URL 對後端作請求，就會返回相應的資料，而在 REST API 結構設計上，為了前端開發著的易讀性，URL 的. al. n. v i n C h USER 相關資料，則在第二層加上第一層是作為資料的類別，要獲取某位 USER 的 engchi U ID 編號，如表 4.1。. Table 4.1:TEST API 設計範例。 URL. 用途. GET /app/user/{userid}. 取得 01 的個人資料. POST /app/user/{userid}. 更新個人資料. 在傳遞資料上，傳統的 URL 會直接把變數名稱放在 URL 上，而採用 REST 設計的 URL，不會直接看到變數名稱，隱藏了所傳遞資訊的意義，如表 4.2 所示。 25.

(38) Table 4.2:REST 風格 URL 與傳統 URL 的差異。傳統 URL. /app/place?placeid=01. REST API. /app/place/01. 以本系統中對於據點進行攻擊防禦的例子，表 4.3。attack 為 1 代表攻擊 0 代表防禦，另外兩個變數代表要攻擊的地點，以及是誰進行攻擊防禦的，可以看到前者很明確的就能讓別人知道這個 URL 所代表的意義，而後者則可以把傳遞的資訊隱藏起來，且也更為簡單易用。. 治政大 /app/attack?attack=1&placeid=2&userid=3. Table 4.3:REST 風格 URL 與傳統 URL 差異(本論文例子)。傳統 URL. 立. REST API. /app/attack/1/2/3. ‧ 國. 學 ‧. 4.3 MVC 實作. y. Nat. MVC 程式實作是採用 Spring Framework 撰寫 JAVA 程式，會由 View、Controller，. er. io. 4.3.1 View. sit. Model 三個面向來說明。. al. n. v i n Ch View 分成網頁端以及手機端兩個部分，網頁端是內鑲在 e n g c h i U Spring 主程式中，透過. Controller 將對應的 URL 轉到相應的網頁，圖 47，瀏覽器對/user 作出請求，後端 Controller 返回 USER 的頁面資料到前端瀏覽器顯示，圖 4.8。. Figure 4.7:Controller 程式示意圖。 26.

(39) 立. 政治大. ‧ 國. 學 ‧. Figure 4.8:USER 資料管理頁面。. y. Nat. sit. 考量到手機端程式維護不易，在設計手機 APP 時，配合後端傳遞的資料，手. n. al. er. io. 機頁面採用程式自動更新的方式呈現，如圖 4.9 的據點是根據後端回傳的 JSON. i n U. v. 資料所自動標記產生，根據後端回傳的頁簽數量自動產生對應的 TAB，再根據傳. Ch. engchi. 回的資料比數建立 listview 頁面，圖 4.10、圖 4.11。. 27.

(40) 政治大. 立. ‧. ‧ 國. 學. Figure 4.9:APP 地點頁面。. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 4.10:APP 徽章畫面。. 28. i n U. v.

(41) 學. ‧ 國. 立. 政治大. Figure 4.11:API 回傳 JSON 資料(徽章頁面資訊)。. ‧ sit. y. Nat. 4.3.2 Controller. n. al. er. io. Controller 是實作 API 地方，根據 URL 具執行所對應的工作，並將結果返回給. i n U. v. 前端，如下圖 4.12，是本系統中前端向後端請求某位 USER 現在擔任哪些地方. Ch. engchi. 的 KEEPER，整個程式分成三個部分，前面是設定對應的 URL，後面是採用的 HTTP 方法，中間是邏輯運算的主體，而最後是將結果返回給前端。為了系統的維護以及 API 的管理，把對資料的運算放在各個 API 之中，優點是當有新的需求或是有功能要修改時只要重新設計一個新的 URL 即可，不會影響到舊版的手機 APP 使用。. 4.3.3 Model Model 是由 Model、Service、Dao 三個部分組成，主要負責的是對資料庫的處理， Model 對應的是資料庫上的表，如圖 4.13，Service 是根據系統所設計的對資料庫的服務，而 Dao(Data Access Object)是面對資料庫的接口，會直接對資料庫 29.

(42) 的操作撰寫在這個部分，為了效能的優化，也會讓部分的功能直接撰寫 HQL 去做資料庫的查詢運算，而非讀取整個資料後在程式中運算，圖 4.14。. 4.4 獎勵制度設計由於另類實境遊戲(ARG)結合定位(Location based service)兩種特性，考量到進行遊戲時玩家不像是傳統遊戲在固定地點遊玩，因此在每個據點進行遊戲時的行為本身是必須是相對簡單的，而遊戲的複雜不是建立據點上產生，而是藉由多個據點的組合或是操作，來進行遊戲。在本論文設計遊戲的複雜度是利用徽章來達成，圖 4.12，徽章的設計主要. 政治大. 分成三類一個是單一據點的造訪次數，一個是特定幾個地點的組合，另一個是時. 立. 間與地點的關係。單一據點的造訪次數，即在某地點累積的造訪次數，如在政大. ‧ 國. 學. 大仁樓進行指定的操作 10 次即可獲的徽章。特定地點的組合，將附有意義的據點組合在一起，來讓玩家探索發現，如造訪過全校的圖書館就能獲得徽章。時間. ‧. 與地點的關係，將特定節日或者時段賦予意義，如在考前一周半夜待在圖書館。. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 4.12:APP 徽章設計。 30. i n U. v.

(43) 4.5 遊戲機制變更與系統的擴充修改性由於本論文開發的 Pervasive game app，隨者時間的進展，有進行遊戲機制的變更，打卡機制變更為巡邏機制，原本的玩家與玩家間的對立關係，即玩家對現在佔領據點的其他玩家進行攻擊，改成玩家與玩家之間是合作關係，對立對象改成是會定期侵占據點的黑暗勢力(電腦)。因此後端程式與前端就需要相應的變更。原本成為據點的擁有者是透過打卡(巡邏)次數決定，現在變成是玩家把黑暗勢力淨化之後會成為據點的擁有者，同時也引入了防禦的機制，當據點成為. 政治大. 玩家所擁有後，巡邏功能就會有額外的能力，能夠增加被黑暗勢力攻擊所減少. 立. 的據點生命值。. ‧ 國. 學. 原本失去據點的擁有權是透過玩家對據點進行攻擊，據點生命值歸零時，據點就成為無主狀態，而現在據點是玩家與電腦間的角力，電腦會固定對據點. ‧. 進行入侵，當玩家無法使用巡邏將據點生命回復時，生命值會隨時間減少，當. Nat. sit. n. al. er. io. 的擁有權。. y. 據點歸零時，就會被電腦所整個入侵佔領，玩家要透過攻擊的方式去取回據點. i n U. v. 總和上述遊戲機制變更，有資料庫、後端程式邏輯、API、前端畫面四個. Ch. engchi. 方向要進行修改。資料庫，要針對新的遊戲機制去增加既有 Table 的欄位或是建立新的 Table，如舊有的據點擁有者是過去一周的打卡次數最高的成為，因此有一個 Table 會記錄本周的擁有者是誰，當一周過去後，就會清除舊有的紀錄並匯入新的名單，而現在變更為玩家與電腦間的角力，就需要一個新的 Table 去紀錄當下各個據點誰是擁有者、生命值多少...等。後端程式邏輯，需要根據新的需求去修改或建立新的程式規則，如原本每周計算一次據點擁有者的的運算在新的遊戲機制下，就顯得不需要，反而要去設計電腦如何定期去入侵玩家佔領的據點，以及玩家與電腦之間對於據點的攻防機制。API，針對新的遊戲機制，決定是否要增加新的 API，如果所需要的資料格式相同，就可以保留原 31.

(44) 本使用的 API，只要後端程式進行邏輯修改即可，如據點的佔領機制改變，但傳遞到手機端的資料一樣是據點、擁有者的相關資訊，就可以在不更動 URL 和前端程式的情況下，進行遊戲機制的改變。手機前端，針對新的遊戲機制，進行畫面的改動，如原本沒有分陣營，現在玩家分成兩個陣營，一同對抗黑暗勢力(電腦)。針對遊戲機制改變所做的變更，在本論文設計的系統架構下前端變動的幅度主要是在 UI 呈現上面，與後端連接程式邏輯不太需要改變，而後端也因為資料庫的設計方式，不必擔心 Table 與 Table 的關係，能專注在新的遊戲機制去撰寫程式邏輯。. 立. 4.6 前端手機 APP. 政治大. ‧ 國. 學. 本節介紹前端 APP 的頁面內容，使用 Android Studio 進行開發，為了使程式能具有一定程度的擴充性，在手機端 APP 設計上，盡可能採用程式碼建構頁面，. ‧. 而不是使用 xml 設定畫面元素，圖 4.16。. n. er. io. sit. y. Nat. al. Ch. engchi. 32. i n U. v.

(45) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 4.13:地圖頁面根據 JSON 資料產生據點旗幟。. 33.

(46) Table 4.4:手機 APP 畫面與功能。首頁. 政大登入頁面. 立. 政治大. ‧. ‧ 國. 學. n. al. er. io. sit. y. 選擇陣營. Nat. APP 故事說明. Ch. engchi. 34. i n U. v.

(47) 開始遊戲頁面，提供個人資料、開始遊戲、徽章成就三個選項. 立. 個人資料頁面，顯示基本資訊. 政治大. ‧. ‧ 國. 學在指定地點巡邏一定次數獲得. sit. n. er. io. al. y. Nat. 專家徽章主要是根據單一地點的累積巡邏次數獲得. Ch. engchi. 35. i n U. v.

(48) 校園尋奇徽章需要對校園背景有一定的了解才能獲得. 立. 使用者需要去根據徽章提示去找出指定的地點. 政治大. ‧. ‧ 國. 學探索徽章說明範例. n. al. er. io. sit. y. Nat. 探索徽章，代表的是遊戲的熟練度 (巡邏地點的次數). Ch. engchi. 36. i n U. v.

(49) 地圖頁面，旗幟代表據點，顏色表示被誰所佔領. 立. 進入據點後的遊戲畫面. 政治大. ‧. ‧ 國. 學. 點擊淨化後，能對黑暗勢力進行攻擊. 敵方生命值歸零後，交由玩家佔領. n. er. io. sit. y. Nat. al. Ch. engchi. 37. i n U. v.

(50) 玩家佔領後，旗幟會變為所屬陣營的顏色. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 38. i n U. v.

(51) 第五章系統測試與回饋本章主要探討本論文系統的擴充性以及另類實境遊戲 APP 進行使用者測試，透過受測者實際操作與訪談蒐集受測者的使用體驗、心得以及遊戲邏輯的修改建. 政治大系統重構性，講述因應遊戲機制的更動，在本論文系統架構下，針對要修立. 議，並根據測試結果修正與優化系統介面功能。. 改的部分進行論述。. ‧ 國. 學. 系統測試分為前測與正式施測，前測的目的是檢驗後端與前端系統是否能. ‧. 夠正常運作以及查看正式施測可能會遇到的問題，並熟悉測試流程確保施測的. y er. io. sit. 進行正式施測。. Nat. 流暢度。並根據前測的結果，對系統、測試流程進行修正，再以修正後的系統. 5-1 使用者測試方法 a. n. iv l C n hengchi U 這個章節是說明使用者測試的相關內容，受測對象的挑選，以及測試流程設計理念。. 5.1.1 使用者測試環境模擬與參數設定本研究開發之另類實境遊戲 APP 實際進行需要藉由 GPS 的定位，由於測試的目的是了解遊戲機制的體驗回饋及系統的穩定性，在進行使用者測試時，解除 GPS 的限制，受測者不需要移動位置即可造訪各個據點，也避免施測時間過於冗長。同時也為了控制受測時間，在各個操作以及後端 server 計算的地方，對時間參數進行調整，表 5.1。 39.

(52) Table 5.1:使用者測試參數設定。相關操作. 原本需求. 測試版本. 巡邏. 三十分鐘. 五秒. 淨化. 消耗 10 點馬那值. 消耗 1 點馬那值. 電腦自動攻擊. 一小時. 兩秒. 進入據點. 附近 30 公尺的據點. 無限制. 5.1.2 測試流程. 政治大機 APP 操作，採訪的操作操作流程，圖 5.1。立. 測試流程分為 A、B 兩組，主要差異在於 B 組會要求閱讀一篇文章後再進行手. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. Figure 5.1:A、B 組測試流程。 40. i n U. v.

(53) 一、測試說明:向使用者說明測試內容與目的，並請使用者填寫過去手機遊戲的經驗。二、A 組會按照給予的指令操作 APP，而 B 組會在閱讀文章後再進行 APP 的操作。操作測試任務，表 5.2，並在一旁觀察受測者的操作行為並記錄。三、使用者體驗訪談:當受測者完成指定任務後，進行使用者體驗訪談，為了解受測者對於本論文開發之 APP 的回饋，針對遊戲機制設計、操作體驗、介面設計、故事對於遊戲的意義與動力四個方面進行訪問了解，以下訪談題目的主要部分，表 5.3。. 立. 政治大. Table 5.2:操作任務指令。. ‧ 國. 學. 操作任務. 1. 登入遊戲選擇陣營. ‧. 2. 進入個人資料並修改暱稱. Nat. sit. y. 3. 開始遊戲，選擇一個地點(點擊黑色旗幟，在點擊名稱). a. er. io. 4. 進行巡邏動作，收集馬納值. n. v 5. 進行淨化動作直到暗黑勢力石碑血量歸零 l ni 6.. Ch. U i e h n c g 占領後等待，觀看到石碑血量減少. 7. 按巡邏將石碑生命值恢復到大於 15 8. 查看徽章成就，選擇一個校園尋奇的徽章並收集完成. 9. 出示收集完成的校園尋奇徽章給受訪員，完成 APP 操作. 41.

(54) Table 5.3:訪談大綱。一. 請回顧您剛才操作的過程中，以「頁面」與「操作的動作」而言，印象最深刻的部分是什麼？. 二. 詢問受訪者關於遊戲操作介面與執行任務的感想. 三. 了解玩家對於遊戲任務與意義的喜好. 四. 了解受訪者對於本遊戲介面設計在操作上的直覺性與流暢性. 五. 本遊戲目前沒有聲光效果，您認為一款遊戲的聲光效果是不是決定您選擇或繼續玩一款遊戲的重要因素？. 六. 1.. 七. 在本遊戲中，您想獲得的是徽章成就還是遊戲任務上（例如：佔塔、. 關於本遊戲的故事，是否是吸引您玩本遊戲的因素？. 政治大. 巡邏）的成就？. 立. ‧ 國. 學. 5.1.3 受測對象. ‧. 受測者分為前測與正式施測兩個部分，前測招募兩位受測者，分別針對 A、B. y. Nat. 不同的流程進行測試模擬，正式施測 A、B 兩組共招募 10 位受測者(表 5.4、表. er. io. sit. 5.5)，受測者挑選各組皆是由三男三女所組成，同時也避免系級影響結論，挑選各個年級系所的學生進行訪談。. n. al. Ch. Table 5.4:A 組受測者資訊。. engchi. i n U. 編號. 系所. 年級性別. 偏好遊戲性質. A0. 資訊科學系. 三. 男. 動作類. A1. 地政一. 一. 女. 益智類. A2. 斯語系. 二. 男. 運動類、益智類. A3. 資訊科學系. 三. 男. 益智類. A4. 社會系. 四. 女. 益智類. A5. 英文系. 四. 女. 益智類. 42. v.

(55) Table 5.5:B 組受測者資訊編號. 系所. 年級. 性別. 偏好遊戲性質. B0. 資訊科學系. 三. 女. 無. B1. 傳播學院. 一. 女. 動作類. B2. 地政系. 二. 男. 策略類、益智類. B3. 財政系. 二. 女. 益智類. B4. 中文系. 三. 男. 益智類、策略類. B5. 社會所. 碩二. 男. 動作類、策略類. 政治大前測共兩名受測者，A 組與立B 組各一位，表 5.6 表示前測時發現的問題或是需要 5.2 前測結果與修改. ‧ 國. 學. 修改的地方。. 測試時 WIFI 正式施測時先確認該地點的 WIFI 穩定度，. n. al. Ch. engchi. 進行參考. APP 進入據點第一次進入遊戲畫面，給予操作說明，操作不夠直覺. 系統邏輯. v. 受訪者會忘記事先準備各個畫面的截圖，並印出以供受訪者操作畫面. 系統邏輯. i n U. 操作任務說明修正用語，並附上提示不夠明確. 操作與訪談. 備案就採用手機網路. er. io. 網路不穩操作與訪談. 解決方法. y. Nat. 操作與訪談. 需要修正內容. sit. 類型. ‧. Table 5.6:前測問題與修正方式。. 並在操作任務指令也提示受測者. 操作任務徽章修正後端 Server 關於徽章的判斷邏輯，有錯誤. 更正圖書館的座標地點. 43.

(56) 5.2.1 後端 Server 與前端 APP APP 的地圖界面的操作不夠直覺，前測受訪者 B0 無法順利從地圖頁面進入據點，關於從地圖進入據點 APP 的設計是先點擊據點旗幟後再點擊顯示的名稱，但受測者 B0 認為點擊據點旗幟應該就能直接進入據點，在正式測試時，APP 在各個頁面加上操作提示。關於指定任務收集校園尋奇徽章，受測者 A0、B0 提出說沒有根據提示造訪指定地點，卻獲得了徽章，經確認後是後端程式邏輯錯誤，並修正其程式碼。. 政治大測試時由於測試地點的無線網路不穩定，影響到受測者 A0 的操作順暢度以及立 5.2.2 測試流程與訪談. ‧ 國. 學. 體驗感受，最後改採用手機行動網路進行測試。. 兩位受測者在操作 APP 時均對於不同的操作指令有提出詢問，像是如何進. ‧. 入據點、甚麼是攻擊據點…等，根據兩位受測者的回饋，針對操作指令的用詞. sit. y. Nat. 進行修正，以及不明確的指令附上提示說明。. io. al. er. 在訪談詢問到各個頁面或是操作指令時，受測者會忘記部分畫面，為了順. n. 利進行訪談，正式測試時準備了 APP 各個畫面的圖示以供受訪者參考。. 5.3 使用者測試回饋. Ch. engchi. i n U. v. 正式施測對象 A、B 兩組各五位，總共十位。本節整理受測者的回饋內容，分成遊戲機制、操作體驗、介面設計、故事意義與遊戲動力四個項目。並整理了受測者對於各個部分的回饋，如表 5.7，多數使用者是喜歡本論文開發之 APP 的介面、也對於 APP 操作上的直覺與流暢性感到滿意。關於遊戲機制部分，整體來說大多數人是滿意的，有七位受訪者感到滿意。關於收集徽章、佔領(巡邏、淨化)來說，收集徽章有九位受訪者感到滿意，一位無意見，但佔領只有兩位受訪者感到滿意。. 44.

(57) Table 5.7:使用者回饋整理。是否喜歡介面. 是. 否. 無意見. A1~A5、B1、B2、. B3、B5. B4 B2、A2. 故事對於遊戲是否. A1、A4、A5、B1、. A3. B3~B5. 有吸引力直覺流暢性. A1~A5、B2~B4. 徽章是否有趣. A1~A5、B1~B4. 佔領是否有趣(巡. A2、B1. B1、B5 B5 A1、A3、A4、A5、. B5. B2~B4. 邏、淨化). 政治A2、A4、A5 大. B1~B5、A1、A3. 遊戲機制喜歡與否. 立. ‧ 國. 學. 5.3.1 遊戲機制. 關於遊戲機制大多數的受訪者對於收集徽章感到有興趣，因為會有成就感. ‧. ( A1~A5、B1~B4)，如 A1:「徽章，因為佔塔感覺沒什麼，就是它沒有跟你講你. Nat. sit. y. 佔塔了，然後可是徽章就很明顯就看得到這裡填滿，然後看到如果都填滿的話. n. al. er. io. 會有點開心。」、A5:「還蠻不錯的，就是因為跟學校做結合，但是我也只看懂. i n U. v. 兩個，蠻有挑戰性，任務我也只能到達兩個。」、B2:「其實就是成就。就是有. Ch. engchi. 東西出來，就是有獎牌出來，我就是會有成就感，就是這樣。」、B3:「操作任務中收集徽章這件事讓我覺得比較特別，巡邏和淨化在每個地方都可以這樣玩，但是收集徽章就會有很多地方可以玩，有完成任務的那種感覺。」、B4: 「我覺得任務看起來很有趣，會讓我想把全部的徽章都收集完。看到有徽章就想要，有一種強迫症，想要把它全部都打到目標。」、B5:「會讓我很想知道說，我把上面它的那個每一個地方的任務解完，會不知道怎樣，所以就，這個部分可能會促使我去比如說把每個地點的任務解決，或者是說，把它的那個徽章給集滿，然後很想看它後面可以幹嘛，這樣子。」。. 45.

(58) 另外對於攻佔據點的設計，有兩位受訪者覺得有趣。A2: 「”淨化”就會給我一種破關的感覺，因為每按一次石碑的血量就會減少。這時也才開始發現”巡邏”的意義。」、B1:「就(如果當成功佔領據點時，)它的角色或是守護者那邊，就名字會改成你的，就有一種「變成我的」的感覺。」。. 5.3.2 操作體驗關於操作體驗的部分，在各個頁面切換的直覺性與流暢性上，多數受訪者是給予流暢並不會有甚麼困難的操作(A1~A5、B2~B4)，如 A1:「嗯，很流暢，不會突然當掉。」、B2:「就是一開始還不清楚的時候，可能會試看看，但是知道之. 政治大. 後，還蠻流暢的」、B3:「沒有難度，很清楚，想要什麼就點什麼就好了。」。. 立. 但對於故事與 APP 操作上的連結，A 組受訪者有三位表示故事與操作沒有. ‧ 國. 學. 關係(A2、A4、A5)。A2:「對故事不夠理解，所以我不太知道在選擇陣營的時候到底要選什麼。」、A4:「如果沒有一些說明的話，其實不太知道就是到底進入. ‧. 這裡到底要幹嘛。就是沒有那張紙上面的步驟說明的話。因為不知道自己到了. y. Nat. sit. 這裡之後……很多打卡的地方，但我不知道自己要幹嘛。」、A5:「OK，因為看. n. al. er. io. 了那個故事，覺得那個故事很有畫面，但是回到遊戲介面就沒有覺得很搭嘎，. i n U. 感覺不看前面那個故事介紹也可以玩這個遊戲。」. Ch. engchi. v. 有四位受訪者表示遊戲地點是在自己熟悉的環境，感覺不錯。A1:「還好，可是我覺得這個....就是還不錯，訪員:政大地圖的地方嗎？嗯，就是還滿有臨場感的。」、A4:「就是地點都是自己很親近的地方。有親切感。」、A5：「就是那個地圖，學校建築物的那個地圖，蠻不錯，」、B5:「包含了生活，就是自己生活週遭的一些資訊、內容，還有地圖。」。. 5.3.3 介面設計關於 APP 介面設計的部分，大部分受訪者都給予喜歡、簡單明確的回饋 (A1~A5、B1、B2、B4)，如 A4: 「還不錯。就是蠻清楚它要我們做些什麼。」、 B4:「操作介面是還 ok，因為它還蠻明白的，很容易懂，而且我覺得介面很乾 46.

(59) 淨，沒有很多有的沒的的，所以就很容易看，看起來也很舒服。」但有部分受訪者給予不同的回饋(B3、B5)，如 B3: 「不太喜歡，因為我覺得顏色怪怪的，這種黃色的介面我不喜歡，只是單純的因為顏色而不喜歡這個頁面。」、B5: 「說實在沒有很喜歡，用起來有一點繁複，有一點卡卡的，然後再來就是，可能是它那個選項的詞吧，就是比較電動化，所以就會不知道它的意思。」。. 5.3.4 故事意義與遊戲動力關於故事對於本遊戲的動力，大多數受訪者表示並不會增加對於遊戲的動力. 政治大 B3)，另一部分是覺得故事太複雜了(A4、A5、B4、B5)。立. (A1、A3~A5、B1、B3~B5)，其中一部分受測者是覺得故事都差不多(A1、A3、. ‧ 國. 學. 而有兩位受訪者表示故事會吸引他們遊玩本遊戲(A2、B2)，A2「它是一個競爭的故事，會有一定的競爭性，所以這兩個種族競爭的故事吸引到了我。」、. ‧. B2「情景設計的比較好，有比較好的帶入感。我覺得文章寫得還蠻不錯的。其. sit. y. Nat. 實這些故事還蠻吸引人的，主要就是他們的戰爭情節吧，我對那塊比較有興. io. er. 趣。」但同時受訪者 A2 也表示故事過於複雜了，A2「人物的名字會有點難記，所以這也是為什麼我沒能很快抓住遊戲故事內容的原因，我最開始就要記很多. n. al. Ch. 名字，然後才能去看他們兩派的關係。」。. engchi. i n U. v. 5.3.5 受測者建議增加與修改的功能. 本節整理受測者對於 APP 功能上的建議，表 5.8。一、收集到徽章時要跳出訊息提醒使用者(A2、A5、B1)。二、陣營要有不同的能力(B4)。三、據點的圖片顯示多張或是有動畫(A1、A3)。四、故事與巡邏和淨化概念的連結要清楚(B3)。五、當該地點相關的徽章收集完畢後，在該據點註記(B1、B5)。六、已佔領的地點被攻擊時要提示使用者(B2)。 47.

(60) Table 5.8:訪談內容整理。項目. 受訪者回饋內容. 關於 APP 印象. A1: 是政大的校園，就是...就是真的存在的東西不是畫出來. 最深刻的部分. 的。 A2: 在故事介面，字比較多，很難很快的抓住故事的內容，最後重複看了兩三遍才會有一個大概的瞭解。沒有，因為介面給玩家的回饋不夠，不知道我到底應該去做什麼。 A3:它看起來比較簡潔，動態的操作，因爲我本身就是不喜歡，就是很少看東西，就是看字或者之類的，如果讓我可以動起來做得話，我會比較好. 政治大化）。（訪員：那印象深刻的原因是？）因為它最後按到最後立 A4: （操作的動作）就是一直按這個（巡邏）和這個（淨. 很煩躁（不足之處在於）就是不太理解這個到底是怎樣才能. ‧ 國. 學. 讓自己的生命值變大，就只能一直亂按. ‧. A5:是地圖，是校園地圖(訪員：為什麼地圖會讓你印象深刻) 因為是熟悉的名字. Nat. sit. y. B2: 操作是還好啦，就是很平常。但是我覺得文章寫得還蠻. al. 情節吧，我對那塊比較有興趣。. er. io. 不錯的。其實這些故事還蠻吸引人的，主要就是他們的戰爭. n. v i n Ch B3: 我對徽章成就的頁面印象最深，因為他跟其他的頁面長 engchi U 得都不太一樣。對巡邏和淨化印象更深。因為我其實很少玩這種遊戲，所以我覺得會有一點困難的感覺，另外也是因為在整個過程中，這兩個按鍵是按的最多的。 B4: 應該是徽章那邊，就是它可以選很多個徽章，有點像是不同任務的感覺。 B5: 頁面，原因是它有包含了生活，就是自己生活週遭的一些資訊、內容，還有地圖。. 48.