（圖片來源：maniacworld.com）

亂數 (Randomness)，是每一位程式設計者們熟悉又親切的好朋友，無論我們開發製作的是哪一種類型的遊戲，亂數機制總是在遊戲設計程序與撰寫程式碼的過程中，扮演著不可或缺的重要角色。亂數最重要的用途，就是提供遊戲世界中必要的「不確定性」，只要能夠將這份「不確定性」的設計機制運用得宜，就可以為玩家們帶來許多驚喜感與樂趣元素。

然而，有許多時候，亂數的產生並不只是使用 rand() 函式般單純容易而已。在某些遊戲機制裡，無邊無際的亂數數值，並不能滿足程式設計者或企畫設計者所想達到的目標——我們需要的是「亂中有序」——能夠在某個限定範圍之內產生亂數。

何謂「亂中有序」？撲克牌遊戲就是一個最好的實例。撲克牌由 4 種花色與 13 種數字，組合成 52 張「牌組」。而「洗牌」(Shuffle) 動作可以定義為：在一組有限的集合元素內，進行亂數排列的程序。只要將牌組洗完之後，就可以按照牌堆的排列順序，開始一張張地進行「發牌」動作了。

對於程式設計者來說，不論是使用哪一種程式語言，要實作出洗牌與發牌的功能都不是件太困難的事情。假設，我們可以使用 Lua 語言來實作洗牌發牌機，是否能夠創造出什麼樣有趣的變化？

由於 Lua 是一種無須宣告變數資料型別的程式腳本語言，所以在 Lua 中我們可以非常便利地對任意數量、任意類型的「資料集合」進行洗牌的動作。下列的 Lua 函式 RandShuffle()，接受一個 table 型別的參數做為洗牌用的「牌組」：

function RandShuffle(deck)
    -- 首先確認傳入的參數型態是 table
	assert(type(deck) == "table");

    -- 將 deck 的所有元素複製至暫用的 clone 中
	local clone = {};
	for k, v in pairs(deck) do
		clone[k] = v;
	end

	-- 取得元素集合的大小
	local range = table.maxn(deck);

	-- 巡訪 deck 結構
	for k, v in pairs(deck) do
    	-- 藉由亂數機制，決定要取出的 clone 索引值
		local index = math.random(1, range);

	    -- 在 clone 中移除該元素，塞回原來的 deck 中
		deck[k] = table.remove(clone, index);

		-- 將亂數取值的範圍減1
		range = range - 1;
	end
end

無論 deck 結構中的資料，是數字型別、字串型別或甚至另一個 table 結構，只要經過 RandShuffle() 程序的操作，就可以得到一副經過亂數排列，也就是洗牌後的 deck 牌組：

-- 數字型別的牌組
NumberDeck = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
-- 洗牌
RandShuffle(NumberDeck);

-- 字串型別的牌組
StringDeck = { "Apple", "Banana", "Cherry", "Lemon", "Orange" };
-- 照樣洗牌
RandShuffle(StringDeck);

-- table結構的牌組
ComplexDeck =
{
	{ 1, Monday, "Apple" },
	{ 2, Tuesday, "Banana" },
	{ 3, Wednesday, "Cherry" },
	{ 4, Thursday, "Lemon" },
	{ 5, Friday, "Orange" },
};
-- 洗！洗！洗！
RandShuffle(ComplexDeck);

但是到目前為止，我們只是得到了一副洗過牌的牌組，接下來該如何進行「發牌」動作呢？

站在使用者的立場思考，我們會希望發牌功能可以一次發出一張牌，並且在整副牌組全部使用過後，自動重新進行洗牌。所以，在此需要另一個輔助函式 OutputCard() 來完成發牌程序：

-- 發牌計數器
g_Counter = 0;

function OutputCard(deck)
    -- 紀錄目前的發牌數
	g_Counter = g_Counter + 1;

    -- 如果發牌數大於總牌數
	if (g_Counter > table.maxn(deck)) then
		-- 重新洗牌
		RandShuffle(deck);
		-- 重設發牌計數器
		g_Counter = 1;
	end

	-- 回傳一張牌
	return g_Deck[g_Counter];
end

實作出「洗牌機」RandShuffle() 與「發牌機」OutputCard() 後，就可以很便利地使用：

-- 牌組
MyDeck = { ... };

-- 先將 g_Deck 洗牌
RandShuffle(MyDeck);

-- 發牌
MyCards = {};
-- 第1張牌
MyCards[1] = OutputCard(MyDeck);
-- 第2張牌
MyCards[2] = OutputCard(MyDeck);
-- 第3張牌
MyCards[3] = OutputCard(MyDeck);
-- 第4張牌
MyCards[4] = OutputCard(MyDeck);
-- 第5張牌
MyCards[5] = OutputCard(MyDeck);

但光是這樣還不夠完善。假設我們需要一次操作兩副以上相同的牌組怎麼辦？有沒有其他方法，可以不使用全域變數 g_Counter 做為發牌的計數器？在 Lua 缺少物件導向設計機制特性的情形下，能不能將「洗牌機」與「發牌機」合而為一，讓使用者得以更直覺地操作洗牌與發牌程序？

答案就是 Lua Closures。利用 Lua 語言提供的 Closure 特性，就可以幫助我們輕巧且優雅地達成目標：

function RandDeck(t)
	assert(type(t) == "table");

    -- Closure所使用的upvalues
	local pool = t;
	local counter = table.maxn(t);

    -- 回傳一個匿名函式
	return function()
		counter = counter + 1;

		if (counter > table.maxn(pool)) then
			RandShuffle(pool);
			counter = 1;
		end

		return pool[counter];
	end
end

上列函式 RandDeck() 的回傳值是一個「匿名函式」，而在這個匿名函式中所做的事情，與先前在 OutputCard() 函式中進行的程序相同。根據 Lua Closures 的功能規範，在 RandDeck() 中宣告為區域變數的 pool 與 counter，被稱為 external local variable 或 upvalue。

藉由 upvalue 的特性，程式設計者得以在函式之間保存變數值，並且讓底下的匿名函式進行讀寫動作。對於全域或 RandDeck() 函式外部的程式碼來說，pool 與 counter 是完全不可見的變數；但是對於底下的匿名函式來說，pool 與 counter 的功用就像是物件導向語言中的「成員變數」(member variables) 一樣。

而 RandDeck() 的使用方式也很簡單明瞭，以 52 張撲克牌為例：

-- 撲克牌牌組
--   花色：c, d, h, s 分別代表 club, diamond, heart, spade 四種花色
--   數字：1 至 13
Poker =
{
	"c1", "c2", "c3", "c4", "c5", "c6", "c7", "c8", "c9", "c10", "c11", "c12", "c13",
	"d1", "d2", "d3", "d4", "d5", "d6", "d7", "d8", "d9", "d10", "d11", "d12", "d13",
	"h1", "h2", "h3", "h4", "h5", "h6", "h7", "h8", "h9", "h10", "h11", "h12", "h13",
	"s1", "s2", "s3", "s4", "s5", "s6", "s7", "s8", "s9", "s10", "s11", "s12", "s13",
};

-- 創造一副牌組
g_Deck = RandDeck(Poker);

MyCard = {};
-- 呼叫 g_Deck() 發第1張牌
MyCard[1] = g_Deck();
-- 呼叫 g_Deck() 發第2張牌
MyCard[2] = g_Deck();
-- 呼叫 g_Deck() 發第3張牌
MyCard[3] = g_Deck();

-- 創造多副不同的牌組
g_Deck1 = RandDeck(Poker);
g_Deck2 = RandDeck(Poker);
g_Deck3 = RandDeck(Poker);

MyCard = {};
-- 使用 g_Deck1() 發第1張牌
MyCard[1] = g_Deck1();
-- 使用 g_Deck2() 發第2張牌
MyCard[2] = g_Deck2();
-- 使用 g_Deck3() 發第3張牌
MyCard[3] = g_Deck3();

結合之前的 RandShuffle() 與 RandDeck() 寥寥可數的幾行程式碼，就完成了雙效合一的洗牌發牌機。

最後，可以再進一步修改 RandDeck() 函式，讓它能夠一次發出複數張的牌：

-- 發牌機加強版
function RandDeck(t)
	assert(type(t) == "table");

	local pool = t;
	local counter = table.maxn(t);

	return function(num)
		num = num or 1;

		if (counter + num > table.maxn(pool)) then
			RandShuffle(pool);
			counter = 1;
		end

		local result;
		-- 判斷要回傳單張牌或複數張牌
		if (num == 1) then
			result = pool[counter];
		else
			result = {};
			for index = counter, counter + num do
				table.insert(result, pool[index]);
			end
		end

		counter = counter + num;

		return result;
	end
end

-- 創造一副牌組
g_Deck = RandDeck(Poker);

-- 一次發出5張牌！
MyCard = g_Deck(5);

在這篇文章裡，雖然只介紹了非常簡單的洗牌與發牌應用，但應該不難看出 Lua Closures 的威力所在。對於習慣使用 C/C++ 或 Java 語言的程式設計者來說，一開始可能會比較難以理解 Lua Closures 的概念，但只要熟悉了它的運作方式，就可以使用 Lua 做到許多目前 C++ 語言無法達成的事情。

關於洗牌與發牌，你是否有更好更巧妙的作法？關於 Lua Closures，你有更棒更實用的應用嗎？歡迎各位給予指教及討論。

（圖片來源：people.hofstra.edu）

原文出處：Creative Assembly Lines

你知道何謂「製造組裝線」生產方法嗎？你可能在書籍媒體上看過製造組裝線方法，甚至親身經歷過組裝線式的產品製造流程，然而你可曾想過對於遊戲產業來說，是否也有所謂「創意組裝線」存在的可能性？本文作者 Colin Anderson 將帶領我們一探今日娛樂媒體產業所共同面臨的挑戰與解答。

在十九世紀與二十世紀早期，所有的產品製造商們皆面臨著一項非常巨大且迫切的課題：如何製造出足夠的產品以滿足客戶的需求？這是一個真實的困境。當時多數製造商所從事的都是與農作物息息相關的產業，而隨著時代變遷，如今我們不僅有了更充裕的人口數以及更先進的技術，同時也意味著製造商擁有了一項嶄新的契機，使他們能夠便宜並且大量地製造產品。

這些製造商所想出來的解決方案就是「組裝線」(assembly line) ——由亨利福特 (Henry Ford) 於他的底特律汽車工廠中，首先倡導的生產方法。組裝線方法，相當有效地解決了產品數量不足的問題，直至今日，從製造小玩意兒到噴射客機等等所有你想得到的商品，組裝線方法仍被廣泛地使用中。

如果你是一名製造商，除非你生產的是食物、房屋或醫藥，否則你所生產的東西並不算是所謂的「民生必需品」。回過頭來看看遊戲產業，我們身為創造娛樂價值的遊戲開發者所生產出來的商品，更是難以勝過人們對於民生必需品的需求。

這意味著我們正在製造某些消費者可能會喜歡，但對他們來說並不是基本需求的東西。相較於食物、房屋或醫藥，就目前的情勢來看，消費者不可能出自全然的必需性而去購買我們的遊戲商品。他們只會在真正想要的時候，才會考慮購買遊戲。而此種情境，也描繪出了今日每一個創意媒體產業所面臨的核心問題：身為消費者，我們不知道我們真正想要的是什麼，直到我們見到它為止。而這也使得遊戲，如同書籍、電視劇、電影與音樂一樣，成為一種「熱賣導向」(hit driven) 的產業。

二十一世紀的娛樂產業製造商，譬如電玩遊戲的開發者們，正面臨著與二十世紀的製造商全然不同的挑戰。複製產品，不再是個問題。單件產品可以被複製成千上百萬次，而且無須任何運送貨物的卡車，就能夠被散佈到全球的各個角落中。

因此，既然現在幾乎每種形式的媒體，都能被數位化地重製並且散佈，那麼創意娛樂媒體公司最主要的關切事務，就會變得更加專注於產品本身的品質上，而非費心在商品通往市場的途徑上。散佈與推銷品質平庸的產品，已不再具有顯著的益處；更明確地說，任何具有長遠眼光的娛樂公司，都必須考慮如何在一個不斷演進的基礎上，一致化地重複創造出熱賣商品。

如果亨利福特的底特律汽車工廠，是二十世紀製造業問題的解答，那麼在二十一世紀裡，我們所渴求的「創意組裝線」解決方案，看起來會像是什麼模樣？換言之，一間公司是否能夠持續產出創意，同時仍保持它的生產力？如果真的可以做得到，這個能夠重複生產出熱賣產品的系統，是如何運作的呢？

畢竟，我們需要認知的事實是：創意與生產力，兩者缺一就會失去價值。有創意很好，但如果你無法釋出產品，最終你將會把錢燒光，並剝奪掉你的創意產物問世的機會。同樣地，如果只是一味注重生產力，生產出一大堆產品，卻沒能提供給世界某些新的東西，也等同於毫無價值可言。換言之，今日所有創意娛樂媒體所面臨的挑戰，是必須建立一個能夠平衡他們的創意能力與生產力的系統機制。

真的有這樣的系統機制存在嗎？首先我們看看幾個過去曾用來平衡創意能力與生產力的系統實例。

（圖片來源：blog.arkabo.com）

第一個系統是「無限猴子」(Infinite Monkeys) 方法。純粹把龐大數量的不熟練工作者，塞進同一個房間裡，給他們合適的工具，然後讓他們開始著手進行工作。理論上來說，或遲或早，他們將會製造並且交遞出一項成功的熱賣產品，沒錯吧？大概，幾乎可肯定，某天一定辦得到……好吧，這是個看起來很好，實際上或許沒那麼好的理論。不僅要付他們薪水，而且還得提供充足的工作空間，看起來投資者應該不會願意將錢投注在這種系統方法上。

