第一次想委託遊戲開發的業主，在評估的時候都會有一個很自然的想法：找一個工程師負責程式、找一個美術負責視覺、再找一個企劃把需求整理好，三個人分工合作，遊戲不就做出來了？
在工程邏輯上看起來沒有問題。但我們在接案這麼多年裡，太多用這個方式開始，但在執行專案的途中遇到非常多問題，讓專案卡了非常久，以至於最後只好放棄專案。
每個人都在做自己的事，但遊戲還是出不來
遊戲開發跟一般的軟體專案不太一樣。程式、美術、企劃這三個方向，在開發過程中需要不斷的互相對齊，美術的視覺風格要符合程式的技術限制，企劃的玩法邏輯要讓程式能夠實現，程式做出來的東西要讓美術的設計意圖能夠被保留。這些聽起來只是溝通的問題，但就我們遊戲貴族的實作經驗遠不止於此。
舉例來說：美術做到第三個角色，才發現跟第一個角色的風格定調對不上，要回去重改。當程式開發到一半，才發現企劃書裡有個邏輯漏洞，雙方對同一個機制的理解完全不同，要重新討論。在這時候會出現一個問題，由於業主第一次執行遊戲開發，少了很多專業的knowhow、知識、技術，使得每一次的來回溝通，都會變成時間和成本的消耗。
這種情況，我們遊戲貴族見過不少。有些最後來找我們接手的，有些是已經無法續接了。
擁有專業knowhow的人，往往是最容易被略過的
在遊戲開發的估價裡，業主通常很容易理解為什麼工程師要花錢、為什麼美術要花錢。這些工作有具體的產出——程式碼、圖檔、動畫——看得到、摸得著。
在規模小的團隊中，其實統籌是很重要的一個角色，通常由企劃兼任。編制大一點的，會有專職的製作人或總監來負責。不管叫什麼，這個角色在做的事情是一樣的——確保程式、美術、企劃三個方向在推進的過程中不會各自跑偏，在出現衝突的時候有人能夠做出判斷，在需要取捨的時候有人知道什麼是真正的優先順序。
這個knowhow，是遊戲開發裡最難被量化、也最容易在第一次委託的時候被忽略的部分。
連內行的專業軟體公司有可能都會低估遊戲製作這件事
如果這個問題只出現在第一次做遊戲的業主身上，那還比較好解釋。
但我們觀察下來，這件事跟產業背景、技術能力、或者有沒有做過軟體，關係都不大。
遊戲貴族有遇過自己有技術團隊的企業，內部有工程師、有產品經理，平常也在做軟體開發，但在評估遊戲專案的時候，同樣會低估整合這件事的複雜度。不是因為他們不懂開發，而是遊戲開發的整合跟一般軟體專案的整合，在很多地方是不一樣的思維邏輯，在玩家體驗、心流設計、美術與程式之間的相互依賴，這些在其他類型的專案裡不一定會遇到。
所以沒有辦法說，某個產業的人特別容易踩這個坑。但這是一個很普遍的現象，而且通常都是在專案出了問題之後，才會回頭意識到當初少了什麼。
散裝團隊為什麼很難走完全程
找散裝團隊的初衷通常是想省錢，就像室內設計你想找統包一樣，這完全可以理解。個別找來的工程師、美術、企劃，每個人的單價可能都比整合廠商便宜。
問題所在是：沒有人負責整合，每個人只能顧好自己的那一塊。
程式在等企劃確認規格，企劃在等美術確認視覺方向，美術在等程式確認技術限制。這個循環可以繞很多圈，而每繞一圈，時程就往後推一點、成本就多出一點，也不可能請這些散裝人員各自討論，在呈報給業主端他們討論的結果，有了結論卻沒有實作經驗的驗證下，到頭來業主只能點頭又或者詢問AI是否可行，但在這塊上AI他能讀懂的是，整體架構邏輯上可不可行，但在最後卻沒有實際專業人員來做評估，這樣的走向是否可以真正的落地執行，這是一件非常重要的事情。
最後的結果，有時候為了省錢，卻花了更多時間和金錢，還沒有做出想要的東西，對於專案進程而言是非常頭痛的事情。
交給有整合能力的團隊，實際上會有什麼不同
說了這麼多風險，也該說清楚另一面。
當整合這件事有人真正負責，開發的過程會是另一種樣子。
需求在開案前就被逐一確認，程式、美術、企劃對同一件事的理解是一致的，不會開發到一半才發現各自的認知不同。遇到技術限制或預算壓力，有人能夠在第一時間做出判斷，哪個功能可以簡化、哪個環節不能省、怎麼在現有條件下做出最接近目標的結果。
上線前的QA不是走過場，是真的有人盯著不同裝置、不同網路環境、不同使用情境，把問題在玩家看到之前解決掉。
最後交出來的東西，不只是「功能都有」，而是玩起來有節奏、有回饋感、讓人想繼續，這個差距，就是心流設計有沒有被認真對待的差距。
我們接過的案子裡，有客戶在遊戲上線後收到玩家主動回饋說「這個遊戲比我預期的有趣」。這句話聽起來很普通，但在行銷遊戲裡，能讓人說出這句話，代表整個體驗設計是成立的。
付高一點的費用，買的不只是技術執行，是有人從頭到尾對這個專案負責，包括那些你不知道需要有人處理的事。
FAQ
Q1：整合能力具體指的是什麼？
簡單來說，就是讓程式、美術、企劃三個方向在同一個專案裡能夠對齊的能力。這包括在開發前把需求釐清到每個方向都理解一致、在開發中有人能夠判斷衝突怎麼解決、在測試階段有人能夠判斷問題出在哪個環節。這個能力很難從履歷上看出來，通常只有做過足夠多案子的人才會有。
Q2：散裝團隊和整合廠商，怎麼判斷哪個適合自己？
這個問題沒有絕對的答案，要看專案的規模和複雜度。如果你要做的是一個功能單純、規格明確的小型遊戲，散裝團隊有機會做得起來。但如果專案涉及多個系統、多個開發方向需要同時推進，整合能力就會變得很關鍵。在決定之前，可以先評估看看：如果中途出問題，你自己有沒有能力判斷問題出在哪裡。
Q3：怎麼確認一個廠商有沒有真正的整合能力？
可以在提案階段問他們：過去有沒有遇過程式和美術方向衝突的情況，當時是怎麼處理的？有實際經驗的團隊通常能說出具體的狀況和判斷過程。說不出來的，不一定代表他們沒遇過，但值得多確認。
Q4：第一次委託遊戲開發，最容易在哪個階段出問題？
根據我們的經驗，最常出問題的是在開發中期——需求已經確認、開發已經開始，但還沒到可以測試的階段。這個時候如果發現方向有偏差，要調整的成本已經比開案前高很多，但很多問題又還沒有明顯到讓人意識到需要停下來討論。這個階段需要有人持續在把關，不能等問題變大了才處理。
Q5：預算有限的情況下，整合這件事可以省嗎？
這個問題我們通常會反過來問：如果開發到一半出了問題，重新來過的成本你能接受嗎？整合的費用省掉了，但整合的工作還是要有人做。如果沒有專職的人負責，通常會落到業主自己身上——花時間在不同的執行方之間來回確認、協調、做決定。這個時間成本，往往比當初省下來的費用還高。