遊戲問卷設計 Game Guestionnaire

問卷設計跟面試方法一樣,如何了解使用者的需求與能力,如何發問、如何誘導都是相當有趣的。對於每一種人格特質,在面對不同問題的問法時,作答的難易度是有影響的,這對面試官也是相當重要的課題,因此需要了解到問題設計的方法。

關於問卷

問卷通常會分成兩種

  • 定量分析
    詢問回答者的意見 程度 ,通常採用二值化,在從正到反極劃分數個單位,讓使用者選擇。
  • 定性分析
    單純詢問使用者的 看法 ,在不給予任何提示下,讓使用者根據自身的經驗回答問題。

當不知道問題的答案分布,既不是好與壞兩者,那麼定量分析就不能作為評估,採用開放式作答的定性分析,讓使用者回答它們所理解的,通常開放式有一個缺點,會導致過於雜亂的回答,很難得到期望的答案。想必很多人在不理解 問題描述 就會答非所問。定量分析的面向去設計,會得不到意想不到的答案,兩種方法各有優缺。

問卷設計

按照上述的兩種情況分成 選項 申論 兩種。申論題就不必說,留給使用者提出自己的看法,欄位設計就是文字欄位而非選項欄位。

特別介紹一下選項部分,通常會有 是 / 否 喜歡 / 不喜歡 ,再複雜一點就是 非常喜歡 - 喜歡 - 沒意見 - 不喜歡 - 非常不喜歡 。如果在量表中只有偶數選項,通常是不存在中立立場,希望每個應答者都給予一個立場去回答,反之在奇數選項中,給予中立立場的應答機會,通常會得到非常多的 沒意見 此時有效問卷的數量相對少。

關於面談

面談通常會分成三種

  • 結構化
    封閉式對答,在已知答案中做決策。循序讓使用者回答問題。
  • 半結構
    相較於結構化問題,不要求詢問順序性,或者是確切的答案回答。
  • 非結構
    問題會隨著應答者回答的方式變化。

通常第三者的非結構面談相當輕鬆,如果變化問題不特別刁難,面談者也會根據應答者的能力詢問相關問題。然而在結構化問題中,相當一板一眼,容易對應答者感到緊張,當問題卡住的時候,接下來的問題就會影響到應答者的狀態。半結構化則介於兩者之間。

團體面談

  • 部分應答者很容易被忽略,需要主持人去引導,觀察每個應答者在聽取其他人回答的肢體語言,適時地將每個人的意見引出。
  • 很難獲得想要的資訊。
  • 回答之間會相互影響。

特別小心主持人不應該讓面談者們 達到共識 ,而是讓他們分享所知。誤導或誘答的情況應該避免,否則有可能會造成馬拉松領先者帶著一群人走錯方向的感覺。感覺不少情況會設下陷阱去讓面談者誤答,在問題描述上不給予明確的規範,在算法問題上也常常會這樣,至於算不算誤答就不曉得,當一個人對問題的背景認知不同時,問題本身就不一樣,能不能 取悅 面試官呢?

歸納問卷

回收問卷後,利用定性方式去得到的答案是最難分析,只能靠觀察去理解,對於定量方式去設計的,將要看採用的數學模型來決策,例如消頭去尾後得到的平均數、眾數、中位數 … 等。不管哪一種方案,要看應答者的文化習慣,是否會造成不願意表態,極端情況是否正常 … 等因素,適時地消去一些實驗數據進行統計。

問卷介面也要有所區別,通常會有數個相似領域的問題,整合在一起,並且給予一個問題大綱有助於對問題的理解,特別注意到問題設計時要確定題目是否能二極化。

各組設計

最奇葩的要來了,針對認知風格進行問卷調查,針對先前設計的遊戲,不同認知風格對遊戲介面的觀感。,各組提出的問卷問題如下:

塔防遊戲

  • 遊戲中介面的引導對你有哪些幫助?
  • 升級頁面的兵種介紹對你有何影響?
  • 過多提示會不會扼殺你對遊戲的興趣?為什麼?
  • 你覺得遊戲中哪一個功能最不直觀?為什麼?
  • 是否希望一開始就解鎖所有關卡?為什麼?
  • 無法順利通關時,你都如何應對?
  • 升級頁面的兵種能力數值是否能幫助你理解兵種特性?如果不行,希望如何改善?
  • 你覺得遊戲中哪一個功能最不直觀?為什麼?
  • 你覺得遊戲中在哪個部分自由度不夠?希望如何改善?
  • 你希望遊戲中哪些介面能夠讓你自行調整?