那麼，讓我們稍微修改一下上述程序。或許可以把龐大數量的不熟練工作者，以有限數量的高度專精工作者取而代之？這樣應該可以做得更好一點，但仍然有其限制存在。不過，這項程序已經接近今日多數開發者所使用的方法了。使用這套系統方法，我們可以在經過某段時間後，得到某項產出物；然而，產品的品質無法得到保證，而且你仍需要相當大量的時間以產出成品。

但請別忘記，對於任何娛樂事業來說，最終成品的內在品質是產品本身的基礎生存能力。一個準時完成的半調子成品，就像是在世界末日當天才釋出的最棒遊戲一樣毫無用處。不僅止於遊戲產業，而是橫跨所有創意產業，我們真正需要的是一項能夠在商業現實化時間與預算之內，交遞出最高品質產品的方法。

真的有可能嗎？

作者 Colin Anderson 相信這是做得到的事情，因為它曾經被達成過。從他學習過的知識與經驗，似乎可以推導出兩項關鍵的組成要素：人與程序 (People & Process)。在此，他故意且引人爭議地將「點子」(Idea) 這個因素忽略掉。

作者注意到在其他娛樂產業中，某些公司確實能夠一致性地在很長的期間內，成功交遞出許多不同類型的賣座商品。在電視與音樂產業中，都有一些成功的例子，但這裡要提的是兩間表現特別傑出的公司：摩城唱片 (Motown Records) 與皮克斯動畫工作室 (Pixar Animation Studios)。

這兩間公司，不僅能夠使用不同的製作團隊與全新的概念，長期持續創造出商業上獲得成功的作品，更能夠創造出具有長期藝術價值的產物。兩間公司展示出了相似的特徵：他們都擁有多款大賣的作品。他們的作品不僅叫好也叫座，廣受消費者大眾的歡迎，而且他們都擁有多支不同的創作團隊，同時在數種不同風格的新專案中進行工作。

如果我們回顧摩城唱片的歷史，有個不斷浮現腦海的形容詞就是「工廠」——不具任何負面意義的詞。整間公司就像是間「賣座工廠」般地運作著，一片接一片地生產出熱賣的音樂唱片。摩城唱片具有從不間斷的持續生產力，而他們也在十年中交出了 110 張音樂排行榜前十名作品的驚人成績。整整十年內，幾乎每個月都有一張熱賣唱片！

（圖片來源：allfreedownloadlinks.com）

摩城唱片的創始者 Berry Gordy，把他對於產品品質的信念，運用於生產程序的每一個面向上。他雇用專門的詞曲作者，雇用最好的專門樂手來錄製唱片，同時他也創立「藝人養成計畫」，訓練年輕的歌手如何應對進退、演出以及表現自己。更值得一提的是，他會每週定期舉行會議，審閱目前正在製作中的唱片，並將其拿來與排行榜前五名的作品做評比，任何歌曲只要沒有達到他心目中的理想程度，或預期無法獲得亮眼成績，就會被送回去繼續製作。

某些最成功的名作，包含《I Heard It Through The Grapevine》在內，都曾經被送回去重製過好幾次。也許很多人會說，敢於做出這樣的決策需要相當大的勇氣，但是選擇另一條路「讓半成品問市」，事實上對於任何娛樂公司來說，都是更加魯莽且不智的決定。

另一方面，皮克斯動畫工作室也同樣地成功。他們在超過十年的時間裡，產出了十部電影，進帳超過 25 億美金，使他們成為了動畫電影產業中的最高標準。在皮克斯的網站上，概略地描述了他們構思、設計、生產與增進電影內容的工作流程。他們的方法與摩城唱片相互呼應，就是由始至終對於品質的掌控，以及在任何時間點把不夠好的產品送回去重新製作的勇氣。

皮克斯的方法，標記出了成功的「創意組裝線」的另一項關鍵要點：與原創點子無關，一切全關乎於人與程序。現任迪士尼與皮克斯的總裁 Ed Catmull，將這個概念表達地非常簡潔有力：「如果你把一個好點子交給一個平庸的團隊，他們會把它搞砸；如果你把一個平庸的點子交給一個優秀的團隊，他們會修好它，或者丟掉它然後想出某個可行的做法。」

「If you give a good idea to a mediocre team they will screw it up; if you give a mediocre idea to a great team they will either fix it or throw it away and come up with something that works.」——Ed Catmull

對於摩城唱片與皮克斯動畫工作室兩間獲得長期巨大成功的公司來說，最關鍵重要的方向，就是找來對的團隊，然後創造出一個確保每項產品都能獲得這些行家悉心照顧的完善流程。如果製造出來的產品成果不如預期，沒有第二句話，就是送回去重新修改。

上述兩個成功的案例，違反了遊戲產業中最基本的假設理論之一：點子是通往成功的關鍵要素。如果這兩間創意工廠的例子證實了什麼事情的話，我想應該就是：團隊才能決定產品的最終品質，而非點子。否則，有人能解釋為何一部關於廚房老鼠的電影能夠創造 6.2 億美金的收入，或者是一部關於機器人拾荒者的電影可以創造 5.2 億美金的收入，並且獲得影藝學院的獎項嗎？

另外在電視、電影與音樂業界中，還有許多成功的實例，但這兩間公司已經完美地演繹了「創意組裝線」的概念，並且得以啟發我們尋得二十一世紀製造商所面臨挑戰的最終解答。至於遊戲產業呢？在遊戲產業的領域中，你會把哪幾間公司評定為賣座工廠？任天堂或許是最明顯的例子，還有其他公司嗎？

在這篇探討娛樂創意產業出路的文章裡，讓我個人感觸特別深的內容，是作者所提到的「人與程序」(People & Process)。

從前，當我還是一個懵懂天真只愛玩電動玩具的小鬼時，總認為在自己的腦袋裡，裝滿了許多獨一無二的遊戲創意與點子。「如果這遊戲這樣那樣修改，一定會變得更好玩更有趣！」我想這可能是所有的遊戲玩家，都不曾缺少過的念頭。然而，只有當自己親身踏入遊戲業界的大染缸中，才真正地瞭解原來「做遊戲」，可不是我想像中的這麼一回事哪。

（圖片來源：justforthekicks.wordpress.com）

身處遊戲業界中，不論你的職位與專業為何，心裡必定有許多對於遊戲製作的想法與見解。很多人認為「創意」就像是仙丹妙藥一樣，只要想出與眾不同的好點子，就一定能夠製作出叫好又叫座的好遊戲。但不論你以及你所自認的「創意」有多麼舉世無雙或萬中無一，在它從你的腦袋中走出來，被實現成為真正可玩的遊戲之前，一切都只是空想與空談而已。

我相信唯有具備執行能力的人，才有資格談論創意；唯有優秀的團隊，才能創造出高品質的遊戲。

要將無形的創意鑄模淬練成為有形的成品，需要團隊合作，而團隊是由每個不同性格不同專長的人所組成。因此，構想的執行者，也就是「人」，才是娛樂創意產業中最關鍵的決定性要素。不論在哪個業界中，具有高度專業能力的人才都很稀少，而公司要能夠吸引、滿足並留住一流的人才，更是難上加難，所以對於遊戲產業來說，更需要將「人」視為公司企業中最重要的資產。

然而，就算公司招募到了具有高強本領的人，但某天當這些人離開公司時怎麼辦？這就是「程序」的必要性所在。

如果沒有建立起妥善的研發流程與公司制度，僅僅仰賴著天縱英才般的「英雄式領導者」帶領公司的專案前進的話，只要關鍵人物或關鍵團隊一離開公司，將會立即引發很大的負面衝擊與崩塌效應。因此，「人」與「程序」應該是相輔相成，缺一不可的東西。沒有優秀的人才，無法制訂出最佳化的開發程序；沒有良好的程序，則無法一致化且持續地產出高品質的成果。

舉個遊戲界的實例來說，當初在 Blizzard 公司中開發製作《Diablo 2》的團隊，我們可以很肯定的說，其中每位成員都是最頂尖的一流人才。而當這個團隊決定離開 Blizzard 自行籌組新公司後，Blizzard 是否就此一蹶不振，再也製作不出超越《Diablo 2》的遊戲了？正如我們所現在所熟知的情形，答案並非如此。

「人」是公司最重要的資產，但不該是無可取代的資產。

如何製作出好玩有趣又受歡迎的熱賣遊戲？在遊戲界裡，我們沒有所謂的「標準作業流程」可以遵行，而全然遵循管理階層指揮，一個指令一個動作的作業流程也不再能夠奏效。在這裡，我們需要的是可以面對挑戰且迅速應對變化的能力，可惜的是，許多老闆與管理者無法瞭解這個道理，認為他們做的決定絕對不會出錯，底下的人只要聽命行事就可以了。他們的想法是，只要有更多的時間、更多的人與更多的錢，一定能製作出超越《World of Warcraft》的遊戲大作！

更多的時間 + 更多的人 + 更多的錢 = 更好的產品？

正如本文作者所述，娛樂創意產業的存亡關鍵，早已與二十世紀時期的製造業大不相同。我們無法仰賴龐大的廠房設備，製作出廣受玩家喜愛的遊戲，就算砸下大筆資金與人力，也完全無法保證製作出來的遊戲能夠大賣特賣或損益兩平。身為遊戲開發者，我們製作出來的商品，目的在於滿足人類的高階需求，因此我們嘔心瀝血完成的產品，不止是要達到「正常運作」的標準而已，而是必須達到「娛樂群眾」的目標。

如果管理者認為只要投入越多的人力與時間，就能夠製作出更好的產品，便會想盡辦法加長每位工作者的工作時數。在華人的傳統道德思維中，總認為「勤勞」是種高尚的美德，也往往相當推崇「勤能補拙」的作法。然而，一旦管理者將這種思維模式套用在工作職場上，「加班」就理所當然地變成了一種展現勤勞的方法。於是，在許多遊戲公司裡，「加班」不是一種選擇，而是成為了一種常態。

即使已經完成預定排程中的工作，仍會被要求留下來加班，只因為這是公司約定俗成的習慣。主管會獎勵表揚自願加班到很晚、甚至以公司為家的勤奮工作者，卻不注重他們解決任務的效率與效能。「既然公司佔用我的自由時間，那我也不必太認真地拼命做事。」久而久之，工作者就會養成急事緩辦的惡習，甚至利用上班時間逛網拍、上撲浪或玩遊戲，也絲毫不以為意。

結果，原本期望每個人辛勤工作以得到最高品質成品的美意，反而變成工作進度拖泥帶水與交付成品品質低落的元兇。如果管理者只是抱持著二十世紀製造業的思維與作法，卻想在娛樂創意產業中獲得長遠的成功，不正是落入了「無限猴子」方法的陷阱中嗎？「雖然投入了大量的遊戲開發時間，到頭來卻減損了遊戲完成品的品質。」聽起來既矛盾又真實，可不是嗎？

總結一句話：同是天涯遊戲人，我們還得繼續拼搏奮鬥才行哪！ ^_^

（圖片來源：cecilia.sweet.blog.163.com）

（圖片來源：techcrunch.com）

原文出處：What Has The iPhone Really Changed?

如果有人問我 2009 年遊戲產業最夯最火紅的東西是什麼？我想我會毫不猶豫地回答：iPhone！

iPhone 是什麼？許多人都知道它是手機、具備照相功能、擁有 3G 無線網路功能、還有很多的應用程式，同時也是個操作介面很創新的玩具等等。如果從更廣義地來角度來看，事實上 iPhone 不僅只是一具攜帶式電話，不僅只是一台數位相機，也不僅只是一個酷炫的科技玩意兒，而是一個由蘋果電腦結合硬體裝置與軟體系統建立起來的整合服務。

iPhone 之所以會被許多科技產品愛好者推崇，並不是因為它擁有多麼強大的硬體效能，具備多麼高畫質的螢幕解析度，能夠播放高品質的音樂，或是配備有高畫素的相機。反之，我認為 iPhone 與其他競爭者最大的不同之處，在於它擁有對於應用軟體的高度整合架構。為了達到這個目標，Apple 一開始就建立起了應用程式的下載服務平台——App Store，並張開雙手歡迎全世界程式開發者的到來。

如同 iTunes 之於 iPod 的重要性，App Store 可說是 iPhone 的活力泉源所在。

對於遊戲產業與遊戲開發者來說，iPhone 問世又代表什麼樣的獨特意義？在 App Store 上販售的遊戲，除了可以獲得很高的拆帳比例以外，藉由 App Store 下載服務平台，遊戲開發者能夠很容易地將自己撰寫的遊戲，散佈到全世界擁有網路線路的每個角落中。勢單力薄的小型遊戲開發者們，再也不必望著 Sony、Nintendo 或 Microsoft 遊戲平台的高門檻興嘆，也無須為了 Nokia、Sony Ericsson 或 Samsung 各家手機迥然不同的技術規格捶胸頓足，更不必經過遊戲發行商與代理商的重重關卡與層層剝削。

如果你仍未發現——這股更快速、更簡便、更無遠弗屆的新力量，正熱烈地蓬勃發展中。

