程式加一點、企劃加一點、美術加一點，打成一杯美味的遊戲果汁

source: http://www.gameproducer.net/2006/05/07/2d-or-3d-graphics/ (原文翻譯於2006年在 GameDev.tw 發表)

在遊戲開發中最初階段有一個最基本的問題就是到底該用 2D 還是 3D 圖形介面。有些人認為應該使用 2D 因為 2D 比較簡單、容易或是其他什麼的特色，這對新手開發者來說比較容易上手。

在我看來， 2D 遊戲 並不比 3D 來的容易或是簡單。我認為不該為了 3D 而 3D。還是有許多好玩的遊戲只使用 2D 畫面的。如果遊戲中有大量的物件和函式，那麼 3D 圖形可能會拖慢遊戲的速度。大公司沒有開發很多 2D 的冒險遊戲還挺丟臉的(幸運的是，獨立開發者仍然持續在這方面努力)，我認為猴島系列和 Full Throttle (或是其他) 如果使用 2D 畫面 仍會很棒。

但是如果你要使用 3D 還是有些好理由的。我把一些列在底下：

-我認為 3D 的環境比 2D 的環境更容易讓你沈浸在遊戲的環境中。這純粹是素材本身的特性，這並不是說 2D 看起來就比較糟糕。這僅僅表示我喜愛三度空間的某些特性。

-3D 的物理特性讓你可以以很棒的方式來使用它。如果你需要一個球的模組可以朝任何方向滾動，那麼使用 3D 會讓實做這個特性簡單一些。在三度空間中，這是可能的，可是在 2D 中則不然。

-建立動畫比較簡單一些：如果你想要針對 2D 的角色建立十種不同的戰鬥方式，你必須做很多的美術動作來達成這個目標。並且調校動畫也需要很大的工作量。在 3D 中你可以只建立 mesh，加入骨架和讓角色動起來。如果動畫需要調校，3D 的調校起來比 2D 的要容易許多。

-視覺效果(透明度、鏡子…等)在 3D 中比較容易達成。有許多引擎都使用 3D 的效果來達成假的 2D … 他們都不是純的2D引擎，實際上，它們是 3D 引擎只是看起來像是 2D 引擎。

還有許多的原因讓我比較喜歡使用 3D ， 但是這並不代表你就必須從 3D 開始。2D 美術還是有生存的空間。 許多解謎遊戲和獨立製作的冒險遊戲都是使用 2D 的。你需要採用哪種決定端看你的需求和目標是什麼。如果你有很棒的 2D 技巧和經驗，那麼就這樣做吧。

source: http://www.gamasutra.com/features/20070301/schofield_01.shtml (原文發表於gamedev.tw)

極致軟體製程( Extreme Programming or XP)是一種敏捷開發的軟體開發方式，這種方式強調適應變化而非預測變化。XP 這個方法的威力是允許遊戲設計者在面對發行商、管理者和開發者本身所提出的多樣化(甚至是互相衝突)需求時，能夠可靠地製作出絕佳的遊戲

慣例告訴我們，如果一個團隊要面對許多人的要求，那麼符合某人的需要就難以顧及別人的需求。XP挑戰這個慣例，並且允許一個開發團隊可以製作出符合所有利害關係人(stakeholder)需求的高品質成品。

XP 可以更加可靠地製作出好的產品是因為它將其焦點放在快速釋出。快速釋出表示遊戲設計者可以看到優先實做的特色看起來像什麼樣子而不用等到整個大型系統被建 立起來才知道。這允許設計者可以更簡單地找出有趣的遊戲方式，並且 “調校”(steer) 遊戲的方向，讓它以最快的速度擁有更有趣的特色。

