2018年12月23日 星期日

[翻譯]有意義的玩法:設計思考與遊戲設計

原文連結
http://gamasutra.com/blogs/MarsAshton/20181003/327768/On_Meaningful_Play_Design_Thinking_X_Game_Design.php

在相似的產業中,遊戲開發是相對新的產業。做遊戲和蓋棟房子乍看之下是完全不同的產業,但有著相似的流程來找到解答。雖然兩者的產出明顯不同,但基礎概念、發想、研究、開發,基本上是一樣的,而且都需要理解使用者定位、價值、及重複迭代的開發流程。

"在我們看設計者的系統性的解法前,我們必須先知道'設計'到底是指什麼"。一棟房子的建築計畫是很清楚。所以一個印刷設計會準備各式版面,但雕刻家要塑造模型不用,這其中有什麼差別?"-L. Bruce Archer

L. Bruce Archer,一個Royal College of Art的機械工程師及設計專家,設計研究的先驅及挑戰者。目前狀況下,我們得知各式產業如建築及視覺藝術有著極大的差距。我們反推回藝術學位的合理性,就像是成為醫生或律師,各大學課程有著普遍的基本設計原則在各個領域。我們可以看到製作廣告並證明其價值的人為"廣告設計師"。

我們體會到這些東西是被創造出來,並依其視覺效果並成為在某問題的解決方案。某人在某時間有了這些想法並將其做出來,呈現出某角度的現代視覺藝術設計。所以到底是什麼讓它得以出現?在短短十幾年內,我們是如何察覺其效果,並發現它的好處?在同樣的精神下,我們是如何定義遊戲設計的合理性?到底是什麼造就百萬下載的手機遊戲點子。成就了獨立遊戲像是"Night in the Woods"及"Braid "的成功,衝擊到3A遊戲"Call of Duty"的市場。

(設計思考)Design Thinking


如果你將Apple視為一個品牌,而不僅是家公司,已經在這十幾年間進化了好幾次,你將會發現使用者所重視的部份即是設計要強調的地方。透過解決問題造就創意的發明。他們找到方法來使流程更簡單,消除次要因素,著重於使用者,透過確定主要功能及特定需求的特別APP,或是簡單的硬體功能令人開心愉快的使用它。利用設計思考的定義出其商品,並奠定粉絲對於品牌的基礎。

要定義Design Thinking,我們通常以5個實際步驟來解決問題,製成產品,並以使用者中心、有理由的、並有作用的方式,來執行計劃或完成目標,。

共鳴、定義、發想、原型、測試


這並不是新的觀念,很多企業都採用設計思考來當最佳的設計方式及企業模式,這不是個一時的流行。這並不令人感到驚訝。當我們教每個世代企業所需的技能,我們努力去統整概念、讓事情有效率且在流程內容易了解並遵照步驟來執行。對遊戲設計來說,敏捷式開發的存在強調定期的開會、為區分工作優先度且保持溝通。

事實上,每個領域的設計思考等同於做遊戲的精髓。它描述了開發者如何遵從方法來產出吸引人的劇情、讓遊戲及其意義使人有深刻印象、並讓某些遊戲能成功而和其它遊戲有差異。這些遊戲必須花時間來找出正確的遊戲感、伴隨著每個現今遊戲都該有的樂趣。基本上許多開發者致力於越早原型開發越好。小規模、大規模、最佳體驗是經過多次精鍊及反思後被選擇出來的。

再次解釋一次、設計思考是:


  • 重度迭代
  • 以研究為取向
  • 解決問題
  • 透過不同的想法來產生點子
  • 使用者導向的原型開發


所有這些元件都指向正規的好遊戲開發流程。我該如何開始?我該先做些什麼?我該如何事先規劃?處理這些、處理那些、到底專案的最終目的是什麼?

經過了十幾年的教學,我觀察學生在開始專案時通常會從2個方向著手。

1.發散.他們在白板上的點子後面再寫上新的點子,列出整面的便利貼,用圖像呈現,動畫,參考其它遊戲、並腦力激盪出個計畫。經過一段時間後,他們開始執行並達成其目標。

2.聚焦. 透過初始的概念,在做其它事之前,他們快速地做出原型。並開始深入分析它,最終達到可以測試並驗證其設計並不斷迭代其初始概念,有效率透過流程產出計畫。

這兩種方式是主要的設計思考的正式方法,並在不同非線性的方法上,呈現不同的面象。這並沒有所謂正確的方法,考慮到每個人的特質,身為個開發者都有自身獨特的觀點,我觀察到不應該去批判個人的開發品質。這種專注讓身為開發者的你增加生產力、溝通並且完成其目標。

除了上述的之外,發散及聚焦表示設計思考的概念及"發想"的階段。最終你會在其中之一的項目下工作,他們都是有效的方法去探索遊戲點子、核心機制及動態與他人互動的方法。了解這兩種方法可以幫助你去驗證並調整你的決定。這兩種方法都有其價值並且使得概念變為實體。

1 概念(Concept) 2 計劃(Plan) 3 製作(Make)

“Less Talk, More Rock”中,透過媒體傳遞訊息的方式是被檢驗過的。問題在於我們為什麼不動手、將我們的概念轉傳給別人、試探玩家到底需要什麼,如何在你的遊戲中做事及探索有意義的元件。確定問題並透過開發且利用各式物品來創造解答,表現特定的風格,及為了玩家去暗示正確細節且留給玩家空間。讓玩家填補細節並完成解謎,那正是他們對於遊戲的看法。

現在我們看到各式大大小小的遊戲在精神上完成它。利用我們從設計思考的理論,試著去推測薩爾達傳說曠野之息是如何設計這遊戲的,使得它如此的特別,用這個方法在過去他們規劃且完成各式有趣的遊戲。他們使它開放,並給予玩家相信他們能靠各式方法解決問題,並留下玩家的各式策略更多過於其故事,更多過於海拉魯的巨大世界。

在各種方式上,曠野之息這遊戲允許玩家透過設計思考當其遊戲機制。

很驚人吧?

1 概念(Concept) 3 製作(Make) 2 計劃(Plan)

這篇文章建議我們可以跳過123的順序。而是強調用雛型(prototype)來探索並計劃,利用成功的經驗來指定專案方向。這鼓勵我們使用設計思考但不拘泥於之中,間接藉由已確立的商品。在這比較自然的方法,工作室已經學到重要的經驗。這是個以設計思考為重心方向的重要例子。

這個方法被我幾年前所教的學生所假設,因為他們的年度專題。結合遊戲美術、視覺設計、互動設計的學生,這個年度專案學生所發現的問題,關聯著業界、甚至可以強化他們更多的專案。大部份的經驗遵行設計思考,強制遵循著固定的流程與討論,這挑戰了學生的設計決策與工作,使他們釐清什麼與為什麼是他們該做的。由我的同事兼課程教師Lilian Crum所提出,他們的行為是"1,3,2",藉著製做,他們將自身當成創意的集合。

被Architecture and Design Lawrence Tech的同事啟發,協作環境下視覺藝術、設計思考、遊戲美術的融合是獨特的。透過在學4年內做遊戲,這是學生生涯倒數第二次的爆發成長。通常學生在某方面開始超越別人。視覺設計師開始做遊戲及強化他們的觀點及技能組。遊戲藝術師開始發跡、推廣、甚至雕塑、作畫。

所以我們如何培育自己?

確定你的極限、定義你所遇到的問題及做出自己的成品:
限制催生出創新。若一個你打算克服的問題沒有範圍限制,試著給它一些條件,使它專注於你的創意,及寫下你雛型計劃。

舉例來說,我曾經嘗試強化Flux的浸入感,它源自公寓的配置,你的角色在電腦前將臉別開,接著有一連串設置好的對話。問題在於缺少與玩家的互動,玩家覺得沒有參與其中,只是當個旁觀者。你現在已經可以在場景移動,讓玩家藉由動作與空間互動,並且提供有意義的選項讓它能產生一些回饋及結局。

知道自己是無知的

當你調整及限制決策時,同時也考慮到你的點子是不是行不通及不夠好。讓心胸開放,使得接下來的迭代能強化你的遊戲體驗。藉由討論及回應,使其能領導它更容易了解,並知道這方法並無法有效與玩家溝通。

將測試列入考量

測試並不會讓遊戲企劃感到有趣。當你面對市場需求,有些從負面消息也許沒有在遊戲開發中。我的太太總是我最好的測試者。有些玩遊戲且不把其當成興趣,她揭露出我必須更加清楚、有用且有效率地傳達。