自從 iPhone 上市以來，我們時常可聽到或看到許多媒體報導的成功故事：某程式設計者在空閒之餘撰寫的小遊戲，在短短三個月內賺進上百萬美金，於是決定離開大公司全職投入 iPhone 程式撰寫；還有許多設計概念十分簡單並且毫無技術難度的小程式，也使程式作者得以每月收入十萬美金以上。一切看起來全都如此美妙，似乎只要寫出一兩個簡簡單單的小遊戲，就可以準備賺大錢然後一夕成名了！

「iPhone 是新世界的神！是遊戲開發者的救世主！」

你，相信嗎？

在今年的 GDC 會場裡，本文作者 Colin Anderson 最常聽見的句子，莫過於：「iPhone 改變了一切的事物。」特別強調的是「一切的事物」。每一場會議、文章與討論，似乎都無異議地推論出這個相同且過於簡化的結論——iPhone 改變了一切。彷彿所有遊戲產業中的問題，都已經被這突如其來的恩賜之物解決了，而唯一剩下的議題，就是去決定我們該如何分享這些突然降臨的財富而已。

（圖片來源：home.comcast.net）

就像是淘金夢一樣。

好吧，這麼說可能聽起來會像是個令人厭煩的老預言者：但你在此仍必須小心謹慎。沒錯，那裡有許多可被創造的財富，但並不像是拿起你的「數位鏟子」直接朝向「App Store 金山」邁進這樣輕鬆容易。所以在你迫不及待想開始動手之前，以下是本文作者 Colin Anderson 對於 iPhone 所真正改變的事物的觀點。藉由此文呈現的內容，希望你能擁有更好的機會獲取你的財富，而不是最終成為歷史教訓中的統計數據。

在今年 GDC 中，作者所參加的其中一場會議，演講主題是「在艱苦經濟時期中的開發者新機會」。不知原因為何，這項活動無可避免地轉變為對於 iPhone 的狂愛集會，而這場會議最終所給出的結論是：製作 iPhone 遊戲是我們遊戲開發者的絕佳機會，而你的動作最好快點——趕在你錯失前往金山的馬車出發之前。

這一切，就好像我們從未經歷過一樣。

在這場會談中，與會聽眾所提出的疑問，多數是關於「什麼樣的遊戲才是一個好的 iPhone 遊戲」之類的問題，而主持者也應答的相當好。然而，正當整個房間準備要陷入 iPhone 程式狂潮時，有個態度較為保守的年輕成員發問：「我在想，要如何能使我的遊戲引起人們的注意？這些日子以來，似乎真的很難使人們發現你才剛發行上市的遊戲。」

作者並不確定這位年輕的提問者，是否真能體會他所問的問題的重要性，但他著實提出了今日遊戲開發者所面臨的最大挑戰：使人們注意到你已發行上市的遊戲。

你看看，在從前的那些日子裡，多數遊戲開發者極少會到達需要仔細考量這項議題的時點。那時候的遊戲開發者們，有更迫切的顧慮需要應付，像是使遊戲發行商一開始就同意資助並且發行你的遊戲等等。在沒有面對客戶的直接銷售管道的情形下，只有非常少數的公司能有機會真正地去製作遊戲。接著假設完成了遊戲並順利發行上市，遊戲開發者們通常也會被拒於市場與行銷的運作機制之外，因為這些事情全由遊戲發行商經手處理。

然而，今日的情勢已全然不同。遊戲的散佈管道，對遊戲開發者來說已經不是難題所在。無論你所製作的遊戲的目標平台為何，歸功於數位下載服務的崛起與興盛，現在你已經能夠更直接地接觸到你的目標客群了。但是，可以接觸到目標客群，並不表示就能夠順利地賣出你的遊戲；某些遊戲開發者新手會犯的錯誤，就是假定以前由遊戲發行商所提供的促銷與市場行銷機制，已經不那麼具有重要性了。

在作者的經驗中，情形絕非如此；他多年辛苦學得的教訓是：好遊戲不賣，行銷良好的遊戲才會賣；而行銷良好的好遊戲，則能夠大賣。

為了證明為何行銷機制很重要，作者拿出以前親身經歷過的遊戲銷售失利案例，以及從《The Logic of Life》一書中學到的知識理論做為佐證。根據《The Logic of Life》作者所述，人們的決定通常是完全理性的；起初聽起來或許會覺得有些奇怪且違反直覺，但人們通常會為了達到對自己最好的結果而努力。因此，我們身為人類，並不會做出看起來像是隨機化或非理性化的決定。

以玩家購買遊戲時的情境為例，當我想要購買電腦遊戲時，通常我要尋找的唯一目的就是「娛樂」——我要的是最能保證獲得樂趣的花費。而當每款遊戲的價錢約略相同時，它們很明顯不是在價格上進行競爭。那麼他們在競爭什麼？簡言之，就是「樂趣」。在我們面對商品架上琳瑯滿目的遊戲時，我們會沈思問自己的問題是：「在面前成堆的遊戲中，哪一款遊戲最有可能提供給我值得這筆花費的娛樂？」請注意，在這個句子中最重要的是「最有可能」這部分。

身為想要購買遊戲的玩家，我要如何知道在這麼多款遊戲作品中，那一款遊戲才能真正帶給我最多的樂趣？想當然爾，我不可能明確地知道答案為何，所以我只是會去衡量各種可能性，而這一點，這點就是促銷與行銷機制顯得如此關鍵的重點所在。

（圖片來源：obsessable.com）

為了瞭解原因為何，不妨自己親身做個實驗：走進一間販賣二手音樂 CD 的店家，站在堆積成山的大量 CD 唱片前，然後開始掃視眼前的這堆唱片。經過一段時間之後，留意你的眼神停留在哪裡。沒錯！會吸引你的注意力的唱片專輯，多半是你已經聽過的唱片，或者是擁有很酷的封面或名稱的唱片。至於其他的唱片，就像是隱形般被你視而不見。

為什麼會這樣？因為你對於你該如何做出決定的基礎所在，完全沒有充足的資訊可使用；換言之，你沒有方法判斷出全部唱片的品質，並且得出一個理性的決定，所以你甚至不會浪費時間嘗試著去這樣做。

更進一步來說，如果你確實有某種方法可以找出在這裡每一張唱片的相對品質評比，例如使用你的 iPhone 與音樂評論網站，你也沒有足夠的時間這樣做。或許你只會概略瀏覽幾十張你可能會喜歡的唱片，也可能會完全忽略你喜愛但從沒聽過的唱片。在這個時間點上，品質真的不重要，因為你甚至不會注意到它——對你而言，它是隱而不見的東西。

這就是為何使用滲透式廣告販賣遊戲（或其他東西），總是很有效果的原因。因為它能夠保證，在我們進入商店時，我們至少知道有關那款遊戲的一些事情。廣告行銷，可以立即性地將這款遊戲從多數隱而不見的群體中，移轉到少數消費者可見的群體中。

上述的實例，也進一步解釋了那些專家學者為何會做出建議：請投資市場行銷與公共關係；它很貴，但值得。儘管有部分是事實沒錯，但拜託，如果真的有這麼容易的話，那麼每一款 iPhone 遊戲都該賣出上百萬套了不是嗎？如果只要藉由投入昂貴的市場行銷與公共關係，就能夠保證遊戲開發者可以把投資的錢全部賺回來，那麼所有人肯定都會這麼做。

但顯然結論並非如此，開發 iPhone 遊戲仍具有很大的風險，以上的例子也說明了 iPhone 遊戲市場問世以來的主要問題。iPhone，被許多遊戲分析師與開發者視為獨立遊戲開發者的救星：低進入門檻、低開發花費，以及上百萬的遊戲客群。當然，事實並沒有如此簡單。

事實是，蘋果電腦改變的僅僅是通往市場的途徑，而非市場的本質。人們想要的仍然是他們一直以來所渴求的東西：隨手可得的娛樂。然而現在的時代，早已與從前不同：遊戲玩家們並非每個月僅有 30 款來自幾個主要遊戲發行商的遊戲可選擇，現在他們每天有 30 款遊戲可以挑選，來自於看似無窮數量的獨立遊戲開發者！是的，iPhone 解決了某些遊戲產業中最巨大、最長久的問題，也同時創造了一連串新的問題。

（圖片來源：iphoneworld.ca）

談到獨立遊戲的處境，可說目前的獨立遊戲界，擁有可與 70 年代晚期到 80 年代早期出現的獨立音樂 (Indie Music) 風潮相提並論的局勢。兩者的興起皆起源於重大技術變化所產生的結果；在我們的遊戲業界中，快速的網路連結與數位化下載及付費解決方案，點燃了獨立製作的火焰；而在那個年代的音樂產業中，則是出現了一般人支付得起的可攜式高品質錄音配備。

從前，幾個主要的音樂大品牌掌握了所有的媒體。即使有個胸懷大志的樂團找到錄製唱片的方法，他們也無法在沒有音樂大廠的支援下複製唱片。然而，一旦可以小量製造與複製唱片的方法出現之後，事情就產生變化了。我們的遊戲產業正面臨著相同的局勢：那些大牌子的遊戲公司，不再能控制遊戲的散佈方式，但還是有人得去做市場行銷以及建立客群的事情。如果遊戲發行商不做這些事情，那麼這些重擔將會落在遊戲開發者的肩膀上。所以，準備妥當是很關鍵的事情。

如果回到 GDC 的那場會談，作者會建議一心嚮往 iPhone 遊戲開發的與會者去看看其他的產業，特別是獨立音樂界曾面臨過的嚴峻局勢。遊戲開發者需要瞭解獨立音樂界的創作者或公司，如何在沒有龐大廣告與公共關係預算的情形下，成功獲取聽眾的注意力。儘管這樣做不太可能供給獨立遊戲開發者們立即可用的解決方案，但獨立音樂界的借鏡，肯定能夠用來激發我們的靈感，藉以找出使遊戲獲得玩家注目的創新方法。

人們經常談論關於社交網絡與口碑行銷的事情，就像是談論 iPhone 一樣的論調：它改變了一切事物。但再次強調，它真的沒有。如果你想要人們注意到你的遊戲並讓它賣得很好，你所需要的東西，將會比一個 Facebook 頁面與一個 Twitter 帳號多更多。對於任何長期性的成功來說，你必須創造出某些具有真實價值的東西，某些有點不同的東西，某些有點變化的東西，或者某些人們會想告訴朋友的東西。

否則為什麼任何人應該關心你的遊戲？認真想想：為什麼你會關心？如果這遊戲不是你做的，而且你也不知道任何關於遊戲的事情，什麼才會讓你想告訴你的朋友關於你剛玩過的遊戲？

總結來說，iPhone 改變了前往市場的途徑，而非市場的需求。如果你不是一個用空餘時間製作 iPhone 遊戲的開發者，那麼你真的真的很需要花時間瞭解這兩者的不同之處。

最後澄清一點，以上一切論述都不是對於 iPhone 的批評。作者在此所描述的種種難題並不是這個平台特有的問題；它們會影響每一個遊戲平台，也影響了每一款發行的遊戲。只是很恰巧地，由於 iPhone 提供了一條相對易於行走的市場途徑，反而使遊戲開發者必須更直接地面臨這些問題。反過來想，這些問題的產生，也再次反映出了最初在 iPhone 上有多少被創造出來的全新機會。

無論如何，在你打算做出任何結論之前，請小心謹慎地考慮任何聲稱「iPhone 改變了一切事物」或者「建造 iPhone 程式是前往名聲與財富的捷徑」這一類的論調。在遊戲業界裡，存在著各種危險的能言善道之詞，而且已經被業界中的人們廣為誤解了。最終，如果你對文章中所提的一切早已了然於胸，那麼你還在等什麼？趕緊抓起你的數位鏟子，開始動手挖吧！

（圖片來源：techcrunch.com）

寬頻網路的普及化，不僅大幅便利了現代人的生活與工作，同時也為遊戲開發者開闢了一條通往市場的坦途。而除了 iPhone 以外，不論是 PSN、WiiWare、PSP Minis、DSiWare，或剛從 XBox Live Community Games 更名為 XBox Live Indie Games 的 XBLIG，都越來越瞭解拉攏第三方遊戲開發者的重要性。

但是，正如本文作者 Colin Anderson 所述，我們身為這個世代的遊戲開發者，雖已身處與上個世紀截然不同的網路科技浪潮裡，但事實上，市場最基礎根本的需求，並沒有產生本質性的變化。在一頭熱投入 iPhone 平台或其他新興起的遊戲市場之前，還是有許多關鍵要點需要悉心留意。

開放，是一項正確的作為，但並不代表是一項完美的作為。就算遊戲開發者能夠妥善地處理市場行銷的難題，iPhone 與 App Store 平台也並非沒有自己的問題存在。目前 App Store 所面臨的最大挑戰，是過度氾濫的遊戲作品、缺乏完善的評比機制，以及過於狹隘的遊戲展示機會等等。再者，面對實力不容小覷的 Google Phone 與 Android 挑戰，Apple 的下一步將會如何應對？iPhone 是否可能更進一步挑戰 PSP，甚至是 NDS 掌機市場的地位？該如何拓展遊戲市場的需求？Apple 如何處理接踵而至的問題，也是接下來值得關注的焦點。

「The bottom line is that markets owe you nothing. If you can’t survive in the market, there will be a hundred other guys that want it more and will take your place.」——Jeff Tunnell

最後，請別抱怨這個市場——市場並沒有虧欠你任何東西。請記得，在你埋怨與不滿的同時，早已有許多遊戲開發者默默地在開疆闢土了！

延伸閱讀：Hey Whiners, the iPhone Market Owes You Nothing

遊戲平台

• Microsoft Windows：Windows XP
• Apple Macintosh：Mac OS X 10.5 以上

遊戲連結