所以 XP 鼓勵設計者在開發的過程中去調校遊戲，並且可以改變更多遊戲的設計？這大概是所有程式設計師最不想聽到的了！ 如果你的軟體更改相當困難或是相當痛苦，那麼快速調校大概是你最不想做的一件事。但是現實是為了找到有趣的遊戲玩法，設計者必須隨著他對目前遊戲的了解改 變目前的方向。如果程式設計師的工作就是製作出一套絕佳的遊戲，那麼我們需要讓我們自己的程式可以擁有最大限度的調校彈性。極致軟體製程實際上專注在讓程 式設計師專心地快速製作出成品，並且保持專案的彈性。

這裡論上聽起來很棒，但是你現在一定開始好奇為什麼 XP可以允許專案如此容易地被調校？ 它使用相互支援的實踐方式來讓程式碼保持簡單和健康。簡單來說， XP 需要團隊列出特色的優先權，並且依照順序開始撰寫，實做這些特色唯一需要的就是撰寫程式，並且持續地套用小規模的改進來讓程式碼變得更健康。

這篇文章剩下的部份就是提供五個 XP 的關鍵實做元素的概觀，包含了： 測試導向開發(Test Driven Development)、共同撰寫(Pair Programming)、持續設計(Continuous Design)、真實客戶介入(Real Customer Involvement )和精力充沛的工作(Energized Work)。這些實踐方式，還有其他未被列在此處的實踐方式，允許團隊快速地產生可見的成品。可見的成品可以讓調校這款遊戲的設計師可以將遊戲導至正確的 方向。因為程式設計師撰寫時就保持程式碼的彈性，讓製作下一個循環的可見產品程式可以比較容易加入一些新的功能。

在你觀看這些實踐方式時，很重要的是記住 XP 並不只包含 自動單元測試()、每週四十小時工時()和共同撰寫。當然好的XP團隊這些特色都有，這些單純只是表示製作出好的產品。這就是XP-製作出絕佳的遊戲。

測試導向開發(2)

當實踐 測試導向開發(Test Driven Development)時，程式設計師撰寫小部的程式碼來描述他們希望這個新的特色如何在程式中如何運作。這一小部份的程式被稱作 單元測試，並且一開始這個測試會失敗，因為這個測試所需要的特色尚未被實做出來。程式設計師知道這特色將會隨著測試成功而完成。這種流程有許多好處，但是自動化的單元測試是其中最顯著的一種。

自動化單元測試是一種拿來驗證程式中每個小元素是否依照程式設計師的想法運作的測試。開發者可以簡單地運行這些測試來驗證他們所修改的程式碼是否有破壞已經時做好的功能。這些測試允許他們快速並且安全地修改這個專案的程式。

Regression 是開發團隊中最常遇到的潛伏性問題。在專案的早期只有少數的特色需要實做，但隨著專案的進行，越來越難讓所有的特色同時正常運作(甚至難以知道哪個功能是 正常運作的)。自動化測試給我們一個可以隨著功能成長的框架，這允許我們實做新的特色而不用擔心潛藏的 Regression。

TDD 另一個好處是幫助開發團隊感到開心，在隨著他們越來越接近最後成果的時候，以許多小量的成功(通過這些測試)來獎賞開發團隊。

共同撰寫3

共同撰寫是同時有兩個程式設計師使用同一台電腦來進行同一個程式編碼工作的流程。傳統來說，其中一位擔任駕駛的角色(像是打字或是決定哪些要輸入哪些程式碼)，而另一位則是領航員的角色。

領航員並不專注在駕駛可能犯的策略錯誤。他們反而專注在他們正在工作的內容上。他們會問一些像這樣的問題： ‘這些新的程式碼要如何跟舊的程式碼結合？’ 和 ‘是否有可能把我們剛剛修改過的程式碼變得更簡單或是再改的更棒？’

這兩位程式設計師所一起創造出來的程式碼的品質和簡單程度遠遠超過兩者分開各自撰寫的程式碼，因為分開的時候他們很少有機會去改進他們的程式碼。”兩個比一個好”這概念帶來更高品質的程式碼。這個高品質的程式碼比起一個人撰寫的程式馬來的更簡單和安全。

