網(wǎng)絡游戲開發(fā)-基本設計

時間：2023-09-10 01:24:01 | 來源：網(wǎng)站運營

時間：2023-09-10 01:24:01 來源：網(wǎng)站運營

網(wǎng)絡游戲開發(fā)-基本設計：

作者：老九—技術(shù)大黍
聯(lián)系方式：qq群(197542621)
原文：Developing Games in Java
社交：本站
公眾號：老九學堂（新人有驚喜）
特別聲明：原創(chuàng)不易，未經(jīng)授權(quán)不得轉(zhuǎn)載或抄襲，如需轉(zhuǎn)載可聯(lián)系筆者授權(quán)

網(wǎng)絡游戲開發(fā)團隊

網(wǎng)絡游戲開發(fā)團隊是一個怪異的團隊，因為他們需要”烏托邦式的夢想 ”(pie-in-the-sky)創(chuàng)造力和扎實(down-to-earth)的技術(shù)相結(jié)合。這要求這個團隊個體相異，但卻需要產(chǎn)生有效性。比如A是一個有趣的人、有創(chuàng)造性的人，所以他可以設計出非常復雜、優(yōu)雅的游戲；而B是比較無趣的，以結(jié)果為導向的人，他喜歡敲代碼和討論技術(shù)細節(jié)。二者之間有會矛盾，大多數(shù)情況下A會勝出，雖然B應該是正確的—這是一個古老的問題：理論與實踐的問題！


團隊中個性問題會貫穿整個開發(fā)過程，包括設計人員、編碼人員、美工和網(wǎng)絡管理員。讓這兩種人和諧是管理這個團隊的核心，比如A類人扮演創(chuàng)造引擎的舵；B類扮演讓A類想法從理論回到現(xiàn)實。這種管理工作花費的精力是巨大的；因為很少遇到腦殘的開發(fā)團隊，一般都很難駕馭開發(fā)團隊，管理這個團隊的總體步驟是：計劃(planned)、排工(tasked)、編碼(coded)、繪畫(drawn)和測試(tested). 這些責任最終落到生產(chǎn)者和PM角色來實現(xiàn)。

理論與實踐原則

下面我們主要討論理論(設計)和實踐(開發(fā))的關(guān)系，主要是給出一些原則。

• 不要長期性的構(gòu)建，也就是不試圖讓代碼非常具有擴展性和維護性，如果開發(fā)運注意這點，那么會減少游戲的財政風險。
• 我們不能關(guān)注所有的服務質(zhì)量，特別是MTBF (平均無故障時間)。比如服務器故障會拒絕幾千成用戶，而客戶端故障會刺激玩家，增加混亂。
• 不要低估任務復雜性。移動部分會導致復雜的非線性性，MMP游戲有諸多移動部分。簡而言之，MMP游戲是標準游戲的三倍，它的復雜度是標準游戲的10倍。
• 不要低估測試和并發(fā)處理
• 高估游戲初始部分內(nèi)容，以及玩家消費時間
• 花太多的時間在游戲機制而不是游戲社會機制，這會讓玩家很難查找和讓玩家彼此之間的游戲，從而不能留住玩家
• 不要忘記CS (客服)與設計和開發(fā)一樣重要，客戶滿意低會讓游戲運行成本增加
• 只是認為是創(chuàng)建一個游戲，而不考慮游戲發(fā)生的社會場所
• 有信心非常重要，但是實施控制更重要：因為網(wǎng)絡游戲是非常龐大工程，很容易缺乏監(jiān)督，因此不要相信任何承諾，你只需要追蹤所有事情就OK
• 問題不會自己解決：個性矛盾必須快速解決，不準接受差別性的糾纏行為。如果解決好，矛盾是非常有價值的。緊張性是非常好的手段，如果運用恰當?shù)脑?。當然這都取決團隊的成熟度。記住：苔癬不會長在滾動石頭上！
• Everything moves. 因為游戲中所有的東西都是變動的，所以需要小心hard-code
• 不斷對自己重復：”Tools! Tools! And more Tools”. 我們需要大量的工具和庫代碼?；ㄥX開發(fā)非常炫酷的工具，來創(chuàng)建更有效的GUI界面，并且強迫編碼人員使用這些工具。
• 如果我們關(guān)注游戲性(游戲機制)而不是參與機制(社區(qū)機制)，那么玩家在每周20小時游戲之后發(fā)現(xiàn)我們的很枯燥無聊。只有社區(qū)機制才能留住玩家