專注於玩家的看法、建立關連性

你的故事、訊息、視點都需要是可以讓玩家專注、玩家取向、玩家為主的項目。談論個人故事引起大家相同感觸,這造成衝擊,這一瞬間造成的長久記憶。若玩家沒有接到這種衝擊,那你可能有些事做錯了。

在"雲行者",基於西遊記的英雄"孫悟空"(這比七龍珠的悟空更加超級,他是不死的且超級強大),它被暫時囚禁在惡魔的夢境中。其中的娛樂與玩家緊緊結合,透過演出,玩家發現這遊戲叫他們不要去玩它(悟空)。藉著結合悟空自身喜好及習慣,玩家迫使它去殺人、偷竊、破壞所造成的各式問題,使我們參與其中體驗。角色會質疑玩家的喜好、升級並獲得成就。

參考Bartle的玩家分類

做出有趣的東西

越早做出雛型越好。如果你在發想階段有許多分歧,雛型是你最好的幫手。你越早對某事有想法,那你越早可以解決它,並且對它規劃。參加GAME JAM,設定小規模專案,讓你工作更加穩定。

更進一步的說,我在Lawrence Tech的經驗,設計導向正好符合現況。我當開發者的經驗,設計思考藉由了解需求與符合玩家期望,定義出我如何開始製做內容。我身為遊戲玩家及消費者揭露出這些技術如何讓遊戲吸引人。

2018年10月1日 星期一

[翻譯]規劃與未知的未知

規劃與未知的未知


原文連結: Planning and the Unknown Unknowns, by Richard Atlas

上個11月,我有一場關於Ultimate Chicken Horse講座,提到遊戲從早期構想到釋出之後的故事。他們會問這過程中的各式問題,例如:你如何得到資金?如何將遊戲放上PS?你如何找到夥伴來開公司?之類。我歸納出各個答案放在研講過程。

我在這個旅程所學到其中一個經驗就是"嘗試去思考所有事情"。這聽起來很平常,但其實很難知道自己沒有考慮到什麼事情,因為很明顯的你沒去思考這些事。因為要思考所有事情是有點難以執行的,所以我開始用另一個方式描述:為未知的未知規劃。

這個名詞是出現在一個心理學家Daniel Kahneman的著作:快思慢想,在其中一個章節提到規劃謬思。規劃謬思是寫下計劃並預測,讓未知的風險接近理想狀況,並利用分析來提升其結果。最後專案花了比計劃更長的時間,花費超出了預算,人們變得不開心,產品完成度低落,大家都沒賺到。聽起來得熟悉嗎?遊戲開發及許多其它產業的工作,都被規劃謬思所困住。

今天我提出三個建議去減緩規劃謬思。


  • 立下基準線
  • 取得外部觀點
  • 為未知的未知做規劃


立下基準線


Kahneman及夥伴Amos從心理學視角在經濟行為領域做了很多研究,最終在2002年得到諾貝爾獎。在提出規劃謬思後,提出立下基準線這個方法。

這個想法是避免一般意念去影響對你的統計數據。例如遊戲開發的例子,"依數據來看,我們的團隊規模會花費4年開發MMO,但我們是業界的老手、有良好的團隊,所以只需要2年的時間",這很明顯不是正常的預先規劃,但這發生在我們身上,不管我們是否有認知到,從小事情到大事情都是。

這個想法最終被確立,並被命名reference class forecasting(參考類型預估),並以接下來的方式運作:

-辨識客觀的參考類型(獨立遊戲、動作遊戲、線上遊戲、由X人團隊做出的遊戲、由Y預算做出的遊戲、等)
-由參考類型上取得統計數據(這些專案花了多少時間、多少預算)
-利用這些數據立下預測,然後用我們自己的資訊來調整基準線

通常你會發現自己迷失於上調預測,你的資源有什麼?你的團隊有相關開發經驗嗎?這些技術可以快速實作嗎?有新的技術需要被習得嗎?什麼東西會讓它慢下來?

由統計數據會發現這其實很明顯,而我們通常會忘了去做這些事,且鮮少發現自己忘記了。

取得外部意見


下一件事是取得外部意見,並從自身狀況退一步。藉著現況,我們會很自然地將擁有、經歷過的經驗、我們面對的狀況,從這些角度來看事情。我們由所知的事物去推斷,我們擁有資料的一小部份,而且當計劃是關於我們及事情時,會被自身的感情困住來下決策。

對於我個人及我的公司,最簡單的方法就是去詢問其它人們。找到可以給你直接意見、不說廢話的人,並告訴你忽視以久的頑強問題。

藉著詢問別人,你不再只被眼前資訊影響,並可以給你更完整的資訊。

為未知的未知做規劃


還記得我們團隊只需花2年就可以做出MMO的例子嗎?我們已經討論過,設想自己能花比較少的時間不是件聰明的事。但大多數人們會花更多的步驟規劃。他們會設想所有所能想到的事情,取得外部觀點、詢問它人,甚至去看相關的專案去預估。一旦他們做了所有這些事,他們可以歸納出所有所需的項目,分配時間給他們,規劃利用現有及未來的資源。過了這些步驟,他們仍然只會覺得要花2年再多一點的時間。

這是因為他們沒有考慮未知的未知。這些事會在專案中期才會到來:僵化的官僚制度(我們都知道這是存在於遊戲業的)、生病、離婚、技術延遲、相關廠商的合作、生涯規劃、離職等等。我在這稍微提一些,因為你不會知道你不知道的事,所以難以規劃。

這就是為什麼我們要把偶發狀況列入預算,而且為什麼開始計劃及訂下時程時,我們要把一大堆額外時間加到計劃內。我們總是儘力不在事情完成前做出保證。許多企業(及個人)出問題而不能準時完成,但這些日期是自我期許而不需這麼固定。當然有些是給客戶的承諾,或是專案要要在某時期完成或上市,但是我已經看過無數個自訂日期是不是被合理制定的,這會造成沒必要的壓力、並因這些排程造成錯誤。

在詢問其它人會遭遇到什麼樣的未知時(就是外部觀點的例子),你可以同時研究其它專案或公司並看看他們有遇到什麼的問題。甚至你不預期會遇到的狀況,這是很好的機會去激發你去思考潛在的問題。

所以首先想想你及同伴的所有事情,然後將這些還沒想過的事列入規劃。

為什麼這是重要的


這關乎於任何在管理職或決策者。在遊戲開發,我聽過的所有專案都無法準時,如果它不延遲,那它一定比人們期望的還要差。我不確定其它產業是不是這麼糟糕,但我認為這是件全世界都會遇到的問題。

這裡並沒有任何困難的科學方法,也不是讓你遵照固定的步驟就能成功,但這些建議能幫助你避免錯誤。當我讀到Kahneman的書時,我理解到了心理學如何應用在遊戲開發上,所以分享了這些,希望你們閱讀愉快。

2018年9月6日 星期四

[翻譯]卡牌遊戲:簡單就是最好的設計

原始連結

在高中時有人給我看他們設計的馬莉歐關卡,關卡要求精確跳躍及各式技巧。他們看起來對作品充滿信心,尤其是在其難度及複雜度上。我點頭微笑,但是我心裡只覺得這並不有趣。
我看到許多新的設計者常犯的錯誤之一,他們執著於設計複雜且需要高深知識的遊戲規則。而結果總是可以預期的,設計變得複雜、散亂無章、令人難以理解。我雖然是個卡片遊戲企劃,但這發生在各種遊戲類型。在這文章我會解釋為什麼會發生,且提供些建議給別人,使他們設計得更集中及精簡。

確認問題

這非常困難且通常不易知道別人是如何思考,但我的文章就是要這麼做。若要我猜測新手企劃為什麼要做這麼彆扭的設計,我想應該是下面兩個理由。

玩家視角

玩遊戲和製作遊戲有著完全不同的視點,企劃知道做遊戲的流程且擁有其技能,而玩家只經歷了遊戲完成的模樣。我們之中有很多人開始時也是個玩家,但是從玩家思考轉到企劃思考是個困難的過程。所以才會有設計者做出太複雜的系統,因為把自己當成玩家一樣去挑戰。

把設計當成遊戲

