學校課程/介面設計

Game Maker 遊戲介面設計

contents

  1. 1. 前言
  2. 2. 本文
  3. 3. 從設計開始講起
    1. 3.1. Visibility of system status
    2. 3.2. Match between system and the real world
    3. 3.3. User control and freedom
    4. 3.4. Consistency and standards
    5. 3.5. Error prevention
    6. 3.6. Recognition rather than recall
    7. 3.7. Flexibility and efficiency of use
    8. 3.8. Aesthetic and minimalist design
    9. 3.9. Help users recognize, diagnose, and recover from errors
    10. 3.10. Game
  4. 4. Demo
  5. 5. Github

前言

學校課程番外篇，有興趣者可以查閱 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 平台。