設計

大多數(shù)網(wǎng)絡游戲開發(fā)過程如下：

• 一個小團隊拿一個項目找發(fā)行商
• 發(fā)行商看一下基本的表格，以及開發(fā)時間表之后同意該項目
• 這個小團隊開始設計文檔
• 在設計文檔還沒有完成時，團隊開始編碼
• 設計文檔還沒有完成，但是程序員已經(jīng)超過了設計人員，所以設計人員只好修改原來的設計。
• 大約一年了，設計文檔還沒有完成，但是程序員已經(jīng)作出來阿爾法版本游戲世界，以及數(shù)據(jù)已經(jīng)完成，所有人都參與構(gòu)造行為。因為這個比設計更有趣的行為
• 大約一年半之后，一些人意識到大多數(shù)的游戲機制沒有按照規(guī)范實現(xiàn)，而直接寫到程序中去，但是設計文檔還沒有完成。這時不斷有非常cool的開機畫面，以及基本的”walk and talk”演示程序給高級管理人員交差。
• 大約21個月到30個月才會達到前三個月的Beta設計要求。此時團隊意識到嚴重延遲計劃，但是人們還在設計戰(zhàn)斗機制(魔法、打斗、圍城、貿(mào)易技巧等)，以及成千上萬了對象，比如地圖片、建筑物、武器、盔甲等數(shù)據(jù)庫項。于是開發(fā)團隊決定向管理層匯報該項什delay了—我們需要更多的美工和更多的程序員加入，以達到在36個月之內(nèi)完成游戲的開發(fā)。
• 等到36個月交付時間時，開發(fā)團隊發(fā)現(xiàn)根據(jù)設計要求有許多bug需要修改。為了讓游戲機制運行，需要去掉以前的機制，包括數(shù)據(jù)設計。于是管理層很不高興，但是已經(jīng)投入6~8百萬了，他們只能同意delay了。
• 大約48個月之后，花費了1千萬之后終于完成原來一半功能的游戲做出來了，公司運行該游戲，雖然有1千個bug存在，以及使用不穩(wěn)定的技術(shù)實現(xiàn)。

怎樣解決這個問題？

在過程執(zhí)行：

• 兩次設計
• 一次建構(gòu)！

設計的態(tài)度

又叫做建議(proposal)、態(tài)度(treatment)或者游戲輪廓(game outline)。但是，所有態(tài)度都會包含如下項：

• 游戲類型(genre) – 是奇幻型，還是射擊類型
• 圖像外觀—是全3D外觀，還是需要圖形加速卡的？它是軟件呈現(xiàn)方式的嗎？它像塑料外觀，還是動漫外觀的？
• 界面樣式—就是給玩家看的界面
• 引擎—付費的，還是使用免費的，還是自己寫數(shù)據(jù)庫—是使用免費的，還是商業(yè)數(shù)據(jù)比如Oracle或者SQL Server等
• 目標觀眾—誰使用這個游戲？技術(shù)派、溫和派，還是普通大眾？這個游戲需要適應多種層次的受眾體嗎？
• 客戶端平臺—包括開發(fā)平臺和端口平臺。明確是否直接針對PC網(wǎng)絡觀眾，還是所有客戶端接入設備：Xbox和PlayStation 2或者是手機用戶。
• 主機平臺—使用什么硬件和軟件做服務器，包括物理配置、操作系統(tǒng)版本，以及開發(fā)環(huán)境、數(shù)據(jù)庫等等
• 游戲劇本是授權(quán)還是原創(chuàng)的
• 游戲性—描述玩家的游戲性體驗，描述關(guān)鍵的游戲性和玩家界面元素，可以讓我們與競爭對象區(qū)分開
• 新手體驗—對于PW而言，一個新手體驗對游戲的基本的特點和游戲機功能的了解是起到了關(guān)鍵的作用。新手體驗會幫助我們練習和引誘玩家進行游戲。
• 競爭—市場是否已經(jīng)有相似的項目存在？我們游戲與它們之間的競爭力？制作該游戲需要投入多少money?為什么我們的游戲更好？
• 員工和他們的資質(zhì)—團隊中需要多少在游戲開發(fā)的開始階段，游戲中的中級階段，以及游戲開發(fā)的結(jié)束階段？有特別需求嗎？這些工作最基本的描述與任務資質(zhì)要求是什么？
• 核心團隊—誰是生產(chǎn)者/項目經(jīng)理，誰領(lǐng)導服務/網(wǎng)絡工程師、誰領(lǐng)導數(shù)據(jù)庫設計者/數(shù)據(jù)庫管理員、誰領(lǐng)導設計？他們需要什么樣的資質(zhì)來開發(fā)這個項目？
• 時間表—開發(fā)的初步預估時間和測試時間表。一般游戲在運行6個月只能使用到80%的功能，但是，執(zhí)行總監(jiān)會希望預估投資的收回時間表。所以聰明的項目經(jīng)理會預估至少6個月的收入效益。
• 預算—初始預算一下構(gòu)建這個游戲和運行它的總費用。它包括：人員工資、軟硬件和測試成本，運行服務器硬件費用，帶寬費用，網(wǎng)絡維護費用；還有CS/玩家關(guān)系管理成本。