角色扮演

  • 你覺得主畫面看起來如何 (例如背景顏色、排版、標題等等)或是其他?
  • 你覺得說明文件的詳細度以及對於操作的說明還有排版等恰當嗎,能助你了解遊戲怎麼進行?
  • 關卡劇情有沒有讓你覺得充滿故事性、關聯性,讓你進入遊戲中?
  • 遊戲的流程、難度、還有系統的圖示資訊你覺得夠完善嗎,能幫助你遊戲順利?
  • 你覺得遊戲的音樂選擇跟切換時機有讓你覺得非常合理,並且具有強大代入感嗎?
  • 您覺得遊戲難度是否可以自行解決?為什麼

我們組所提出的七個問題如下

  • 您覺得遊戲難度是否可以自行解決?為什麼
  • 您最喜歡、討厭這遊戲哪一部分,討厭的話,想改成什麼?
  • 您覺得遊戲內介面的看法如何?
  • 您對於介面的動畫效果的看法如何?
  • 您玩完這款遊戲後,對遊戲目標瞭解程度 (例如劇情 …)?
  • AI 擬真程度對遊戲操作的感受?
  • 原本期望的效果、事物卻沒在遊戲中的是什麼?

解謎遊戲

  • 在遊戲進行當中在覺得最困難的部分為何?
  • 如果在遊戲中加入選關模式,你有什麼看法?
  • 對於遊戲介面,你認為有什麼可以改善的地方?
  • 教學關卡對你學習遊戲的操作模式有什麼影響?
  • 對於破關後才加入競速模式,你有什麼看法?
  • 你認為遊戲劇情有何改善空間?

問卷統計範例

本課程教學極為詭異,應該請全班人一起填,總共才七組來卻只要求自己去找 課程班上 十個人來填問卷,互填對方設計的遊戲問卷難道這麼困難嗎?老師應該要直接請全班來填寫吧,用鼓勵的方式,居然在畢業前一周要大家填問卷,一星期統計好並且報告,明顯地大家都在忙畢業典禮的拍照,問卷也很晚統計回來。

當然十個人的樣本數只能自我安慰,下什麼結論都是不具有信用的,只好按照老師的調調亂扯一通。就算遊戲做得再差,問卷回饋不如預期的對答,也許按照自己的預測方式去報告就行,問卷感覺就是裝飾用的。自己的教授自己靠北?

問卷結果

分別對於兩個版本,非常非常少的實驗數據。

遊戲難度 Holist 認為難度簡單,對遊戲進行不算困難,對於 Serialist 比較有新事物認知上的起手問題。

在遊戲偏好上,大部份的 Holist 看到了整體的光影效果對此深感好奇,而 Serialist 不少指出遊戲說明上的困惑與扣除血量的細節。

在遊戲內介面上,Holist 對於道具切換、使用狀態有強烈的要求,太過簡潔的界面是介意的地方,而在 Serialist 對於顏色要求較為強烈,對於簡介的介面設計滿意。

在遊戲介面動畫上,Holist 比較偏向回答遊戲內部的元素動畫,而 Serislist 則比較在意流血效果和字體閱讀。在這一部分的回答可以說是有點誤導,預期是想要讓他們回應遊戲介面動畫,而非遊戲內的元素動畫。

在遊戲目標上,一致都朝著遊戲通關目標為基準,而非劇情走向,估計是劇情走向對遊戲進行流程不影響,所以沒有必要去注意遊戲劇情內容。

在人工智慧 AI 上,Holist 比較偏向滿意,對有一些與現實邏輯不合的反應介意,對於 Serialist 對於 AI 的反應比較兩極,有好有壞。

對於預測遊戲進行上,Holist 比較想要的是局部性改變,例如效果與道具使用上、遊戲進行邏輯、新的功能利於闖關。而 Serialist 比較喜歡全局性的擴充,如新增關卡、不同類型的通過條件、關卡成就感、角色成長的需求。

課程意見

請不要一堂課的結尾就喊出成績來決定一個學生的價值,若要從認知風格中挑選一種分類,老師的認知風格屬於一種衝動型,部分是需要不斷反思來接受新的資訊。不強求這門課的走向,但從做遊戲方面,可說是此次教學的創舉,既然要我們寫程式,麻煩就以資工系的方式引導,時間跟計劃不是一兩個星期前講就了事,牽涉到設計與構思,不給一個明確的方向,導致各組面向不同種遊戲,類型不同的遊戲設計出來就不能隨意說好與壞,若是要符合你們口味的網路學習,那直接說做益智遊戲即可,有些探討問題也因遊戲類型扯不上關係。

