設計中的優先順序(上)
我現在已經把車開上了馬路,這也就意味著,新的一期的《行路雜談》就要開始了。今天我們的主題是:設計中的優先順序。
我在部落格和社交媒體上經常聽到的一個問題是這樣的:“我想要事件X發生!X是對我非常重要的東西,對我來說,事件X是我在萬智牌中最期待的!”然後有些時候,玩家會在一段時間後繼續問道:“我喜歡事件X,為什麼你們還沒有做事件X?”有時候,這樣的問題只會有一兩個人問到,而有時則是很多。玩家們想要一個東西被設計出來,而當時間流逝,他們看到這件事並沒有發生之後,他們就會變得越來越沮喪。尤其是一個他們認為非常契合他們願望的系列發售,但是卻沒有看到願望實現的時候。
這正是我今天想要討論的問題。我把它叫做優先順序問題。如果玩家向我反饋一些事情的話,那麼這些事情在他們的心中佔有很高的地位,也就是說這件事情在他們眼中的優先順序很高。但是故事並沒有這麼簡單,因為玩家們的優先順序並不等同於設計組的優先順序。畢竟玩家們不可能僅僅希望一兩個事情發生。我們收到成千上萬個玩家的反饋,所以就會有成千上萬個願望。而我們做的是盡力使得大部分玩家開心,所以我們一直在找機會來讓玩家期望的事情發生。玩家的願望多種多樣:我們還沒有做一個特定型別的指揮官,我們還沒有做一個特定效果的神器,或者是主題層面乃至更大層面上的問題。而對於一些專注於某些玩法的玩家來說,這個願望的實現對他的萬智牌遊戲體驗會有巨大的影響。我並不是否認玩家們的願望,也並不是認為某些願望不會實現——事實上我們一直在等待機會滿足一些小眾願望。畢竟我們工作的一部分就是讓玩家願意花錢去買萬智牌的產品,而我們這樣做的途徑肯定不是用什麼手段去逼迫你買牌,而是讓你從萬智牌中獲得樂趣,從而心甘情願地掏錢,因此滿足玩家的願望是我們中很重要的一點。我想說的只是:你覺得最重要的事情可能對我們並非如此。
首先,我們在做很多設計的時候並不是聽從玩家的願望才設計的,有一些很棒的設計玩家們並沒有想到,但是我們卻做了:像是雙面牌和混血法術力。很多創新設計和玩家的反饋沒什麼關係。所以造成我與玩家們的優先順序差別的一個原因就是,當我想到一個設計並相信玩家們會很喜歡這個設計的時候,還沒有玩家想到這樣的設計呢!
另一件事情關於組織工作。玩家們不需要關心如何做到他們想要的事,但我們關心。在這裡我想要舉一個艾卓王權裡的例子。當預覽到七個矮人的時候,有人說:“如果七個矮人能有七種不同的插畫的話,那就太棒了!!!”是的,我承認那確實很棒,但是這在實際的操作層面並沒有那麼簡單。
我們應該如何將這些不同的插畫安排到印刷版面上呢?通常我們在印刷版面上會留下幾個位子來讓我們印異畫牌。但多出來的六張插畫太多了,這就導致我們需要改變我們的印刷版面。當然我們不是沒有做過很多異畫的系列,但是那些系列往往不是標準賽制系列。在一個標準賽制系列中,單卡的數量相對來說更為固定——我們有101張鐵牌,80張銀牌,53張金牌和15張祕稀。正因如此,我們在鐵牌的印刷版面裡並沒有6個額外的位置來印6多出來的6張異畫矮人。而其它的系列(例如大師系列)的印刷版面則更加寬鬆,允許我們印比較多的異畫牌。
而正是因為標準賽制系列同時也要作為輪抽系列,強行加入6張異畫會帶來很大影響。因為我們要保證每一種畫的矮人都會出現在同一個印刷版面裡,所以七個矮人就將會出現7次。這就代表著兩件事:1.七個矮人在輪抽中出現的頻率將高於其它鐵牌;2.由於七個矮人佔了其它鐵牌的卡位,某些鐵牌出現的頻率就會低於平均值。並且在插畫任務的分配上也會出現一些問題。儘管與我們合作的畫家的數量能夠保證一定的靈活度,但是一下子增加6張插畫就有可能導致某些插畫的數量被砍:像是食品衍生物的插畫種類等等。總之,我承認七個矮人7種插畫的想法很酷,但這個想法的真正實施需要克服很多組織工作上的阻力。因此我們最終沒有這樣做。
總之,七個矮人的例子是“這件事確實很酷,但是做這種事的代價太大”的一個例子。從更籠統的層面上來說,當玩家期望一件事情發生的時候,一般會有以下3種情況:1.我們完全可以做這件事,但是要等到合適的時間場合;2.我並不確定我們會不會做這件事,因為這件事的發生需要特定的環境;3.這件事在萬智中很難做到,除非萬智牌發生了什麼重大改變。讓我們來討論一下這三種情況。
第一種情況,這件事完全可以發生,只不過是時間的問題。而有的時候這種事情的發生也會等待比較長的一段時間。我在祕羅地系列設計了能量機制,但是當時能量機制並不契合這個系列,所以它就被砍掉了。但是我一直相信能量機制很有趣,也很符合萬智牌的意境,我也相信玩家們會喜歡它。所以我一直在嘗試尋找一個能夠契合能量機制的時空。而在多年以後的卡拉德許,我終於能讓能量機制發揮用武之地。而這樣的等待花了十幾年的時間。當我們認為一個東西很棒的時候,我們自然想要將他設計出來,但是我們依舊需要找到合適的時機。
另一件我們考慮的事情是:既然我們是系列的設計師,那麼我們關心的就不僅僅是某一個系列,而是將這個系列和在它之前之後的幾個系列當成一個統一的整體來加以考慮。當我設計一個系列的某些單卡的時候,我要保證其中的一些卡可以補強之前的思路,同時我也要保證其中的一些卡可以為之後的構築思路打下基礎。而玩家們經常只會考慮到之前的系列中有什麼,而不會去想之後的系列可能會出現什麼,這就是玩家和設計師的分歧之一。比如,在卡拉德許時空,玩家們反饋說想要一個神器主題的紅藍雙色傳奇生物,這樣就可以填補他們指揮官的空白。然而最後他們發現並沒有這樣的生物,於是他們非常沮喪:“卡拉德許是神器的時空,而紅藍在卡拉德許中又是神器主題的顏色,而你們竟然沒有設計紅藍神器主題的指揮官?”而我想說的是,紅藍神器主題的這個卡位給了莎希莉,一位鵬洛客。儘管我們知道玩家們很想要紅藍神器主題的傳奇生物,但是莎希莉畢竟是補充包上的封面人物哎!她在卡拉德許中扮演著重要的角色,我們怎麼能夠輕易地把她的卡位讓出來呢?
事實上,我們也確實做了紅藍雙色的神器指揮官。因為我們知道我們會重返多明納里亞,而晴空號船長尤依拉正是這個指揮官的最好人選:她是紅藍雙色的傳奇生物,而因為她是晴空號的船長,所以她又和神器有很大關係。因此當你覺得有些事情在它應該出現的最佳場合卻並沒有出現時,也許只是你沒有看到設計師們的想法——他們已經在更合適的位置做出了你想要的設計。
我們的設計週期也會導致實現玩家願望的延遲。假設你告訴我一個東西,而我覺得非常有意思,並打算把它加到我正在著手設計的系列中。而離這個系列發售還要有差不多兩年的時間呢!所以,如果你向設計團隊提出了你的訴求以後過了幾個月無事發生,那麼請稍安勿躁——也許我們已經在做了,僅僅是時間問題。
第二種情況是我並不確定這樣的設計能不能發生,但是這一定需要很特別的環境。比如,我們在預知將來環境裡做了一張叫做莫甘達巖畫的卡:
它能獎勵白板生物思路。然而這張牌事實上存在著一些問題,這我在之前的行路雜談中也講過了。總之我們發現做一個有很多白板生物的系列是很難實現的。白板生物對初學者很友好,但是玩家想要做的可不僅僅限於進攻和阻擋。總之,想要做出莫甘達系列的話我們會需要其它很多元素,而白板生物應該僅僅是其中的一小部分。不過在一個有很多變身生物或者很多衍生物的系列中,我們會不會讓白板生物成為一個主題呢?我不會說這一定不會發生,只是這種事情的發生需要太多的天時地利。我們有一個清單記下了玩家們的這類反饋,並嘗試在某些特殊的情況下將一些願望變成現實。但很多時候玩家並沒有意識到他們的願望被實現的難度有多高,因為玩家們只需要去想象一個東西,想象它會有多棒,但是在設計過程中,這裡面的影響因素就太多了。所以當有人在網路上問一件事情的時候,我在心中已經知道了它其實並不是很可行。
第三種情況就是玩家的願望和我們的設計思路相悖。而這些願望是最難的。但誰知道呢?時過境遷,誰也無法斷定我們在以後的設計思路會不會恰好可以讓這一類訴求得到滿足。從我自己的工作經驗來說,如果在我剛剛開始設計生涯的時候有人問我:“你們有可能會設計X嗎?”我會說:“噢,X太瘋狂了,它不會發生的!”但是回顧我的生涯,我們確實做出了很多瘋狂但又成功的設計,所以也許現在覺得不可能的設計在今後也會發生。誰知道呢?
另一件你需要知道的事情是,我們做了很多市場調查,所以我們有很多渠道可以從玩家那裡得到反饋。我們有銷售資料,電子版資料等等,玩家們在玩線上版萬智牌的時候,我們也在後臺收集著資料。從店家,社交平臺上我們也能夠獲得很多資料。而我在判斷玩家反饋的重要性的時候,就會用到這些資料。我需要搞清楚這些東西:1.有多少人想要這件事發生?這僅僅是一兩個人的想法,還是一個小團體的心願,抑或是很多玩家的呼聲?我經常和R&D的其它員工開玩笑說我的部落格是一個晴雨表,因為當我知道一個事情有很大訴求的時候,通常我的部落格上問這個問題的人就會很多。在我的部落格上留言的人實在很多,而我也因此收到了很多情報。儘管我不會一一瀏覽回覆這些留言,我也已經大致瞭解了玩家們想要的東西。當然我的部落格上的訊息並不能代表萬智牌的整體情況,但是它往往可以反映那些最活躍的玩家的訴求。這個玩家群體對萬智牌很狂熱,他們在萬智牌的玩家中可能指佔一小部分,但是卻發揮著舉足輕重的作用。因為這些人通常是萬智牌群體中消費最多的,也是對萬智牌最熱愛的。而當這些人對某一件事感到激動時,他們往往也會帶動其他人。
舉例來說,當我們準備重返多明納里亞時,有些員工提出這樣一個疑問:我們已經有13年沒有到過多明納里亞了,而萬智牌的玩家平均入坑年齡只有10年,這意味著很大一部分人其實並不知道多明納里亞時空。但是那一小部分最活躍的玩家卻認得多明,而他們會對此很激動。於是就會產生一種“光環效應”。就好像是:那個帶我入坑,教我打牌的老前輩對此很激動,那麼我也應該很激動才是!而其它本來並不激動的玩家看到這個社群中的人都很激動,自己也會激動。這就是我很經常和在我部落格下留言的玩家互動的原因。
下篇:設計中的優先順序(下)
作者:Mark Rosewater
譯者:小閃電0124
來源:旅法師營地編譯
相關文章
- 設計中的優先順序(下)
- 中斷優先順序
- java setPriority()設定優先順序Java
- CSS優先順序CSS
- linux中設定程式排程的優先順序別Linux
- 運算子的優先順序
- python運算子及優先順序順序Python
- win10怎麼設定優先順序 win10如何設定程式程式優先順序Win10
- Yacc使用優先順序
- Android程式優先順序Android
- [譯]HTTP/2的優先順序HTTP
- 介紹python中運算子優先順序Python
- SpringBoot配置檔案優先順序載入順序Spring Boot
- 如何在Mac上更改WiFi網路的優先順序 ?MacWiFi
- SQL 優先順序join>whereSQL
- java運算子優先順序Java
- ORACLE中sql語句----運算子的優先順序OracleSQL
- CSS 選擇器的優先順序CSS
- SAP UI configuration determination的優先順序UI
- 測試用例的優先順序
- 程式設計答疑:記不住運算子優先順序怎麼辦?程式設計
- C++運算子優先順序C++
- ansible 變數優先順序示例變數
- Yarn任務優先順序配置Yarn
- 封裝優先順序佇列封裝佇列
- css 選擇器優先順序CSS
- nginx的location匹配順序、優先順序,location對映衝突排查Nginx
- Linux基礎命令---設定程式優先順序niceLinux
- 【pytest】fixture 與 setup, teardown 的優先順序
- 【分享】如何評估 bug 的優先順序
- 怎樣做好客戶的優先順序?
- Java之執行緒的優先順序Java執行緒
- lodash原始碼分析之baseFindIndex中的運算子優先順序原始碼Index
- C++ 運算子優先順序表C++
- C++運算子優先順序特例C++
- Linux排程器:程序優先順序Linux
- 華為路由協議優先順序路由協議
- Python 運算子優先順序 運算子Python