做游戲外包最怕的不是開發(fā)延期而是交付那天你打開包發(fā)現(xiàn)做出來的東西跟你腦子里想的那款游戲完全不是一回事。我做過發(fā)行、也接過外包兩邊角色都干過對(duì)“驗(yàn)收”這兩個(gè)字的體會(huì)特別深。很多人把驗(yàn)收當(dāng)成走流程覺得“東西交了、我看看沒問題打款就完了”結(jié)果項(xiàng)目上線才半個(gè)月各種隱藏問題集中爆炸再回去找外包方人家一句“當(dāng)時(shí)驗(yàn)收你過了啊”就把你堵死了。這篇就圍繞游戲外包開發(fā)的驗(yàn)收從驗(yàn)收標(biāo)準(zhǔn)怎么定、流程怎么走、常見怎么坑到不同平臺(tái)的側(cè)重點(diǎn)全部捋一遍。1. 游戲外包驗(yàn)收的核心認(rèn)知1.1 驗(yàn)收不是終點(diǎn)是項(xiàng)目風(fēng)險(xiǎn)的最后一道閘門游戲開發(fā)外包和買標(biāo)準(zhǔn)件完全不同。買一百個(gè)螺絲釘抽檢三個(gè)合格這一批基本沒問題。但游戲是個(gè)復(fù)雜的軟件系統(tǒng)加數(shù)字內(nèi)容產(chǎn)品有玩法邏輯、美術(shù)表現(xiàn)、程序穩(wěn)定、適配兼容、性能優(yōu)化、計(jì)費(fèi)安全等一串維度交織在一起。任何一個(gè)環(huán)節(jié)出問題玩家感知到的都是“這游戲真爛”。外包開發(fā)模式下驗(yàn)收就是你手里唯一的正式控制手段。開發(fā)過程中就算你天天看版本、提反饋乙方在最后階段也可能為了趕工或降成本悄悄替換素材、精簡(jiǎn)實(shí)現(xiàn)邏輯、甚至把某些功能做成“看起來是這樣其實(shí)是假的”。這些小心思只有在嚴(yán)格驗(yàn)收時(shí)才會(huì)暴露。我把驗(yàn)收比作游戲上線前的“安檢”你不可能因?yàn)閷?duì)方說“我們做了安全檢測(cè)”就放心登機(jī)你必須親眼看到檢測(cè)報(bào)告、親自確認(rèn)關(guān)鍵指標(biāo)。游戲外包驗(yàn)收做得越扎實(shí)項(xiàng)目上線后的運(yùn)營(yíng)風(fēng)險(xiǎn)和口碑風(fēng)險(xiǎn)就越低。1.2 分清驗(yàn)收和體驗(yàn)反饋別把兩件事混為一談很多項(xiàng)目方犯的第一個(gè)錯(cuò)誤是把“驗(yàn)收”當(dāng)成“試玩提意見”。朋友玩了一下說“手感不對(duì)”老板看了一下說“按鈕不夠炫”這些是主觀體驗(yàn)反饋雖然重要但不是驗(yàn)收的正式依據(jù)。真正的驗(yàn)收依據(jù)是事先明確、雙方書面確認(rèn)的標(biāo)準(zhǔn)。它包含兩類量化標(biāo)準(zhǔn)可測(cè)量的指標(biāo)比如啟動(dòng)時(shí)長(zhǎng)不超過3秒、幀率穩(wěn)定在30或60fps、崩潰率低于0.5%、包體大小不超過200MB、內(nèi)存占用峰值不超過1GB等。清單標(biāo)準(zhǔn)功能完整度清單比如“商店系統(tǒng)包含商品展示、購(gòu)買、支付回調(diào)、發(fā)貨、斷網(wǎng)重試、訂單查詢六個(gè)模塊”每一個(gè)模塊必須按需求文檔逐項(xiàng)確認(rèn)。主觀體驗(yàn)只能作為“是否達(dá)到驗(yàn)收邊界條件”的參考不能作為拒絕驗(yàn)收的核心理由。如果驗(yàn)收標(biāo)準(zhǔn)里寫了“操作手感流暢無遲滯感”那這個(gè)“流暢”也需要定義成“點(diǎn)擊響應(yīng)時(shí)間小于100ms角色移動(dòng)與輸入延遲不超過一幀”否則雙方理解永遠(yuǎn)不一致。1.3 合同階段就要寫清驗(yàn)收條款不是做完再說這是我踩過最深的坑之一。早年我接過一個(gè)休閑游戲外包合同里關(guān)于驗(yàn)收只寫了一句“符合雙方確認(rèn)的設(shè)計(jì)文檔”。結(jié)果交付時(shí)對(duì)方美術(shù)風(fēng)格大變我說不符合人家拿出文檔里一句“風(fēng)格兼顧卡通與寫實(shí)”懟回來。這種模糊表述到了驗(yàn)收階段就是扯皮源頭。正確的做法是在合同或者附件里明確嵌入驗(yàn)收條款。幾個(gè)必須寫清楚的點(diǎn)驗(yàn)收依據(jù)文檔列表列出需求規(guī)格說明書、UI/UX設(shè)計(jì)稿、技術(shù)方案文檔、QA測(cè)試用例清單這些文檔一旦雙方確認(rèn)就具有合同效力。驗(yàn)收節(jié)點(diǎn)和周期比如初驗(yàn)、復(fù)驗(yàn)、終驗(yàn)三個(gè)節(jié)點(diǎn)每輪驗(yàn)收的反饋時(shí)間窗口是幾個(gè)工作日超出默認(rèn)怎么處理。驗(yàn)收通過的定義是“無嚴(yán)重Bug、無功能缺失、達(dá)到所有量化指標(biāo)”才算通過還是“主要功能可用、已知問題有處理計(jì)劃”就算通過必須白紙黑字寫明白。未通過的處理機(jī)制是限期修改后重新驗(yàn)收還是罰款、按比例扣款或者允許項(xiàng)目方自行修復(fù)后從尾款中扣除費(fèi)用。2. 驗(yàn)收前的準(zhǔn)備工作2.1 建立驗(yàn)收標(biāo)準(zhǔn)清單一個(gè)原因兩個(gè)維度準(zhǔn)備驗(yàn)收第一步不是“打開包開始玩”而是先把標(biāo)準(zhǔn)清單寫出來。我習(xí)慣用一份驗(yàn)收明細(xì)表把整個(gè)驗(yàn)收拆成多個(gè)可勾選、可打分的項(xiàng)。這份表不是我自己悶頭寫而是從需求文檔里逐條提取并跟乙方在開發(fā)中期就對(duì)過一遍。清單至少包含兩個(gè)維度缺一不可功能維度需求文檔里的每一個(gè)用戶故事、每一個(gè)模塊、每一個(gè)按鈕跳轉(zhuǎn)全部列成條目標(biāo)明“必須實(shí)現(xiàn)”“建議實(shí)現(xiàn)”“可選實(shí)現(xiàn)”三個(gè)優(yōu)先級(jí)。必須實(shí)現(xiàn)的遺漏直接算驗(yàn)收不通過。建議實(shí)現(xiàn)和可選實(shí)現(xiàn)可以商量但談判籌碼要跟尾款掛鉤。質(zhì)量維度性能指標(biāo)、兼容性范圍、安全要求、代碼規(guī)范、資源規(guī)范如每張圖的大小上限、音頻采樣率等非功能性的要求。這部分最容易遺漏也最容易在驗(yàn)收時(shí)爆發(fā)矛盾。一個(gè)游戲如果美術(shù)精美玩法完整但一到低端機(jī)就閃退玩家照樣罵街那這個(gè)驗(yàn)收只能算“半個(gè)通過”。我通常會(huì)做一份表格化的驗(yàn)收清單示例大致長(zhǎng)這樣驗(yàn)收類別驗(yàn)收項(xiàng)驗(yàn)收標(biāo)準(zhǔn)驗(yàn)收方式結(jié)果功能新手引導(dǎo)玩家在3分鐘內(nèi)完成完整引導(dǎo)流程引導(dǎo)步驟無卡死人工試玩自動(dòng)測(cè)試通過/不通過功能商店購(gòu)買支付成功后2分鐘內(nèi)到賬斷網(wǎng)時(shí)有明確提示重復(fù)點(diǎn)擊不會(huì)重復(fù)扣款人工支付沙箱通過/不通過性能啟動(dòng)時(shí)間冷啟動(dòng)不超過3秒中端設(shè)備性能測(cè)試工具通過/不通過性能幀率核心玩法場(chǎng)景幀率穩(wěn)定在30fps以上Profile工具持續(xù)記錄10分鐘通過/不通過兼容設(shè)備覆蓋覆蓋目標(biāo)機(jī)型Top100列表全部通過啟動(dòng)與核心玩法測(cè)試真機(jī)云測(cè)通過/不通過安全協(xié)議防篡改核心道具購(gòu)買請(qǐng)求無法通過簡(jiǎn)單抓包篡改實(shí)現(xiàn)代碼審計(jì)抓包測(cè)試通過/不通過2.2 準(zhǔn)備測(cè)試環(huán)境、測(cè)試工具和測(cè)試賬號(hào)驗(yàn)收最怕什么最怕兩邊環(huán)境不一致。你說“我這邊崩了”他回“我這邊好的”最后一查一個(gè)是Android 13一個(gè)是Android 8一個(gè)是iOS 16.5一個(gè)是iOS 17 beta問題壓根不在同一頻道上。準(zhǔn)備驗(yàn)收材料時(shí)必須同步準(zhǔn)備以下東西測(cè)試設(shè)備矩陣列出覆蓋目標(biāo)用戶群的測(cè)試機(jī)型列表至少包含低端機(jī)2臺(tái)、中端機(jī)2臺(tái)、高端機(jī)2臺(tái)、iOS和Android各半有條件地把平板也納入。測(cè)試網(wǎng)絡(luò)環(huán)境弱網(wǎng)模擬工具比如Charles、Network Link Conditioner分別模擬2G/3G/4G/Wi-Fi高延遲環(huán)境驗(yàn)證游戲在網(wǎng)絡(luò)波動(dòng)時(shí)的表現(xiàn)。測(cè)試賬號(hào)體系包含不同付費(fèi)等級(jí)的賬號(hào)白號(hào)、首充號(hào)、活躍賬號(hào)以及用于測(cè)試支付回調(diào)的沙箱賬號(hào)。日志與抓包工具Logcat、Xcode Console、Charles、Wireshark等遇到問題時(shí)可以第一時(shí)間拿到證據(jù)跟乙方溝通時(shí)直接甩日志效率比來回截圖高十倍。我個(gè)人的習(xí)慣是在驗(yàn)收前建一個(gè)共享的問題管理表乙方、我方測(cè)試、我方策劃都在里面。所有驗(yàn)收過程中發(fā)現(xiàn)的問題誰發(fā)現(xiàn)的、什么設(shè)備、什么操作步驟、什么現(xiàn)象、日志鏈接、截圖鏈接、指派給誰、修復(fù)狀態(tài)全部記錄明確。這個(gè)表既是驗(yàn)收過程的追蹤工具也是最后簽署驗(yàn)收?qǐng)?bào)告的附件證據(jù)。2.3 安排角色分工誰驗(yàn)收、誰拍板、誰記錄驗(yàn)收不是一個(gè)人的事情也不是讓“某位同事順便玩一玩”。一個(gè)規(guī)范的項(xiàng)目驗(yàn)收至少要三個(gè)角色驗(yàn)收負(fù)責(zé)人我方項(xiàng)目經(jīng)理或制作人負(fù)責(zé)把控整體進(jìn)度、安排驗(yàn)收計(jì)劃、匯總問題清單、對(duì)接乙方負(fù)責(zé)人、最終簽署驗(yàn)收?qǐng)?bào)告。測(cè)試人員專職QA或者懂技術(shù)的同事負(fù)責(zé)按測(cè)試用例逐項(xiàng)執(zhí)行記錄問題提交復(fù)測(cè)。業(yè)務(wù)/策劃代表負(fù)責(zé)從產(chǎn)品角度判斷功能是否滿足需求文檔玩法是否符合設(shè)計(jì)意圖UI交互是否合理。如果把產(chǎn)品經(jīng)理也拉進(jìn)驗(yàn)收當(dāng)然更好但一定要避免“人人都有發(fā)言權(quán)、最后沒人拍板”的局面。外包驗(yàn)收講究的是“以標(biāo)準(zhǔn)為準(zhǔn)以證據(jù)說話”不是比誰嗓門大。在所有問題處理完畢后只有驗(yàn)收負(fù)責(zé)人有權(quán)跟乙方說“通過”還是“不通過”。3. 驗(yàn)收流程實(shí)操?gòu)奶釡y(cè)到達(dá)標(biāo)的完整鏈路3.1 第一步乙方提測(cè)先做冒煙測(cè)試乙方說“我們做完了可以驗(yàn)收了”你不能直接開大會(huì)更不能不測(cè)試就召集所有人一起看。先讓測(cè)試團(tuán)隊(duì)做一輪冒煙測(cè)試也就是快速過一遍核心鏈路游戲能不能啟動(dòng)、主界面能不能進(jìn)去、新手引導(dǎo)能不能走完、核心玩法能不能跑通、商店能不能打開、支付能不能發(fā)起。冒煙測(cè)試的目標(biāo)不是找細(xì)節(jié)Bug而是判斷這個(gè)包“到底有沒有資格進(jìn)入正式驗(yàn)收”。冒煙測(cè)試但凡有一步過不去直接打回讓乙方修好再重新提測(cè)。這一步看著簡(jiǎn)單但能幫雙方省掉大量時(shí)間。我有一次驗(yàn)收乙方信誓旦旦說做完了結(jié)果安裝包在iOS 16真機(jī)上直接白屏連啟動(dòng)都過不去那還驗(yàn)收什么直接打回重做省得浪費(fèi)整個(gè)團(tuán)隊(duì)一下午。冒煙測(cè)試通過后就可以進(jìn)入正式驗(yàn)收流程。我在實(shí)際操作中會(huì)將冒煙測(cè)試的結(jié)果也記錄進(jìn)問題管理表作為正式驗(yàn)收第一階段的狀態(tài)方便后續(xù)追溯。3.2 第二步正式驗(yàn)收按清單逐項(xiàng)執(zhí)行正式驗(yàn)收階段我建議把功能測(cè)試放在第一步性能測(cè)試和兼容性測(cè)試可以并行或交叉進(jìn)行。因?yàn)楣δ軠y(cè)試發(fā)現(xiàn)問題往往需要乙方修改邏輯修改有可能影響性能和兼容性先測(cè)功能能減少后續(xù)測(cè)試輪次中的變數(shù)。功能驗(yàn)收的具體操作方式是拿著之前做好的驗(yàn)收清單從第一條開始逐項(xiàng)過。這里要強(qiáng)調(diào)一個(gè)詞“逐項(xiàng)”不是“大概看一下”。每一個(gè)功能都要在對(duì)應(yīng)設(shè)備上執(zhí)行對(duì)應(yīng)操作路徑并記錄結(jié)果。比如驗(yàn)收“背包系統(tǒng)”測(cè)試操作至少包括背包打開、關(guān)閉、滑動(dòng)道具分類篩選道具詳情查看道具使用及效果觸發(fā)道具批量使用背包滿狀態(tài)背包內(nèi)道具數(shù)量超上限時(shí)的提示所有操作過程中的內(nèi)存與幀率記錄我不能在這兒把每個(gè)系統(tǒng)的完整測(cè)試用例都寫出來但核心思路是功能驗(yàn)收必須細(xì)化到可以復(fù)現(xiàn)的具體操作路徑而不是停留在“這個(gè)功能能用”的主觀判斷。功能驗(yàn)收的同時(shí)并發(fā)測(cè)試的還有支付流程。游戲項(xiàng)目里支付環(huán)節(jié)是最敏感的部分測(cè)試重點(diǎn)有三塊正常支付流程是否順暢、支付取消/失敗是否不影響用戶數(shù)據(jù)、斷網(wǎng)情況下支付回調(diào)延遲或丟失時(shí)用戶資產(chǎn)是否正確發(fā)放。支付一旦出了問題輕則玩家刷單運(yùn)營(yíng)虧損重則被渠道處罰。3.3 第三步性能、兼容性和安全測(cè)試這部分在工作量上可能不亞于功能測(cè)試但很多人會(huì)忽略或壓縮它。我以前遇到過一位外包項(xiàng)目經(jīng)理他說“我們性能沒問題手機(jī)上都玩得挺流暢”結(jié)果拿低端機(jī)一測(cè)主界面60秒界面卡死直接就露餡了。性能測(cè)試的核心指標(biāo)和參考值可以這樣定指標(biāo)參考范圍測(cè)試方法冷啟動(dòng)時(shí)間中端安卓機(jī)不超過3秒從點(diǎn)擊圖標(biāo)到進(jìn)入主界面計(jì)時(shí)安裝包體積根據(jù)目標(biāo)市場(chǎng)一般小于200MB為宜直接查看安裝包文件大小運(yùn)行時(shí)內(nèi)存建議不超過設(shè)備物理內(nèi)存的40%使用Unity Profiler或Android Studio Profiler記錄峰值幀率核心玩法穩(wěn)定30fps推薦目標(biāo)60fps使用Profile工具記錄10分鐘中位數(shù)與P95溫度連續(xù)游戲30分鐘設(shè)備背面溫度不超過45°C體感溫?zé)釤岢上駜x或手機(jī)自帶溫度監(jiān)控電耗30分鐘游戲耗電小于10%滿電測(cè)試前后對(duì)比每個(gè)項(xiàng)目目標(biāo)不同數(shù)值要按實(shí)際情況調(diào)整。有些重度3D游戲包體大、內(nèi)存高是正常的有些輕度休閑游戲標(biāo)準(zhǔn)就必須苛刻。關(guān)鍵是標(biāo)準(zhǔn)要在驗(yàn)收前定下來而不是驗(yàn)收中臨時(shí)拍腦袋。兼容性測(cè)試方面建議結(jié)合遠(yuǎn)程真機(jī)云測(cè)平臺(tái)做覆蓋測(cè)試比如用Testin、百度云測(cè)或者各廠商云真機(jī)平臺(tái)把Top100的機(jī)型清單跑一遍安裝啟動(dòng)和核心玩法場(chǎng)景重點(diǎn)記錄啟動(dòng)失敗、崩潰、渲染異常等問題。安全測(cè)試更偏向于有后端接口的項(xiàng)目。需要驗(yàn)證接口有沒有做簽名校驗(yàn)、是否有重放攻擊風(fēng)險(xiǎn)、敏感數(shù)據(jù)是否明文傳輸、客戶端包體是否容易被篡改或二次打包。如果項(xiàng)目沒有后端單機(jī)邏輯也要關(guān)注存檔是否有被本地修改的風(fēng)險(xiǎn)。這部分如果不熟悉可以請(qǐng)懂安全的同事支持或者直接要求外包方提交安全自測(cè)報(bào)告再針對(duì)重點(diǎn)做抽樣復(fù)核。3.4 第四步bug分級(jí)、復(fù)測(cè)與驗(yàn)收結(jié)論驗(yàn)收過程中發(fā)現(xiàn)的所有問題我習(xí)慣按嚴(yán)重程度分成四個(gè)級(jí)別致命Blocker游戲無法啟動(dòng)、核心功能無法使用、閃退、數(shù)據(jù)丟失、支付錯(cuò)亂。存在任意一個(gè)驗(yàn)收不能通過。嚴(yán)重Critical主要功能無法正常使用、重大性能問題、高概率崩潰、兼容性問題覆蓋核心機(jī)型。存在多個(gè)時(shí)驗(yàn)收不能通過。一般Major非核心功能缺陷、界面顯示異常、特定機(jī)型性能問題、操作卡頓等。需要修復(fù)后再?gòu)?fù)測(cè)但不一定影響驗(yàn)收結(jié)論。輕微Minor文案錯(cuò)誤、極低概率的顯示問題、優(yōu)化建議類。可以記錄到后續(xù)維護(hù)清單不阻塞驗(yàn)收。每輪驗(yàn)收結(jié)束后把對(duì)應(yīng)級(jí)別的問題清單發(fā)給乙方約定修復(fù)時(shí)間。致命和嚴(yán)重問題需要修復(fù)后復(fù)測(cè)。一般問題如果不影響核心體驗(yàn)可以在雙方協(xié)商下安排到下一迭代修復(fù)但這需要明確記錄并作為扣款或后續(xù)維保的參考。復(fù)測(cè)不是簡(jiǎn)單地問“改好了嗎”而是要按原問題路徑重新執(zhí)行一遍操作確認(rèn)修復(fù)且沒有引入新的相關(guān)回歸問題。這一步必須有我方人員親手操作不能只相信乙方反饋。我說過很多次非我操作不算數(shù)。4. 不同游戲類型和場(chǎng)景的驗(yàn)收側(cè)重點(diǎn)4.1 微信小程序游戲開發(fā)的驗(yàn)收特別項(xiàng)這幾年微信小游戲外包需求增長(zhǎng)很快小程序游戲和原生App游戲在驗(yàn)收上有明顯的不同。小游戲包體限制2MB主包現(xiàn)在部分支持4MB加載方式、性能表現(xiàn)、運(yùn)行環(huán)境都和原生游戲差異很大。驗(yàn)收時(shí)除了常規(guī)內(nèi)容必須加測(cè)以下方面首包加載時(shí)間在普通4G網(wǎng)絡(luò)下從點(diǎn)擊進(jìn)入小游戲到出現(xiàn)可交互界面建議不超過5秒超過的話流失率會(huì)非常明顯。分包加載策略確認(rèn)分包邏輯是否正確當(dāng)玩家進(jìn)入某個(gè)玩法時(shí)才拉取對(duì)應(yīng)資源包而不是一啟動(dòng)就把全部分包加載了。微信API兼容性登錄、分享、支付、廣告組件都要逐一驗(yàn)證真實(shí)調(diào)用。尤其注意iOS和Android在微信內(nèi)的不同表現(xiàn)比如某些API在iOS端或Android端的支持程度會(huì)有差異。內(nèi)存與性能微信瀏覽器環(huán)境的內(nèi)存限制比原生系統(tǒng)更嚴(yán)格長(zhǎng)時(shí)運(yùn)行后頁面變卡是常見問題測(cè)試時(shí)特別留意連續(xù)游戲30分鐘以上的表現(xiàn)。緩存與更新小游戲版本更新時(shí)老玩家能否正確拉到最新版本不因緩存問題導(dǎo)致白屏或邏輯錯(cuò)亂。小游戲項(xiàng)目最坑的一點(diǎn)是很多外包方會(huì)用一套Unity或Cocos代碼打包成原生游戲后硬轉(zhuǎn)小游戲?qū)е掳w超標(biāo)、啟動(dòng)巨慢。驗(yàn)收時(shí)必須重點(diǎn)驗(yàn)證運(yùn)行環(huán)境是否真的是微信環(huán)境測(cè)試網(wǎng)絡(luò)面板和性能面板確認(rèn)沒有在小游戲環(huán)境內(nèi)嵌隱藏WebView運(yùn)行的情況。4.2 Godot項(xiàng)目的驗(yàn)收開源引擎要盯緊資源管理和導(dǎo)出配置Godot是目前技術(shù)圈討論熱度很高的開源引擎很多小團(tuán)隊(duì)和個(gè)人開發(fā)者入坑Godot做獨(dú)立游戲也催生了Godot相關(guān)的外包需求。Godot項(xiàng)目驗(yàn)收與Unity/Cocos項(xiàng)目有一個(gè)顯著差異引擎本身免費(fèi)且開源但項(xiàng)目工程質(zhì)量參差不齊極其嚴(yán)重。用Godot做外包項(xiàng)目驗(yàn)收有幾個(gè)特別要留意的地方資源導(dǎo)入規(guī)范Godot對(duì)紋理壓縮、音頻重采樣、字體格式有一定要求如果外包方處理粗糙最終包體可能異常膨脹。驗(yàn)收時(shí)要檢查導(dǎo)出報(bào)告里各類資源的占比判定是否有未壓縮的大尺寸資源被直接打包。場(chǎng)景與腳本組織Godot項(xiàng)目常常因?yàn)殚_發(fā)者水平差異把大量邏輯堆在場(chǎng)景節(jié)點(diǎn)的_Process里或者用全局單例亂搞。這種代碼風(fēng)格可能不影響功能實(shí)現(xiàn)但會(huì)給后續(xù)維護(hù)埋雷。如果合同里有“代碼可維護(hù)性”要求驗(yàn)收時(shí)就要抽查腳本組織是否合理。導(dǎo)出配置Godot在不同平臺(tái)導(dǎo)出的坑不少比如Android導(dǎo)出需要配置自定義構(gòu)建模板、iOS導(dǎo)出需要特定Xcode版本。驗(yàn)收時(shí)要確認(rèn)每個(gè)目標(biāo)平臺(tái)都有真實(shí)的導(dǎo)出包真機(jī)測(cè)試記錄而不只是在編輯器里跑通就行。版本鎖定Godot版本更新較快不同版本的導(dǎo)入格式和Shader兼容性都有差異驗(yàn)收時(shí)檢查引擎版本與項(xiàng)目配置版本是否統(tǒng)一鎖定避免后續(xù)版本更新導(dǎo)致項(xiàng)目無法打開或運(yùn)行異常。4.3 美術(shù)和UI外包驗(yàn)收的獨(dú)立標(biāo)準(zhǔn)游戲開發(fā)外包不只是程序外包美術(shù)外包是另一個(gè)大頭而且美術(shù)驗(yàn)收標(biāo)準(zhǔn)跟程序完全不同。程序可以看指標(biāo)、看日志、看崩潰率美術(shù)驗(yàn)收主要靠眼睛和規(guī)范。美術(shù)外包驗(yàn)收時(shí)我一般看三樣?xùn)|西與概念設(shè)計(jì)的風(fēng)格一致性不是看單張圖好不好看而是跟整體世界觀、UI風(fēng)格、參考圖放一起看協(xié)調(diào)度。很多美術(shù)外包單張出彩放進(jìn)游戲里跟UI、跟其他場(chǎng)景完全不搭。技術(shù)規(guī)范達(dá)標(biāo)比如角色模型面數(shù)是否在規(guī)定范圍、貼圖尺寸和通道是否合規(guī)、動(dòng)作資源是否有合理壓縮、UI切圖是否遵循九宮格規(guī)則、字重行距是否一致。這些不懂行的人看不見但直接決定運(yùn)行效率。實(shí)現(xiàn)表現(xiàn)動(dòng)畫是否流暢、特效是否遮擋操作、UI布局在異形屏上是否安全、多語言文本下是否會(huì)溢出。這些必須實(shí)際進(jìn)游戲跑一遍才能發(fā)現(xiàn)。美術(shù)外包驗(yàn)收最講究“參考對(duì)照”驗(yàn)收的時(shí)候最好打開需求文檔里的參考圖和動(dòng)效參考視頻逐幀對(duì)比別憑感覺說“還行就這樣吧”不然等美術(shù)外包走了你看著自己游戲里那套UI只會(huì)越想越難受。5. 驗(yàn)收過程的實(shí)戰(zhàn)技巧與常見爭(zhēng)議5.1 如何應(yīng)對(duì)“程序上的Bug不是功能性缺陷”的甩鍋驗(yàn)收過程中最常遇到的扯皮是乙方對(duì)問題定級(jí)有異議。比如你提“主城界面加載時(shí)出現(xiàn)半秒白屏”乙方說“這個(gè)不影響功能屬于優(yōu)化問題不列入驗(yàn)收Bug清單”。這時(shí)候不要爭(zhēng)論直接拿出之前確認(rèn)的驗(yàn)收標(biāo)準(zhǔn)指著“啟動(dòng)流程中不應(yīng)出現(xiàn)明顯白屏或黑屏”這一條告訴他這是合同標(biāo)準(zhǔn)不是我的個(gè)人意見。只要標(biāo)準(zhǔn)寫得明白扯皮的空間就很小。如果標(biāo)準(zhǔn)里確實(shí)沒寫那就事論事評(píng)估是否影響核心體驗(yàn)再商量是修、還是記入后續(xù)優(yōu)化清單同時(shí)調(diào)整尾款付款比例。項(xiàng)目驗(yàn)收不是玩零和游戲不是非要壓對(duì)方一頭核心原則是明確的問題明確修不明確的問題商量著處理。5.2 遠(yuǎn)程驗(yàn)收時(shí)怎么保證測(cè)試真實(shí)性有些外包方是異地團(tuán)隊(duì)項(xiàng)目方無法到現(xiàn)場(chǎng)驗(yàn)收遠(yuǎn)程驗(yàn)收就成了常態(tài)。遠(yuǎn)程驗(yàn)收比現(xiàn)場(chǎng)驗(yàn)收更容易出現(xiàn)“乙方一邊演示、一邊讓問題不出現(xiàn)”的情況。遠(yuǎn)程驗(yàn)收我的做法是要求乙方提供錄屏所有核心功能測(cè)試路徑要求乙方按清單預(yù)先錄制操作視頻而不是直播時(shí)臨時(shí)演示。遠(yuǎn)程控制或模擬器加真機(jī)一起測(cè)可以要求乙方開放遠(yuǎn)程真機(jī)控制權(quán)限或者使用云真機(jī)平臺(tái)保證你的測(cè)試操作是自己執(zhí)行的。關(guān)鍵問題孤證不立任何一個(gè)嚴(yán)重/致命問題必須由我方人員在云端真機(jī)、或者用我方指定的測(cè)試設(shè)備上復(fù)現(xiàn)。乙方那邊“我這兒好的呀”完全不能作為證據(jù)。我特別反感一句話“這個(gè)bug我們這邊復(fù)現(xiàn)不了?！痹隍?yàn)收語境里這句話的意義非常有限。正確的回答是“那你按我的操作步驟再試錄屏發(fā)我?！睆?fù)現(xiàn)不了要么是不想復(fù)現(xiàn)要么是環(huán)境確實(shí)不同但只要是真實(shí)用戶路徑中會(huì)發(fā)生的就需要被正視。5.3 驗(yàn)收與尾款支付什么時(shí)候付、付多少游戲外包項(xiàng)目通常的付款方式是里程碑付款也就是設(shè)計(jì)原型、首個(gè)可玩版本、內(nèi)容完善、最終交付等節(jié)點(diǎn)分期付款。終驗(yàn)通過后支付尾款比例一般是總額的10%到30%?？铐?xiàng)和驗(yàn)收的關(guān)系我建議這樣安排節(jié)點(diǎn)付款比例付款前提啟動(dòng)20%–30%雙方簽訂合同并確認(rèn)需求文檔里程碑一20%首個(gè)可玩版本交付核心循環(huán)可跑通里程碑二20%–30%內(nèi)容開發(fā)完畢版本功能完整終驗(yàn)10%–20%終驗(yàn)通過簽署驗(yàn)收?qǐng)?bào)告維保期滿5%–10%上線維保期結(jié)束后無重大問題終驗(yàn)通過后一般來說尾款要在一個(gè)明確的賬期內(nèi)比如15個(gè)工作日支付不要拖。拖尾款在行業(yè)里口碑影響極大而且容易導(dǎo)致對(duì)方后續(xù)維保不配合。反過來項(xiàng)目方也一定要堅(jiān)決執(zhí)行“不驗(yàn)收不付尾款”的原則哪怕對(duì)方說自己資金緊張也不行。驗(yàn)收是質(zhì)量證明尾款是契約履行兩者不沖突但必須掛鉤。5.4 知識(shí)產(chǎn)權(quán)與驗(yàn)收?qǐng)?bào)告一起簽署寫到最后必須提一嘴知產(chǎn)因?yàn)楹芏囗?xiàng)目方在驗(yàn)收時(shí)會(huì)忘掉這件事。游戲外包項(xiàng)目的核心知識(shí)產(chǎn)權(quán)代碼、美術(shù)、音頻、策劃文檔、技術(shù)方案的歸屬應(yīng)該在合同中有明確條款。大多數(shù)情況下費(fèi)用結(jié)清后知識(shí)產(chǎn)權(quán)應(yīng)全部歸項(xiàng)目方所有。驗(yàn)收?qǐng)?bào)告的簽字頁或附件里最好增加一頁“交付物清單及知識(shí)產(chǎn)權(quán)確認(rèn)書”乙方確認(rèn)以下事項(xiàng)所有交付的源碼、資源、文檔均為乙方原創(chuàng)或已獲得合法授權(quán)未侵占第三方知識(shí)產(chǎn)權(quán)項(xiàng)目方支付全部合同費(fèi)用后擁有完整知識(shí)產(chǎn)權(quán)乙方移交全部源工程和構(gòu)建工具鏈確保項(xiàng)目方可獨(dú)立編譯構(gòu)建新版本。這一頁簽完才算真正閉環(huán)。我有朋友因?yàn)槭×诉@一頁半年后想做個(gè)新功能發(fā)現(xiàn)乙方找不到人、代碼庫不完整、引擎版本被修改過無法構(gòu)建整個(gè)項(xiàng)目只能推倒重來。6. 驗(yàn)收單和問題清單模板的實(shí)操分享這部分是我最想拿出來的私貨直接用表格結(jié)構(gòu)和思路分享給大家。在實(shí)際項(xiàng)目中我通常把兩類文檔配合使用。6.1 驗(yàn)收確認(rèn)單的核心字段不管你用什么工具Execl也好、在線表格也好驗(yàn)收確認(rèn)單至少要有這些字段項(xiàng)目名稱與版本號(hào)驗(yàn)收階段初驗(yàn)/復(fù)驗(yàn)/終驗(yàn)驗(yàn)收日期與驗(yàn)收人驗(yàn)收依據(jù)文檔版本號(hào)需求文檔、設(shè)計(jì)文檔、測(cè)試用例清單版本功能完整度結(jié)論完整/部分缺失質(zhì)量指標(biāo)結(jié)論達(dá)標(biāo)/不達(dá)標(biāo)附測(cè)試數(shù)據(jù)嚴(yán)重/致命問題數(shù)量0為通過前提遺留問題清單及解決計(jì)劃結(jié)論通過/有條件通過/不通過雙方簽字6.2 問題管理表的實(shí)操細(xì)節(jié)問題管理表的字段上一條已經(jīng)提過我再補(bǔ)幾個(gè)實(shí)操細(xì)節(jié)編號(hào)規(guī)則建議按“階段縮寫-日期-序號(hào)”記錄復(fù)測(cè)時(shí)通過原編號(hào)作為前綴派生新編號(hào)比如“FINAL-0601-07”復(fù)測(cè)后變成“RETEST-0610-07”這樣整個(gè)問題生命周期一目了然。優(yōu)先級(jí)自動(dòng)排序所有致命和嚴(yán)重問題自動(dòng)置頂未關(guān)閉的問題數(shù)實(shí)時(shí)統(tǒng)計(jì)方便進(jìn)度追蹤。截圖與日志強(qiáng)制綁定每一個(gè)問題必須有截圖或日志不能只有文字描述。一個(gè)“游戲閃退”的條目任何程序員看到都無從下手但配上了logcat日志和時(shí)間點(diǎn)之后定位速度會(huì)提升十倍。6.3 驗(yàn)收?qǐng)?bào)告的存檔意義驗(yàn)收?qǐng)?bào)告簽完之后所有相關(guān)文檔——驗(yàn)收清單、問題管理表、測(cè)試日志、錄屏證據(jù)、正式驗(yàn)收?qǐng)?bào)告、知識(shí)產(chǎn)權(quán)確認(rèn)書——統(tǒng)一存入項(xiàng)目檔案。這些文檔不僅是為了存檔而存檔它們有幾個(gè)實(shí)際用途上線后如果出現(xiàn)問題可以快速定位是否已知遺留問題。維護(hù)期外包方如果扯皮這份記錄就是憑證。后續(xù)接手的團(tuán)隊(duì)可以通過驗(yàn)收?qǐng)?bào)告快速理解項(xiàng)目有哪些坑。7. 驗(yàn)收之后你還需要做這幾件事很多人覺得驗(yàn)收通過就萬事大吉了其實(shí)驗(yàn)收完成只代表“乙方該做的做完了”還遠(yuǎn)遠(yuǎn)不是項(xiàng)目的終點(diǎn)。驗(yàn)收通過后至少還有兩件事要做安排素材和源碼歸檔。拿到乙方交付的全套源工程后立即做一次構(gòu)建驗(yàn)證確認(rèn)在你自己的電腦或服務(wù)器上不依賴乙方環(huán)境也能編譯構(gòu)建成功。如果有CI/CD環(huán)境馬上把項(xiàng)目導(dǎo)入跑一遍自動(dòng)化打包流水線。如果構(gòu)建失敗立刻反饋給乙方此時(shí)尾款還在你手里解決一切問題都還來得及。做一次內(nèi)部體驗(yàn)評(píng)審。驗(yàn)收測(cè)試是通過標(biāo)準(zhǔn)的但標(biāo)準(zhǔn)不是萬能的。把項(xiàng)目發(fā)給團(tuán)隊(duì)里沒有參與開發(fā)過程的同事、朋友玩一玩你往往會(huì)收獲很多測(cè)試用例里寫不到的真實(shí)視角。但注意區(qū)分“體驗(yàn)意見”和“驗(yàn)收問題”體驗(yàn)意見可以整理成下一版本迭代建議不要拿來推翻驗(yàn)收結(jié)果。我個(gè)人的體會(huì)是游戲外包開發(fā)能不能做好很大程度不取決于外包團(tuán)隊(duì)的技術(shù)天花板而取決于項(xiàng)目方對(duì)驗(yàn)收的理解和執(zhí)行力度。驗(yàn)收嚴(yán)格外包方就會(huì)拿出更好的資源來對(duì)待你的項(xiàng)目驗(yàn)收松散對(duì)方就會(huì)認(rèn)為你“好糊弄”后續(xù)服務(wù)和維護(hù)質(zhì)量都可能打折扣。最后分享一個(gè)我常用的技巧驗(yàn)收過程中溝通全部用文字記錄重要結(jié)論發(fā)送雙方確認(rèn)郵件。不是不信任對(duì)方而是項(xiàng)目周期長(zhǎng)、人員可能流動(dòng)哪天對(duì)接人換了這些記錄就是項(xiàng)目管理的唯一錨點(diǎn)。你認(rèn)真對(duì)待驗(yàn)收流程其實(shí)也在幫助對(duì)方養(yǎng)成嚴(yán)謹(jǐn)?shù)慕桓读?xí)慣最終受益的還是項(xiàng)目的質(zhì)量本身。