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的演算法下我們賺到了不少,我們在發佈的首週表現得很有競爭力。

最終產品

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