Game Planning | 類圖(Class diagram)的使用流程與步驟
前言
這篇文章將會講述類圖的基本介紹，並且詳細敘述從零開始製作完整的類圖流程。
類圖
類圖是企劃版本的程式設計，甚至有一群以 UML 為主的程式設計師，他們不負責撰寫程式，專門製作 UML 的各式圖形，我在之前有撰寫一篇文章介紹它的基本介紹及類圖的寫法，詳情可以參考：
一、視覺化程式邏輯
在程式設計之前先繪製 UML 圖，能協助程式設計進行視覺化的幫助，程式有哪些變數、哪些函式，並且在開始撰寫之前用更低成的本與更高的效率進行程式的規劃。
開學後，在新的專案中我嘗試使用 UML 的方式進行程式撰寫，效果雖然沒有到很好，因為我們是規劃完工能後就直接開始撰寫程式，不過有一個視覺化的紀錄效果依然很好。
當我使用 UML 之後，我就能跟另一位程式用比較具體的方式去討論程式設計的內容，哪一個 class 有問題、哪一些函式說的不夠清楚，也能去判斷是否完成功能的實行。
二、功能需求的呈現
在單純的 UML 中，就能看出一個類別的功用與職責，並且能妥善地呈現是否有達成物件導向的單一職責原則，是否疊加了許多不同的功能，還是良好的只執行一個單一功用。
功能需求是我在撰寫這篇文章後想到的部分，因為我撰寫的時候習慣只列出公有函式而非私有函式，因為我以為給其他程式有關連的部分比較重要，。
這時我想到，當初撰寫程式時，其實為了完成單一職責，把函式細分成很多種不同的函式，這應該可以在 UML 階段去規劃，這項功能可以拆分成多少私有的函式。
三、程式腳本的關聯
如果有經歷過那種專案後期，應該有不少人體驗過太多程式碼纏繞，不知道這個程式腳本與哪一個式腳本有關聯，這個值是否會被其他值給改變，有哪些物件會控制這個程式腳本，這些資料都能一目了然。
程式之間的關聯在前期並沒有太大的影響性，因為前期的程式碼並不會太過於複雜，然而在設計程式時，很有可能一再疊加程式碼上去，導致最終的程式碼過於複雜，用 UML 的輔助是很有幫助的方法。
五大流程
我目前撰寫 UML 文檔，主要預計有五個步驟，雖然我目前應該只到第四個步驟而已，不過第五個步驟是我下一步預計要處理的內容，所以我依然寫進這篇文章了。
一、廣泛列舉可能需要的遊戲需求與功能
首先，把遊戲中的「所有」功能與需求列出來，只要腦袋想到一種遊戲功能或遊戲需求，就先寫下來，哪怕重覆也沒有關係，重覆列出腦中飄過的思維，直到腦袋一片空白為止。
基本上遊戲在這一塊會有很多可以處理的內容，包括遊戲管理員、玩家按鍵輸入、主角行動、敵人智能、場景控制等等，把腦中浮現出來了所有內容都列舉出來，並繼續撰寫其中的子功能。
二、分割程式功能，直到不可分割為止
當我們列完所有功能，開始繼續分割，每一寫出來的功能，包括子項目，這個功能是否可以分為不同的單一職責：例如玩家移動，玩家按下按鍵、確定方向、給予推力等等，這一連串的過程初步就能分成三個基礎功能。
這個動作要持續到不可分割為止，現在應該會有很多功能陳列，依照大致上的功能把類似的項目放在一起，以便於下一階段的進行。
三、合併相似的功能與需求
現在我們有了一群以功能分類的項目，把那些相似的功能合在一起，例如玩家跳躍、玩家移動、玩家調查都會使用到 GetAxis 來取得玩家輸入，因此可以把他們之中關於玩家輸入的部分就會合併。
當我們把所有相似功能合併之後，我們就能用這些功能去實現各種不同的功能；除此之外，也適合繼續製作出其他功能，以利維護與擴增，因為之後遇到類似功能的時候，只需要讀取這段資料即可。
四、開始製作 Class diagram
此時就可以開始製作比較詳細的規劃，也就是製作 Class diagram，開始思考比較詳細的變數與函式安排，哪些是私有、公有的變數或函式，逐步規劃每一項前面確定好的功能。
五、排列並增加連接
最後，把這些各自獨立的類圖連接起來，詳細可以參考我之前寫的文章或者網路上提供的教學，類圖的連接比較複雜，不過記得箭頭指向的是關聯對象，而非來源，應該會比較好理解。
後記
這篇文章講述了我對於類圖的理解，裡面有很多項目都是最近的感悟，因此可能有些簡陋或潦草，不過都是屬於比較印象深刻的部分。
瓶裝雪
為什麼會看到廣告
留言0
查看全部