• Windows：ColorMemory_Win.zip (1.53 MB) (下載次數： 593 )
• Mac：ColorMemory_Mac.zip (1.50 MB) (下載次數： 161 )

遊戲概述

考驗你對色彩的記憶能力！

請記憶「色彩方塊」出現的順序，然後依此順序一一點選畫面上的「色彩機器人」。每次遊戲共有三次機會，結束後會對你的記憶體能力值做出綜合評比。

遊戲類型

益智腦鍛

操作需求

1. 滑鼠：移動與左鍵點擊。
2. 空白鍵：可暫停遊戲，以及回到遊戲中。

遊戲畫面

製作團隊

• 美術：Feeling
• 設計：半路
• 程式：半路

第三方素材

• 音效與背景音樂：Propan_Mode
• 字型：Webpage Publicity

版本歷史

• 2009/08/04：v1.0 初版釋出。

歡迎各位提出遊戲心得、建議或感想唷～ ^_^

「閱讀選錄是什麼鬼？」

關於猴子靈藥的「閱讀選錄」分類下的文章，目前總共包括「遊戲業界閱讀」、「遊戲程式閱讀」、「遊戲設計閱讀」、「遊戲美術閱讀」與「遊戲開發閱讀」五類。請注意，在這個分類底下的文章，全部都不是由我自己原創撰寫的內容，而是來自國外遊戲開發網站的優質專業文章。

在撰寫閱讀選錄文章時，我會盡最大努力將文章中的關鍵要點，詳細地用中文轉述解釋，但並不會依照原文逐字逐句地進行翻譯。在每篇閱讀選錄的第一行，我一定會先附上原文的文章名稱與網址連結，而在翻譯文章時，我會使用自己慣用的名詞語句，例如將「Designer」翻譯為「企畫設計者」、「Artist」翻譯為「美術設計者」，「Programmer」翻譯為「程式設計者」等等。除此之外，在一些比較難以傳神表達原文意義的字句中，我會以刮號附註原文名詞，或是節錄一部分原文句子的方式呈現出來。

「所以這是文章翻譯嗎？」

是，也不是。如前所述，這並不是百分百完整的文章翻譯，有些原文寫作風格較為口語化，有些字語詞彙較為艱深難懂，所以我會依照自己的個人偏好以及對於題材的熟悉度，僅摘錄翻譯其中部分的內文。因此，如果你期望讀到最完整也最原汁原味的文章內容，我建議閱讀原文會得到更多的收穫唷！另外，除了原文的段落以外，我也會將文章所述的內容，與自己在業界的經歷相互印證，然後在文章裡撰寫一些自己的心得與感想。至於哪一段是原文，而哪一段又是我自己增加的補充心得，我不會特別標示出來，需要請各位自行查閱原文了。請體諒我的一點小小任性。

「為什麼要做閱讀選錄？」

因為我爽。講得更明確一點，是因為我喜歡做這件事。閱讀，原本就是一件很過癮的事情，每每讀到一篇好文章，總會使我有醍醐灌頂與豁然開朗的感受，如果能夠將這份充滿喜樂的滿足感與更多人分享，豈不是一件更加痛快的事情？雖然可能需要閱讀完十篇文章，才能夠選出一篇值得翻譯的文章，雖然翻譯一篇文章所需花費的時間，超過閱讀一篇文章所需時間的十倍以上，但我認為，光是閱讀並不能夠使我真正瞭解作者原文的精華內容，唯有透過自己的筆調用心詮釋，才有機會將這些東西化為自己的靈魂血肉。

所以結論是，「閱讀選錄」不是翻譯文章，而是翻譯文章加上閱讀心得，也是經過咀嚼消化之後反芻出來的產物，可能會有些黏乎乎地，外表看起來也不太可口，如果各位朋友及讀者發現文章裡有詞不達意或者不太通順的段落，都非常歡迎提供更好更流暢的翻譯，將來我才能夠呈現出品質更好的文章。

最後，在目前共 30 篇的閱讀選錄中，我挑選出幾篇自己很喜歡的文章，推薦給每一位熱愛遊戲開發的遊戲人：

• 《Statistically Speaking, It’s Probably a Good Game, Part 1》：遊戲設計者的基礎機率入門
• 《The Code/Art Divide: How Technical Artists Bridge The Gap》：技術美術設計者，為您搭起團隊的橋樑
• 《How Mega Man 9 Resembles… Real Life?》：那些洛克人教我們的事
• 《Flagship Founder Bill Roper Interview》：地獄之門崩壞，旗艦之夢沈沒
• 《How to Prototype a Game in Under 7 Days》：如何在七天內完成遊戲原型
• 《Postmortem: RiverMan Media’s MadStone》：奉獻、持續，以及無與倫比的熱情

Let’s read, write and share!

（圖片來源：www.cals.ncsu.edu）

原文出處：Game Artists: The Three Cardinal Rules

這是一篇專為遊戲美術設計者所寫的文章，同時也是一篇對所有遊戲業界從業者很有幫助的文章。

在這篇文章裡，作者提出了三項最基本也最重要的準則：自我意識管理、專業面向的溝通，以及接受多樣化任務。其中，佔最多篇幅的內容在於專業溝通的議題上。多數人都知道「溝通」非常具有重要性，但是在現實生活與每天的工作中，到底該怎麼做才能達到良好的溝通成效？該用什麼樣的態度與主管溝通？該用什麼樣的方式與同儕溝通？要如何說話提問，那些該死的企畫設計者與程式設計者才聽得進去？本文為遊戲美術設計者，提出幾項實用而懇切的溝通要領。

本文作者 Keith Self-Ballard 從普渡大學 (Purdue University) 的電腦繪圖技術系畢業後，旋即進入遊戲產業工作。目前他在遊戲公司裡擔任美術部門主管的職務，也同時兼任母校的業界諮詢委員。去年，電腦繪圖技術系的教授向他詢問，是否能夠提供一些給美術設計者的小提示，讓學生們能夠瞭解什麼是他們必須學習與追求的東西。

這是個令 Keith 十分感興趣的議題。十年多以前，當他剛進入遊戲業界時，對於如何成為專業的遊戲美術設計者，他只有非常非常稀少而有限的認識。當他學習到新的工具與技術之後，同時也發展了自己的知識，瞭解該如何與同儕以及領導者協同合作，在製作過程中解決問題，並與各種不同類型且擁有獨一無二特質的人共同工作。

在那個時候，Keith 也在自己專業工作上犯了一些錯誤。我們每個人都會犯錯，幸運的是，他犯的錯並沒有糟糕到使他的業界生涯終止的程度；其中大多數的錯誤，應該都是剛進入業界的新血員工容易犯的那種錯誤。這些年來，不論是對於自己或者他人所犯的錯，Keith 繼續以這些錯誤行為做為自己的警惕，並持續地觀察這些錯誤所造成的衝擊與影響。

當他在兩年多前成為管理階層的一員時，他開始面對關於美術設計者的成員管理、人才招募，以及個人績效評量等各種事務。正因如此，他熱切地想要識別出對專業美術設計者的共通期望。於是，他開始研究遊戲業界對於美術設計者，究竟保持著什麼樣的期望。最終他想要獲得某些具體的東西，使他能夠與美術設計者分享，並對於那些直接從教育機構進入業界的新血，或者從其他業界進來而不夠清楚瞭解準則的員工，能夠用來做為一項訓練輔導工具。

令人驚訝的是，Keith 發現在這方面有所著墨的文章極少。多數文章不是講得太過於廣泛，就是太過於專注在細節之上。由於在這個主題上，缺乏足夠份量的文獻研究，他必須以其他方法建立這些專業指導準則。除了他自己的個人經驗與觀察以外，他也向其他專業同仁徵求意見，另外與其他遊戲工作室的美術指導者以及遊戲製作人請教，也與幾個不同的教育機構的職員討論，最後則和遊戲業界之外的資深美術設計者討論，一切只為了找出這些實例中的一致性或不足之處。

最終，在 Keith 回覆給教授的清單裡，鉅細靡遺地列出了超過 30 項條目。其中比較關鍵的項目，包含自我意識的管理、與同儕間的相處、面對工作任務的態度，以及如何學習積極溝通等等。而在這篇文章裡，他將原先所列的 30 項條目，濃縮成三大項最一致化也是優先權最高的專業準則。期望這些內容不僅能夠做為新血美術設計者的指引，同時也可以提供老手美術設計者一些值得思考的營養補給品。

1. 管理你的自我意識 (Managing Your Ego)

這是 Keith 在原回覆信件中排名第一的首要準則，而他現在依舊認為在任何關於專業美術設計者的討論中，這個項目應該佔有最高的優先順序。自我意識是一個複雜的議題，不論你的職業為何，它都會對於你個人的職業生涯以雙面刃的方式運作著。他認為美術設計者，是特別容易受到自我意識效應影響的人。

首先，我們應該先釐清「自我意識」的意思。在專業面的意義上，自我意識代表一個人對於自己的工作的認同感，也是對於自己的作品所擁有的關心；就某種程度上來說，自我意識也是使一個人能夠繼續增長自己的技巧與才能的動機。在這個面向上，自我意識能夠以「對動機與靈感的正面力量」角色存在而良好運作著，同時對自己產生影響也對其他人產生影響。

然而，自我意識的確需要被管理。如果疏忽而未加抑制的話，自我意識同樣會在你自己身上以及你的工作環境中，產生有害的影響力。如果放任自我意識恣意而為，原來對於「個人工作」的驕傲感，有可能會隨著時間逐漸轉移成對於「個人」的驕傲感或自己應得的特權，而這種個人的驕傲感，在每個人的工作關係中，的確會擁有最具毀滅性的衝擊力。

（圖片來源：www.insideoutshop.de）

個人驕傲就像是一條滑坡，可能會導致美術設計者看不起他們的同儕，認為其他人比較沒有價值或是比較沒有才能。因此，他們便會停止給予具有建設性的意見回饋給那些他們認為較沒有價值的人。而同儕間的意見與回饋，卻是對於成長中的美術設計者來說，最為關鍵重要的事物之一。

以上種種觀察，對於那些身為專業美術設計者而無法管理自我意識的人，令人想到兩種可能的結果：其一，無法或不願管理自我意識的美術設計者，很少能夠達成他們最高的創造潛力。當他們的態度趨於疏遠他人的時候，他們也關閉了創造性輸入的渠徑，因而限制了自己的潛力與成長空間；其二，遊戲業界可能會慢慢地淘汰這一種類型的人。

在超過十年的業界生涯中，Keith 所認識的那些最有才華與最有成就的美術設計者，絕不會讓自我意識或特權以任何方式危害他們的成長，他們總是會非常細心地照顧他們的藝術技能。無法掌控自我意識的美術設計者，不僅冒著傷害自己聲譽的風險，更會損害自己的職業生涯。

2. 專業面的溝通 (Professional Communication)

專業溝通的重要性應該很易於理解。當我們創造的產品在規模與複雜度上增長時，我們的製作團隊人數也會跟著向上攀升。積極溝通，將會對於團隊的執行效能有直接且立即性的衝擊。

對照來說，如果未能有效溝通，將可能為團隊帶來最高昂的代價。關鍵點取決於互動方式的效能，就像許多人所說的一樣，你所使用的溝通風格，應該要隨著你的目標聽眾而轉換。在接下來的幾個段落中，將討論三種不同類型的聽眾與溝通方式：

• 與同儕的溝通

  這裡所謂的「同儕」，特別指的是其他的美術設計者。美術設計者對美術設計者之間的溝通，最簡單的例子，就是學習與教學。因為學習與教學需要持續不斷地互動與刺激，它們通常也是最難維持的事情。多數時候，任務期限與工作時程的重擔，會阻礙這些具有生產力的知識交流行為，然而它們的重要性絕不會因此而減退。

  維持這些溝通管道的第一個步驟是經由「分享」。多數的美術設計者，都知道多種方法能達成相同的目標，或許是不同的工具，或許是不同的技術。即使像是使用熱鍵這樣簡單的事情，其重要性也經常會被忽視，但這些知識交流卻能夠對於你周圍的美術設計者，造成立即性的正向衝擊。強烈的美術設計者文化，正建基於這種彼此參與的程度上。

  然而，現實是這項動力在每一位美術設計者「自己」的身上。如果美術設計者們不願意投入其中，管理者或領導者也無法創造出這樣的環境。值得悉心留意的是，請記得分享你所知的知識，並且從其他人身上學習。身為美術設計者，這種知識交流對於你的個人成長非常緊要。其中有許多機會，將會來自於美術的檢閱過程或是具建設性的批評，如果想要獲得更多，你自己就需要奉獻更多。