若要用小組程式作業、設計作為不上課的理由實在說不過去,導致這一學期很多次沒上課,起碼可以一個小時上課,後兩個小時討論的方式。而在論文上台報告卻有報告老師的同一篇論文,導致報告內容重複且冗長。上課投影片請不要用講稿模式 (兩攔筆記式,另一半的筆記欄位不知道給誰看的),可以請助教弄全螢幕的投影片。

Read More +

遊戲介面設計及效果 Game UI & Effect

前言

上次沒有好好地將遊戲內容進行擷取說明,單純對介面設計原則做說明,介面設計會根據裝置操作有所不同吧,那遊戲介面是否又能如此?

要把法則呈現在遊戲中又是另一回事,畢竟遊戲跟網頁又有點差別,當然也有人認為認知風格跟遊戲性不相干,倒不如說會跟遊戲內容有關,遊戲內容決定介面設計方向,若要根據認知風格設計,想必會是一道難題。

遊戲內容的多寡將決定運行的流程、架構,遊戲介面越簡潔越好,最後的演化就是什麼 都沒有最好 ,除非有人喜歡儀表板,那就另當別論。隨著遊戲必要才出現的介面,會導致程式撰寫相當麻煩,要用排除法來防止奇葩的流程走向。

不僅介面擺設需要考量,還要有觸發時間、方法,以及浮現效果,這些會影響到使用者是否知道可以使用,大部分的介面以文字為主,那串接效果影響不大。為了提升使用者體驗,最好是使用圖示為主,但這會造成跟背景融合的一體感,可能會造成無法被使用者察覺可觸發,必須在圖示效果加點功夫。

就像虛擬實境課程內容所提及的漸進式效果會比較好,對於使用者有如虛擬實境,也就是說介面出現的時間跟方法不能太過迅速。關於上虛擬實境課程的那些小事,有如在上影像處理課程的虛擬實境呢。

以上內容,僅本人觀察。

Github

如果圖片看不到,請至 Github 中的 doc 目錄下查閱本篇附圖。

遊戲執行檔和開源代碼都在其中,當然還有遊戲的編輯器。更多的遊戲截圖在裡頭,只支持 windows 平台。

Animate

Info Demo
Menu Enter/Select Menu
Button Enter Menu
Popup Menu Menu
Menu Focus Menu
Lighting Menu
Fog Menu
Use Props Menu
Caption Menu

Screenshot

選單使用方向鍵和滑鼠點擊操控,同時提供大綱說明。

Info Demo
How to Play Menu1
Story Menu2
Test Room Menu3
Achievement Menu4
Options Menu4

Tutorial Design

使用教學關卡,步入遊戲元素與操作。

Info Demo
Tutorial Tutorial

Game UI Design

遊戲介面細節設計

Info Demo
Tip Tip
Control Information Information
Exit Warning Information
Props View 1 (Scroll up) Letter
Props View 2 (Scroll down) Letter
Level Complete Clear
Level Fail Fail

Game Element

遊戲元素效果

Info Demo
Hide Hide
Use Use
Test Room Test

Option Design

遊戲配置設計

Info Demo
Sound Sound
Difficult Difficult

Story Design

過場 (eyecatch) 劇情的介面設計

Info Demo
Story Story
Story branch 1 Story
Story branch 2 Story branch

Other Mode

遊戲模式設計

Info Demo
Time Mode 1 (Time Count) Time
Time Mode 2 (Time Up) Time
Time Mode 3 (Time Over) Time

Feature

考量的設計並沒全部去實作,提供設計參考。

Info Demo
Old 1 Old 1
Old 2 Old 2
X-Box X-Box
Andriod Android
Hexagon Hexagon
Overview 1 Overview 1
Overview 2 Overview 2

Game Layout

Info Demo
Origin Origin
Clear Clear
Icon With props 1 Icon
Icon With props 2 Icon
Exit Menu Exit Menu

Option Setting

Info Demo
Keyboard 1 Keyboard 1
Keyboard 2 Keyboard 2

Over Layout

Info Demo
Popup popup

Game Flow

Info Demo
With Over over
With Eyecatch eyecatch

Game Caption

Info Demo
Balloon balloon
Read More +

認知風格 設計篇

接續上一篇

調整方法

調適能力 (Adaptivity) 與調適性 (Adaptability)。前者能依據使用者的互動 (interaction) 自動修改應用程式的行為,後者則是依照預先定義好的選項來改變應用程式的行為。

