一個小遊戲項目《Forced landing》

<a target="_blank" href="http://blog.51cto.com/attachment/201111/170616595.jpg"></a>

<a target="_blank" href="http://www.nowpaper.net/blog/upload/month_0901/2200916104654.rar">點選下載下傳此遊戲</a>

這個遊戲展示了基本的圖形處理（镂空、疊加、切割、變色、不同格式讀取）、碰撞、動畫、按鍵處理、聲音播放，内部技術包括記憶體處理、異步處理、時間邏輯、觸發類、數組邏輯、類庫編譯、外部API調用等，當然這些看不見，要看代碼。主要使用工具：Visual C# 2008 Express程式編寫、3DMax9角色制作、Photoshop資源制作。

既然是搞項目管理的，這個小遊戲也按照一個項目來做的，那麼就按整個項目以項目管理的知識體系來說，由于非正式，一些量化的方面僅做概念處理，另外提一句，項目沒有按照原定完成。

一、啟動階段

項目目标：一個新穎的小遊戲，以此鞏固C#學習成果，試驗圖形處理

組織團隊：就一個人，管理、執行等工作有一個人完成，職權表——免

項目方案：初步方案，主角是一個失事的飛行員，要躲開殘骸順利跳傘降落，敵人是飛機殘骸被擊中生命減少直到死亡，增益道具同殘骸一起随機産生，主角獲得增益道具補生命，減益道具包括大量損血、減慢、反向操作三種，殘骸和道具的路線随風向改變，風向有辨別，界面包含場景、主角、敵人、道具、生命值顯示、風向标、高度值，主角在高度到達一定數值完成遊戲過關，共8關，難度展現在風向變化時間、敵人飛行速度、增減益道具數量，小單機無網絡，無複雜AI，無雙人對決，策劃案——免

可行研究：遊戲方式較為新穎——可行。鞏固C#學習成果——難度不大，可行。試驗圖形處理——有圖檔就可以處理了，主要檢驗于動态圖形處理方法。目标使用者主要是自己和朋友，是以項目幹系人較少，另外此作品可展示自身能力，一些潛在幹系人需要分析，考慮潛在幹系人需求，釋出的文檔要寫的好。

評估項目：基本上通過前期的準備，C#的編碼能力已經初步具備，完成此遊戲難度應不大，時間應在2天之内完成，潛在風險包括技術難度過高、軟體無法使用、個人突發事件、檔案丢失、需求變更、項目延期，這些問題的應對方案就免了，反正就我一個人嘛。評估結果是，按照二八原則，可以認定實作項目目标的80%左右是可以的，也沒有财務支出，影響到的僅是個人時間和并行事務，排好計劃就可以了。

項目決策：一個人的項目說明會……免了

二、規劃階段

可用時間計劃：星期五6個小時、星期六4小時、星期日6小時、星期一14小時，共20小時

項目範圍管理：項目範圍按照項目方案實施，工作包分解分成編碼和設計兩個部分，由于僅有兩天時間，就沒有花大力氣做工作包分解。

項目時間計劃：網絡圖如下

<a target="_blank" href="http://blog.51cto.com/attachment/201111/170627578.jpg"></a>

細緻的計劃就不寫了，計劃安排星期五完成圖形類和基本界面設計，星期六完成全部的界面設計和資源制作，星期日編寫角色代碼和邏輯架構，星期一完成剩下除了釋出和專稿以外工作。給自己的緩沖時間為星期二一天，畢竟星期三還要上課。

資源管理計劃：就一個人，無非是吃飯花點錢，需求一台電腦，編碼和設計環境，看樣子不少什麼

品質管理計劃：考慮到特殊情況，這裡就沒有寫太多，關鍵看計劃的實施品質怎麼樣。

風險管理計劃：參考前面

溝通管理計劃：一個人有啥溝通呢

三、項目實施

項目過程控制、範圍控制、進度控制、費用控制、品質控制、風險控制就不一一列舉，此項目雖小但是确為一個很全面的項目，具體說說實施過程。

項目的過程控制較為順利，基本上按照計劃進度在進行，在前期和後期都遇到一些技術難題，這些難題通過搜尋查詢的方式解決，但對最終的測試時間有一定影響，是以，網絡圖中K項工作被推到星期二進行（注意，K項的推遲并不是指單項移開，按照網絡圖以K為前置任務的任務都将被推遲）。

最不好的是範圍控制，按照原定的項目需求，應有增益道具、生命條、高度訓示，這個是沒有的，因時間問題而去除，如果按照項目管理的變更計劃，我應對此部分負責提出理由并通過準許。在這裡出現了項目範圍蔓延的狀況，不是少東西了，為什麼還蔓延，原來的項目方案中沒有過關過程，這部分邏輯沒有想到，而且界面設計也沒有考慮過關之後的結果，如果按照一個好的項目标準評判，因為在項目進展到快結束的時候才發現少了這麼多，可以說完全不對，也沒有什麼補救措施，隻好減少功能隻有一關，而且是無限玩下去。

範圍變更使得品質控制就有所制約，這裡雖沒有品質控制，但是實際上還是影響到了，到了一半還要減少功能，品質控制該怎麼辦，到底按什麼标準來控制？

四、項目收尾

收尾檢查：範圍未實作的是增益道具、生命條、高度訓示、過關邏輯、失敗邏輯都沒有做，其中包含了編碼和設計兩個部分，如果做評判，遊戲的邏輯層面僅完成不到60%的功能需求，整個項目來說，已經80%以上。

時間進度比原來推遲約4個小時，加上2兩個小時的釋出整理超過6個小時，超出是項目時間計劃6/(6+20) = 23%，時間進度控制很失敗，原因來自需求不全面，評估偏差。

項目收獲，此次項目收獲大量C#編碼實踐，并且學習到很多的新知識，項目的學習目标完成的不錯。

文檔已經儲存，并且編目加版本号，以便于随時查詢和使用裡面的實作方法。

這個項目雖然短小，但是卻也暴露了很多問題，要想管理一個項目确實非常難，那麼，項目的總結報告就算在晚上睡覺前，這是一個不錯的主意。

本文轉自nowpaper 51CTO部落格，原文連結:http://blog.51cto.com/nowpaper/712613