另一個原因應該是新手企劃將"遊戲設計"當成了遊戲。他們藉著創造的過程來娛樂自己,結果是做了許多複雜設計,讓玩家很難了解並喜歡上遊戲。
上面兩個理由指出了根源的問題在於,設計者忘記了自己是在為玩家做遊戲,而不是為了他們自己。


為什麼

在我提出建議前,你可以先思考剛剛的問題為什麼真的算是問題。

對新手好一點

一開始新手還不清楚你的遊戲,所以你需要給他一些簡單的方式來進入遊戲,太快速及複雜的機制會造成負擔,並且迫使玩家離開。給他們第一印象是很重要的,一開始就讓玩家恐懼,會使玩家再也不回頭。
為什麼你需要迎合新玩家?這算是長期投資你及你的遊戲,例如爐石由2014年由一千萬玩家到2017年7千萬玩家,這提升絕對不只是好產品及廣告刊登,這還需要個對新手友善的環境。記著每個玩家一開始都是新手。

記憶力有限

我們一次能處理的資訊是有限的,複雜的設計會佔用我們有限的記憶力,所以我們要花越多在複雜設計上,越難讓玩家進入我們遊戲。換句話說,複雜的卡片消耗的資源更多,讓玩家更難集中在遊戲核心。複雜的卡也越難使玩家記住,尤其是當你的遊戲有成千上萬的技能及效果。他們花越多時間去記憶,越少時間去享受遊戲。

提供建議

終於到了最重要的部份,你要做什麼事才能增進你的設計技能。我下面會列出些提示,但是這些提示是用來改變你的方法及想法用的。這是項技能,但是如同所有技能,你需要練習及耐心才可以習得。

做一件事並且把它做好

當你做一張卡牌,一張卡牌就可以造成很多的變化及影響,卡牌上的功能可以讓遊戲更有變化與有趣。無論如何,通常最有效率的設計會著重在一項機制。這是爐石或魔法的基本生物卡。
魔法專家(4 魔力)
當你打出技能卡時,魔法專家+1生命/+1攻擊直到回合結束
每回合可以使一張棄掉的技能牌回到手中
3生命/2攻擊

當你使用技能卡時他會變得更強,而且他讓你有更多機會使用技能,並且讓自己更強。同時他的攻擊性比防禦還強,有了這些加成會強化你的主動侵略性。這是張只專注一件事的卡片。下面是張稍微複雜的卡。
召喚專家(5點魔力)
棄掉2張牌:得到+1生命/+1攻擊。
花6點魔力:將一張生物卡放回戰場。
3生命/3攻擊

起初你會覺得這張牌做了很多事,他可以棄牌,可以強化自己,還可以復活生物。無論如何,他其實只圍繞在一個策略上,棄掉卡牌,然後將卡牌拿回放到場上。你得到了一個棄牌引擎,可以讓卡牌放到場上,其棄牌的交互作用是其主要考量。
你會覺得這兩張卡牌專注的事情很渺小,但這不是唯一的例子。這兩張牌都可以和其他牌組合運用,即使他們各自有其專注的機制。
如果你想驗證我的說法,試著挑選一個規則或策略、機制,試著建立個專為此設計的卡片。

越大不見得越好

我們很容易覺得簡單的設計很無趣,自然就會去做個複雜的設計。簡單真的比複雜無聊嗎?也許是,但只在特定的時間及對特別的人們而言。大部分狀況是太複雜的設計反而讓大部份玩家難以使用,或是太難以理解。這次我將拿真實的例子來說明。看看這張醜陋的山頂徘徊者(Summit Prowler)。

這是魔法風雲會Khans of Tarkir擴充的一張卡。這個擴充裡有項機制叫兇殘(Ferocious),只要控制最少4點力量的生物,可以提供卡牌們額外強化。你想起山頂徘徊者正是4點力量的生物卡,所以將它放在場上會觸發兇殘效果。簡單且單純,就像我之前所提到的。山頂徘徊者在魔法風雲會是張平凡的(vanilla)卡,意思是指它沒有額外的效果或能力,對某些人而言,他可能少了些什麼,你可以想像新手會試著為它增加些能力來強化它設計。像是如下面這例子:

藉著給它一個有條件的能力,雖然給了它額外的深度,但卻讓他變得更糟糕。它也許價值提升,但是有條件的能力,讓它要花時間處於弱勢的狀態。這也使得我要發動兇殘更加困難,我必須在特定時機符合特定條件。這設計也許會讓遊戲更有趣且富有挑戰性,但事實是玩家會追求負擔拿較少的方法,甚至不會想將這張卡加入牌庫,也連帶不會組有兇殘機制的其他卡,繞了一大圈,事實上是讓遊戲不有趣,而且讓其更加複雜。
如果你總是設計些額外能力到你的卡片,你可以試著挑戰自己,設計張平凡的卡或單一效果的技能讓它可以配合現有的策略或遊戲理念。這是種視野的想法,每個人都可以為壯麗的風景拍張好照片,但是你可以讓一片葉子有趣嗎?練習這技巧可以讓你建立基本能力及從中感受到單一效果的回饋。



一為全

卡片遊戲是很特別的,它會因為眾多卡片的互動而變得複雜。在這種情況下,新手企劃應該試著設計多張單純的卡片,使其組成複雜的架構。將每張卡片都設計的極其複雜反而是不好的方法。
首先,企劃錯誤假設玩家會和自己一樣,用特定的方式來瞭解及使用卡牌。再來企劃會讓某些卡牌組合較強來吸引玩家,他們用意想不到的方式使用卡牌,而企劃根本沒意料到,因為他們只專注於其大作。最後,企劃可能設計出非常特別的策略,使得玩家的牌組單一化,同時也失去構築牌組及選擇策略的樂趣。
當設計一組卡牌,試著不要太專注在特定機制,相對的設計一組較開放的策略(技能卡強化、復活生物、生命恢復),然後創造一組卡牌能與其交互運用。你可以將各式效果放在不同地方,但你的目標必須是提供各式工具讓玩家創造有趣的牌組,這比給他們一份固定的施工藍圖要有趣多了。

再見

我希望這篇文章能對大家有幫助,這主題還有許多可以分享的,但這邊我就提這三個意見。所以當你在設計卡牌,記得簡單就是最好,事實上許多簡單的卡牌擁有最優雅的效果。


2018年7月6日 星期五

[翻譯][Video][統計]Steam遊戲到底賣的如何?


2017
每款遊戲賣500套 (500中位數, 3700平均)
第一個月營收$2000中位數,$18000平均.
第一個月平均價 $7 中位數, $8.3 平均數

2018
每款遊戲賣50套 (50中位數, 2000平均)
第一個月營收$250中位數,$2000平均.
第一個月平均價 $5 中位數, $7 平均數

2017.08
每天出25款新遊戲
2018.02
每天出40款新遊戲

除去粗製爛造的遊戲 2018.02
每款遊戲賣2000套 (2000中位數, 10000平均)
第一個月營收$12,500中位數,$110,000平均.
第一個月平均價 $12 中位數, $13 平均數

第一年營收預估
第一個月營收 * 2.5 = 第一個星期營收 * 5 = 第一年營收 $30,000

2018.02 early access的遊戲
每款遊戲賣3000套
第一個月營收$24,500中位數
第一個月平均價 $15

2018.02 有發行商的狀況
每款遊戲賣6000套 (3倍)
第一個月營收$61,250 (5倍)
第一個月平均價 $15

2018.02 定價和銷售狀況
大於$15
每款遊戲賣5,000套(中位數)
第一個月營收$70,000(中位數)
$8-$14
每款遊戲賣1,000套(中位數)
第一個月營收$7,000(中位數)

93%開發者賺不到生存下去的錢!!

2018年6月9日 星期六

[翻譯]你的遊戲到底是什麼?

http://gamasutra.com/view/news/193338/What_is_your_game_actually_about.php

這是2010 Game Developer magazine的文章,Civilization IV Lead Designer Soren Johnson談論遊戲的風格及意義的差別


誰來決定遊戲到底是什麼?


看到桌遊Ticket To Ride的第一眼,你可能覺得又是個超級鐵路連線的遊戲,類似Age of Steam, Eurorails, 1830系列。在遊戲中,玩家會挑戰將兩座城市用鐵路連起來。紐約到舊金山、邁阿密到芝加哥等。

為了完成遊戲,玩家需要建設一連串的鐵路將各城市相連,同時也要阻礙對手完成鐵路。也有次要目標,像是完成最長的鐵路或第一個完成網路等。