遊戲程式設計師常常做出小型設計的決定。這些決定可以讓遊戲變得更好(或是更難)玩。讓兩位有創造力的人腦力激盪數分鐘可以帶來極為優秀的結果。共同撰寫鼓勵他們快速地討論而不需要聚集大家或是打斷其他人來做個大型的討論，。

共同撰寫幫助這個團隊建立強固的程式碼，並且透過分享經驗、更多人與人之間的互動和減少因為卡住而導致的挫折感來讓這個團隊的氣氛更好。

持續設計4

持續性設計是保持軟體設計可以跟程式每天的需求保持一致的一項藝術。這表示除非程式需要泛用性，否則你不需要建立泛用的系統，但是你必須確保你為這個系統 所設計的簡單版本必須是良好的設計(well designed)。所寫的程式碼較短並不就一定表示這段程式走捷徑或是使用hack手法; 這僅僅表示你應該單單實做你需要的程式碼，因為當程式碼不那麼複雜的時候，程式碼才好容易修正實做方向。

持續設計的其中一個部份就是重構，重構是一種不改變程式的特色但使程式碼變得更健康的方式。隨著你越來越了解你的設計或是原本簡單的設計不再適用於日漸成長軟體的需求，你時常發現如果程式碼適當的更動會讓整個程式更為健康或是簡單。重構是我們讓程式碼保持彈性的方式。

持續設計帶來簡單的程式碼。越簡單的程式碼越容易了解，並且較不容易令人沮喪。這讓程式設計師感到滿足，有自信和安全，這些帶來一個快樂有活力的團隊。

真實顧客參與 5

簡單來說，真實顧客參與就是讓實際的玩家越早玩到遊戲越好。既然遊戲團隊的目標是可見的結果，那麼這方面就應該放到開發前期。這可以讓團隊決定哪個特色需要優先實做，並且調整更好的開發方向。

另一種這個概念的實做方式就是讓設計者跟程式設計師非常緊密地一起工做。這會讓程式設設計師的努力達到最高限度，並且在現實與理想中達到一個最佳的 平衡，讓設計師會說 “這在目前看起來夠好了。” 當程式設計師努力在提供可見的成果時，設計師可以提供某方面是否有趣的意見或是他們可以一起找出哪部份一點也不有趣。

跟可以讓結果更好的人一起工作，對設計者和程式設計師來說，都是一件令人開心的事。這種協同合作來實做功能的方法同時也帶來團隊中的互信。

精力充沛的工作 6

精力充沛的工作，又稱做Sustainable Pace 或是一禮拜工作40小時，這種法則表示你工作的時間不要超過你有生產力的時間。當你疲倦或是生病的時候工作都會減緩你的工作速度，發生許多錯誤，不開心，或是疲倦跟生病更久。

因為程式設計基本上跟靈感有關，如果他們在正確的時間帶著正確的想法，程式設計師可以就可以在短時間內做出大量的成果。但是有著靈感是最難的部份; 我們的大腦需要100%的運作不然它很難想出最棒的解答。 精力充沛的工作讓我們的大腦保持健康、高興，所以它才能常常傳遞出最佳的靈感

精力充沛的工作支援其他XP的實踐方法，並且讓程式設計可以寫出最棒的程式碼和做出最有趣的遊戲。

結論

在這篇文章的開始，我就說過XP並不只是關於自動化測試、每週工作四十小時，也不是只關於共同撰寫。當然，所有好的XP團隊都會做到這些，這些單純地只是引導出絕佳的產品。這就是XP所關心的-創造出絕佳的遊戲。

XP的力量就是它允許遊戲開發者在面對大量個異、甚至是互相衝突的需求時，可以可靠地製作出絕佳的遊戲：

*發行商的需求被滿足了，因為他們的產品更為有趣，他們更常看到可見的結果，並且當他們的行銷人員需要改變他們的產品時，他們的新需求就可以被滿足。

*管理者也開心了因為團隊的士氣更高昂了，遊戲可以改變來符合新的商業需求，並且可見的過程和回饋讓他們知道這個團隊正在正確的路上。