• 與管理者及領導者的溝通

  就像稍早前曾提過的，製作團隊的規模不斷地增長，也意味著我們需要更多有能力的管理者。而如果管理事務也跟著增長，那幾乎可以確定，你將會需要更頻繁地與你的領導者與管理者們進行互動。從一個遊戲工作室到另一個，任何團隊的組織結構都不會相同。一個常見的思路是，人們似乎認為管理者和領導者絕對不會犯錯；他們可能不會說出口，或者正好相反，但通常他們的行為已經揭露了他們的心態。

  簡單的事實是，你不會同意管理者或領導者所做的每一項決定。這樣沒問題。不能接受的是，當他們看見一個錯誤或問題出現在地平線上時，卻理所當然地以為他們不能說出口。Keith 把這種情形稱呼為具有「沈默習俗」(code of silence) 的環境，它可能起源於許多不同的因素，包括害怕因為指出問題點而被駁斥，或者會遭受某種形式的懲罰。

  不幸的是，這樣一來負責製作產品的美術設計者，也是每日從事大多數工作的人，將會與發生在他們周圍的決定變得疏離。他們能夠預知那些可能發生的問題，但卻選擇不說出口而且不提供建議。在這樣的環境中，這些人同樣該為「因不行動而產生的失敗」受到責備。

  真正的事實是，管理者與領導者需要倚賴他人提供的意見做出決定——或者至少他們應該這麼做。因此，幫忙辨別問題就是身為產品製作美術設計者的責任。採取積極的步驟去發現問題，遠有利於已成事實後才對問題做出反應。

  然而，指出問題是容易的，但管理者與領導者們應該會同意，只是說出某件事情有問題存在並不足夠。所謂「發現問題」的最關鍵要素，就是推薦合理且適宜的解決方案。對許多美術設計者來說，這也是最困難的一步。「你打算如何防止問題發生？採取你的替代方案有什麼好處與風險？這是一個合理適宜的計畫嗎？」這些對話，需要在你與你的決策者之間被揭露。

  另一項值得警惕的是在討論問題時的態度。有些人覺得他們可以選擇做個「誠實的人」或者做個「好人」。想像一下，在工作中可能有某個令人挫敗的個人或專業面問題，已經被忽略了很長一段時間，只因為「談論它會令人難受」。正如預期地，當人們不回應外界的輸入訊息時，會導致他們覺得唯一的選項就是「做個好人」，並且將問題忽略。

  但是，經常會被人們忽略的事實是，「誠實」與「好人」並不是互斥的觀念。你可以具有很好的專業才能，同時也是個誠實而且尊重別人的傢伙。當你與同儕、領導者或管理者討論問題時，「尊重」才是其中關鍵的要素。

  上面提到許多關於「問題」的事情，但必須澄清的是：問題與錯誤，與失敗並不相同。錯誤會發生在遊戲開發的許多面向中，它是被預期的，而且可以被理解為學習與實驗的常見實踐結果。然而，錯誤仍然帶有付出代價的重擔，最明顯的花費就是時間，時間的損失將可能對你視為重要的功能或素材造成直接衝擊。因此，身為一位優秀的美術設計者，你需要盡可能積極主動地與管理者或領導者進行溝通。

• 與其他人的溝通

  所謂的「其他人」，指的是「非美術設計者」。這裡要談論的是與其他部門的同儕，例如與程式設計或企畫設計之間的協同合作。

  

  （圖片來源：teachers.saschina.org）

  簡單來講，美術設計者應該使用不同的方法，從不同類型的團體中獲取資訊並且呈現給他們。根據 Keith 的經驗，每個團體與團體之間的互動，很容易會變得十分挫敗，而幾乎所有這樣的情況，都是源自於溝通上的問題。多數情況下，這樣的障礙並非只存在於某一方，而是雙方都沒能提供或取得他們真正需要的資訊。更直接地說，他們都未能「使他們的訊息迎合聽眾的喜好」，因而產生誤解。

  這樣講應該不會讓任何人意外：程式設計者往往比較喜歡詳細且精確的資訊；比較上來說，美術面的分析更加地捉摸不定且具有主觀性。因此在這兩個團體的溝通行為之間，往往需要更多的時間與更多的思考。有好幾次，Keith 都聽到程式設計者這樣下評論：「美術設計者不知道他們要的是什麼。」舉例來說，這種情景可能源自於再三重複或失敗的工具創造，或者各種功能的修改事項上。

  可理解的是，雙方都會因為這種情形而受挫。程式設計者受挫，是因為從他們的觀點來看，他們已經花費了時間建造出某些東西，結果竟然不可用或不是別人想要的；美術設計者受挫，是因為從他們的觀點來看，他們已經要求了某些東西，但程式設計者卻沒有交付出他們想要的成品。

  有些時候，美術設計者提出的需求太過於模糊不清，或易於被非美術設計者錯誤解譯，唯有清楚闡明你的目標才是更有效益的方式。為此 Keith 會經常性地鼓勵美術設計者提供參考範本，或某種形式的視覺化指示，藉此明確傳達什麼才是你想要達成的事情。這才是你如何澄清需求目標的好方法。

  另一項要點，是你如何提出你的需求。美術設計者常見的錯誤是問：「我們可以有Ｘ功能嗎？」透過這個問句，你已很有效地詢問某人一個「是或否」的問題，就像是在問他們是否想要做更多的工作一樣地有效。在這樣的情況下，你期望能夠得到什麼樣的答案回應？

  更有效的問題是問：「如果要實現Ｘ功能，需要什麼樣的代價？」代價或許是三天的時間，或許是更動的工作項目順序，也或許只是一個小時的功夫而已。關鍵在於這種類型的問題打開了對話，讓你知道實現某功能所需花費的代價為何。也許你所問的東西將會需要某些犧牲，也許你的要求會值得那項犧牲，但如果你不用正確的方式詢問的話，你就無法找出答案。

  就算沒有得到其他好處，程式設計者仍然能夠進一步瞭解你重視的事項的優先順序，有助於未來做出其他決定。程式設計者會很願意與美術設計者一同工作以協助支援他們想達到的目標——只要他們願意討論各種選項與替代方案。請不要再讓程式設計者說「美術設計者只是想要每一樣東西」了。

  對照來說，當美術設計者與企畫設計者進行溝通時，常見的卻是相反的情形。企畫設計者向美術設計者提出需求時，最尋常的原因是為了要支援遊戲性的變更。在 Keith 的經驗中，美術設計者時常會抱怨企畫設計者提出的需求太過於模糊，或不瞭解什麼是他們想要的東西。聽起來很熟悉嗎？

  然而我們需要瞭解的是，精確的企畫設計很難在開發過程的早期中達成，好的設計常常需要經過許多迭代與實驗的程序。因此，改變應該是在預期中的事情，同時美術設計者必須注意他們自己也是這個迭代程序中的一部份。

  舉個好例子，關於模糊的關卡設計指示，企畫設計者可能會說：「請把房間加大一點。」或者是：「你能不能夠增加更多的裝置物？」有些美術設計者，會直接採用這個模糊的指示並且做出變更，他們或許會抱怨指示太模糊，但卻沒有採取進一步的步驟去釐清這項資訊，最終結果就是雙方都可能必須要重新檢視這項需求數次。就像是與程式設計者溝通一樣，問題在於只有「功能需求」被闡述出來，卻遺漏了更重要的「功能目的」。

  Keith 的建議是：小心謹慎地，並且充滿尊敬地，詢問對方為何做出這樣的要求。也許企畫設計者想要一個更大的房間讓他們能加入更多的敵人，也許他們想要更多裝置物以創造出能讓玩家獲得掩護的地方。一旦瞭解目標之後，討論就可以專注於選擇或其他替代方案上，某些方法可能得以節省許多時間與精力，並且可以避免丟棄已經完成的素材與作品重新製作。

3. 多樣化 (Diversification)

所謂的「任務多樣化」，在此特別指的是美術設計者如何回應或應對廣泛類型的指派任務。美術設計者面對多樣化任務的方法，將會影響他們的職涯成長以及他們的技藝發展。

在 Keith 的經驗中，這個挑戰較常發生在後進的美術設計者們當中。在最糟的情境下，美術設計者可能會抱怨或拒絕做那些他們視為「不配他們做」的事情。通常有幾個原因會造成這樣的情形，但最常見的抱怨就是這些工作沒有創意、無法鼓舞人心或者是不夠吸引人。

我們可以很容易地識別出其中的自我意識元素——面臨這項挑戰的美術設計者，已經對工作採取了主觀的價值判斷。他們可能會以個人的喜好程度，來決定指派工作的價值高低；而問題在於，無論如何這項工作仍然需要由某人來完成。身為一位專業的美術設計者，不論你的個人喜好為何，你會被期望以相同等級的品質與投入程度，完成每一項交派的任務。

擁有個人喜好的心態是可以理解的。Keith 相信只有當每位美術設計者對他們的工作充滿熱忱時，他們才能夠交付出他們最佳的作品。具有爭議性地來說，美術設計者可能是對的，並且可能在意願較低的任務中，只能夠交付出品質較低的成品。高強的領導者能夠辨識出身邊的人的強處與弱點，因此多數管理者與領導者，會試著以這個思維模式去分配工作，但並不保證一定能夠如此。

應對這種工作項目的最佳方法，取決於你著手處理它們的態度。即使你可能無法對某些工作樂在其中，但它可能正代表著一次個人成長的機會：

（圖片來源：www.unf.edu）

• 技術性任務：有些美術設計者會推延技術性的工作，因為他們覺得這些任務會使他們與自己的創造力疏離。然而，技術性的工作，通常會讓美術設計者更加瞭解驅動整個遊戲的系統。此外，這種工作也能顯示出美術設計者是否能夠滿足於瞭解運作的細節。獲取更多技術限制的認識，也意味著你可以做出更好的決定，並且對於如何提升視覺品質提出更強而有力的建議。
• 組織性任務：安排工作時程以及對於工作小組的管理，幾乎是每位美術設計者都需要應對的事情。此外，業界外包的成長，也擴展了追蹤指導大量素材的需求。

  我們很容易可以理解，為什麼美術設計者會對於建造美術內容更有興趣，而不是去創造那些待追蹤內容的清單。但是，這種層級的計畫經驗，對於任何領導階層的職位來說都相當關鍵。如果你未來渴望指導專案中的美術面製作，那麼這些組織性任務將可以提供給你穩固的學習經驗，瞭解如何管理生產時程表中的重要元素。

• 團隊價值：能夠處理較多不同面向事務的美術設計者，對團隊來說更加具有價值，因為他們可以有更大的影響力。專注於某些項目的專業人才，對於專案來說很珍貴；然而，遊戲專案總是一直渴求能夠在不同面向領域中解決問題的人才。如果你能夠協助解決團隊中的大小問題，你就會成為更不可或缺的團隊成員。

總結來說，這篇文章只是概略性地提出了給美術設計者的三項專業指導準則，事實上還有許許多多可以被討論的議題，但以上三點肯定是其中最重要的項目。這些事情對於每一位美術設計者來說，都是一項嚴格的考驗，而對於那些有興趣想成為美術設計者的人來說，這些都是以後你將會遭遇，並且應該謹記於心的事情。

這篇文章所提到的準則，不只是對遊戲美術設計者有很大的助益而已，我想就算是企畫設計者或程式設計者，也能夠從中學到許多正確的待人處事觀念，以及與美術設計者之間的溝通要訣。看完文章後，你有什麼心得感想或其他的想法嗎？不論你是不是遊戲美術設計者，都歡迎加入討論，提出更多不同的想法與意見！

（圖片來源：diplomaguide.com）

原文出處：So You Want To Be A Producer

「遊戲製作人」(Game Producer)，或許你曾聽過這個高貴的職稱，或許你心中有幾位崇拜的業界典範，或許你從小就立下志向想成為一位遊戲製作人。但是，你真的知道什麼是「遊戲製作人」嗎？

製作，是個有點過於廣泛而籠統的詞彙，也使得「製作人」職位蒙上了一種神秘的色彩。在遊戲開發過程中，程式設計者不斷製作程式碼，美術設計者不斷製作圖片與模型，企畫設計者則不斷製作規則、數值與文件。在這樣分工明確、三足鼎立的研發團隊中，製作人究竟扮演著什麼樣的角色？是肉盾坦克、控場輔助、看護療癒、傷害輸出者，或者只是個可有可無的尷尬角色？

讓我們先回頭想想，遊戲界裡的幾位大師級遊戲製作人，像是製作《模擬城市》系列的 Will Wright，製作《潛龍諜影》系列的小島秀夫，以及製作許多任天堂經典作品的宮本茂，他們是不是成天坐在自己舒適寬敞的辦公室裡，憑空想像出遊戲的各種設計與創意玩法，然後豪爽地說聲「去吧！」就把自己天馬行空想出來的好主意交給底下的人，進而製作出一款又一款經典遊戲作品的那種人？

到底應該如何定義「遊戲製作人」？更進一步來說，遊戲製作人的職責與任務為何？如果你是嚮往遊戲業界的學生，你可能想瞭解要成為遊戲製作人必須具備哪些專業技能與個人特質；如果你是身處遊戲業界的遊戲人，心裡可能已經有一套對於遊戲製作人角色的定見。不論你對遊戲製作人的認識有多少，藉由這篇文章，作者將帶領我們一窺遊戲製作人在開發過程中所需承擔的各項職責與任務。

Producer 〈名詞〉

1. 能夠成為遊戲發行商與遊戲開發團隊之間的聯繫橋樑的人
2. 製造煤氣的熔礦爐

英文的 Producer 具有兩種截然不同的意義，如果你想要知道熔礦爐是怎麼製造出煤氣的話，你肯定是走錯地方了。而如果你想要學習成為遊戲製作人的各種基礎概念的話，請繼續往下讀吧！

從遊戲公司的徵才資訊來看，遊戲製作人的職位，範圍廣從入門等級的助理製作人職位、聯合製作人、資深製作人、線上製作人、研發指導製作人、內部製作人、外部製作人，到管理階層的製作人等等。無論你想要成為哪一種類型的製作人，首先你必須確認自己是否擁有正確的專業技能。

在學生時代時，你是不是會使用分類文件夾妥善組織讀書計畫的那種小孩？你是不是個有計畫、喜歡排定時程，並且會指揮與朋友間的遊戲比賽的那種人？有時候，這個世界的其他人可能會因為你的「指揮者態度」而感到有些困擾，但這些正是能夠使你成為明星遊戲製作人的重要特徵。因為實際上，每一位能夠勝任遊戲製作人職位的人，都需要具備下列這些屬性：