下面是初步設計的步驟

• 故事背景—游戲的歷史，玩家為什么在這個PW中被這樣虛擬
• 玩家界面設計
• 人物種族分類，特定的能力、優(yōu)缺點
• 人物創(chuàng)建和成長過程
• 游戲世界的位置和環(huán)境，包括所有自然的和人造的地形
• 所有的游戲機制，包括魔法、戰(zhàn)斗、貿(mào)易技巧，以及其它的相關(guān)的機制
• 圖形樣式指南(the art bible)
• 所有物品和神器列表
• 怪物類型和游戲中的怪物列表
• 固定任務，需要詳細列出
• 人員列表—設計人員數(shù)量和美工人數(shù)，什么時候需要這些人
• 第一個里程碑，第一次交付的里程碑，以及什么時候交付
• 第一次總體開發(fā)和預算啟動的時間

下面是第二次設計—初步的技術(shù)設計。當然技術(shù)設計必須有技術(shù)設計文檔，它與游戲設計文檔完成分開。技術(shù)設計文檔是根據(jù)游戲設計文檔來的，技術(shù)設計人員在書寫設計文檔之間有，必須花很多時間與游戲設計人員交流以。

初步技術(shù)設計

• 軟件—操作系統(tǒng)環(huán)境(客戶端和服務端)、編程語言和腳本語言，會用什么數(shù)據(jù)庫進行編程，會用圖形軟件和建模軟件
• 工具—使用哪種工具進行構(gòu)建，包括游戲世界構(gòu)造工具到CS和游戲內(nèi)部的GM工具。
• 游戲服務器配置和環(huán)境—需要指出物理服務器的數(shù)量(服務器叢集)，購置這些硬件的費用，第個叢集支持多少在線用戶，每臺機器的物理空間(內(nèi)存和磁盤大小)。
• 帶寬—每個玩家每秒傳輸多少位，由此估算服務器叢集需要的帶寬
• 任務列表—詳細的編碼列表，以及時間段
• 功能列表—所有接口和游戲機制功能，它的優(yōu)先是第一的
• 人員列表—完成這個項目多少程序員、工程師和數(shù)據(jù)庫管理員
• 初步切割(Fist cuts)—初步預估里程碑，交付的里程碑，以及什么時候交付；以及初步預估所有
• 原形列表—確定哪些元素是原形，哪些元素希望在粗略的框架中被demo出來？
• 技術(shù)風險列表—哪些硬件和軟件元素可能成開發(fā)的瓶頸，以可能產(chǎn)生交付延遲和失敗
• The CCP—整個游戲的改變過程，以及技術(shù)設計什么時候被提交、reviewed(復查)、approved(審批)和實施。

初步技術(shù)設計文檔階段完成之后，會有大量的技術(shù)文檔產(chǎn)出。成千上萬的被切割的小任務文檔，這些文檔在項目管理表格中會有幾百頁產(chǎn)出。比如使用MS的Project軟件生成的項目文檔，就一個角色扮演游戲來說，一般會超過200頁！

最后

記得給大黍??關(guān)注+點贊+收藏+評論+轉(zhuǎn)發(fā)??


作者：老九學堂—技術(shù)大黍


著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。