*團隊成員也開心，因為XP這麼多的實踐方式讓人很開心，有趣和帶給人活力。

最後，使用XP可以讓每個人都很開心，因為我們都想要同樣的東西，”做出絕佳的遊戲”

source : http://www.casualgamedesign.com/?p=27 (原文發表於gamedev.tw)

如果你對於遊戲只要玩就好，那你認為學會玩一套遊戲是一種與生俱來的本能這種想法是可以被諒解的，不過就是跟著遊戲的節奏走嘛。

然而，對於遊戲設計者而言，你必須了解到學習的過程是你可以(也應該)設計的。一套遊戲的學習曲線在玩家如何看待這套遊戲方面有著強大的影響。

然而，我還是懷疑你可以快速地想像學習曲線的長相，我將會為你們繪製出來，主要是因為在我們成為好的研究人員之前，在這上面我想指出一些東西。

問題：這個學習曲線是陡峭的還是平緩的？

上面這張圖所顯示的是你越努力去學習遊戲的規則，你可以了解的越多。你的目標跟玩家一樣，都是完全了解遊戲的規則。如同你在圖中看到的，如果要完全了解這個遊戲它需要花費一些努力。

所以，這就是為什麼我們稱它為陡峭的學習曲線。下一張圖則是平緩的學習曲線。

在這張圖中，你只需要花費少許的努力就可以了解這套遊戲，這就是為什麼我們稱它為平緩的曲線。最奇怪的事是，如果你仔細看這兩張圖，第二張圖才是陡峭的而第一張圖則是平緩的。

我的解釋方式則是請你以換一個軸來看，但是這還是與我們的直覺相反。當你在繪製它們時，你會發現我們稱為陡峭的曲線實際上是平緩的，反之亦然。很神奇，不是嗎？無論如何，先讓我們回到原本的主題。

一般而言，平緩的學習曲線會比陡峭的好，尤其是在休閒遊戲這方面。

當然，有許多玩家是在尋找一種挑戰，但通常來說，將玩遊戲這件事設計成一個挑戰而不是學習遊戲

是一個好的決定。所以，如果我們可以將陡峭的學習曲線轉換成平緩的學習曲線那麼這將會相當有價值。

提供一個遊戲導覽(tutorial)

你可以試試，不過你沒有辦法設計一套沒有規則的遊戲，如果它有規則的話，那麼玩家就必須學習它。其中一個策略就是把規則丟在那裡。

換句話說，你將會告訴玩家：”這裡有一些規則。學習它，等你學完的時候，你就可以開始玩了。” 這是棋盤遊戲所採取的方式。

在你進行遊戲之前，你必須讀使用者手冊，並且盡你可能地記起所有的規則。你要向其他玩家解釋你學到甚麼, 不要以為這件事會更輕鬆。

通常會發生這種狀況：就是當你讀完三分之一的手冊，跳過中間的三分之一，最後的三分之一則是約略掃過。你把手冊丟到一邊，說些像是”好吧，讓我們來看看這要怎麼進行。”

在你們這些棋盤遊戲設計者抱怨之前，讓我告訴你電腦遊戲的玩家如何對待這些手冊。「手冊？有手冊這種東西嗎嗎？」這就是問題所在。

那麼，電腦遊戲的設計者怎麼做呢？恩，好吧，那就把手冊放到遊戲裡並且把它叫做遊戲導覽。這方式已經變成學習遊戲規則這問題最常見的解決之道了。

(這也是最不精緻的解決方法了，不過這是另一個主題了。)遊戲導覽最基本是要加快學習的過程。

要注意的是，在x軸上的不是時間，努力才是。遊戲導覽將會快速地把遊戲規則介紹給玩家(或是把玩家介紹給遊戲規則)，但是它並不意味著學習這些規則並不需要玩家那方面額外的努力。

當你在設計一個遊戲導覽的時候要記住：你的目標是讓學習得過程變得簡單，而不是快速。

使用常識

