第04組 團隊項目-需求分析報告

項目總體規劃預期表

階段編號 階段時間 階段主要任務 完成狀況
第零階段 開學前 確認團隊項目,撰寫項目初期策劃 已完成
第一階段 9.18-9.20 根據策劃內容組建團隊 已完成
第二階段 9.18-10.20 前期學習、確認項目具體解決方案,撰寫完整項目策劃 已完成
第二階段過渡期 10.20-10.28 討論具體分工,等待項目啓動 已完成
第三階段前期 10.28 項目已經開始了?何時開始的? 持續懵逼中
第三階段初期 10.28-11.10 UI組設計項目原型
GamePlay組開始搭建遊戲框架
網絡功能(後端)開始搭建
設計遊戲世界觀及素材
進行中
第三階段中期 11.10-11.20 UI功能性基本實現
GamePlay基本實現運行
網絡功能(前端)開始搭建
未開始
第三階段末期 11.20-11.25 完成alpha版並測試 未開始
第四階段初期 10.28-12.10 開始驗收美術素材與文字素材
開始設計關卡和關卡製做器
未開始
第四階段中期 12.10-12.20 遊戲基本能夠正常運行(包括關卡和劇情)
網絡功能開始測試
未開始
第四階段末期 12.20-1.3 完成Bata版 未開始
第五階段 1.5-期末 測試,完成Gold版 未開始

團隊分工

Alpha規劃表

分工內容 截止時間 負責人 項目狀態
UI部分:原型設計 11.01 吳宜航 運行中
UI部分:登陸及主頁(玩家社區) 11.08 鍾博 未開始
UI部分:Playing界面 11.20 鍾博 未開始
GamePlay部分:框架設計、關卡文件註冊 11.03 鮑子涵 運行中
GamePlay部分:場景移動 11.10 王鎮隆 未開始
GamePlay部分:人物操做即動做動畫 11.10 劉俊傑 未開始
GamePlay部分:物體斷定 11.17 王鎮隆 未開始
GamePlay部分:得分斷定 11.17 劉俊傑 未開始
GamePlay部分:總體 11.20 林得翔 運行中
社區部分:能正常保存文字,上傳、下載文件 11.10 陳志明 運行中
社區部分:前端能顯示文字,能夠瀏覽歌曲信息 11.20 陳志明 未開始
社區部分附加項:能試聽關卡文件 11.20 陳志明 未開始

TODO list

成員名稱 分工 TODO list
鮑子涵 遊戲製做人、關卡設計師 一、組織團隊人員分工和任務分配,推進項目發展
二、設計遊戲主要內容
吳宜航 遊戲主策、UI設計師 一、負責項目原型設計與UI設計
二、策劃遊戲主要內容
林得翔 團隊資源管理員、遊戲主程 一、負責整合團隊資源
二、設計GamePlay邏輯框架
鍾博 UI設計師、前端工程師 一、負責項目原型設計與UI設計
二、實現原型內容
黃海東 關卡設計師、遊戲測試負責人 一、設計、實現遊戲關卡
二、負責測試遊戲,提交遊戲bug
王鎮隆 數值策劃、系統策劃 一、設定遊戲數值相關規則
二、設計遊戲其他系統合理化
高鵬 關卡設計師、前端工程師 一、設計、實現遊戲關卡
二、實現GamePlay程序
陳志明 後端工程師 設計和搭建玩家社區後端服務器
駱友鵬 前端工程師 設計和實現遊戲界面
羅繼鴻 關卡設計師、任務策劃 一、設計、實現遊戲關卡
二、策劃遊戲任務相關內容
劉俊傑 前端工程師 設計和實現遊戲界面

燃盡圖

思惟導圖

需求分析報告及答辯團隊分工狀況

隊員名稱 分工佔比 主要負責內容
鮑子涵 10% 一、撰寫需求報告
二、撰寫需求報告博客
吳宜航 10% 一、準備需求報告材料
二、準備需求報告PPT材料
林得翔 9% 製做需求報告PPT
鍾博 11% 填評審表,提問題
黃海東 5%
王鎮隆 17% 參與答辯,提問題
高鵬 7% 填評審表
陳志明 12% 填評審表,作評審表
駱友鵬 7% 填評審表
羅繼鴻 5%
劉俊傑 7% 填評審表

評審表格

UML

類圖

用例圖

活動圖

狀態圖

登陸狀態圖

遊戲狀態圖

實體關係圖

做圖工具的選擇及其評價

思惟導圖做圖工具:XMind前端

類圖做圖工具:VP Online後端

其餘做圖工具: StarUML服務器

評價:XMind是很是優秀的思惟整理軟件,其中有很是多兼顧美感和實用的思惟導圖模板網絡

VP Online是一款優秀的在線類圖製做工具,支持團隊合做前端工程師

StarUML則是比較傳統的UML製做工具,能夠製做多種UML圖框架

答辯總結

答辯得分:

小組編號 分數
第一組 53.4
第二組 49.2
第三組 47
第四組 54
第五組 44.4
第六組 48
第七組 52.8
第八組 48.6
第九組 49.8
第十組 49.2
第十一組 45.6
第十二組 39.6
平均分 48.80