網頁設計類型 優點 缺點
Adaptivity 迅速地貼近使用者,使用者不必做過多設定 由於自動變化,對於使用者教學會相當困難
Adaptability 客製化過程有參與感,可以更了解系統功能 入門困難,適應介面到可以客製的過程長

介面初步

1
2
3
4
5
6
7
8
9
10
test version
______ ______ ______ __ __
/\ == \ /\ __ \ /\ __ \ /\ \/ /
\ \ __< \ \ \/\ \ \ \ \/\ \ \ \ _"-.
\ \_____\ \ \_____\ \ \_____\ \ \_\ \_\
\/_____/ \/_____/ \/_____/ \/_/\/_/

+-------------------------------------+ +--------+
| type you want | |Find it!|
+-------------------------------------+ +--------+

從最基礎的設計中,明顯地會需要一個輸入框與觸發的按鈕。但是搜尋條件有幾種,從 作者 本文 標題 出版期刊 … 等,這些要怎麼設計才好?

《大神落伍了?這些搜索引擎比 Google 精確還更有趣》 這裡提到專門的搜尋引擎,可以針對音樂、圖片、社群、找人 … 等內容進行搜尋。他們是怎麼完成的?

介面二步

1
2
3
4
5
6
7
8
9
10
test version
______ ______ ______ __ __
/\ == \ /\ __ \ /\ __ \ /\ \/ /
\ \ __< \ \ \/\ \ \ \ \/\ \ \ \ _"-.
\ \_____\ \ \_____\ \ \_____\ \ \_\ \_\
\/_____/ \/_____/ \/_____/ \/_/\/_/

+-----------+ +--------+ +-------+ +--------+
| BOOK NAME | | AUTHOR | | WHERE | |Find it!|
+-----------+ +--------+ +-------+ +--------+

這裡的設計多了三個欄位,有些欄位可填、可不填,進行分開的搜尋。然而會不會發生有人誤填一些資訊,誤把人名當書名,造成搜尋結果不好。為了考量這些,基本上都是在搜尋結果中做一個排序,排序的優先權可能先按照書名、作者、地點。搜尋方式的比例差異通常呈現普遍性。

為了加速篩選結果,通常會先抓書名,如果書名不夠具有特色,則會嘗試抓作者名稱,如果作者出版很多本書,則會考慮出版時間、內容。能按照內容進行搜索的引擎,肯定規模很大。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
         ______     ______     ______     __  __    
/\ == \ /\ __ \ /\ __ \ /\ \/ /
\ \ __< \ \ \/\ \ \ \ \/\ \ \ \ _"-.
\ \_____\ \ \_____\ \ \_____\ \ \_\ \_\
\/_____/ \/_____/ \/_____/ \/_/\/_/

+-----------+ +--------+ +-------+ +--------+
| BOOK NAME | | AUTHOR | | WHERE | |Find it!|
+-----------+ +--------+ +-------+ +--------+


+---------------+---------------+---------------------+
| BOOK NAME | AUTHOR | WHERE |
+---------------+---------------+---------------------+

+---------------+
| TITLE |
+---------------+
| SUBTITLE |
+---------------+
| CHAPTER |
+---------------+
| NICKNAME |
+---------------+
| PROLOGUE |
+---------------+

有一種方式是提供搜尋條件的細節,來增加使用者的搜尋效率。上面就是一個範例,不僅僅只是官方書名提供搜索,細節劃分也是相當重要。甚至有人會將書給予暱稱,例如書的名稱太普通,卻以某種封裝、寫法出名,那麼這些書的名稱可能就比較特別。

對於場依賴的而言,看得到的搜尋介面相當重要,它們比較容易根據環境提供的條件,因此設計效能上影響很多。反過來看看場獨立的人,對於這個介面操作可能會將自己的想法投入,這些想法可能來自於自身或者是之前學習過的知識。

1
2
3
4
5
6
7
8
9
10
argument version
______ ______ ______ __ __
/\ == \ /\ __ \ /\ __ \ /\ \/ /
\ \ __< \ \ \/\ \ \ \ \/\ \ \ \ _"-.
\ \_____\ \ \_____\ \ \_____\ \ \_\ \_\
\/_____/ \/_____/ \/_____/ \/_/\/_/

+-------------------------------------+ +--------+
| learning in 23 days type:reference | |Find it!|
+-------------------------------------+ +--------+

對於隱藏式的操作想必也是相當上手。但這種使用需要教學,不是相當方便。可以由簡到繁地引領使用者,例如說第一次搜尋操作後,自動填充,提示使用者下一次搜尋的方法。

