本篇和 C/C++ 沒有絕對關係，但大多數遊戲都是用 C/C++ 寫的，所以多少
還是有點關係。（我承認，我是為了賺某 x 幣才這樣硬凹）。
由於被老闆唸，只好把之前的貼文都砍了，但這篇是以前寫的，應該沒事。
原文刊載在《RUN!PC》十月號和北京《程序員》九月號的雜誌（2004年）。
所寫的很淺，大家沒事瞄瞄就好，與其說是拋鏄引玉，毋寧說是對自己接觸
與經歷的一些心得紀錄。因為寫這篇文章時，我已經不再寫 Game 了。
和很多事情一樣，做遊戲最重要是熱忱和態度，技術還是其次。但這不表示
技術不重要；技術絕對重要，只不過太重視技術，通常是會做不好遊戲的。
在台灣這樣的環境，RD 是很可憐的，做 Game 尤然。個人是不建議大家走這
條路，不過有個好處就是：透過做 Game 來學習 Programming，不失為一種
具體而有效的方式。
---------------------------------------------------------------------
淺談遊戲產業與遊戲編程技術
◎了解遊戲產業
對一個有心踏入這個領域的新鮮人而言，首先要了解的是，遊戲產業的
生態。很多人以為遊戲開發就是寫寫程式，畫畫美術，再組合起來就行
了。當然這樣想也不能說錯，不過以目前的情形而言，遊戲市場的生態
大異於已往，經濟規模大幅成長（主要原因是單機版轉為網路遊戲），
遊戲產業走向垂直分工，經營成本與研發成本的比例逐漸拉開，遊戲產
業在台灣，基本上已屬服務業，而非科技產業。例如台灣幾家大的遊戲
公司多是以代理、行銷和經營為主體，研發投資的比例有限，技術方面
更是遠落後於日、韓、歐美的先進廠商。
關於技術落後的問題，主要的原因是台灣的大環境並不適合遊戲研發。
細分述如下：
一、先天不足：單機遊戲盜版嚴重，網路遊戲的技術尚未成熟，廠商靠
自製單機遊戲，已無生存的空間，紛紛轉型走向代理，對自行開發頗多
顧慮，興趣缺缺，研發單位多成陪襯點綴。在此惡性循環下，遊戲開發
的整體水平，自與先進國家的差距愈拉愈大。
二、政策無力：雖然近幾年政府不斷鼓勵「數位內容」產業的發展，然
其相關配套措施，只重產業與產值的表象，並未埋下技術紮根的種子，
故在實際上成效不大。台灣不乏技術方面的高手，但為生計及前景考量
，多未進入遊戲產業。
三、技術團隊融合不易：軟體研發，首重團隊合作；遊戲產品的開發，
需企劃、美術、編程人員合作無間。且有好的產品，尚需通過行銷、經
營體系，方能打入市場。然而偶有人才踏入業界，往往流於單打獨鬥，
多頭馬車散行，難以成長為高質量的團隊。
許多來自業界內外的觀點指出台灣所缺乏的是能夠「結合文化與技術」
的人才。這個結論是對的，但忽略了真正的原因。其實說穿了也很簡單
，台灣最好的人才都去當醫生、律師，跑去台積電、聯電，就算當公務
員、教師、警察，甚至普通的業務員、作業員，也比遊戲這行安穩得多
。（寫程式不如賣雞排，這在台灣已經是「不是笑話」的笑話了）
自網路遊戲的風氣興起，因其經濟規模龐大，不論代理或自行研發，都
屬於高風險的投資，一般的小公司只要失敗，在資金耗盡以前無法達成
損益平衡，就很難有第二次機會；且小公司受限於資金，無法吸引好的
人才進入。因此，所謂「國內缺乏ＸＸＸ方面的人才」，並不是真的沒
有人才，而是沒有培養人才的環境；而之所以沒有培養人才的環境，則
是由於沒有適當的政策。
代理網路遊戲，雖然在台灣創造了頗高的產值，但成長已趨於減緩乃至
停滯，畢竟台灣本身的市場有限，需求已達飽和（目前國內外遊戲公司
的戰場，已經轉至大陸）。且一個以代理為主的產業，若有商機，自會
吸引競爭者廣舖通路，並無太困難的進入障礙可言。如果台灣遊戲產業
的眼光始終定位在服務業，僅憑語言、文化的優勢競爭，卻並未真正掌
握產品的關鍵技術，這種優勢能夠維持多久，殊為可慮。
顯然，提升研發技術，才是遊戲產業永續經營的根本之道。政府若有心
推動，最直接的方式是補助小公司，降低研發的風險，吸引更多更好的
人才專心投入，同時在軟硬體方面給予適當的支援。綜觀韓國成功的經
驗，他們開發網路遊戲的技術為什麼能迅速提升？因為韓國的政策就是
如此，優惠的補助，甚至還可以折抵兵役。此經驗可作為台灣的借鑒。
在一個規模較小的遊戲公司，或一般的軟體（商業應用）公司，編程技
術可能是非常重要的，薪水相對也較高。但在規模比較大的遊戲公司，
技術人員的重要性（以及待遇）相對的就可能不如管理、行銷人員。同
時，在規模較大的公司，不論程式、美術、企劃都算是「技術人員」。
這意謂，從老闆──經營者的眼光來看，他所需掌握的只是技術的
Leader，他所關心的只是技術部門什麼時間可以做出什麼產品，底下的
人不論編程、企劃或美術都「只不過是」技術人員，重要性在某些時候
可能還不如客服人員。
國外很多大的遊戲開發公司，最重要的智慧資產是遊戲的企劃，而不是
程式。一個遊戲的成功與否，就開發面，主要取決於它的PM，企劃、美
術風格的設定，而通常不是編程技術（但也需要相當的水準）。此外，
非研發面的因素，如經營、行銷、宣傳，切入的時機，甚至運氣，這些
總合因素的影響力甚至超過產品本身的好壞。
總之，即使是一個非常好的遊戲，在多元化的激烈競爭下，也不見得會
成功大賣；爛遊戲就甭說了，只有等死的份。因此，在台灣，遊戲廠商
（老闆）對投資研發的興趣不高，態度趨於極端的保守。如果真的有心
投入這個行業，那麼可能要有相當的熱情，才有支撐下去的動力；否則
，倒不如選擇其他路線，嘗試去找另一片天空。
◎遊戲所需的編程技術背景
先前提到，台灣的遊戲開發技術，落後於歐美日韓。但台灣在遊戲內容
方面，尚具有一定的文化優勢；單機遊戲在華文地區，也有一定的市場
。某些專業評論指出，未來單機遊戲和網路遊戲，仍會呈現平分天下的
趨勢。例如在日本，單機遊戲，特別是TV Game仍然非常受歡迎（筆者
個人也比較喜歡日式細膩風格的遊戲），當然日本在最近幾年，也已經
大力投入到網路遊戲這一塊。手機遊戲現在也是熱門項目，但其系統性
能尚不足以支援一般遊戲的規模及互動性的需求，市場亦有待開發。
可以想見遊戲平台未來的概略走向：在PC上，網路遊戲會逐漸吞食單機
遊戲的市場，將後者擠壓至TV遊戲機台。TV Game當然也會朝網路遊戲
發展，但短期內還是小規模的連線型態，單機遊戲仍佔大多數。手持式
平台，特別是手機，則受限於系統性能，其商機的空間必須建立在提高
互動性的前提下，並朝與生活實務結合（例如個人化服務、虛擬貨幣、
金流…等）的方向。
接下來談談編程技術。其實，不管是否從事遊戲開發，一般軟體設計所
需要的技術都離不開以下四個領域：
一、核心編程
二、多媒體
三、網際網路
四、資料庫系統
當然這四大領域無論任何一個，都非常複雜，幾天幾夜也講不完。但在
遊戲開發上，並不需要了解每一部份的所有細節，就筆者個人的經驗所
及，概述如下：
一、核心編程的部分：
首先，基本的資料結構、演算法，資料流、執行緒、物件導向設計概念
，常用的模式…等等，不論在軟體界的哪一個角落，這些都是基本功，
毋須贅言。但遊戲的型態、內容和進行方式變化無窮，遊戲開發實在是
一個沒有範圍的課題，技術的進步革新從未停止；甚至可以說，沒有什
麼軟體技術，是和遊戲完全無關的。其挑戰性自是不言而喻。
遊戲軟體本質上是一個即時軟體。玩家透過軟體，與機器或其他玩家互
動。它需要華麗的聲光效果、流暢的用戶輸入、操作機制、網路資源…
…等，這些項目的實作，都是與硬體高度相依的。因此，在底層技術的
開發上，熟悉作業系統和開發環境比編程語言更重要。
由於目前Windows作業系統是主流，PC遊戲的前端介面幾乎一定運行在
Windows系統，後端（如果需要）則並無限制。編程語言方面，遊戲界最
常用的是C++。若考慮到非PC平台（以及可能跨平台）的需求，其他語言
／開發工具也有使用。不過，在記憶體受限系統（TV遊戲機或手持系統）
上運行時，其慣用手法／設計模式與PC平台大不相同，這也是遊戲與一
般軟體開發的主要差異處。
某些基礎層次的技術，例如：遊戲AI常用的決策樹、有限狀態機、路徑
搜尋…等演算法，2D遊戲使用的平面貼圖、矩陣、圖塊表、斜向視角、
置換頁捲軸、調色盤、點畫、混色…等種種技術或特效，由於並不特別
困難，且非常直覺；因而往往造成編程人員的錯覺，認為很容易就可以
徹底掌握遊戲所有的底層技術。
靠這一套思維方式，在早期單機平面遊戲的時代，尚無困難。但網路進
來了、3D流行了，遊戲軟體的規模，再不是一個人可以應付的；過於執
著「單騎馳騁天下」的觀念，反是造成產品和技術的停滯不前的主因。
對開發人員而言，並不需要完全通曉所有技術底層的來龍去脈；反而，
了解遊戲軟體的基本架構，何種狀況何種需求下，應該使用哪些慣用技
術，以及如何使用該技術，比技術的本身如何研發更為關鍵。
此外，在目前，寫出所謂「最快」的程式，已經不具有任何意義，嘗試
在有限的時間內，完成「效能足以接受」的專案，才是重要的。
遊戲軟體開發的方式，有經驗者通常會設計專屬的工具，例如：場景、
劇本、角色、道具編輯器…等，再根據每個專案的特色，例如：戰鬥系
統、階級系統、關卡系統、資財管理系統…等，做細部的修改、擴充、
調整。（在網路遊戲中，重要的運算工作，則會轉移到伺服端處理。）
有時，為了彈性和靈活性，遊戲內容的部份運算規則，不會直接寫在程
式碼內，而是獨立出來，以Scripting的方式控管。
將遊戲開發工具化，有兩個主要的好處：首先是便於編程人員、企劃人
員、美術人員的分工和整合；此外，亦很重要的是，這種方式有助於量
產。也因為如此，在遊戲界，主要的智慧資產通常不是編程人員，而是
企劃人員。好的遊戲不僅是聲光效果出色，其內容的豐富性、創意、整
體的平衡度都必須達到一定的水平。
遊戲軟體的設計，基本上相當符合物件導向／模組化的精神；它將幾個
主要的工具組合起來，每個專案、版本的更新調整，實際上拆解成每個
工具各自的修正。因此，開發遊戲軟體最大的挑戰，不在於某一方面的
技術，而在於「如何用技術表達遊戲性的概念」，也就是如何將一個遊
戲專案拆解成獨立的工具，再巧妙結合起來。
遊戲開發的工作，創意、技術與經驗三者並重，絕無捷徑可行（如同小
說創作，才情、學養、人生歷練，缺一不可）。當技術層面不是特別困
難時，知道怎麼規劃工具的價值，通常比實作更高；而只是作工具的局
部修改的價值，當然就更次之了。這也呼應前面提到企劃人員的重要性
，事實上，許多優秀的企劃人員，都是優秀的編程人員出身的。
二、多媒體的部份：
既然是遊戲軟體，前端的影音效果、操作界面，2D, 3D成像技術，這些
都是不可或缺的，甚至可以說這是遊戲軟體技術中最重要的一部份。底
層技術方面，目前3D的框架主流是DirectX和OpenGL，前者是在Windows
上運行，後者是可跨平臺的。
3D技術不僅應用在遊戲界，它同時也是許多尖端工業、商業科技的關鍵
技術。其基本原理，是將要顯示的畫面，以三角形頂點編碼成資料流，
透過3D管線作業，決定可視區域、解析度等級、幾何轉換及光源處理（
Trasnform & Lighting; T&L）、材質、混色…的過程，最終成為顯示
的象素。
在現今的3D加速卡上，許多工作是由硬體來處理的；為了強化細部控制
的彈性，近年來發展出一種可編程化的技術，也就是「著色語言」（
Shading Language）。另一方面，基於遊戲型態和內容的變化，亦發展
出各種適用於封閉或開闊的場景、建築，角色單元、粒子系統、有機體
的繪製、動畫…等特殊的演算法和優化技術。此外，3D貼圖、陰影、特
效，攝影技術…等，莫不牽涉複雜的數學運算。
3D遊戲的開發技術在國內還沒有成熟。如果有心自行研發前端的遊戲開
發工具甚至遊戲引擎，當然必須具備3D框架、製作流程的觀念，以及相
關的數學背景知識。不過，實際上遊戲公司通常並不自行開發3D引擎，
而是購買遊戲引擎來開發遊戲。
用做餅來比喻，做遊戲引擎廠商的角色就像是把麥子磨成麵粉的工廠，
而遊戲公司則是廚房，它負責的是烹飪、調味的工作，其重點是擺在如
何做出好吃的餅，而不會太計較麥子怎麼磨成麵粉，更不用拼命去鑽研
磨麵粉的技術，只要麵粉夠香，可以用就行。
以上並不是表示遊戲公司所需的編程技術不高。相較於絕大多數的商業
應用軟體而言，遊戲所需的軟體技術是最廣泛最複雜的，光是要能夠使
用遊戲引擎開發出完整的遊戲，就不是很容易的了。此處強調的重點是
「術業有專攻」，遊戲公司本身不可能去研發所有必須的軟體技術，因
此對遊戲製作人員而言，不論是否自行研發，「知道怎麼運用現行技術
做遊戲」比「知道怎麼開發底層技術」更重要。
同樣用做餅的例子來說，當然，懂得磨麵粉，甚至很會磨，這很好，絕
對有幫助！但是，遊戲開發的技術關鍵在於「怎麼做出好吃的餅」，而
非「怎麼磨出好的麵粉」。
三、網際網路的部份：
這當然也是很複雜的一項，但僅就遊戲軟體而言，算是比較單純的。網
路遊戲的開發當然不用去實作底層的TCP/IP，而是直接使用具有Network
功能的函式／類別庫即可。根據遊戲型態的特性，當流暢性的需要較高
，而安全性的顧慮相對下降時（例如動作類、射擊類、小規模的即時戰
略遊戲…等），有時也會應用到UDP。
許多遊戲引擎都內建網路功能，然而，工具一旦設計成為「引擎」，它
的應用就受到限制，只能照著規格去設計，但未必符合需要。同時，網
路遊戲也可能和其他網路應用服務結合，例如：整合其他的遊戲、平台
、與電子商務結合…等，因此這部份不能完全依賴特定的引擎。
網路遊戲Server/Client的基本運作方式是：運算由伺服端處理，用戶
端發出訊息要求，接到伺服端回應（或收到其主動通知）後，作介面顯
示的更新。為了處理網路傳輸的延遲，在顯示上會利用種種平滑、預測
的計算，求得較順暢的表現；更常見的做法則是把不重要的資料和運算
，直接在前端處理，但這種設計可能會導致不公正的結果。因此，如何
在流暢性和安全／公平性之間取得平衡，也是在規劃時的一個不容輕忽
的重點。
多人連線網路遊戲目前的瓶頸在網路I/O的部份，因為網路遊戲的連線
型態，和許多其他網路應用服務，例如：FTP, Web Applications…等不
同，它的特性是高連線數（動輒數千上萬）、高頻率、低流量。但I/O處
理的部份，屬於作業系統層級，因此網路實作的部份，往往和作業系統
綁在一起，造成開發和移植的困難。
例如：在Windows平台上最適合開發網路遊戲的I/O模型是I/O Completion
Port模型，在POSIX上，則是Asynchronous I/O模型；但目前在各平台上
廣泛使用的Socket API，並不直接支援對應的模型。當然，解決的方式有
很多種，包括自行研發底層技術在內。（例如：筆者選擇的是使用ACE框
架，它是一個成熟的跨平臺的IPC框架，因而省去了許多麻煩。）
網路遊戲本質上是一個分散式系統，這不僅僅針對伺服端／客戶端而言
。為了要容納更多的玩家同時上線，在大規模的網路遊戲中，伺服端不
可能靠單一機器運作，採用多階（MultiTier）伺服器架構是必然的，因
此在比較複雜的系統中，也可能必須解決伺服器群組內的行程間同步問
題。
此外，Web Application的技術（ASP, PHP, Java 或 .NET…的任何一種
皆可），和遊戲平台作整合，也是需要用到的。Web技術的某些特性和一
般AP正好相反，它是屬於高流量的應用服務；另外它還有一個重要的特色
，就是：（大部份情況下）不需要安裝。這些特點集合在一起，使Web很
適合用來作為會員管理、電子商務…等，即時性、互動性需求較低，但前
端介面則常常需要調整改變的服務功能。
四、資料庫系統的部份：
和網際網路的部份相似，大部份的遊戲所需應用到的資料庫系統的功能比
較單純，因此有部份遊戲，甚至是自行開發資料庫系統；雖然從軟體工程
的觀點來看，完全無此必要。目前使用最廣泛的還是關聯式資料庫系統（
RDBMS），如：Oracle, MS-SQL, MySQL…等都是。
資料庫系統存取的性能，在某些遊戲上也成為後端效能的瓶頸；這也是某
些遊戲專案使用自行開發的資料庫的原因。之所以如此，是因為資料庫系
統並非專門為遊戲所設計，所以它的普通I/O方式比較不適合遊戲的需求，
其每秒鐘的查詢操作／交易次數遠低於網路I/O動作的次數。
不過，這個問題可以很容易透過軟體的技術解決，例如：使用Thread Pool
或非同步的I/O模型存取資料庫，或者採用MultiTier的伺服器架構，使用
伺服器叢集…等。另外，當In-Memory Database的技術成熟之後，也可以
降低此部份的開發難度。（32位元機器的記憶體定址只到4GB，因此這個技
術的普及應會在64位元的機器上）
雖然使用自行開發的遊戲專屬的資料庫（儲存）系統並不特別困難，但通常
它在安全性的考量上，遠不及正式的資料庫系統周密，在維護和擴充，以及
和其他（正式）資料庫系統的結合方面，也較為薄弱。因此，比較理想的
作法還是應該使用正式的資料庫系統，再配合軟體技術解決效能的問題。
遊戲程式員並不需要完全了解資料庫系統的每一部份，只要知道如何與資
料庫建立連線、基本操作、資料表設計、索引建立、正規化、SQL語言、
交易或預儲程序…等（以目前的 RDBMS 而言），遊戲所需的相關部份就
足夠了。總之，開發遊戲最重要的，是「運用適當的工具」。
另，關於軟體技術的使用，不管是遊戲或非遊戲軟體，「最新的技術」有
時並不一定是最有用的技術，且根據經驗，大多數遊戲軟體偏好使用的是
「成熟的技術」而非「尖端的技術」。但對新的技術和觀念，還是應該抱
持積極接觸、思考的態度，不一定要學會它，但至少了解新的技術和觀念
，適合用來做什麼，可以怎樣運用。
畢竟，身為技術的專業人員，時常站在前線，保持和外界資訊的接觸、互
動與交流，思考技術的本質和應用，是很重要的。唯有透視本質，才能創
新！
◎技術以外
不論你是否相信。當你在這個產業愈久，觀察的愈多，你會發現，在遊戲
界，編程技術以外的「能力」，有時甚至比「技術」本身更重要！（其實
絕大多數的工作本就如此，在遊戲界也不例外）
最重要的一點，筆者認為，是團隊工作的配合度和能力。一個人，不論再
厲害，是做不了多少事的，每個人都有自己專長的地方，截長補短，團隊
合作，所有人擁有共同的目標，而不是各自為政，才是成功的關鍵。（所
以，一個好的Leader，也要能善盡管理、溝通、協調者的職責，扮演好掌
舵的身份角色）
不要抱持「技術本位」的觀念，不論是程式、企劃、或美術人員，都應該
要常常和其他人溝通，在做以前，先確定自己做出來的東西能用，有用。
有的時候，往往行銷、宣傳人員，甚至一個普通的GM，他們的意見也很有
用。沒錯，他們可能不懂技術，不知道程式怎麼寫，不知道美術怎麼畫，
不知道企劃的構想是什麼；但他們卻是最貼近市場，最貼近「玩家」，也
是最容易從「玩家」的立場去思考、發現問題的人。
遊戲開發的工作，就像廚師，最終的目的是做出好吃的菜色（不是種菜也
不是磨麵粉），不是說技術不重要，它是根本。但不應把目光侷限在技術
上。一個遊戲成功的因素很多，少了任何一點（包括運氣），就有可能會
失敗。技術可以讓編程人員加分，但不要因為技術的加分，反而在其他方
面產生扣分的負作用。多觀摩成功者／產品的經驗，學習其中的思維觀點
、設計規劃的理念、眼界和格局，將技術實踐為有價值、創新的產品，才
是成功之道。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.120.214.120
※ 編輯: cppOrz 來自: 59.120.214.120 (09/23 20:58)