• 優秀的時程安排能力。
• 極佳的組織技巧。
• 傑出的領導力與建立共識的能力
• 從頭至尾指揮專案的開發，使其能夠在期限內完成的能力。

身為一位遊戲製作人，你必須要熟知如何善用 Microsoft Project、Word 與 Excel，以及一些尋常可見的腳本語言。同時，你也必須熟知最新的遊戲系統。而且一般來說，你應該要是一位熱愛遊戲的玩家。

對於想要應徵遊戲製作人職務的人來說，撰寫出組織良好的履歷表是一項必要的條件。如果連一份簡單的履歷表都無法寫得好，又如何能夠妥善組織錯綜複雜的遊戲開發程序？另外，在期限內完成專案以及注重事物的細節，對遊戲製作人來說都是至關緊要的特質，所以如果你要去遊戲公司進行面試的話，請確認你會準時到達！

除此之外，如果你想成為一位遊戲製作人，更需要仔細瞭解製作人工作中的每一項基礎，包括如何發展最初的遊戲概念，以及如何向管理階層推銷你的想法。直到遊戲進入組裝廠壓片裝盒為止，遊戲製作人都必須親身參與遊戲開發過程中的每一個面向。

魔鬼全在細節中

對於遊戲製作人來說，以紮實穩固的根基啟始遊戲專案，是一件很重要的事情。在面對如遊戲開發這樣需要創造力的工作時，所謂的穩固根基，就是本質上在你的內心所感受到的願景，或者是能夠成為專案靈魂的那份主體概念。這個願景將會成為一股驅動與刺激的力量，協助你以及你的團隊，度過許多難以成眠的夜晚與現實世界的限制，並且將其實現。

身為製作人，你最初的任務有兩個面向：第一，概念化或者辨認出你所相信的遊戲概念。第二，將這些想法推銷給上頭的管理階層。毫無疑問地，你將會被要求將你的遊戲概念當作一個商業上的良機，呈現給上位的決策者或擁有資金的投資者。因為唯有如此，才能夠使你得到足以開發遊戲概念原型的資金。

下一步，則該評估你的開發團隊。無論你是在尋找一個團隊投身實現你的遊戲概念，或者是在尋找一個持有引人入勝想法的團隊，徹底地評估每一位開發者以及整個團隊，都是一項不可輕視的重要事務。把它想像成一個面試程序，你必須確認每位成員都具備正確的處事態度與專業技能。因為開發團隊所扮演的角色，和願景本身具有相同的重要性，因為唯有優秀的團隊才能夠克服重重險阻，將「腦袋中的願景」化為「現實中的成品」。

花費時間與團隊以及團隊中的個別成員相處，同樣也是相當重要的要務。瞭解每一位成員的長處與短處，瞭解驅動他們前進的力量是什麼，以及他們如何在一起共同工作。當你逐漸瞭解團隊以後，就能夠以此評估出專案的潛在風險。更重要的是，觀察團隊是否對專案的目標遠景懷有熱忱，以及是否擁有足夠的技能得以執行任務。另外，技術層面的考量同樣具有重大意義；例如，團隊是否有能力使用既存的遊戲引擎來開發遊戲？他們是否已經具備充足的開發工具？

這個階段的關鍵，在於定義團隊中的各個角色，包括遊戲製作人自己。良好的溝通並不只是基本事務而已，而是遠比基本事務更重要的事情。每一位團隊成員都應該對於誰負責什麼項目，以及誰有權做出決定，有非常清楚的認知。打從一開始就討論這項議題，並且使所有人都清楚瞭解，將有助於預防在專案開發過程中可能發生的衝突情形。

前製時期：企畫設計、技術設計，以及可玩的遊戲原型

在遊戲開發的預算數字日益升高的情況下，通常最好在啟動完整的遊戲開發程序之前，先進行一至兩次前製階段的執行程序。在這些階段中，完整的遊戲設計、技術設計，以及在目標平台上的可玩遊戲原型都應該被完成，並且以這些前製的成果，共同定義及證明遊戲中的基礎遊戲性、角色動作與基底技術。

在前製開發階段中，不僅可以給遊戲製作人一個機會，觀察你的開發團隊是否真正瞭解這款遊戲的願景，你也將從中習得開發團隊如何共同分工合作，並以此評估團隊是否能在預期的時限內完成專案，以及你目標內的開發預算與開發時程是否符合實際現況。為了達到這項目標，你必須開發每個月的專案里程碑，藉此追蹤專案的開發進度，並且瞭解團隊如何回應這些里程碑的目標。

訂定里程碑文件的目的，並非為了製作出詳盡的遊戲建造藍圖，而是為了提供結構與方法以量測開發程序的成效。對於每一個里程碑，必須考慮以下各項定義：目標、企畫設計工作、程式設計工作、美術設計工作、音樂設計工作、整合測試、風險評估、到期日，以及完成後所需付出的預算等等許多項目。

另外，工具開發與核心引擎技術研發，也應該被納入里程碑的時程中。重要的核心遊戲性功能與相關的技術，同樣必須在早期的里程碑時程中被處理；例如，在一個平台動作類型的遊戲中，早期證明基本的遊戲機制，如移動與遠距離跳躍動作，是非常重要的事情；必須先確認這些基礎的運作機制，遊戲關卡才有辦法依此功能特徵開始進行建造工作。

最後，關於製作遊戲的試玩版、電玩展的用展示版、市場行銷材料，以及每年的假期與感冒季節等等，都是經常會被忽略，但應該好好納入專案時程考量的要素。一旦完成遊戲的前製階段，並且通過管理者與執行團隊的檢驗之後，雖然還有一座高山需要攀越，但你與你的團隊至少已經到達關鍵的高原區了。

（圖片來源：www.young-germany.de）

完整開發時期

當專案來到這裡，你的遊戲正處於完整開發時期。遊戲的靈魂已精神抖擻，遊戲的框架已準備就緒，現在正是開始動手執行的時刻了！然而正如我們所知，並不是所有的事情都能夠一如預期地順利執行。遊戲製作人的角色，就是要成為這段期間裡的力量支柱，幫助團隊度過每一段無可避免的風暴。

與團隊建立良好且頻繁的溝通，將會是你最重大的資產。更重要的是，要讓你的團隊知道你會「為了他們而在」，以及確保資訊能夠盡可能客觀地被連結呈現出來。即使是過度的溝通，也比完全不溝通來得好。請記得這個世界並不是個客觀的存在體，而是端視人們怎麼看待它。身為遊戲製作人，你看待世界的方法毫無疑問地將會與你的團隊中的成員有所不同，特別是當你必須同時與極為「左腦導向」與極為「右腦導向」的兩種人應對來往時。

關於專案時程的里程碑，即使可交付的里程碑目標通常都是以月做為單位，但是你最好經常性地每週追蹤任務的進度。如果你正與外部的開發團隊共同進行工作，可以考慮在週一時詢問他們本週的預定目標，然後在週五時檢閱本週的進度。如果團隊的進度落後了，請立即找出問題的根源所在。盡可能鼓勵團隊多花一點額外的時間補足目前落後的進度，而不要在快到達里程碑期限之前，才開始像是燃燒生命般地瘋狂加班。

在專案開發期間，請帶著急迫感回應開發者們的需求。不論是開發者所需使用的硬體配備，或是對於專案里程碑的意見回饋等等，請將他們所發出來的聲音，視為必須即刻處理的燙手山芋。你的開發者通常會焦急地等待著你的領導與回饋，所以你最好可以很迅速地釋放他們的壓力，才能夠使整個團隊保持備受激勵與快樂的狀態。

讓團隊快樂：好的、壞的或醜的

在遊戲專案的執行時期中，你需要使「團隊」——這個瞭解你的願景並且活生生、會呼吸、有機的生命體——感到快樂。以下是幾點建議事項：

• 讚美：如果在應得的時候真誠地給予，讚美會有很長遠的影響，特別是當團隊或個人做出了超越職責的工作之後。這些正向的回饋，會讓團隊或個人知道怎樣的表現才是你所想見到的成果，而且他們通常都會以更多相同的事物回應，因而形成一種良好的正向循環。
• 透過開放式溝通以解決衝突：衝突，經常是溝通錯誤或缺乏溝通的一種徵兆。舉例來說，有可能是主程式設計者被一項剛定案的設計決定激怒，特別是當專案逼近結束期時，他可能不會再壓抑心裡的各種感覺而一口氣爆發出來。不被衝突本身纏住而迅速地找到衝突發生的根源，讓事情不會逐步擴大升高，是一件非常重要的事情。做為一位製作人，需要找出具有創意或心理學的方法來解決衝突。或許你需要給程式設計者一天的假期，讓他休息以回復狀態（我舉雙手贊成！XD）；或許最好是將企畫設計者與程式設計者聚集在一起，坦承佈公地討論這些議題。
• 加入市場分析、公共關係與行銷人員：在整個專案的開發過程中，將這三個團體視為你的盟軍是很關鍵的事情。市場分析人員能夠協助提供市場研究資訊，並且藉由焦點測試蒐集許多玩家資料，而銷售人員則能夠提供寶貴的第一線回饋訊息。身為遊戲製作人，最好能夠教育他們透過你的觀點來看待遊戲中的各種面向，同時也要將他們對於遊戲的意見納入考量。他們越加熟悉遊戲，同時你也越加重視他們的意見，遊戲產品成功的機率就會越高。

最終開發時期：封閉測試、開放測試，最後的里程碑

當遊戲專案到達了這個階段，毫無疑問地你必須放手，將一些在專案啟始時覺得很棒的想法捨棄。理想上來說，專案里程碑必須將那些不屬於遊戲核心元素的東西，排到更後面的順序。

在開發的最終階段，好好照顧你的團隊更是一件特別重要的事情。在最終的測試期間裡，將會是一段非常艱苦的時間；遊戲臭蟲源源不絕地冒出來，其中有些臭蟲似乎不可能找到合理的方法修復，而程式設計者也可能正對於某部分的程式碼感到焦慮不安。身為遊戲製作人，這是一場你必須帶領他們共同度過的風暴。

請用盡一切可能的辦法。例如，向技術指導人員諮詢以解決技術層面的問題；給予你的團隊關心，推心置腹地瞭解他們缺少什麼與想要什麼。「不論任何代價也要解決問題」，是你在這個階段中必須奉行的座右銘。

通過考驗

最後，不論是在內部或外部測試期間，遊戲製作人都需要定義回報遊戲臭蟲的方法與流程。開發者會希望盡早得到關於臭蟲的報告，而不是非得經過漫長的等待才能得知測試後的結果。藉由建立出適當的處理程序，例如一個線上臭蟲回報資料庫系統，就可以幫助你的團隊減輕負擔。

製作人應該要檢閱臭蟲的報告，並且在指派給開發者之前先行過濾臭蟲。臭蟲報告必須要結構良好並且易於閱讀，臭蟲的敘述也應該要清楚又精確，如此才能夠避免指派多餘或重複的臭蟲給開發者。你一定要瞭解哪些臭蟲很重要且必須修復，而哪些又是基於時間與理性因素，必須放手讓它走的臭蟲。抗拒要求遊戲一定要達到完美程度的誘惑，並接受使其達到優秀的程度吧！

經過漫長的測試與考驗，當遊戲送廠壓片，專案告一段落後，記得舉行慶祝會！讓你自己和團隊有機會感謝這段期間以來的辛苦工作，並且感激我們能夠在此做著我們熱愛的工作！

（圖片來源：www.asiaarts.ucla.edu）

看完以上對於遊戲製作人的工作職責簡介後，你是否更加瞭解該如何扮演開發團隊中的領導人物了？有些讀者或許會覺得遊戲製作人，好像只是個高高在上、不容侵犯，只負責出一張嘴交代工作的人。事實上，遊戲製作人除了必須發展初期的遊戲概念以外，更需要監督專案的執行成效、協調各部門的事項、做出關鍵的設計決策，同時也要懂得信任團隊中的成員。

從這篇文章的內容與我個人的業界經歷來說，我心目中的理想遊戲製作人形象，應該是個使用「耳朵」更勝於「嘴巴」的角色。溝通，是一項說來容易，執行上卻困難異常的事情。我認為溝通並不是從「說話」開始，而應該以「聆聽」做為起點。有句諺語說：「當你知道如何聆聽，每個人都是你的導師。」我想就是這樣的意思吧。

製作商業遊戲，是一件很艱苦，甚至會使人非常痛苦的事情。以開發一款 MMO 線上遊戲來說，一般情形下至少需要花費 2 至 3 年的開發時期，30 人以上的研發團隊規模。在這段漫長的完整開發階段裡，研發團隊需要每天 8 個小時沈浸在專案當中，剛開始時，多數成員都會處於鬥志高昂、興趣盎然的狀態，然而隨著專案的推移，難以避免地將會逐漸開始產生疲乏的感覺。更甚者，如果專案中發生了進度延宕、設計變更或溝通衝突等問題，未獲得妥善解決而日積月累之後，往往會嚴重侵蝕團隊的士氣，造成非常負面的後果。

以客觀理性的角度來說，身為受雇於公司的工作者，只要每月領到薪水，就應該認真地把上頭交付的工作做好。然而，如果遊戲製作人或管理者，只是把團隊成員當作機器一樣，認為只要輸入指令，就可以得到分毫不差的結果，不會有任何失誤的話，恐怕就太過於高估了人類的不確定性。我們並不是機械人，所以我們會有情緒起伏，有各自的工作態度，也有各自的人生目標。如果團隊成員無法感受到公司或領導者對他們的關心，那他們又怎麼會關心公司的前途，或甚至是遊戲的品質？