1
2
3
+-------------------------------------+     *--------*
| learning in 23 days | |Find it!| <--- click
+-------------------------------------+ *--------*

得到結果後

1
2
3
4
5
6
7
8
9
    +-------------------------------------+     +--------+
| learning in 23 days type:reference | |Find it!|
+-------------------------------------+ +--------+
----------------------------------------------------------------------
Find result with ...

* learning in 23 days, author:Alice, type:reference
detail ...
* ...

現在的設計大多都是由 簡到繁 的方式,從蘋果軟體中都可以發現到這些特徵,將不常用的功能都先藏在特定的地方,先基礎地提供最低需求,當使用者發現結果越來越不好時,主動地去察覺要怎麼使用更複雜的操作。

介面三步

當然有些人搜尋的結果,會根據場依賴、場獨立來查閱,場依賴偏向是由觀眾評分、評論來判定是否找到正確的書,場獨立純文本內容為主。著重的觀點不同,為了成功銷售所有的書籍,顯示的方法如下兩種參考。

1
2
3
4
5
6
7
----------------------------------------------------------------------
Find result with ...

* Learning in 23 days, author:Alice, type:reference
detail ...
* WTF Learning, author:Blob
detail ..
1
2
3
4
5
6
7
8
----------------------------------------------------------------------
Find result with ...

* [HOT] STAR: 5, learning in 23 days, author:Alice, type:reference
detail ...
* STAR: 3, WTF Learning, author:Blob
detail ..
* ...

以上示範的是場獨立、依賴的兩種。當然上面的設計屬於階層式、也有水平擺放訊息的方式。其實還有很多種的!

1
2
3
4
* 1 TITLE AUTHOR 
* 1.1 DETAIL
* 1.2 DETAIL
* 1.2.1 DETAIL
1
2
3
4
5
6
7
8
+-------+   +------------------------------------------+
| | | TITLE |
| | +------------------------------------------+
| COVER |
| | +------------------------------------------+
| | | AUTHOR, DETAIL |
| | | |
+-------+ +------------------------------------------+

如果找書不根據任何別人推坑的想法,階層式會是很好的細節來決策,嘗試把每一本書的概要都仔細讀過,階層式很吃 優先權順序 ,設計起來相當挑戰。

如果是下方的方式,比較偏向大致上已經在事前知道要買哪本書,有了大概目標。這樣的設計方式方便跳躍性的搜索,因為階層式會 改變高度 ,檢索時的位移量不同會造成操作時間會比較久,但是下方的那種方式屬於固定位移量。

至於對色彩學的配色部分,又分單色、雙色欄位,來加快視窗滑動的對齊。而每一個欄位的文字色彩也相當講究,用色數量越多,看起來越五花八門,面向的使用族群也越多。為了讓使用者有 貼切感 (服務的專一性),通常用色不大於三種。

回頭調整

Adaptivity 提供系統自動調整變化,最好提醒使用者可以切換回去舊的介面設計,否則多個使用者在現實中交談時,可能會發生矛盾的錯亂交流。

Adaptability 提供使用者自定義,這些功能從系統中抽離出來,對於開發者來說是件好事,讓所有功能盡可能地讓特定使用者使用,但普遍性來說,大多數的功能都會被忽略,甚至當作從來沒有過。

Adaptability 類型的網頁設計,提供高度穩定性、客製化,有利於長時間的網站經營,培養長遠的顧客為主,對於短期入門的新手而言,對於客製化的吃力程度不一,當尚未熟悉系統前,對於功能設定處於一知半解狀態,需要閱讀文檔或累積經驗。因此在使用前期效率並不高,有待一段時間後,使用效率就有機會突破 Adaptivity 類型的。

正因為使用時間的長短,Adaptability 比較適合高頻率使用的軟體,而且功能性很強。相較於 Adaptivity 給予功能性較低,但操作起來會比較耗時 (滑鼠移動、滾動) 的軟體。

Reference

Evaluation of a personalized digital library based on cognitive styles: Adaptivity vs. adaptability

課程需求才看得,雖然我對裡面的實驗方法一點也不認同,很多地方沒有考慮進去,實驗的順序性有考慮到,卻沒有去考慮適應面向的主體,拿幾次任務的時間來進行比較往往是不夠的,根據時間成長的效率比較也應該被提出。

課程公告

由於明天的課程有多數同學因畢業旅行而無法前來上課,因此明天上課的方式將不在課堂上進行,而改為同學閱讀所附的 paper,並找時間與組員討論所附的問題

請容許我罵一聲!我擦!為什麼不上課!雖然老師上課的認知風格與我不同,無法好好地學習知識,在盡可能地去適應,卻不斷地減少上課次數,學期結束前都還沒有適應吧。