然而大多數的玩家認為Ticket To Ride是個挑選路線並同時阻礙對手的遊戲。但是背景故事是另一回事:"在秋風颯颯的早晨,5位老朋友約在城市的一個隱密的小包廂。每個人都是從世界各個角落長途遊行過來的,為了這特別的一天。1900/10/2。28年前的今天,Phileas Fogg贏得了賭注20,000英磅,因為他在80天內環遊了世界一週。"

背景故事參考

接下來每年他們都碰面慶祝並且付獎金給Fogg。且每年都提出新的探險(總是越來越難)。在世紀末的今日,是該來趟新的冒險了。賭注是100萬美金的競爭。看誰能在北美七日內藉由鐵路經過最多的城市。

這官方的故事令許多人感到驚訝,甚至是遊戲的老手,因為這風格根本完全和遊戲方式不搭。例如:為何玩家要搭建自己的鐵路?是因為有人把鐵路關閉,防止其它人來使用鐵路?或者是有不擇手段的大富豪為了獲勝而嘗試去控制鐵路?

不論如何鐵路是可以被佔據的,這和現實世界的印象、物理法則完全不搭。取而代之佔據鐵路反而比較像打算買下它而不是利用它來旅遊。

遊戲機制帶來意義


這個差異帶來許多有趣的問題。一個遊戲設計者有資格決定這遊戲是什麼樣子嗎?而玩家感覺又是另一回事?如果設計者沒這個權力,那遊戲的背景故事到底代表了什麼?遊戲是否真如玩家所體驗?

最終來說,設計者必須了解遊戲風格並無法決定它所帶來的意義。反倒遊戲的意義是從機制衍生,這一連串的抉擇及結果對每個玩家造成影響。這遊戲到底對玩家問了什麼問題?它懲罰了什麼?又獎勵了什麼?什麼樣的策略及方法是遊戲所獎勵?回答過這些問題才能真正顯示出你的遊戲是什麼。

更進一步思考,當人們為了其風格("我想當個宇宙特戰隊")買了款遊戲,而遊戲機制中得到了樂趣("事實上是射擊外星人")。當這兩者有強烈的差異時,玩家會覺得被欺騙了,認為是設計者只是想騙玩家錢。

關於Spore的接受度,它提供了"物種進化"的風格,提供了比較近代的例子。在2008十月的科技雜誌上,John Bohannon寫了篇他如何保證遊戲風格的文章:"我已經與團隊中的分析人員玩過了遊戲,確定了其各方面符合科學角度。這絕對符合生物學及演化論,但是Spore完全失敗了。根據分析,問題並非出在Spore在科學角度的分析,而是出在其遊戲機制。甚至它讓生物學變得沒意義"。

讓這兩者差異如此明顯的原因於Spore雖然以"物種進化"的風格為賣點,但其遊戲機制並非真的關於進化。Spore的遊戲事實上是創造-玩這款遊戲通常是想用編輯器造出他們想像中的生物,而非是遊戲設計者所想像,由樂器產生優美的音樂而進而營造出其環境。

無論如何,即使Spore雖然不是關於進化,而分析人員關注另一款真正的進化遊戲-"魔獸世界"。他的風格也許是劍與魔法的世界,但他的機制鼓勵玩家去改變他們的角色來克服環境上的挑戰。

經過了數年的更新經驗,WOW的老手確立了各種版本的職業配裝來符合其角色定位。例如:聖騎有三項天賦樹:Holy(治療),Protection(坦),Retribution(DPS)。更進一步,除了主要的分類,次要的分類如PVP,PVE,刷寶等。這些分類被發展出來,源自於這遊戲獎勵的玩家行為。

回顧過去


回顧過去有些遊戲機制影響玩家體驗的例子。超級瑪莉:事實上是抓時機的遊戲,而不是水管工。Battlefield是有關團隊合作,而不是WWII或現代戰爭。Peggle是混沌理論,而不是獨角獸或彩虹。

事實上,相同風格的遊戲事實上可能是不同東西。例如:人類對抗異形在電玩史上是個很熱門的題材,但是每款對抗異形遊戲,因規則的不同可能有極大的差別。Galaga(小蜜蜂)是在找圖形規律,而X-COM是以有限資訊的決策遊戲。戰爭機器是利用掩體為防禦武器。星海是挑戰非對稱戰爭。

反過來說,遊戲雖然有不同風格但是機制相同則是表是同件事。文明帝國及Alpha Centauri雖然在不同星球,但是其機制大致上的一樣的。Alpha Centauri的心靈蠕蟲、飛船小隊及機密任務剛好和文明帝國的蠻族、間諜、世界奇觀一樣。玩家可以從過去的遊戲脈絡發現在做相同的決策及相同的利益評估。

例如兩個最近的遊戲:Halo Wars, Brutal Legend,都是策略(strategy)遊戲。大家期望前者Halo Wars是靠敏捷反應為主的戰鬥。而後者重金屬風格則不像是一般策略。因為策略遊戲常常玩起來和想像中不太一樣,玩家因為風格所影響,反而造成遊玩失望。設計者建立了有趣且吸引人的組合,但風格確讓遊戲賣給了不同的玩家。

讓風格和機制一致


有個有趣的例子是桌遊Risk和Diplomacy,它有著一致的世界征服風格。事實上,第一眼看起來兩個遊戲有著相同的機制。遊戲版圖因勢力而分佈,玩家可以控制一般軍隊或海軍。玩家輪流操作不同勢力戰爭,勝利者通常控制了版圖上最大的軍隊。

但是規則有個小小的差別,讓這兩個遊戲變得非常不一樣。在Risk中回合是依照輪流進行,而Diplomacy則是同時進行回合。這個差別讓它們成為了不同的遊戲。在Risk,玩家依自己回合能做的最大利益做決定,並希望骰子能符合自己的相法。在Diplomacy,他們是沒有骰子的玩家只能依靠彼此的幫忙,而這些幫助只有口頭同意,而沒有遊戲內確定的協議。只有當密秘身份為揭露時才能真正確認誰是友人、誰是叛徒。

Diplomacy完美地結合了其風格及機制,事實上這還是甘迺迪總統最喜歡的遊戲。這遊戲和它宣傳地一模一樣,衝突及外交協議!

2018年5月3日 星期四

[Unity][教學][翻譯][筆記]動態尋路Part1

原址:https://www.youtube.com/watch?v=4Kj6YUPLWCw

首先來看最後成果
最後成果為藍球走到藍色目標、紅球走到紅色目標。

#1 設置好你的場景
我將場景靜態物件都放在同一物件Map之下,之後可以一同設定。
然後挑一個紅球當Agent、另一個紅色為目標物
其它顏色及數量最後再複製就好

#2 設定好靜態物件
將你所有的場景物件設為靜態,即為右上角的選項Static
事實上主要是要設定Navigation Static,右鍵點擊Static可以看到

#3 Bake Navigation Map

由上排選單列打開Window/Navigation
參數有空再看文件調整,
直接按下Bake就會產出Navigation Map了.
你可以在scene的視窗看到他畫出的圖,淺藍色即是可以移動的路徑

#4 將NavMeshAgent指定給紅球


#5 寫個簡單的script Agent控制NavMeshAgent

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.AI;

public class Agent : MonoBehaviour {
    public Transform target;
    private NavMeshAgent navAgent;
// Use this for initialization
void Start () {
        navAgent = GetComponent<NavMeshAgent>();
        navAgent.SetDestination(target.position);
}

// Update is called once per frame
void Update () {

}
}

#6 將Agent也塞給紅球
並目標Target設定好

#7 按下執行

若想測試多個只要再複製紅球
及再用同方法製造藍球即可

範例:https://github.com/MageWang/Crowd-Behaviours-on-a-Dynamic-Navmesh-in-Unity-Part-1-Sample
會寫這篇只是想留個筆記

2018年4月20日 星期五

[翻譯]Rogue Legacy設計筆記

原文網址:
http://cellardoorgames.com/rogue-legacy-design-notes/





這些不是你所想像的正規設計文件,它們不只難以閱讀、而且有很多缺陷。這也不是一般的遊戲製造流程,我們是一對兄弟在家裡工作,我們用SKYPE去和美術及音效溝通。若你將其應用在更大的團隊上,事情可能不會進行的這麼完美。我們同時也蒐集很多的素材。

Rogue Legacy需要兩週的時間來開發基本引擎及關卡編輯工具來製作這款遊戲。主要的設計文件都是在這時期設計的。所以這遊戲的內容及工具同時間被一起做出來,像是雞生蛋問題一樣。