問題回答:

小組編號 問題概述 問題簡答
第一組 音樂的節奏點和跑酷的地圖設計如何有機結合 這一點上咱們參考了一些主流的音樂遊戲,並學習了一些基本的樂理知識,雖然已有解決方案但目前尚未辦法比較直觀的解答這個問題,相信咱們的關卡設計師能發揮想象力將一個完美的答案獻給玩家。
第二組 遊戲創意和可玩性仍是挺不錯的,可是我的以爲充值部分有些不現實,尤爲是年卡模塊,建議仍是在免費模塊上多投入 遊戲的設計、製做、運營都須要大量的資金,咱們力求與在分享音樂和收益中獲取平衡。並且咱們的產品中接近60%的部分玩家均可以避免費得到(瀏覽關卡、論壇發言、自譜遊玩),付費部分僅限於一些來自遊戲設計方製做的須要設計與維護的增值部分(遊戲劇情、競技性等)。
第三組 若是沒有玩家本身喜歡的音樂,是否能夠上傳本地的音樂 固然能夠,製做器自己就容許並鼓勵玩家上傳已購買的音樂。
第五組 在玩家自制圖譜功能中,如何處理玩家上傳的音樂的版權問題? 這個問題我上次回答過了。對於挑戰模式,咱們不會對其進行商業化,惟一收費的項目是用於維護用戶社區的服務器,用戶本身製做和上傳的音樂素材不會被咱們商業化使用,在版權方默許的非商業化環境下玩家能夠隨意上傳、下載和遊玩。具體方案會參考《OSU!》的處理方法。
第六組 遊戲界面沒有設計如何推進項目進展文字再多也只是紙上談兵,怎麼解決? 這我也想問啊,我具體原型還沒開始設計呢,項目何時開始的我都不知道,我還等着柯老師喊開工呢結果大家全都搶跑了?
第七組 如何突出這個遊戲的亮點從而增長用戶粘性? 解決方案是競技氛圍搭建和IP建設。
一、對於硬核的玩家,搭建一個高競技性和高自由度的遊戲環境將是他們熱衷這款遊戲的方法,咱們的工做就是爲他們提供一個優秀的競技平臺與創做平臺。
二、咱們這款遊戲還引入了劇情,玩家在遊玩劇情的過程當中會帶入到主角的經歷之中。強大的IP將會是讓玩家繼續遊玩這款遊戲的利器。
第八組 實現視覺與聽覺的衝擊,仍是挺有吸引力的,對一些音樂的選取方面還能夠去作更多的調查,增強宣傳的力度 好的,後期會進行調查來完善咱們的做品。
第九組 我的認爲這種音遊比的是手速和熟練程度,論壇好像沒有用,建議去掉。 音樂並不侷限於圈地自享。咱們但願每一位聽衆能在論壇中留下本身對某一首音樂和某一個關卡的想法,讓每一位玩家都能感覺到並不是本身一我的在遊戲。
第十組 我的感受餅畫的有點大,建議仍是先從如何吸引玩家,如何留住玩家上入手 在這點上,咱們嘗試先以優秀的主線劇情和關卡來吸引玩家,並在某些方法上鼓勵玩家進行社區創做。
第十一組 後期或許能夠考慮多端? 會考慮移植到iOS和Windows平臺,Unity和C#的多平臺性是咱們選擇這套工具考慮的緣由之一。
第十二組 有玩法或者內容或demo嗎? demo暫時還沒作(我一直還沒讓他們開工...)。

根據答辯中其餘組提出的意見和建議修改完善本組需求分析報告,並標明修改之處

針對一些字體和縮進問題,對文章進行了修改工具

修改1:學習

修改2:測試

《需求規格說明書》

遇到的困難及解決方法

困難描述

一、不熟悉思惟導圖、UML圖的製做字體

二、不清楚《需求規格說明書》的具體要求

作過哪些嘗試

一、瞭解XMind、StarUML等做圖軟件

二、百度搜索《需求規格說明書》具體要求

是否解決

有何收穫

消耗大量時間瞭解了一些規範進一步學習如何吹牛皮

PSP

PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃 120 100
Estimate 估計這個任務須要多少時間 60 60
Development 開發 280 325
Analysis 需求分析(包括學習新技術) 150 160
Design Spec 生成設計文檔 300 300
Design Review 設計複審 30 30
Coding Standard 代碼規範(爲目前的開發制定合適的規範) 30 30
Design 具體設計 160 200
Coding 具體編碼 0 0
Code Review 代碼複審 0 0
Test 測試(自我測試,修改代碼,提交修改) 0 0
Reporting 報告 150 150
Test Report 測試報告 0 0
Size Measurement 計算工做量 10 10
Postmortem & Process Improvement Plan 過後總結,並提出過程改進計劃 20 20
合計 1310 1385

學習進度條

週數編號 新增代碼 累計代碼 本週學習耗時(小時) 累計學習耗時(小時) 學習內容
1 0 0 48 48 準備《選題報告》文檔,準備各項工做
2 0 0 24 72 準備《需求分析》文檔,分配人員分工
相關文章
相關標籤/搜索