Game Planning | 類圖(Class diagram)的使用流程與步驟

前言

類圖

一、視覺化程式邏輯

　　在程式設計之前先繪製 UML 圖，能協助程式設計進行視覺化的幫助，程式有哪些變數、哪些函式，並且在開始撰寫之前用更低成的本與更高的效率進行程式的規劃。

　　開學後，在新的專案中我嘗試使用 UML 的方式進行程式撰寫，效果雖然沒有到很好，因為我們是規劃完工能後就直接開始撰寫程式，不過有一個視覺化的紀錄效果依然很好。

　　當我使用 UML 之後，我就能跟另一位程式用比較具體的方式去討論程式設計的內容，哪一個 class 有問題、哪一些函式說的不夠清楚，也能去判斷是否完成功能的實行。

二、功能需求的呈現

　　在單純的 UML 中，就能看出一個類別的功用與職責，並且能妥善地呈現是否有達成物件導向的單一職責原則，是否疊加了許多不同的功能，還是良好的只執行一個單一功用。

　　功能需求是我在撰寫這篇文章後想到的部分，因為我撰寫的時候習慣只列出公有函式而非私有函式，因為我以為給其他程式有關連的部分比較重要，。

　　這時我想到，當初撰寫程式時，其實為了完成單一職責，把函式細分成很多種不同的函式，這應該可以在 UML 階段去規劃，這項功能可以拆分成多少私有的函式。

三、程式腳本的關聯

　　如果有經歷過那種專案後期，應該有不少人體驗過太多程式碼纏繞，不知道這個程式腳本與哪一個式腳本有關聯，這個值是否會被其他值給改變，有哪些物件會控制這個程式腳本，這些資料都能一目了然。

　　程式之間的關聯在前期並沒有太大的影響性，因為前期的程式碼並不會太過於複雜，然而在設計程式時，很有可能一再疊加程式碼上去，導致最終的程式碼過於複雜，用 UML 的輔助是很有幫助的方法。

五大流程

一、廣泛列舉可能需要的遊戲需求與功能

　　首先，把遊戲中的「所有」功能與需求列出來，只要腦袋想到一種遊戲功能或遊戲需求，就先寫下來，哪怕重覆也沒有關係，重覆列出腦中飄過的思維，直到腦袋一片空白為止。

　　基本上遊戲在這一塊會有很多可以處理的內容，包括遊戲管理員、玩家按鍵輸入、主角行動、敵人智能、場景控制等等，把腦中浮現出來了所有內容都列舉出來，並繼續撰寫其中的子功能。

二、分割程式功能，直到不可分割為止

　　當我們列完所有功能，開始繼續分割，每一寫出來的功能，包括子項目，這個功能是否可以分為不同的單一職責：例如玩家移動，玩家按下按鍵、確定方向、給予推力等等，這一連串的過程初步就能分成三個基礎功能。

　　這個動作要持續到不可分割為止，現在應該會有很多功能陳列，依照大致上的功能把類似的項目放在一起，以便於下一階段的進行。

三、合併相似的功能與需求

　　現在我們有了一群以功能分類的項目，把那些相似的功能合在一起，例如玩家跳躍、玩家移動、玩家調查都會使用到 GetAxis 來取得玩家輸入，因此可以把他們之中關於玩家輸入的部分就會合併。

　　當我們把所有相似功能合併之後，我們就能用這些功能去實現各種不同的功能；除此之外，也適合繼續製作出其他功能，以利維護與擴增，因為之後遇到類似功能的時候，只需要讀取這段資料即可。

四、開始製作 Class diagram

　　此時就可以開始製作比較詳細的規劃，也就是製作 Class diagram，開始思考比較詳細的變數與函式安排，哪些是私有、公有的變數或函式，逐步規劃每一項前面確定好的功能。

五、排列並增加連接

　　最後，把這些各自獨立的類圖連接起來，詳細可以參考我之前寫的文章或者網路上提供的教學，類圖的連接比較複雜，不過記得箭頭指向的是關聯對象，而非來源，應該會比較好理解。

後記

瓶裝雪