很多的文件只是初期設計,額外的文件是在Rogue Legacy開發期間一邊進行的,但是有更多特別的狀況是在產品階段被發現的。這些並沒有特定的時間順序,我們也不知道它們的正確順序是什麼。

Teddy Lee
Creative Designer

#1

一開始這款遊戲叫做Rogue Castle,之後我們將名字改為Rogue Legacy,讓它更貼近遊戲本意。我現在還是滿喜歡Rogue Castle這名字。

這是最早遊戲各個狀態的設計。有兩項數值之後被移除了體力(Stamina)及移動速度(Move Speed),體力是個玩家揮砍的可用量,限制玩家無用的揮砍。移動速度則被移到符文系統。玩家本來是通過擊殺怪物來取得經驗值。經驗值可用來升級技能樹。而這些技能被稱為特徵,因為你利用經驗值去強化你基因的強度。這頗令人混肴。這個名稱在開發期造成很大的困擾。

本來的金錢可以兌換技能及符文,被改成金錢兌換符文、經驗值換特徵,而且還有些特徵是這邊看不到的(例如:色盲、肌肉萎縮)。

由於我們曾經更改過命名,我們兩個的溝通常常不是很順利。我們名字用了越久,要更改它的難度越大。所以如果你要做款遊戲,你的系統是很相似但是卻又不一樣的,最好在一開始就確定其術語。

雖然你也許不相信,Rogue Legacy不是我們第一次做城堡升級的系統。我們第一次做這個系統是在Villainous、一個守塔遊戲。我們需要做個相似的系統在RL。這有很多工作需要做,所以與其做個複雜的城堡,我們決定做個相對簡單的樹狀結構。(我們也參考了族譜的樹狀)。我們決定停止Villainous,它是個可完整成長的莊園。因為它是個完整遊戲的一部份,所以早期稍有不注意就會造成錯誤。

因為這是個容易死亡的遊戲,升級畫面也同時出現在這時間點。

當你死亡時,家族傳記同時也被當成排名榜。我們最後只稱呼其排行榜,讓其比較容易視覺化。

#2

這份筆記描述更多有關我們的舊的技能樹。

Rogue Legacy的技能樹原始設計其它是像是Kingdom Rush,而我們稱呼技能為"圖騰"。當你放置技能在較低階的圖騰,更高階的技能就被解鎖。

這系統現在看起來很奇怪,但是回頭來看遊戲的主要目標一直沒被設計。我們想要讓擊倒各個頭目會得到極大的獎勵,所以他們本來會解鎖更多圖騰讓玩家來裝備技能。

接下來是圖騰技能的獎勵,這並不是完整列表,因為早期設計還不需要這麼明確的列表。取而代之,更重要的是讓玩家知道你未來想要的技能什麼時候能取得。讓長期規劃變得更加重要。

#原始的技能樹設計。這還真的是棵樹。

你可以看到筆記上我們比較注重被動技能。但即使他們是被動的,每項被列出的技能都有其特別的實作方式,他們有其各自特別的實作方法(雖然我不是工程師)。

例如:

-14:陷阱的傷害降低,這表示我們需要能特別調降環境造成的傷害。
-19:更高的掉寶率,這表示我們需要一個公式來調整寶物的取得及機率。
-20:減傷系統,這包含了對所有傷害的抵抗力或是對特定傷害的防禦力。
2,3,4 我忘了這到底在寫什麼,看來十分愚蠢。

#3

更多關於技能樹的筆記。在右上方可以看到我所畫的遊戲循環。

Play->Fun+Change->Death->RPG

這個循環是我們一開始就打算做的。分析所有遊戲內的機制都是為了滿足這份體驗,像是你在其它RPG所遇到的一樣。這是一小部份的筆記,但這是真的很重要的一部份,這也是為什麼它會被寫下來。

這裡也有寫下特徵系統為是如何被看待的。它們看起來像是圖騰。

我們也有記下角色職業的筆記。所以你可以看到原始概念,騎士可以擋住傷害、忍者可以瞬移。我們也有另外的職業可以衝刺攻擊,但在早期的設計被砍掉了。衝刺移動為了重新滿足符文系統後來被加回去。

在這你也可以看到原始的遊戲控制設計。B鍵是職業的特別能力,Y是藥水(我們本來打算設計讓玩家可以有可消耗道具)。

大多的項目在最後版本都被徹底簡化。像是以上所說的,衝刺變成符文,Y鍵變職業特別能力,技能變成單鍵使用而不是方向鍵加動作鍵。而藥水成為臨時消耗品。

這些大部份的原始設計大多沒有成為產品。我們常在重新檢視我們的遊戲,並將某些項目開始做之前就刪除。這也是另一個原因,為什麼我們不看重設計文件。它讓我們的行動不再敏捷。

很多人說實作雛型是重要的,但同時給予雛型方向也是很重要的。如果你做的事只有10%機會放到遊戲內,則這是浪費時間的。所以將某些意見刪除是可以省下很多時間及金錢。

#4

這份文件描述地圖生成器是如何運作。

上面的字都很簡單,關鍵字足以勾起我的回憶。我的經驗中,一長串的文字解說未必有幫助。有以下幾點原因。

1 可以節省設計者的時間
2 這只有設計者會讀這文件
3 這限制了創意的發想
4 這不是個理想的資料給程式或美術。因為我並不是專長於那些領域,所以寫下我所知道的細節,對工作並不會有幫助。

當這些事被寫下來,這同時也賦與了這些意像其創造力。因為它是真正被正式記錄下來,而不是只是隨口說說。我知道這聽起來很好笑,但這是真的。至少我認為是真的,對我而言。

同時,事情也從未照所寫下的執行。這也幾乎不可能去預測這個點子多困難被實現,這最好能保持單純。這樣當另外的團隊成員加入時,可以隨時更改它。同時,人們也總時很懶散,而非愚蠢。他們總會將點子的印象記在腦子,如果他們忘記了,沒有人能從60頁的厚重設計文件內去找出一個正確的答案。

** 重申一次這份文件在製作時持續改進,而且我也從未在5人以上團隊工作。

#5

這份筆記詳述了舊職業及特徵系統。本來基因特徵系統並未存在於遊戲內,特徵有點像是天賦。一個角色可以擁有主要加強法力的天賦,而副天賦力可以小幅強化其它能力。這雖然有點複雜,但這就是在我們重新建構新系統前的原始天賦系統(新的是基因系統)。這是少部份被移出正式版的特色,另一方面它也讓工作變得相當麻煩。

這遊戲同時也有可以多次升級職業。下面的例子是"礦工、冒險家",而騎士及法師就沒有舉例了,因為他們是相業單純的職業。我們必須先確定這個系統能應付最複雜的職業需求。這份筆記上,冒險家能強化藥水能力。

這算是非常無用的能力。

#6

這頁描寫的很單純是整個遊戲的概略設計,你可以在腦中視覺化這些項目,且你的筆記會涵蓋這些項目。這頁算是一種思緒的整理,像是重點筆記,這歸納了我的所有想法,確保沒有遺漏的部份。

歸納自已的點子也是個將工作確定的好方法,因為這可以強迫自己去想過一次整個遊戲的各個項目。你會發現其中多餘的設計。歸納可以讓你整合及移除遊戲中不需要的元素。

這頁的下方簡述了戰鬥,而更下方則是初始關卡結構。

我們知道自己想要找到方法去固定部份遊戲,但又要能提供每次遊玩的不同體驗。初始想法是擊倒一個魔王後有部份的關卡會被鎖定。這想法很早就被丟棄了。理由如下:
1 太難去實作
2 太難讓玩家瞭解
3 太愚蠢的點子

#7

這額外的筆記你可以看到更多天賦的例子(例如:舊的特徵)

這天賦下方是我們的新消費系統。之前有提到Rogue Legacy原本擁有XP及金錢系統。金錢可以升級圖騰(後來的莊園)。這個金錢即使死亡還是會存在,XP則會被重置,除非你拿去升級,否則死亡時所有XP都會歸零。

每次升級你的基礎能力都會上升,而且這有個公式確保玩家可以不斷升級。這個系統太複雜了,而且我們遊戲要用XP升級,看似不太適合。

這是個困難的抉擇,但我們決定最佳方案是拿掉其中之一的消費系統。所以我們把XP給拿掉,將金錢變成唯一的升級方式,而且金錢也取代原來的XP作用。