有些遊戲你不用學習遊戲規則就可以馬上上手了：就是那些你已經知道規則的遊戲。這看起來似乎是不太需要特別提出來的道理，但是你可以把這個道理當作你遊戲的優勢。

你如果直接把人丟到電腦前面，其中大多數的人可以馬上玩起接龍遊戲(好吧，在他們停止跟滑鼠講話之後)。這不單單只是因為這遊戲的規則很簡單，另一個因素是因為玩家們已經知道這些規則了。不是所有人都想建立另一套不同的接龍遊戲，那麼，這個建議的好處在哪，尤其是當你不將實體世界的規則改寫後放到虛擬世界中，或是你沒有複製任何一套電腦遊戲的時候？ 實際上，很多。

即使你沒有複製其他遊戲的規則，你的遊戲中還是使用了很多遊戲世界裡一般性的常識。舉例來說，在大多數的接龍遊戲中，你可以藉著將一張順序較高的卡覆蓋在另一張卡上造成一個組。

像是：你可以把六放在七上面，十放在十一上面，和把十二放在十三上面。所以，如果你正在設計一套新的接龍遊戲，你可以使用這套規則讓玩家可以可以很容易了解。

當然，紙牌的號碼大小只是一些標準的範例。像是十三比十二大，所以你會很聰明地採用這個設計。

藉著這種方式你可以創造出類似的效果讓使用者易於了解該怎麼做。當你開始玩小精靈(Pac-Man)的時候，你會看到五個角色而且只有一個不動，所以那很有可能就是你所扮演的角色。

在迷宮裡，你可以在走廊間移動，因為這是迷宮一般的運作方式。並且穿牆通常來說是不可行的。現在你知道為什麼小精靈不需要遊戲導覽了吧。

讓學習曲線平緩一點

儘管採用了上述的策略，有些遊戲還是仍然難以學習。如果你所設計的遊戲正面對這個問題，那麼我想你可以採用接下來的方法。

這個曲線是不是比前面的好多了？可能不會，因為在玩家學會所有規則前要花費太久的時間。但是，再仔細地想一下玩家的目的。玩家並不想要很快地學會這些規則，他們想要很快地開始玩這個遊戲

(是的，我知道我之前說過你的目標就是讓玩家完整地了解這些規則。所以，我說謊了嗎？ 好吧，關於這個，是的，我現在將會告訴你們實話，真的。)

對某些遊戲來說，尤其是複雜的遊戲，你很有可能可以在了解所有的規則前就開始玩遊戲必且沈浸其中。大多數的彈珠遊戲都有一套桌面的規則。跟隨這些規則允許你在完成任務的時候

還拿到更高的分數。但是，即使你不了解這些規則，你還是可以單純地把球彈出去就得到很多樂趣。剩下的規則會隨著你玩的時間越多而漸形明朗。

有時候你可以設計一套遊戲全然地略過完整的規則，如果玩家不需要的話。如果你正在設計一套角色扮演遊戲，在裡面玩家可以決定他不想成為使用魔法的玩家，那麼你可以不必解釋如何施法。

同樣地，也有許多遊戲可以在不知道完整規則的情況下享受並且完成這套遊戲。在我了解全部的規則前，我就玩完許多套文明系列的遊戲(嘿！我那時才七歲好嗎！)，但是我需要連續玩好幾個鐘頭。

記住我們的目標

我將會重述一次，因為我認為這是很重要的：玩家並不想要很快地學會這些規則，他們想要很快地開始玩這個遊戲。當你在設計遊戲的時候，謹記這一點，你可以做的很好的。

Gamasutra 上這篇  The Future Of The Real-Time Strategy Game 提到了所謂即時戰略遊戲的未來。簡單的說，就是作者拿現實生活的戰爭來類比這些即時戰略遊戲(ex:星海爭霸、C&C)，並且提出未來可能的發展。作者提出最重要的建議有：

1) 可以讓工兵自行決定採集策略，玩家不需要再去擔心資源收集的問題，可以把心力放上策略上。

