好吧，我知道軟體工程是很無趣的。而遊戲開發卻是令人興奮的。為什麼遊戲開發需要看軟體工程，總有一些充分的理由。
遊戲開發在技術上日益複雜。無論SDK和遊戲引擎將變得多麼強大，無論一個專案能動員多少人資源，遊戲開發的進度仍然很慢。遊戲開發的成本一直很高。為了做出更好的遊戲，我們必須改進軟體開發過程。
在軟體工程中，一個標準的軟體生命週期包括提出需求、設計、執行、驗證和維護。在遊戲開發週期中，構想（提出需求）和設計是由遊戲設計師負責的。程式設計師和美工按照具體的遊戲設計說明來執行。程式設計師手動將遊戲設計說明轉譯成原始碼，而原始碼將在目裝置（如PC、遊戲機和手機等）上編輯和執行。美工製作遊戲所需的美術資源。遊戲可執行後就要進行驗證測試。問題就是在這個階段中發現的。遊戲設計並不更改高層次的說明部分。相反地，只更改低層次的執行原始碼部分。在軟體工程中，這種錯誤一般被稱作“程式設計師的捷徑”。維護程度不高不僅使設計說明完全廢棄失效，而且使維護本身變成一項更容易出錯、成本更高的任務。這時，我們就走上了一條危險的道路，迷失了唯一的地圖。我們可能會因此毀掉整個軟體。
programmer(from drimmit.com)
程式設計師的揵徑可能會產生其他遊戲開發說明上的問題。我們都知道迭代遊戲設計可以產生更好的遊戲：通過增加遊戲玩法改良的次數來找到樂趣要素。但我們怎麼可能迭代越來越複雜的原始碼？畢竟它已經一團糟了。我們必須在設計層次上調整遊戲玩法，然後再將遊戲設計說明轉譯成原始碼。但我們不能再那麼做。將遊戲設計概念手動地轉譯成遊戲執行概念是非常耗成本的。程式設計師必須騰時間再做一次，我肯定他們不會樂意的。
如果有一種遊戲設計編輯器能自動地將遊戲設計高階概念轉譯成程式碼，就像原始碼編輯器自動地將原始碼轉譯成二進位制，那該多好啊！我們不能像忘記二記制一樣忘記原始碼。但在此之前，我們需要一種用於遊戲設計的準確說明語言。
我們如何將遊戲說明做得準確？
一般的解決辦法是，寫成自然語言。當然，我們可以將遊戲描述在紙上。但自然語言是很模糊的，不適合將互動系統準確地表達出來。所以用自然語言描述遊戲設計將會很糟糕。
在軟體工程中，有一種叫作指定域語言（DSL）的東西。DSL是一種適用於描述準確域任務的語言。所以我們可以將DSL用於遊戲開發。更準確地說，我們必須將DSL用於遊戲開發。
我不打算說得太詳細，但我們將DSL用於遊戲設計時將遇到兩個大問題：
第一個問題是電子遊戲設計的抽象度。有些人不在具體的技術執行範圍內就無法想象電子遊戲。我更傾向於將電子遊戲當作一種高層次的技術抽象，獨立於執行和目標裝置。為了不談Atari遊戲機，我們必須藉助高階DSL來談論《吃豆人》這款遊戲。在軟體工程中這叫作平臺獨立模式（PIM）。不要擔心裝置的具體細節，我們將在更低的抽象度上用平臺指定模式（PSM）來處理。所以我們可以將《吃豆人》指定為高階PIM，將其轉譯為適用於許多目標裝置的PSM。
第二個問題與遊戲型別有關。有些人偏好型別指定的DSL，因為它的遊戲設計概念表達更具體，可以輕易地將所有型別常表現出來。例如，一個RPG DSL應該提供的概念包括龍驗值、命值、武器、魔法等。當型別容量太大，還有存在亞型別或型別常規隨著型別演變而變化時，問題就產生了。這時的DSL就變得不充分、不實用了。這就是我不喜歡型別指定DSL的原因。型別獨立的DSL可以泛化這些遊戲設計概念，以適用於所有電子遊戲。
但什麼是技術獨立和型別獨立的遊戲設計概念？
根據Crawford提出的互動迴圈，那正是我最初的建議。我們可以從不同的方面或興趣點來看待遊戲。遊戲玩法、圖形使用者介面（GUI）和控制是所有遊戲都應該具備的三大方面。
在探討遊戲玩法時，我們可以規定有多少名遊戲與遊戲產生互動。我們還可以將存在於虛擬遊戲系統的遊戲實體歸類。遊戲實體可以分成由玩家操作的物件（即玩家角色）或由遊戲AI控制的非玩家角色（即NPC），還有一類不表現任何智力行為的對角叫作消極遊戲實體。這些概念準確地規定了遊戲玩法規則。以後有時間我將另外討論遊戲規則定義這個主題。
先說GUI。遊戲是由畫面組成的。不要將畫面看作等級或階段，而是圖形資訊佈局。各個畫面都代表了不同的遊戲實體或遊戲資訊（展示實體，如圖象、進度條、數字和文字）。所有畫面都可以是靜止的，或呈水平滾動、垂直滾動或雙向滾動。
再說控制。玩家使用控制器如鍵盤、滑鼠、控制桿或手柄來操作。各種控制器都由不同的控制元素組成，如按鍵、觸發器或手柄，它們分別向遊戲系統傳送0、1和2。更準確地說，玩家與控制元素的互動是為了執行玩家角色的活動。控制元素互動可能是按下或鬆開一個按鍵、將觸發器設為高於或低於某個閥值或將手柄轉向某個方向。
那就是用於遊戲設計的高階型別獨立的DSL。我知道這顯而易見，但非常實用。我們可能用這三個簡單的方面指定遊戲設計。當然我們還可以增加其他方面：音訊、劇情、AI或關卡設計。以上所說的只是作為一個出發點。
《吃豆人》是一款單人遊戲。遊戲中有一名玩家角色（吃豆人）和許多NPC（鬼）。還有一些消極遊戲實體，如大理石和能量球。《吃豆人》的GUI有單個靜態畫面，所有遊戲實體都用影像展示在上面。另外，玩家角色的得分是由數字表示的，而圖示進度條則表示玩家角色的命值。玩家使用操作杆或鍵盤上的四個鍵移動吃豆人。
DSL的第一個優勢是準確。因為不存在含糊不清的描述，所以所有人都能理解這種說明。甚至編輯器也能理解。
另一個優勢是，DSL容易製成圖表。各個實體概念可以表現為圖象，使整個遊戲設計說明相當直觀和容易理解。這樣我們就有了一份表現準確清析的說明。
好吧，我的DSL很不錯。但是，實用嗎？遊戲設計師真的可以用這種DSL來改進遊戲設計嗎？可能不是所有的遊戲設計都行。但我肯定它適用於某些遊戲設計：比較簡單的那種。它仍然是一種理論工具。很適合用來說明《吃豆人》和《防禦者》這類簡單的老遊戲。但是，還是那句話，我所說的只是作為出發點。
via：遊戲邦/gamerboom.com