這個改動造就了我們最具代表性的想法之一。舊的XP系統提供了rogue-like的概念,因為每次你死亡你就流失了所有XP。我們不能對金錢做同樣的事,所以我們必須用其它方法解決。最終決定建造這座城堡。甚至將死亡掉落金錢給拿掉,迫使你在重新進去城堡內前,花光身上的錢。

最後一點,我真的討厭砍去XP系統。不只因為我喜歡它,因為我曾經加入了它,我應該更有遠見去考慮到這是不適合的。我並沒有仔細去想過,我應該可以避費浪費許多開發時間。

XP是另個被完全砍去的系統。XP內的項目也沒有被保留在遊戲的其它部份。連帶受影響的不只設計者,而是整個團隊。所以嚴格看待你提出每個點子。

#8

這個篇幅比較短。只是記下通常的平衡問題。我一開始希望

玩家技術 >>>>> (遠大於) >>>>>>  遊戲時間

但我們仍然希望即使玩家技術不好的人可以過關,所以花時間累積是個可行的選項。這面就是在說如何管控玩家傷害、生命等。確保玩家在短期遊玩時不會感到突兀,但長時間會對遊戲有影響。

#9

有關Fairy Chests的概念寫在這裡,連帶發展出符文系統。

符文系統允許玩家將用類型的符文裝在身上,與能力相乘成長。

原本符文系統的點子是比字面上更加強大。例如:一種符文是給予陷阱無效,而加上額外符文時會再有另一項傷害無效。當然不能強到過頭,所以我們限制符文的上限是5個。這仍然使技能無效的點子太過複雜,不只針對程式,還包含如何顯示給玩家。所以我們拿掉所有傷害無效的符文功能,為了更加簡潔的系統。

陷阱無效最終成為了特別的道具(飛鞋)。
#Hermes boots宙斯之子Hermes的鞋子,法國時裝品牌愛馬仕。

飛鞋讓故事更多了些浪漫的氣氛。因為我們會不斷重複遊玩,所以我們決定拿掉有特別背景的技能,讓我們有更多的創作空間。

#結尾

就這樣。希望從這些枯燥的東西帶給大家些樂趣。

2018年2月7日 星期三

[翻譯]製作20XX的故事(上)

原文:
https://www.gamasutra.com/blogs/ChrisKing/20171115/307769/Making_20XX_Listening_Well_and_Lucking_Out.php

嗨,我是Chris King,我最近釋出了遊戲20XX。20XX是個洛克人X、ROUGE-LITE、結合傳統橫向捲軸動作(classic action platforming)及自動生成關卡(random level generation)及永久死亡(permanent death)的遊戲。
20XX的最終美術畫面,我們重新設計了好幾次。

這文章中,我將說明開發中的重大時間點,並且稍微說明過去這四年我們學到了什麼。

開發真相


20XX是用C++自製引擎製作。我為了履歷而自己製作引擎,本來打算遊戲完成後可以用遊戲開發者的稱號來找工作。我從如何畫出三角形開始做起,20XX也是從這時候開始。我們實在應該直接用Unity的。

產品開發時間軸

第一天: 2013/7/1

Steam Early Access: 2014/11/25(512個開發日)

推出1.0版(離開Early Access) 2017/8/16(1507個開發日)

詳述時間軸

2013/7/1 開始開發20XX

我做了一個非常簡單的20XX雛型,且到reddit(/r/gamedevclassifieds, /r/forhire)去找到遊戲美術,Zach Urtes。我們簽下了6個月的專案合約,準備去完成我們絕對完成不了大架構。他創造出了第一個Rollster角色(看下面的雛型美術)。

我存下了第一個雛型的畫面,還有"ix"的血量條。
ix代表了第9個我們開發的角色模組,但我們在Mighty No. 9出現後,把它改掉了。
紫色的條狀是梯子,這是我們所捨棄的企劃,很可怕的梯子。

2013/8/31 洛克人之父"稻船敬二"發起了Mighty No. 9 Kickstarter

我花了一個星期的時間去觀查他們的Kickstarter及它所帶來的群眾效應,我覺得被完全打敗了。我花了很多時間(我那時候非常沮喪)研究MN9的專案價值,而且我得到2個重點:

1 MN9的盛大迴響證明了傳統洛克人遊戲在市場上仍有需求

2 我們都有著各自的想法,但我們是非常不同的遊戲。我知道嘗試去做一款和洛克人一模一樣的遊戲是不明智的,所以我做了一些基本上的重大變更。加入我最喜歡的roguelikes及重複可玩性,我們給予了20XX隨機生成關卡及永久死亡懲罰。加入我喜觀的各種怪物及莫明奇妙的特色。我們同時設計區域及線上的多人遊玩模式。這些都是MN9沒有的大賣點。

我們幾乎要放棄20XX了。但是我選擇了去相信這世界是足夠容納20XX及Mighty No. 9的。

2014/1/1 Zach的合約超過6個月的預訂週期

我們決定四月去PAX參展,並開始我們的Kickstartar及Greenlight專案,幾乎是同一時間。我為所有我能找到的發行商做介紹,並全部被拒絕了。(我相何他們做了很合理的決定,我們在那時候還不是很好的遊戲。我們用來簡報的雛型也很簡陋)

我開始尋找音效設計師(啊!!我們真的用暫代的音效展示給開發商)。我們第一次出擊並不讓人印象深刻,我們是這樣告訴自己的。

- 我現在還記得我很興奮地送出開發版本,也記得因為對方不想幫20XX做音效所遭受的打擊 -- 因為這是個不好的專案。我很想為自己辯解,但我選擇問他哪裡不好、哪裡我們該改進,並且感謝他給予我們一長串的改進建議。這給了我們很大的改進空間,並讓遊戲變很更好。這教了我如何從批評中取得資訊。這成為20XX開發的基本要素之一。

我們找到了音效設計師Brandon Ellis(Cityfires),他為我們做了20XX中所有驚人的音樂。Brandon 確定了我們的風格,讓遊戲立刻大大地躍進。

2014/4月  我們同時參加PAX East、開始greenlight及Kickstartar專案。我們開始有點厭惡自己了。

Kickstartar是個全職的工作,在第一天我們決定不要一直盯著專案網頁看。若你打算將Kickstartar與展覽結合,在展覽結束後再開始KS並積極地搜集所有展場上對你有興趣的玩家的EMAIL,可以讓你不會忙到崩潰。

- 我們從第一次出展PAX中學到了很多,這些經驗我過去曾經記錄過,過去的我可能比現在的我更能說明這些經驗。

- KS是殘酷且高壓的事情,我們做的是正確的事但沒辦法將所有時間花在其中。事情過後,我們瞭解到專案過早進行了,等視覺做的更好後可以有更好的成果。但在那個時間我們並不知道這些事。我們的回覆也太過於輕浮且不專業,這會傷害到我們自己。

KS的這個月是我人生中最痛苦的一個月。我若沒有強大的耐心及朋友的幫助是撐不過來的,包含了Bianca(早期行銷、社群推廣、注意東方市場、處理KS之外的垃圾事務、和我結婚"這特別重要")、DJ(雖然沒有和我結婚但幫我建立了初期我們所需的網路推廣)、Chase(測試一堆我們早期的糟糕版本、在我做出一堆垃圾時還持續支援我)。
2014/4月的美術畫面

2014/9月 我們與Fire Hose Games合作

我在IGDA 的會議上遇到了Eitan。我們同意他幫助我們讓遊戲變得更專業,令它可以到足夠販賣的程度。這是我們其中做過比較好的決定之一。Eitan有很多我們所缺乏的業界經驗與人脈。

我們將專案的規模放大了一點。取而代之不在11月釋出最終版本,而是決定釋出Early Access版本,且藉由社群的意見建構剩下的部份。

2017/11月 20XX釋出Early Access

第一天我們只賣出了64份20XX。我嚇到了,我們做了一連串的承諾給社群,而且盡了我們最大的力氣去維持。

- 我們承諾在Early Access期間,每兩週更新一次,我們在每二個週三的晚上6:00更新。我們在遊戲內放了個時鐘,清楚地告訴玩家下次更新什麼時候會出。我們很準時依Early Access的計畫更新,大家都很喜歡我們的更新時鐘。這使我們獲得很好的社群印像,而且給我們很穩定、有週期的方式得到我們接下來工作的反饋。