2)即時戰略遊戲的勝利條件可以不再侷限在用兵力打敗對手（外交手段？還是透過語音來說服對方投降？甘有可能），畢竟不戰而屈人之兵才是上策。這些遊戲可以更朝策略面去而不是戰略面。

老實說，這個點子並不新穎。而且把兩種類型的遊戲給攪在一起了。以文章中提到的世紀帝國為例，世紀帝國提供了多種的獲勝方法，有搶蓋世界奇觀，有最先收集到一定數量資源這幾種獲勝方法。但是，當時不論是網咖或是微軟所提供的GameZone，清一色看到的遊戲獲勝方式均是：毀滅對手的單位。 這表示一般玩家就只想要轟轟烈烈的戰鬥。

如果他想多點策略，他會去玩文明帝國。

此外，採集資源的策略也不是那麼沒意義。以星海為例如果你要打長久戰跟快速戰的採集策略就不同，這邊是很難交給電腦去處理的。當然，電腦肯定可以算出最佳C/P值的作法。但如果要這樣作，那我們看電腦打就好了阿~~~~

但是這種未來並非不無可能，畢竟當前的即時戰略遊戲的策略大同小異，實在需要一些突破。但目前看來似乎尚未有遊戲可以成功融合兩者，不知道未來有哪款遊戲可以做到呢？Blizzard 秘密研發中的新遊戲嗎？

source:http://www.businessweek.com/innovate/content/oct2007/id20071012_041625.htm

遊戲中101條重要的使用性法則：

1. 絕對不要詢問玩家是否要儲存遊戲進度
2. 永遠呈現 “按下我開始遊戲”
3. 總是允許玩家可以重新設定鍵盤的配置來符合他們的習慣
4. 永遠讓玩家可以選擇是否觀看過場動畫，無論這動畫對於遊戲的劇情多麼重要
5. 不要讓攝影機太接近玩家角色或是卡在牆裡
6. 不要只是因為程式辦得到，就使用所有可以用到的按鈕
7. 讓玩家可以設定遊戲的易用性
8. 不要設計無法抵擋的攻擊 (仙劍還蠻常見的阿XD)
9. 為了新手玩家，永遠呈現教學、常見問題和幫助選單
10. 永遠讓玩家可以自由地選擇何時離開/進入 遊戲(不然他們會乾脆關掉整個視窗)

link: Designing a Gameless Game: Sulka Haro On Habbo Hotel

Habbo 是一套透過Director運行在瀏覽器端的線上遊戲，它是一套可以跟遊戲中的物品大量互動的遊戲(pixel風格的圖形真的很可愛)。這篇訪談中有幾點有很趣：

1)文中花了很多的篇幅在討論Habbo到底是不是一套遊戲以及遊戲的定義。 這的確有趣，如果聊天室套上圖形介面可不可以就被稱做遊戲？沒有圖形介面難道就不能稱做遊戲嗎？ 很明顯不是，因為mud就是這樣的一種遊戲。 所以到最後定義就變成：所謂的遊戲就是某種你可以與之遊玩的東西(唔，真的很寬廣的定義，可是如果不這樣，遊戲就相當難以定義)。

2)Habbo要進軍電視遊樂器的市場。他們討論到鍵盤的事：他們一致認為雖然玩家可以插上鍵盤但是玩家們還是不會加上鍵盤。 到底為什麼呢？
我也覺得很好奇(不知道有沒有相關的研究)，玩電視遊樂器的就一定會用搖桿，鮮少用到滑鼠跟鍵盤，Why？ 像是之前魔獸二移植到主機上的時候，也是使用搖桿的介面。但是反過來就不見得成立喔！

其中遊戲的特點就是大量與所謂的傢俱互動。這應該很有趣吧，之前就很想做荒島求生記(拓荒或是製造系)的遊戲，你可以自己建造自己的房舍(樹屋或是穴居)，可以製作一些東西、可以跟環境互動，感覺就很有趣呢！