Read More +

認知風格 找你所好

前言

曾想過明明有資源,卻怎麼樣都學不好嗎?在一個群體中學習,偏偏是落單的那一個人嗎?最近上課講到認知風格的相關內容,又對學習上有所障礙,到底是哪裡出了問題?

本文

如果一名學生的認知風格與教師類似,這個學生就會有更積極的學習經歷,學習將會改善。
隊員如果擁有 類似認知風格 ,將會使他們對於參與有更 積極 的感受。而認知風格的匹配將使參與者與人共事時感覺更為 舒適 ,雖然它並不能獨自保證取得勝利的結果。

明明身處同一個環境下,成長幅度卻來得比別人低,沒錯!學習上完全沒有共鳴,導致學起來相當痛苦,建造、聚集知識的方式不同,兩路不相逢,要如何引領另一個走向相同目標?

在思考知識、經驗傳播問題前,先來認識自己,當然以前人所提供的分類方法,既不是唯一也不能二值劃分,必然有人有於兩邊優缺點,呈現自然分布,很少人是相當極端的特例!

接下來要胡言亂語囉!不用擔心!只是學習的過程不同,不代表能力的侷限。

認知風格

Wholist-Analytic

看待一個事物時,採用策略的認知方法 (從舊有事物著手,了解處理事物之間的關聯)。來看看是怎麼 吸收 管理 新訊息。

Field Dependence & Independence

美國心理學家威特金 (Witkin) 在 1940 年代研究垂直知覺時首先發現的。強調認知的過程而非內容。

  • Field Dependence 場依賴
    偏向利用環境訊息來了解事物。
  • Field Independence 場獨立
    不依賴外界資訊,由個體的方式去理解。

場獨立自主、改造能力高,對於社會技能低。相反地,場依賴則在社會技能高,對於自主、改造能力低。當然從成長過程、性別差異,會逐漸地特化、轉變成另一類,並非完全由天生決定。

一種宅宅的既視感,不外乎差別就是願不願意聽外界,當個固執的聰明人還是頑固的蠢蛋,靠著外界成長就能成為現充,當個活在社會的人。場獨立則相當危險似的,若不是聰明的那一群,很容易被誤解、淘汰於社會中。 社會究竟是何物呢?

Leveller & Sharpener

赫爾茲曼 (K.Holzman) 和克萊因 (Klein, 1954) 使用 水平 - 尖銳 認知型來描述認知風格的另一維度。

  • Leveller 水平
    利用舊有資料產生關聯,並且加入新資料進去,但這樣做容易發生混淆,關聯的下場不保證能夠邏輯地去理解,相當於把多個物品放在同一處,「 他們應該是相似的 」的感覺,甚至有時還會因為擺滿物品而捨棄。一種以增加代替修改的 持久化算法 呢!
  • Sharpener 尖銳
    相對於水平,會想盡辦法 取代 掉舊有資料,把相似之處抓出來後,放大物品差異再放回去架子上,減少混淆的情況。但對於相似之處會被移除,聯想某個物品時,只會看到最後擺放的位置,回答問題只會去描述極端的差異?操作起來一定相當耗時,放大差異去分析處理,想必會很慢。

接下來分析行為上,有一種傾向。Leveller 運行 self-inwardness 模式,避免主動參與活動,對於指導、相助有迫切的需要,傾向於 自我貶抑 的性格。Sharpener 運行 self-outwardness 模式,相較於 Leveller 更喜歡 競爭 自我展現 ,對於成就有高度的需求,常常會逼迫自己推進。

看起來,Leveller 只是因為有 Sharpener 的人存在,才會偏向自我貶抑吧!而 Sharpener 擺明就是一個抖 M 推進器。

Impulsivity & Reflectivity

由卡根 (J.Kagan, 1964) 及同事提出來的,指在不確定條件下個體作出決定速度上的差異。

  • Impulsivity 衝動
    快速地成形自己的看法,對於問題可以很快速地回答,有迫切做出決定的慾望。
  • Reflectivity 反思
    相反地,不斷地反思自己看法,考量所有可能性才能回答問題,並且設想所有評估所有答案的優缺。

這兩種在整體性的工作上沒有任何差異,但反思型學習速度比較慢。

Diverging & Converging

由吉爾福特 (Guilford, 1967) 在介紹智力模型時提出的。

  • Diverging 發散
    回答問題時,答案允許多個,接受多種解決方案,強調多樣性、創造性。
  • Converging 收斂
    強調找到一種明確的正確答案。