* 千萬不要許下自己做不到的承諾。若你訂下個日期但沒做到,那會比沒有任何承諾還糟糕。如果我沒記錯,在70次的更新內,我們有2次沒有準時達到,一次延遲了1天、一次延遲了1小時。

- 我讀過每篇在Steam社群的文章、每篇在reddit /r/20xxgame 的回覆。(/r/20xx是被廢棄的舊討論區了),及每篇e-mail。我回覆每一個人,而且當社群成長,有一部份玩家會對我提出更多平常的問題。

* 我們的成功一大部份來自於長時間的分析社群反饋。篩去情緒上的字眼再去分析剩下的。當玩家很喜歡你的遊戲時,不會只用客觀的角度提出建議。同時也不要將憤怒玩家的好建議給踢除。

- 我儘量將我們所做的事對社群公開,讓玩家的意見來決定我們的規劃。若大部份的玩家對某Bug十分在意,我們會停下手邊工作來先修復它。若社群認為我們的方向錯了,我們就認真的論是否我們要修正方向。

* 在2015 9月時,我們花了很多時間改造Ace及Nina的角色設計。
上面是20XX重新設計的角色(2015夏季)
下面則是之前的設計

- 新的設計讓我們獲得了前所未見的負評。我們十分沈重的討論,放掉所有我們決定在Beta所做的項目,將心力花在重新打造舊的角色設計(藉由之前錯誤設計的教訓)且剛好完成新的展示影片及宣傳在beta釋出前。
重新設計後的角色們,在推出前又再次改進了一次

- 這次的調整是我們最大幅度的修改我們的計劃。我很確定如果我們堅持修正我們的槍而不去重新設計我們的角色,我們在beta時就會淹死了。

* 對社群開放不表示你要過渡承諾,分享你可以掌控的項目。

2015/3月 了解到我們的遊戲需要提供視覺設計,我們雇用了Clemens Scott

Clemens(最近的作品是Broken Rules工作室的Old Man’s Journey)花了6個月,將我們的遊戲由"沒有吸引力的"變成"極具特色的"(巨大的躍進)。沒有了Clemens的幫忙,20XX宣傳不會如此成功。

2015/4月 我們第二次在PAX展出我們的作品,這次在我們喜愛的Indie MEGABOOTH展出。

這次比我們上次展出好多了,而且我們甚至得到了些宣傳。接下來的一個月,MANvsGAME 及Zeke(Ezekiel_III)開始實況20XX,那時是凌晨兩點,我正在Bianca(女友/現在是未婚妻)的家裡。我一直看到凌晨五點,好險他們沒有把我怎樣。有了Clemens的第一波美術改進很令人興奮,這是很有幫助的合作,我們在隔天就賣出了64套遊戲。而且我簡直如同過節般的快樂。

在9月15號,Mighty No. 9也宣佈了他們的第一次延期。這並不是什麼壞事,延期總是會發生,這時他們也解釋了為什麼會延期、且告訴大家正在努力。

2015/5月 資金快要見底了。Bianca私人大力的贊助我們。她是真的是我們的天使。我去銀行貸款了,所以我可以繼續雇用Zach。