所謂的「團隊」，其實就像是「人」一樣，需要被鼓勵、需要被鞭策、需要被刺激，也需要被教育。遊戲製作人，身為團隊中的領導者，則像是引領羊群的牧羊人一樣，你不可能期待團隊中的每個人，每次都能夠平安順利地回到羊圈裡。他們需要你的指引，才不會走上歧路險途；他們需要你的信任，才能夠發揮出百分之百的戰力。我想，這些困難的事情，就是遊戲製作人真正的使命與職責所在吧。

不論你的專業領域是企畫設計者、美術設計者或程式設計者，同樣可以朝著「遊戲製作人」這項目標努力前進。只要時常抱持著積極開放的心胸與學習態度，多多結交不同專業領域的同事朋友，即使面對未知的挑戰也願意勇敢嘗試的話，相信將來你也能夠成為一位令人景仰的遊戲製作人！

你認為一位稱職的遊戲製作人，需要什麼樣的個人特質或專業技能？歡迎各位提出自己的觀點一起討論～ ^_^

（圖片來源：potq.cl）

標題壞掉了？沒壞，就是 12345。

從 2004 年 4 月踏入遊戲業界開始，到現在 2009 年 4 月為止，已經滿 5 年整了。說起來就像是算算數一樣，用完一隻手的五根指頭 12345 剛剛好，但卻又不是像算算數一樣簡單的 12345。

五年，代表著什麼樣的意義？有人說，在一個行業裡持續工作滿五年的時間，表示你正式從菜鳥的行列中畢業了，雖然還稱不上是功力深厚的老手，但至少也是個具有一定裝備等級的「中手」。最近這段時間以來，幾次試著動筆想為自己的五年下些註解，卻不知從何開始。回首來時路，在這五年的光陰裡，雖然經歷過大大中中小小數個不同的遊戲專案，但竟沒半個能夠稍微拿來說嘴，或者能夠引以為傲的遊戲作品，想來真是有些令人沮喪。

所以我害怕，也不害怕。

我很害怕，害怕自己在歷盡風霜的面容中，已經遺忘了最初擁有的熱情；害怕自己在現實生活的壓力下，已經拋棄了最初緊握的堅持；害怕在接下來的五年內，還是做著差不多的工作、領著差不多的薪水、寫著差不多的遊戲，然後就這樣過完差不多的人生。翻轉到硬幣的另一面，我不害怕；即使前方的道路誨暗不明，即使身處險惡嚴峻的環境之中，即使所有人都說這條路沒有前途，我不會害怕。

And all the roads we have to walk are winding.
And all the lights that lead us there are blinding.

不懼且懼。反覆咀嚼著這兩句歌詞，別有一番滋味。

五年前，當我懷著滿腔熱血進入遊戲界時，是國產單機遊戲最衰弱的黃昏期，網路遊戲是新興的強盛勢力，幾乎所有的遊戲公司與許多從來沒做過遊戲的公司，都急著想跳下去分食市場。在那個年代裡，線上遊戲的競爭者還不是很多，只要代理到一款正確的遊戲作品，幾乎就可以養活一整間遊戲公司好幾年。

很快地，打著免費制口號的線上遊戲，開始大舉侵略月費制線上遊戲的市場，除了超大型強作之外，幾乎所有遊戲都改投向免費遊戲的陣營。除此之外，遊戲的類型越來越豐富而多樣化，也逐漸地由技術門檻較高的萬人同時在線模式，演化出「開房間」或「下副本」等技術門檻較低的遊戲機制與類型。

線上遊戲就像是從前的單機遊戲市場一樣，一款接著一款地問世，每個月都有許許多多新的遊戲、新的資料片或新的廣告活動。然而，打著免費旗號的商城制線上遊戲，已經漸漸地顯露出了疲態，玩家們對於換湯不換藥的線上遊戲，感到厭煩的速度也越來越快。線上遊戲需要「新玩意兒」，不論是新的收費模式、新的遊戲機制或者新的樂趣技術。但沒有人敢踏出第一步，所有人都在等待先驅者的降臨。

如果從另一個角度思考，除了線上遊戲以外，還有沒有其他的可能性存在？大型遊戲機台、數位下載服務平台、手持式遊樂器平台、野心勃勃的 iPhone 平台……，我們還要錯過多少台灣以外的世界？市場可以借鏡，技術可以模仿，但文化無法複製。我們在存活下來之後，是否應該花費更多的心力在別人無法輕易複製的獨特優勢上？

包含電腦遊戲與遊樂器平台遊戲在內，電子遊戲的發展歷史並不很長，比起其他娛樂媒介，電子遊戲像是個正逢青春期的毛頭小鬼，一下子往東跑，一下子又衝向西，雖然擁有備受期待的巨大潛力，但也十分令人捉摸不定。我很敬佩那些知名的遊戲製作人，以及更多籍籍無名的遊戲開發者，心甘情願投身於遊戲界奮鬥打拼十年、二十年，甚至是更久更久的時間。我想，他們一定很愛很愛「它」，才能夠和它在一起這麼長的時間吧。

回過頭來問自己：我能夠愛它這麼長這麼久，保證永遠不會變心嗎？現在的我無法回答。但我選擇了這條路，至少到目前為止還沒有後悔過，也從來不會覺得特別辛苦。能夠打從一開始，就得以從事自己熱愛的工作，我認為這已經是一件非常非常幸福的事情了。職業無分高低貴賤，差別只在於熱情與用心程度罷了。

（圖片來源：www.zmemusic.com）

除了埋首撰寫程式碼，以及參與遊戲製作的歡樂時光以外，工作中也常需要面對許多明知不合理，但卻無能為力改變的事情。因此，偶爾我也會感到沮喪、不平甚至憤怒，即使看起來有些負面，但這些情緒有其獨特的價值存在：正因為我關心在乎，所以我有情緒。

如果哪天我變成了冷漠的「社會化完成體」，只是成天將「沒辦法，這就是現實」這句話掛在嘴邊時，或許我已經成為一位真正的「大人」，可是也失去曾經擁有的寶貴特質了。如果你也有相同的心情感受，請化憤怒為力量，時時保持氣（熱）血通暢，不要讓自己成為麻木不仁的傢伙！

某本書裡提到，要在特定專業領域中成為出類拔萃的傑出人物，至少需要經過一萬小時的努力、練習與累積。一萬小時，約略等同於十年的時間。嘿，原來我才正好在「半路」上而已，再回頭想想之前那些比較消極的想法，現在似乎舒坦多了。

下一個五年，我會在哪裡？寫著些什麼樣的文章？與什麼樣的伙伴相處？做著些什麼樣的遊戲？老實說我並不清楚。但這個問題，不能就這樣輕易地交給五年後的自己來回答。我非常清楚，並不是現在什麼也不做，到了五年後我就會自動成為我想要的那種人。我要交由現在的自己，親筆寫下每一頁的歷史。

最後和各位分享兩篇我非常喜歡，而且讀來很有感觸的文章：

• HP大中華區總裁孫振耀退休九大感言
• 朱學恆：不當富翁，快樂做自己

勉勵各位，也勉勵自己。 ^_^

所謂的「多執行緒」程式設計，或者可簡稱為「多緒」程式設計，在英文中有許多相關的專業技術名詞，例如 Threading、Multithread、Concurrency、Parallel、Multicore 與 Multiprocessor 等等，在搜尋資料時可以嘗試不同的關鍵字，往往可以找到不少意料之外的好東西。而其中最常見的總括性簡稱，應該就是 Threading 了。

基礎定義

既然要學習 Threading 程式設計的知識，首先要瞭解的當然是 Threading 的基礎概念：

• Thread：看看 Wikipedia 裡的定義，至少把最前頭那段 Thread 的基本定義，以及 Thread 與 Process 的不同之處搞懂。簡單來說，執行緒是用來執行電腦程式的執行環境；而多執行緒，就是能夠使程式系統同時執行多個不同程式碼區段的一種技術。
• Thread Safety：雖然使用 Threading 技術能夠提升程式系統的執行效能，但伴隨而來的則是麻煩又難解的 Thread Safety 議題。大致上，我們可以使用 Re-entrancy、Mutual exclusion、Thread-local storage 以及 Atomic operations 這四種方法來達成安全使用多執行緒技術的目標。

教學文章

• C++ Multithreading Tutorial @ paulbridger.net：質量非常不錯的基礎教學文章，從 Race Condition、Mutex、Deadlock 到 Condition Variables 等等重要的基本概念，都有清楚易懂的文章教學與程式碼範例。
• Multithreading Tutorial @ Homepage of Mario Konrad：網站裡分成基礎、中間與進階三種等級的教學文章，可以看看 Socket 網路程式與 Producer-Consumer 的程式碼，應該會更加瞭解多執行緒技術的可運用之處。

跨平台函式庫

• Boost.Thread（連結為 1.38 版）：簡單易用且功能完備的跨平台函式庫。如果沒有使用過 Boost C++ Libraries，可以參照這篇文章的步驟來建置 Boost.Thread 函式庫。
• threadpool：以 Boost.Thread 為基礎，實做出一個非常好用的 Thread Pool 設計模式。

名家專區

• Intel: Parallel Programming and Multi-Core：因為 Intel 的本業是靠 CPU 吃飯的，所以自然相當注重多執行緒程式設計的議題，在這裡可以挖到不少質量兼具的優秀文章。
• MSDN: Parallel Computing：MSDN 中的平行計算處理專區，充滿文章、影片以及部落格等相關資源。
• DevX.com: Move to the Future with Multicore Code：有幾篇不錯的概念性文章，另外還有介紹如何使用 .NET 平台的 Task Parallel Library。
• Sutter’s Mill：Herb Sutter 大師的個人部落格。目前在 DDJ 雜誌上，有他每個月固定連載的 Effective Concurrency 專欄文章，適合進階高手服用。

投影片

微軟於 2007 年與 2008 時所舉辦的 Gamefest 開發者會議，其中有許多關於 Threading 的演講主題，內容非常豐富多樣且紮實，而且大部分課程都有投影片與錄音檔可供下載：

• Multi-Threaded Rendering for Games
• A Detailed Overview of Xbox 360 Direct3D Synchronization and Multithreading
• Introduction to the Direct3D 11 Graphics Pipeline
• Practical Parallel Rendering with DirectX 9 and 10, Windows PC Command Buffer Recording
• Multicore Programming, Two Years Later
• Magic and Technology: Migrating from One to Many Cores in Shadowrun

另外這篇是微軟於 GDC 2008 中開設的講座：

• GDC 2008: Getting More From Multicore

推薦文章

• Threading Basics for Games：概略簡介了遊戲所使用的基礎多緒程式架構。
• Threading the OGRE3D Render System：這篇文章闡述了三種能夠使 OGRE 繪圖引擎充分利用多緒能力的技術，並完整實作出其中一種方法，附源碼可供下載。
• Multithreading the Rendering Pipeline for 3D Model Animation：相對於 GPU 的強大運算能力，這篇文章試圖藉由多核心 CPU 的力量來達成 Skinning Animation 的功能。雖然目前這個作法的實用性不高，但是文章中的設計架構仍然非常值得參考學習，也有完整源碼可下載。
• Designing the Framework of a Parallel Game Engine：相當夠份量而且完整的好文章！著重於設計概念與流程架構，沒有提供任何程式碼範例。

書籍文章

關於書籍中的文章，我推薦《Game Programming Gems 7》中的「Design and Implementation of a Multi-Platform Threading Engine」與「Multithread Job and Dependency System」這兩篇文章。前者實作出了一個可跨平台的 Threading 引擎架構，後者則著重於更加複雜的任務相依系統上，兩篇文章各有擅場，而且都有完整的程式源碼可供讀者仔細研究！

如果有其他關於遊戲 Threading 程式設計的資源，隨時歡迎各位的回應與補充喔～ ：D

（圖片來源：www.codinghorror.com）

原文出處：Physics in Games: A New Gameplay Frontier

截至目前為止，在猴子靈藥中從未探討過與遊戲物理學相關的課題，主要原因是我以前從未接觸過任何物理引擎或物理面向的應用程式，所以相當缺乏對於遊戲物理學的概念與知識。讀完這篇文章以後，我總算是開了眼界，對物理學有了一番新的體悟，也開始能夠想像如何在遊戲中的運用各種物理學的觀念。所以我希望藉由分享原作者所寫的這篇文章，讓大家都能認識並且開始思考遊戲物理學的設計應用。

如許多老玩家所知，在遊戲中使用物理學，並不是什麼新鮮的事情。事實上在許多年代久遠的老遊戲，譬如《Lunar Lander》與《Marble Madness》中，已經充滿許多與「重力」這項物理特性互動的遊戲性。隨著時代的推移演進，今日我們所擁有的嶄新技術方案，使遊戲開發者能夠將更進階而且更新穎的物理學特性運用於遊戲之中。

物理學處理程序對電腦運算能力的要求非常高，所幸拜核心數目越來越多的中央處理器，以及專門的硬體加速卡誕生所賜，身為遊戲開發者，現在我們可以真正深入考量如何在遊戲中緊密結合物理學的使用。而真正的問題所在，是我們該利用這些新的資源來做些什麼事情？直到目前為止，遊戲中所使用的物理學大多侷限於裝飾性的效果，雖然這些效果能帶給玩家很重要的沈浸感受，但卻無法真正改變現有的遊戲性。