只有一種答案不是很無趣嗎?對於我而言,越是要求那麼唯一,就越不是答案,也許是因為找不到唯一的答案吧,才去接受多種選項的可能性。

Holist & Serialist

由帕斯克 (G.Pask, 1972) 和司科特 (Scott) 提出的。

  • Holist 整體
    大規模搜索資料,進行較大的特徵假設,嘗試去找到一個模式、關係來理解。
  • Serialist 序列
    單一方向、單一步驟來完成理解,對於細節較為著重,不在意整體的連接關係。

序列導向的人肯定對於讀書這類的序列資料很感興趣,也比較能一頁一頁的讀完,對於整體導向的人而言,常常會跳躍章節去讀,才會逐漸深入理解。

序列導向通常面臨的是細節著重,而無法看到整體概念,整體導向則由整體概念來理解,而缺少細節的驗證。從具有遠見的程度來看,整體導向會比序列導向來得高,正因為不清楚,才有廣闊的視野吧!

Verbaliser-Imager

心理學家 Paivio (1974) 提出了長時記憶信息如何被加工存儲的理論。影像儲存還是文字儲存?有一種原始影像資料和壓縮過後的大綱儲存差別,語言系統一改,壓縮而成的文字內容會造成理解錯誤吧?

Verbaliser & Imager

Riding 和 Taylor 最初提出的。

  • Imager 形象
    傾向於以視覺表象的形式思維的人被稱為形象型的人。
  • Verbaliser 言語
    傾向於以詞的形式思維的人被稱為言語型的人。

根據許多研究,當學習材料不匹配時,得到的成績往往不理想。而在人格性質上,往往言語型偏向外向、形象型偏向內向。等等,好像明白為什麼語言類型的科目會比較難學,因為很難形象化,導致只有言語型的人可以在這一方面學習得不錯。

Reference

Read More +

Game Maker 遊戲介面設計

前言

學校課程番外篇,有興趣者可以查閱 Github

本文

本課程一開始著重 尼爾森法則 的介面設計,不只是在網頁操作等介面設計,雖然遊戲沒有複雜的狀態跟操作流程,但在設計上的操作反應、都應該要符合尼爾森法則。

Game Maker 這套軟體只是製作 UI 方便,遊戲性跟高難度設計不是很著重, 不看你的代碼或實作複雜度 。這也是本課程最弔詭的地方。Game Maker 有一個缺點,製作時的分工無法按照軟體分工的方式,實作部分代碼來完成,除非組員們都會寫 script 並且了解語法的變數存取方式。

從設計開始講起

可以從課程問卷中看到 link 幾個遵循的法則。

Visibility of system status

狀態可視有幾格要點,玩家方便知道當前狀態,例如所在關卡、遊戲模式的狀態、角色資訊的狀態、完成關卡的結算畫面 … 等。

紅框位置處表示狀態

同時在需要連續操作的完成流程,如銀行手續的設計,會顯示當前步驟進行到幾分之幾,來提示使用者其實還沒有完成所有步驟。然而在遊戲上,完成比例通常不是著重的一環,而是有哪關卡可以玩、有哪些關卡還沒去探訪過。

Match between system and the real world

主要為圖示運用,icon 對應的操作符合普遍性,通常會遇到的第一個錯誤設計是將原本用在某個地方的圖示拿來放在不應擺放的位置。例如音樂撥放器的撥放、暫停、停止、前轉、循環、 … 等,很容易在選擇上誤用箭頭的格式。

接著是在文字對應,選項的文字也要具有普遍性,符合直觀的反應文字,詞性也應選擇恰當 (當心誤用形容詞當選項文字),問題描述的正面詢問與反面詢問,反應在選擇選項時應足夠明確 (反問內容是否合理,不常見的反面詢問應該捨棄,防止使用者用既有概念進行操作)。

遊戲規則設計符合合理,當要貼切真實世界時,如物理反應與遊戲元素之間的關聯應該符合,如遊戲中運用到水和火,兩物體若發生碰撞,反應結果應符合消滅對方的關係。

User control and freedom

所謂的自由度,玩家不會被困在一本道的遊戲設計,但是在抖 M 類型的遊戲中,只要一失敗就必須從頭打起。玩家不會一直被系統帶著跑,而無法中斷、暫停遊戲,同時也表明重新步入遊戲時,可以選擇自己進行的模式。

自由度的操控有很多,客製化玩家的操作、給予玩家改變遊戲的部分設計,如鍵盤控制的改變、允許玩家更動角色的樣貌、樣式,可以更動關卡模式,例如 L4D2 可以選擇專家模式 … 等。