2015/8月 Mighty No. 9第二次延期了。這次他們處理的比較不好(有很多文章講這件事-例如這篇https://kotaku.com/the-story-behind-mighty-no-9s-shady-delay-1722766843)。Mighty No. 9損失了不少支持,我們覺得這是宣傳的好機會。

在MN9宣佈延期不久後,我們發佈了Beta版本。我們受到前所未有的媒體關注,我們由販賣不到多少款變成銷售成績不錯的遊戲。

我們仍然很辛苦的在開發,但從現在開始20XX賺得的錢比開發費用還要多了。蜂擁而來的玩家、收入、與評價完全出乎我們意料之外。之後的一個月,我們保持著穩定的銷售狀況且終於還完了借款。

2016/1月 20XX已經成長了。我們決定在每個更新前都需要社群的意見。

我開啟了我們的"超級好友"群組,為了在上線前的早期開發就能取得玩家的意見。我們盡了最大努力讓早期版本能覺得好玩。上線前看新的物品及關卡是很有趣的,但測試引擎的改版則是不是。

我們提供他們初期的開發關卡,能完成這些關卡真的是需要很多好運。第一版的這些關卡還需要很大部份的改進,而超級好友的意見正是改進的重要來源。

2016/5月 我們決定20XX應該有些過場畫面(所有專業的遊戲都有過場畫面),所以我們開始徵人。

過場畫面真的是件很難做好的工作。我們花超出預算且整個流程花了14個月完成。我們之中沒有人專精於此,所以要討論我們到底要找什麼東西是困難的,但經過了這一切,相較於我們學到了許多東西,我更覺得我們是僥倖存活了下來。

2016/6月 Mighty No.9 PC正式版釋出
玩Mighty No. 9不如玩這個吧.

在MN9釋出之前,20XX最中肯的評論是"如果你不想再等Mighty No. 9,你可以來玩這款"。Mighty No. 9發售之後,雖然它做得還不錯,但仍不如它所宣稱的那麼好。這些評論也改變了,很好運地,MN9釋出的日期正好差不多是Steam的夏日特賣,20XX剛好接收了對MN9失望的玩家。

從此開始20XX的開發變得順利許多。我們維持了一定的銷售量,並在每次特價時期提供20-25%的折扣。直到2017/8月1.0正式版釋出為止都十分順利。

2016/12月 我們發佈了"piecemaker"試驗,讓玩家可以使用我們恐怖的關卡設計工具。

這個遊戲工具糟透了。超過一百位自願實驗者,只有兩位有拿出一點成果,而其中之一將它放入了遊戲。這百分之百是我們的錯 - 我們的關卡設計系統太笨重且很難以上手。

- 做一個更好的編輯器成了1.0之後的問題。我們仍然(至2017/11月為止)在思考這是否為20XX合理的計畫。(如果你很有經驗做遊戲編輯工具快來聯絡我吧!)

2017/8月 過了71個持續性的隔週更新,20XX離開了Early Access,在PC上推出了。

我們做了新的展示影片,但這100%仍然是動作取向。(歡迎大家關於這點提出意見,我們認為這方面還有很大的改進空間)

之後的1個月,我們和幾乎每個對我們遊戲有實況主接觸,並親自寫了信件給媒體。我們並沒有得到很多回應。有3個比較大的媒體會在發行時幫助我們,這是其中一個。(Tim的影片十分強大,即使你不喜歡20XX)。當Kotaku影片發佈時(約遊戲發行後的第3天),我們的銷量比前面的2天暴增了30%。雖然很難指出多少是被影片吸引的(20XX在週末也總是賣得比較好),但這仍然給了我們很大的幫助。

有一大部份來自於我們的發售時在Steam的銷售排行前20-25名。Steam的排名拯救了我們的能見度。雖然我們在媒體上沒有很到很大的曝光,但在Steam的演算法下我們賺到了不少,我們在發佈的首週表現得很有競爭力。

最終產品

未完待續(下篇會歸納從製作中習得的經驗)

2018年1月30日 星期二

[翻譯]專案管理 Part1: 避免遊戲工作破壞腦袋


原文:
http://www.midnighthub.com/blog/2017/11/01/project-management-part-1-avoid-brain-damage-from-working-with-games/



作者:Sara Casen
遊戲開發者,過去在Paradox及Tarsier任職。現在經營Midnight Hub,之前在Casen Crowd,社群經營公司。

為什麼這麼多的遊戲工作室超時工作?如何避免你的組員的熱情燃燒殆盡?以及如何讓你的開發夥伴投注熱情及創意在工作上?及有什麼方法可以取代惡名昭彰的遊戲開發?若你是個管理者從專案開始便將超時工作視為正常,或是認為燃燒熱情本來就是製作遊戲的一部份,那這一系列的開發文章不是為你所寫的。但是你若好奇為何我們花上數個小時來寫這篇文章,你想去最小化你的團隊的壓力、或你想要些遊戲專案管理的秘方,那就讀下去吧。

遊戲製作生涯的平均長度

這個夏天我參加了一個遊戲CEO及管理者的聚會。這個聚會在德國旁的小島上。北歐國家的管理人都在一起討論遊戲產業的現況。在這會議中,大家談論了北歐遊戲製作生涯的平均長度。猜猜看是多長?答案是4年!平均開發者會在4年之後離開遊戲產業。他們可能燒光了熱情、犧牲了健康、或花光了資產。我並沒有確切的數字,但有報導指出這個產業是如何一次次的消耗熱情,使其產業活下去。超時工作被視為常態,一週工作80小時並不少見。但科學證明這並不能讓遊戲變得更好。

在過去百年來的工業研究證明了以上的問題,過渡工作的工人造成更多的錯誤、計劃延宕、損壞工具、多餘的支出、降低貨物的品質、甚至影響收益。他們對於專案、管理、員工、其它人甚至自己都是危險的。
– Evan Robinson, IGDA “Six Lessons On Why Crunch Mode Doesn’t Work”.

在2015年我們開始了自己的工作室 "Midnight Hub",我們想要做些改變。之前我們曾經在Minecraft、The Division及其它專案工作。我們的目標是用穩定的方法持續產出獨特的遊戲。我們是5位獨立開發者,現在花了兩年在第一個遊戲上。"Lake Ridden"。這是個單人第一人稱充滿神祕的解謎遊戲。我們並非總是做對所有事情,但我們仍然努力去嘗試。

這段時間我們儘量不超時工作,我們仍有效利用工作時間且產出許多我們遊戲的文件。我們團隊儘力做出最大效率的產出,並且確實記下每個人的壓力狀況。我將在這分享專案管理的哲學。我們是如何最小化壓力所帶來的影響,並且讓遊戲可以準時在2018春季上市。這包含了許多的層面,所以我將它拆成三篇文章,每篇專注在不同的方向。

提醒一下大家,我們是生活在社會主義的瑞典,這邊一般工作約佔每週40小時,而且員工有權力要求數週的休假及帶薪產假、陪產假。遊戲產業在這邊會更加的扁平化及外國人稱讚我們會主動幫助工作上的夥伴。我們通常也鼓勵彼此做各種嘗試,並且也不認為上司會知道所有的知識。不幸地我們也是會被壓榨的,很多人在遊戲業的工作時數也很長。犧牲假期去追求永遠也無法完成的完工日期。最後迫使他們帶著極大的工作傷害離開遊戲業。

為什麼我們以這種方式工作?


我第一個遇到擁有真實人生的遊戲開發者,是在DICE的Battlefield 1942團隊。他告訴我團隊是如何被消耗到最終失去了他們的熱誠。他們睡在自己辦公桌而不回家,他們的腦袋漸漸地變得緩慢,人們忘了如何去談話、憂鬱、失眠、漸忘。這些都是持續強烈的壓力的徵兆。這些逐漸地傷害你的身體、神經系統、及腦袋。思考看看由製作遊戲造成的腦部傷害。這是有可能被修復的,即使在有社會醫療良好的瑞典,也要花一段很長且辛苦的時間。

在這種工作環境很容易發現一個問題,一些很優秀且具熱情的開發者會不斷的流失。而且當他們開始覺得這是正常的,所以認為忍耐才可以讓事情完成,認為這樣才可以讓遊戲做出來。遊戲當成藝術媒介或故事媒介,這並不是個累積業界經驗的方法。因為有想像力的創作者會在幾年內被榨乾,大多數的人們不會想再次回到遊戲業。那個他們花費許多投資及時間去完成作品的地方,同時也將他們燃燒殆盡。若你也曾經因過渡工作而腸思枯竭,甚至你還需要面對這種症狀數十年。而我們是如何讓遊戲媒體帶邁出這種困境的。

當你擁有創意的人、對工作的熱誠、完美主義者,並將他們混進數千萬預算及糟糕的排程,事情通常會變得很糟糕。人們被強迫超時工作,最終失去他們。不僅是過渡工作同時也無法讓遊戲品質提升。

公司的佈告欄,給予大家分享及鼓勵彼此

為何要用穩定的方式製做遊戲?


所以為什麼我們想要減少壓力、避免超時工作及從第一天就開始防止員工流失?也許是我瘋了。但能成為一個正常的人類感覺很好。若你想用同一批優秀的人才做出更多好遊戲,你該避免讓他們過渡工作。壓力降低了我們的耐心及溝通(你是否看過團隊成員在類似狀況"我不想立刻和你解釋,快去處理它")。遊戲開發是一個團隊運動,若你不打算溝通會造成分崩離析。據我的經驗,壓力是人們開始爭吵的主要因素。

另一方面,人類(抱歉,我遇到某些管理者視人類只是種資源),我的專案管理經驗中,大多份管理者只把人類視為一個可壓迫的變因。若金錢、時間、其它因素是不可變的,那人們就會驅向更加壓迫人類變因。那是因為你很難去衡量能由人類身上取得多少。有的人每週可工作80小時,有些人每天工作6小時後就沒力了。所以管理傾向儘量壓迫人類資源。你知道你在銀行的金錢什麼時候會燒光,但你的員工呢?當你知道迫使人們會失去熱誠,可能已經為時已晚。在我的觀點中,取得金錢要比修復人們的工作傷害要簡單多了。

較短工時的科學根據


有很多研究顯示更多的工作時間並不等於更多的產出。就像是做多件工作比較划算一樣(還需要付出切換工作的成本),讓你感到很有效率但事實不然。若你是在做高腦力的工作,像是編寫程式、寫故事,實際上人腦一天只能夠專注約六小時。過了這段時間,你開始懈怠且開始犯錯(無論如何,這仍然會讓人們感到有效率),然而你必須在隔天整理昨天幹的蠢事。專注於聰明的工作,而不是努力的工作。我相信聰明的管理者該妥善利用各項資源,來做出最佳的遊戲。為什麼不該把這些技能也用在員工身上。

找到新的團隊成員、安置他們、提升效率、確定他們符合團隊等等,是一項艱難的工作。所以照顧員工一直以來都是個好的投資,總比盡力壓榨他們然後再找新的人來取代。老實說這也是因為我們相信一定有更好、更人性的方法來做遊戲,讓開發者有效開發及玩家喜愛。

製作迭代前後比較。迭代是Midnight Hub的主要遊戲製作流程。白色方塊是測試元件,如上圖

事實上大部份的壓榨及超出排程、浪費金錢來自於錯誤的計畫、規模。當然像是引擎意外更新、相同市場上的競爭者、主要成員的離開等重要的因素也是。但我想你若能用乾淨的方法管理你的遊戲專案,會比你增加員工的工時,讓遊戲更有機會準時上市且打造更長遠的團隊。更重要的是,這是你少數你可以真正控制的變因,你無法控制主企劃突然去了地球另一端、或是你的遊戲被破解、或新的遊戲引擎版本讓你的遊戲壞了。但你可以且應該控制你的計劃、遊戲規模、及專案管理,不該有任何藉口。

關於縮減壓力的實際例子


這是我們讓所有人不被壓垮在Midnight Hub做的事。記著若你是領導者或資深開發人員,所有員工都會看著你所做的事。若你不想要讓別人超時工作且親自執行,那所有人會開始真的相信他們不該待在公司太久,言教不如身教。

-減少在公司的時間。我們待在公司9:00-17:00,且有1小時的午餐時間。
-所有人同時間離開公司,沒有人會獨自留下辬公。
-管理必需避免員工超時工作及壓榨。
-所有員工放的到特休
-若你正在處理巨大的任務,可以調整成只工作80%或50%時間。因為那些任務可能會榨乾你的精力。他們可能是你從來沒做過的事,非常困難,要花了數週、數月去完成,而且做錯了會有很嚴重的後果。像是擬定開發合約、對投資人的簡報等。
-規畫時間緩衝放假的心情
-在假期內完全關閉辦公室,不讓任何人單獨工作。
-員工生病假的第一天就可以拿到80%薪水(瑞典通常第一天不支薪)
-在規劃時期給出更佳且更實際的時間估算
-用ABC法則製做遊戲(接下幾篇文章會提到)
-在每週開會評測每人的壓力


整理一下

在Midnight Hub開始時,我寫了有關如何白箱測試遊戲的文章,迭代開發每個部份。我們如何用敏捷開發的方法,將測試用美術轉成可正式美術素材每次一個迭代。這方法讓我們不用花費過多時間就可以有機會測試它,我們現在將其粹取出來。我會在下一章解釋如何用這方法,讓你有機會試用這配方,我們叫它"ABC"。之後我將告訴你,我們如何用實際的金錢去估算時間且規劃我們的迭代。我的目的是分享這方法幫助大家建構長久的團隊,且讀者的回饋也可以幫助改良我們的方法。你在工作上所耗費的心血將不會對你自身造成傷害。