當我們瞭解物理學在遊戲性中各種應用的可能性以後，我們又該如何提供給玩家與物理學相關的全新體驗？本文的目的就是為了回答這些問題，同時作者也分享了他從設計多人連線地圖模組 CTF-Tornado 中所學習到的經驗。（CTF-Tornado 是在《Unreal Tournament 3》中，被設計來充分發揮 Ageia 物理加速卡優勢的地圖。）

首先讓我們從一些物理學的基礎定義開始吧。物理學的範疇並非僅侷限於模擬重力或者物體與物體間的碰撞行為，實際上物理學也包含了以下這些應用：

• 流體力學，包括液態與氣態。
• 扭曲形變，包括柔軟物體或者剛硬物體。
• 摩擦力與黏力的行為模擬。
• 改變物質的狀態，例如水由液態變成固態的過程。
• 材質的破壞。

由此可知，物理學涵蓋了相當廣泛的內容，而其中有些理論仍未實際被應用於遊戲之中。因此我們可以預期，物理學的發展潛力非常龐大，但遊戲開發者所面臨的各項議題也十分具有挑戰性。隨著開發者在遊戲中使用物理學而產生出來的難題，主要可以分為以下四個項目：

• 對電腦運算能力的需求。
• 更多物理學以外的處理程序。
• 多人連線遊戲中的挑戰。
• 在既存劇本與物理學混沌本質間的不相容性。

讓我們更進一步仔細地檢視每一個項目。

對電腦運算能力的需求

首先必須具備的認知是，處理物理學需要龐大的運算能力。由此可知，儘管市場上已經有像 Havok 這樣非常優秀的物理引擎存在好幾年了，但物理學仍沒有被廣泛應用於遊戲中，並不是個令人意外的結果。

在目前的遊戲作品中，只有非常少量的 CPU 能力，約佔單個核心的 10% 至 25% 左右，是分配給物理學處理程序使用的運算資源；但就現實面來說，處理物理學的邏輯需要相當可觀的運算資源。讓我們來看個最簡單的碰撞處理範例：

每一個動態物件的移動行為，都是被許多參數（移動方向、速度以及多軸向旋轉等）所控制，必須要在每一張畫面顯示之前被重新計算出來。而除了動態物體本身的參數之外，這些動態物件之間的互動行為也必須被計算出來。假設有 10 個動態物件需要處理，就需要進行 55 次的檢測處理程序，20 個動態物件需要 210 次檢測程序，而 30 個動態物件則需要 465 次檢測程序！

我們有兩個技術方案可以解決這個問題：

• 多核心 CPU 世代的來臨，將帶給我們非常大量的運算能力。雖然雙核心 CPU 仍不足以產生顯著的影響力，不過從四核心開始，將會開始帶來物理學應用所需要的運算能力。但是四核心的 CPU 是否真的足夠？我們無法確定。因為遊戲引擎與繪圖引擎對於硬體能力的需求，同樣也在不斷地增長當中。
• 第二個方法是使用專門的物理加速卡，例如由 Ageia 公司製造的產品。（註：Ageia 已於 2008 年 2 月被 NVIDIA 公司收購）

（圖片來源：www.shbear.com）

更多物理學以外的處理程序

使用物理學使得遊戲關卡中所需的路徑搜尋演算法更加複雜。事實上，這個演算法必須要能夠適應不斷發生變化的環境：如果一個巨大的石塊掉下來擋在路中間，遊戲中的人工智慧必須將這項突如其來的環境變動納入邏輯思考程序，才有辦法使由 AI 控制的角色繞過這些物件或者使用它來當作掩蔽物。

另外，場景中的光源和影子也必須以動態的形式製作。因為如果物件會移動，或者牆壁會被摧毀，我們就無法使用預先計算完成的光影效果，因此動態光源的使用會變成遊戲的基本需求。或許我們可以選擇採用對比度較低的場景以避免光影失真的問題，但是地圖場景的繪圖品質也會因此而犧牲。

多人連線遊戲中的挑戰

從遊戲性的觀點來看，在多人遊戲中使用物理學，允許玩家們能夠動態變更遊戲場景的拓樸結構，將會帶來非常有意思的遊戲樂趣。然而與單人遊戲相比，多人連線遊戲會因為網路頻寬及延遲的因素產生限制。所以在多人連線遊戲中使用物理學的難題，就是在於必須同步化所有會對遊戲性產生直接影響的事件。

在大多數遊戲中，通常只會對玩家的位置以及它們的投射物體進行同步化程序。但如果物理學會對遊戲性產生影響的話，代表所有的物理事件，例如具物理屬性的物件、可能遮蔽玩家視線的粒子群，或者是損害區域等等都應該要被同步化。其中有些程式設計面向的技巧，可以用來解決部分網路延遲所產生的問題。因此，如果要在多人連線遊戲中加入物理學的功能，設計者就必須打從一開始就將這些限制因素納入考量，並且約束進行同步化程序的物件數量最大值。

在既存劇本與物理學混沌本質間的不相容性

所有遊戲作品的目標，都是為了提供給玩家最佳的感知娛樂體驗。但由於遊戲開發經費有限，多數遊戲提供的都是線性式的遊戲關卡設計，確保玩家在滿足某種條件後，會在某個特定的時間地點，看見某些特殊效果、過場動畫以及按腳本進行的戰鬥場面。線性化的關卡設計使遊戲開發者能夠良好地控制遊戲的節奏，能夠充分避免玩家隨處閒晃而開始覺得無趣。

在這樣的前提下，使用物理學可能會發生許多關卡設計者原先所沒有預測到的情形，這也就是所謂的「應變式遊戲性」(emergent gameplay)。這種類型的遊戲性，通常很受到玩家們的歡迎與喜愛，但如果玩家利用物理學的功能來改變關卡中的拓樸結構，藉此阻擋對手的移動路徑，也可能會因此擾亂了 AI 的運作程序，甚至使得原先安排好的過關道具消失不見等等，各種物理學的元素都會增加遊戲設計層面的複雜度與困難度。

上述這些狀況同樣可能發生於多人連線的遊戲關卡中。因此，當作者在 CTF-Tornado 地圖中，設計了一個會阻礙玩家去路的「龍捲風」物體時，他們必須非常小心地考慮各種可能產生的問題。因為龍捲風的出現，不僅會破壞場景上的某些物體，也會直接妨礙玩家的行進路線，但同時也可以孕育出許多嶄新的戰略。為此他們決定增加地圖中的通道數量，並且讓玩家能夠使用 Impact Hammer 武器來擺脫移動路線中的阻礙物。

物理學除了可以提供主要的遊戲性機制以外，實際上最初是被拿來做為裝飾性的用途，像是遊戲物體爆裂飛散，或是遊戲角色受到衝擊力所做出的動作回饋反應等等。即使到了今日，仍然少有遊戲使用物理學來增進它們的遊戲性。因為大眾市場裡的一般遊戲，例如動作射擊類型的遊戲，對於電腦運算能力的需求已經非常高，所以如果在這些遊戲中使用物理學，將會對遊戲其他面向，譬如繪圖成像上的表現，造成強烈的衝擊。

當我們克服了上述四項難題之後，就可以大膽地說：「不論是哪一種類型的遊戲，現在都能夠更密集而且更深入地使用物理學了！」但問題是，我們該為了什麼目的使用物理學？大致上可以分成四類應用：

• 給予玩家新的方法處理他所面臨的挑戰。
• 創造機動式的遊戲環境。
• 發展強而有力的學習機制。
• 允許玩家建造自己的工具。

讓我們深入檢視這些應用項目。

給予玩家新的方法處理他所面臨的挑戰

對多數遊戲來說，遊戲性不外乎有兩項主要的出發點：第一，提供玩家一項需要克服的「挑戰」，像是擊倒一群敵人或通過關卡；第二，給予玩家一些「工具」，例如武器、動作或場景元素等，讓他們有機會獲得成功。而玩家玩遊戲的目的，就是學習如何精通這些工具，並且明智地使用它們來克服面前的挑戰。

如果從這個觀點來看，任何由遊戲設計者提供給玩家的新工具，都應該要使他們能夠達成這個目標。對物理學來說也是相同的道理，如果物理學無法提供新的方法讓玩家克服挑戰，那麼它將會在遊戲性的層面中完全失去意義。例如以動作類型的遊戲來說，主要的挑戰要素在於「戰鬥」以及「移動」。而物理學的應用，應該要提供給玩家新的工具，讓他們能夠達到以下這些目標：

• 削弱或消滅對手。
• 保護自己。
• 開啟或關閉通道。
• 偵測對手。
• 閃避對手。

一旦瞭解玩家的目的之後，立即就可以想出幾個可於遊戲中應用物理學的實例：

• 如果可以破壞場景中的元素，將使得玩家能夠佔據有利位置接近對手，建造掩蔽物以獲得保護，或是開啟新的通道與關閉現存的通路。
• 如果能夠運用流體力學，無論是液態或氣態的形式，都能夠提供全新的遊戲廣度。它們可以使玩家點燃火焰，或者讓風把火焰吹到正確的方向。而由玩家的行動所產生出來的煙霧，也可以削弱對手的視線，因而產生出許多全新的戰略性機會。

創造機動式的遊戲環境

現今多數遊戲的遊戲關卡都是全然靜態的形式，真正賦予遊戲關卡生命力的是其中的敵人對手。假設我們能夠使「遊戲環境」變成一位對手，或至少提供某些變動的狀態，是不是能夠讓遊戲變得更加多樣化而充滿驚喜？物理學能夠允許遊戲環境發生變動，以及隨之而來的各種影響效果，像是物件掉落、失去平衡、根據坡度來決定物體是否容易移動等等。其他譬如火災、地震、潮汐波浪、炸彈爆炸、海嘯火者是重力改變等等，也都是遊戲開發者可以設想的應用情境。

事實上，這就是作者的團隊在 CTF-Tornado 地圖裡所做的事情。其中的「龍捲風」就像是第三組團隊，藉由阻擋或者開啟數個可變動的通路，龍捲風得以動態改變關卡地圖的狀態，也可能因為被撕裂的牆壁與屋頂而使防守態勢產生變化，甚至還能夠使玩家發射的子彈偏離原本的軌跡。

（圖片來源：roleplayingpcgames.info）

發展強而有力的學習機制

遊戲本身就是一種學習過程。在動作射擊類型的遊戲中，藉由探索遊戲環境以及試驗各種不同的武器效果，我們學會如何在適當的時機選擇使用最合適的戰鬥方式。

物理學特別適合用於這種自學式的機制中，因為我們都知道它在真實世界中是如何地運作。我們出自本能地知道萬有引力與流體力學會影響潑灑出來的水，所以只要提供給玩家們仰賴物理學的遊戲機制，將能夠使他們學會如何找出複雜問題的答案。

允許玩家建造自己的工具

物理學的出現，使得扭曲破壞遊戲中的物件，例如裝甲、管線或橫樑變得可行。我們可以想像，如果玩家能夠依照自己的需求形塑出自己的武器、謎題的解答或者通過關卡的途徑，例如藉由扭曲某些金屬片，玩家可以建造出水渠或者球的通道等等，或許遊戲也可以變得更加有趣而多元化。

這種類型的物理學應用項目，或許只能夠運用在某些特別的遊戲，像是解謎類型的遊戲或者生存類型的遊戲中，而且操作介面也會有許多限制，但是遊戲潛在可能發展出來的樂趣非常龐大。如果可以讓玩家使用具有物理性質的磚瓦材料來建造東西，將能夠使玩家們建造出完全獨一無二的遊戲環境。

雖然在本篇文章中提到的某些想法，目前可能還沒有辦法達成，但是隨著可預期的科技發展與工具發明，未來將會賦予遊戲開發者全新的能力。從今以後，物理學不只可以運用在裝飾性的效果上，更能夠用來增進核心的遊戲性機制。而對於遊戲設計者與關卡設計者而言，也必須利用這些新技術帶給玩家更多新鮮有趣的娛樂體驗。物理學，使一切不可能變成可能。

自從 Ageia 被 NVIDIA 收購以後，「物理加速卡」就從消費市場上消失無蹤，改由效能突飛猛進的繪圖顯示卡提供物理引擎的硬體加速功能。當 ATI、NVIDIA 甚至 Intel 的顯示卡與顯示晶片，將物理引擎的硬體加速功能推向普羅大眾，成為每台電腦中的標準配備時，不論你是美術設計者、企畫設計者或程式設計者，我們都將會擁有全新的力量以及隨之而來的艱鉅挑戰。

以我在最近幾個月內玩過的幾款遊戲來說，我認為將物理學運用在主要的遊戲性機制上，並且得出十分出色成果的遊戲，包括之前提過的《World of Goo》、用蠟筆畫出謎題解答的《Crayon Physics Deluxe》，以及使用 Flash 製作的物理解謎遊戲《Fantastic Contraption》。從這些遊戲中，讓我們見識到即使是以 2D 畫面形式呈現的遊戲，同樣能夠充分應用各種物理學的理論知識，而且遊戲性也完全不會輸給 3D 形式的遊戲。

前一陣子如果各位有注意《Diablo 3》的展示影片的話，應該不難發現，物理引擎的功能將會在這款萬眾矚目的遊戲中，扮演舉足輕重的遊戲性機制。就讓我們一起思考也一起期待，物理學在遊戲中的應用與發展吧！除了上面提到的這幾款遊戲以外，你有玩過什麼令你印象深刻的物理學遊戲嗎？或者是曾經見過將物理學特性運用的很出色的實例？非常歡迎各位一起提出來討論唷～ ：D