Consistency and standards

一致性設計,相當於風格設計。

  • 按鈕的圖示在不同狀態若具有相同功能,使用圖示相同。
  • UI 擺放位置,不常因不同模式而更動 (突然放左、突然放右。)
  • 文字字型的使用統一使用,並且區分遊戲劇情與系統介面,相同類型的文字說明應符合一致。

Error prevention

防止錯誤操作,當玩家已經在別款遊戲中擅長使用快捷鍵時,那很有可能在遊戲中使用快捷鍵操作,這可能會造成不預期的反應,如快速關閉遊戲、啟動某個遊戲的系統功能。

因此在防止錯誤,通常會用 第二次詢問 來防止。在快捷操作上,二次詢問要利用不同的快捷鍵觸發,防止連按的快速操作,如連按兩次 ESC 突然跳出遊戲的蠢事。

提示操作的後果也是相當重要,必須在文字說明上明確描述,盡可能使用簡短的句子和例子來說明操作後果。說明時著重使用者觀點,而非功能性介紹 (介紹對於使用者的感受可能會變成怎麼樣,而不去說明電腦架構的效能 … 等專業知識)。

當遊戲需要高度複雜的邏輯,導致道具使用上的 順序性會影響流程 。當玩家處於無法通關的狀態時,提示哪個步驟錯誤,同時也告知玩家應該重新挑戰。這一類型就是引導提示。

Recognition rather than recall

在遊戲功能分類上,遊戲道具的使用類型應該設計主動操作與被動操作,在欄位劃分上是其中一種設計。當空間不足與進行欄位劃分,在道具的背景、顏色上的區分是一個解決方案,例如用三角形的外框表示消耗型道具、六角形表示永久的增益型道具。 用圖示背景與位置來區分操作類型 ,防範使用者如猴子般地等待道具效果。

Flexibility and efficiency of use

操作相當具有彈性跟有效地使用!

有些遊戲需要高度複雜的組合鍵來完成一個動作,同時也要求組合鍵的有效時間。先不論組合鍵的設計,若存在組合鍵,是否符合效率使用,是否可縮減成另一個指令,當分化深度歧異過大時,考量壓縮組合鍵的長度。例如有 5 個技能是由 3 個鍵組合觸發,4 個技能是由 5 個鍵組合觸發,壓縮到 4 個鍵以內 … 等。

正常情況下,有多少使用者會直觀這麼做,組合鍵設計是否合理,是否可以藉由 系統輔助來簡化操作流程 ?這些考量將成為易上手,入門玩家最需要的部分。就如 vim 編輯器的使用,直接面向高端使用者,入門就會相當地困難。

Aesthetic and minimalist design

提示、排版設計,在 Apple 軟體看得很明顯,操作相當簡單,不會一次把很多功能塞在同一個頁面。在功能性很強的軟體,常常會把很多參數調校放在同一個頁面,而沒有做好區別與預設,即使功能性很強、軟體很好用,但很多功能反而會被忽略,由於沒有好的簡化設計,第一手想要嘗試的使用者,會跳過好幾個功能設定進行反饋。 開發者開發的功能就白費了!

盡可能讓畫面簡潔,縮減不必要的進階資訊,用額外的方式體現,設計不同的介面模式。

Help users recognize, diagnose, and recover from errors

系統發生錯誤時,是否有足夠的資訊讓使用者查覺到 不是遊戲正常設定 ,來讓使用者回報這些程式設計 Bug。在系統設計的魯棒性,不應一個 Bug 產生而造成系統崩潰,遊戲也是一樣,讓使用者返回上一個正常的狀態,不會造成卡關、或者卡關之後遊戲損毀。

復原狀態對於小遊戲設計上相當困難啊!

Game

  • 故事劇情 (Storyline)
  • 遊戲性 (GamePlay)
  • 美學圖形 (Artistic/Graphics)
  • 音效特效 (Sound/Special effects)
  • 人工智慧 (AI)

故事劇情可以結合真實部分,在真假交織下發展。

可以參考 《额外加分 Extra Credits》 《TUN高品位低调宅》 系列影片,這將會告訴你遊戲如何設計才具有特色。

下面列了兩個影片,更多可以直接去觀看 youtube 上的頻道。

其他的列點就是一種個人價值觀體現,還沒有詳細學習。

Demo

影片加速展示內容。

Github

遊戲執行檔和開源代碼都在其中,當然還有遊戲的編輯器。更多的遊戲截圖在裡頭,只支持 windows 平台。

Read More +