《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

玩Game天堂     2017-05-15     檢舉
《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

《Lost Castle》是一款包含了rogue-like隨機元素的動作冒險類遊戲,製作團隊僅有4人。2016年,遊戲上架Steam,截止目前,已經收到6000多好評,已經售出40萬份。5月13日Unite 2017 案例分享專場上《Lost Castle》製作人何斌從技術、遊戲設計、其他重要細節三方面分享了一些小團隊製作遊戲的技巧。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

大家下午好,我是何斌,是Lost Castle製作人,不知道大家有沒有玩過,這款遊戲已經上線了。我今天講的一個主題是小團隊遊戲開發製作技巧,我們本身就屬於一個小團隊。很巧的是今天還跟之前演講鳳翔溝通過,他講的是小團隊的團隊的成員管理以及項目的控制。我講的是小團隊的一個遊戲開發製作方面的經驗分享。

 我本身是程序出身,所以第一點的話會講一些關於技術方面的開發思路,第二點是我在Lost Castle製作人角度分享一些遊戲設計方面的製作技巧,第三點是除遊戲自身外的重要細節,這一點很重要。每一個點有四到五個實例,我今天講的是比較點狀的內容,可能聽起來會比較累一點。

技術方面的開發思路

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

第一個實例,我覺得非常有意思的地方,但是很多程序或者開發者忽略的一個地方,就是靈活的UpdateMgr管理替代方案。現在很多開發者在默認的Monobehavior的生命周期函數裡寫一些邏輯,但是沒有注意到,這個可以進行一個管理。可以設計一個UpdateMgr,將會大量構造實例類的對象,按特定規則將自身註冊進Mgr里,我們會在Mgr的Update按照規則去統一調用一個或多個對象集的MyUpdate。就是這麼簡單的一個理念。但是其實可以衍生很多東西。

 這樣做有什麼好處,第一個好處會統一調度周期函數,會比Update周期函數回調效率高很多,但是其實這點並沒有什麼意義,因為我們的性能瓶頸根本不在這裡,所以這點意義不是很大。

第二個好處我們可以動態控制Update的執行順序,我們知道ProjectSettings里可以調整腳本的執行順序,但它是靜態的,沒有辦法在運行時動態改變。但是如果去做一個Update的管理,那麼我們可以在運行時動態控制Update的順序。比如死亡生物的Update,可以後面執行。

第三點就更好了,可以更加靈活控制Update的頻率,這樣會節省比較多的性能。舉一個例子,比如你是一個平台類的,你分了好多層,如果怪物和玩家不處於同一層,那麼它的一些腳本Update可以不執行,或者是檢測敵人的Update可以不執行。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

 第二個實例,是Lost Castle內的遮蓋關係實現。如果沒有玩過Lost Castle,右邊這個就是Lost Castle的一個遊戲內的截圖了,是一個斜視角的2D類的動作遊戲。我們在做2D遊戲的時候,遮蓋關係是肯定會遇到的問題。那麼在Lost Castle內是怎麼樣實現的呢? 我們會實現一個SortingModule類,在需要實現遮蓋排序的實體上去掛載這個組件,它做什麼事情呢,只做兩件事情,一個將當前Y坐標乘以1000,以該值遍歷設置所有的SpriteRenderer的SortingOrder;二是根據實體當前Y坐標,換算得到當前Z坐標並設置,這個也貼了簡單代碼去理解。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

從上圖可以看到,左上角,你可以看到Lost Castle其實把場景打斜放置,為什麼?是為了讓點光源效果更好一些。為什麼需要動態設置SortingOrder,因為如果兩個物體足夠靠近,然後Order相同可能會發生兩個物體的子節點前後錯亂,如果靠的很緊,可能後面人的手顯示在前面這個人身上,就出現了錯亂。

 這裡提幾個小技巧:第一個SortingModule裡面,不要在Update里去Get所有的SpriteRenderer。但有時候需要更新SpriteRenderer列表,你可以在SortingModule里實現一個觸發器去做這件事情,比如主角換了一個武器。

第二個是可以將Y坐標乘以1000作為SortingOrder,這個跟腦筋急轉彎有點像,你可以省去排序y軸的步驟,但是這裡需要注意取值範圍。沒有記錯SortingOrder最高是65535。

第三點、在攝像機外的物體,可以把SortingModule停掉節省性能。 另外提一下,其實Lost Castle裡面用到大量的動態光源。我們嘗試過像baking,light probe等技術,但嘗試發現在2d里顯示效果很差。我昨天去問了一下Unity2D的技術負責人,他們說下一步會做2D lighting的東西,所以可以期待一下。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

第三個實例是事件分發的高效解耦,相信大家做遊戲都會用事件分發的模式和機制。這一點真的非常有用,對我們寫Lost Castle的代碼幫助非常大,非常高效去解耦。Lost Castle是roguelike類型的遊戲,裡面涉及非常多的各種功能的道具,耦合程度很高,我們是怎麼做的呢?

第一點、要有一個標識事件的ID。

第二點、有一個儲存事件信息的一個類,去儲存事件信息,比如一個事件的對象、一個數字、一個字符串等等。

第三點、申明一個委託。

第四點、寫一個委託對象的集合,就是裡面有對應某個事件的大量的委託對象,負責註冊、剔除或者執行回調。

第五點、一個靜態的單例EventMgr,其實就是做事件的觸發和分發,也是個對外接口。其他腳本不用關心分發機制裡面的事情,就跟EventMgr打好關係就好了。

比如說我們需要監聽玩家死亡的事件,比如是一個復活道具,他需要知道玩家什麼時候死亡,可以在他腳本start時候,把自己註冊進去,成為這個事件的監聽對象,傳入一個事件的ID和回調,如果觸發這個事件,就執行那個回調函數執行相應的邏輯代碼。在需要觸發玩家死亡事件的地方,比如主角死了,需要分發這個死亡事件,會用EventMgr.Call觸發分發死亡事件,並傳入相應的參數。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

剛剛提的是做Lost Castle裡面處理大量解耦的一個模式。它幫我們做了非常多的東西,因為Lost Castle裡面有各種各樣的道具,它們之間的耦合可能非常多,我們就用這個方式讓他們之間解耦,讓程序更加清楚更加明白。

最後,寫Lost Castle的代碼思路是怎麼樣,肯定不是最優解,我們希望能拋磚引玉。Lost Castle的代碼思路,只有兩個核心:

思路一是儘可能少的類繼承,儘可能多的專一功能模塊。就比如說剛才提到的那個,SortingModule,不對外做什麼接觸,只關心對象的Sorting一件事。

思路二每個重要的實體,掛載有一個面向對象設計的腳本,但是那個腳本自身不做什麼事情,只處理可能的耦合情況。比如說Lost Castle里的主角,有個Hero腳本,它是面向對象設計的,繼承自creature,往上還有繼承關係。主角實體本身掛載了很多專一功能模塊,比如控制移動的模塊,比如控制生物屬性的模塊,比如控制道具檢測的模塊,但是模塊之間會存在一些耦合關係,我們就通過在圖示中間這個繼承關係的柱子(Hero,Creature,Entity),把他們耦合關係解決掉,但是這根柱子本身不做任何具體的事情。

遊戲設計方面的製作技巧

勿陷入遊戲類型誤區

這裡講的也比較散,都是每個點每個點的。第一個希望跟遊戲製作人分享,不要陷入遊戲類型的誤區。可能會經常考慮一個問題,是沙盒還是Roguelike還是RPG還是生存還是模擬養成,哪個玩家比較多比較多受眾,我往玩家多的地方去做。其實我是比較反對這種思維的,我覺得遊戲類型取決於創作者想表達的內容和他們的喜好,一個創作者本身對這個遊戲類型不足夠熟悉,或者對這個類型不足夠喜歡,是沒辦法把這個遊戲做好。

第二個點是正確評估遊戲類型對團隊的可行性,風險一直都是存在的,從立項到遊戲上線都是一直存在的。這邊可以舉我們做Lost Castle為例,因為一開始立項的時候,Lost Castle跟現在不是一樣的遊戲,其實一開始的時候,是計劃做帶一些沙盒性質的roguelike。現在Lost Castle是完全沒有沙盒的,大概第一年就把沙盒徹底砍掉了,為什麼砍掉,因為做不來,就這麼簡單。

快速原型試錯

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧《Lost castle》製作人何斌:小團隊遊戲開發製作技巧《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

這邊舉幾個例子,上面都是我在GameJam上做的遊戲,一個是解謎類、一個是拼裝戰艦對抗、還有一個是關於以磁力為主題的撕逼遊戲。我非常推崇創作者去短時間到打造一個遊戲原型,可能是兩天或者一周都沒有關係。就像葉斌前輩說的,現在越來越推崇快點讓遊戲見著樣子,不然回爐重造的成本很高,另外需要儘早確定遊戲的核心玩法。

遊戲難度設計

其其實在這裡,我也不會說我們做遊戲難度怎麼做,第一關做怎麼難,第二關做多難,我想提一個我非常喜歡的概念。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

圖示這兩個遊戲是兩個極端,第一個遊戲是IronSnout,第二個是黑魂。左邊非常簡單,右邊那個非常難。但他們都很好玩。我想提一個概念:簡單但是有趣,難但不會沒有道理。我覺得大家可以在做難度設計時,如果覺得很彷徨,或者是覺得不知道該怎麼做的時候,可以仔細想想這個理念,可能會讓你很有啟發。

物理慣性模擬的誤區

慣性這個一開始我們也有用,但是後來基本上就沒怎麼用了。一般情況下,越是接近現實的慣性模擬,越是通常帶來不好的體驗。為什麼?因為慣性模擬會給玩家一種失控的感覺,通常來說玩家更希望對他自己控制的角色是處於一種完全掌控的狀態,不希望出現失控。這邊也可以舉例,就是某一個已經上架的Steam遊戲,是一個國產遊戲,上架的幾天時間內,因為慣性的問題,收到非常多的差評,後來開發者修改了,但是並沒有用,為時已晚了,因為差評已經擺在那裡了。但這不是絕對的。好的例子也有很多,最熟悉就是超級馬里奧,裡面也有慣性,比如轉向,跑步過程中轉向,其實是有一個剎車,然後停止然後帶轉向加速的過程,其實也是一個慣性過程。那麼這樣的話,到底我們應不應該做慣性?答案並沒有絕對的。幾乎所有的系統跟設計都是為遊戲體驗服務,我們應該讓這個點為基礎去考慮,到底應不應該做,或者應該做到哪種程度。老任(任天堂)對這種細節把握程度是超級高的,並不是開發者想當然的,這個剎車,或者這個加速一個Sin或Cos曲線,就搞定了。

這邊也提一個比如說我們做動作遊戲,我們可能會涉及到打擊頓感的設計,像怪物獵人,是我很喜歡玩的一個動作遊戲。怪物獵人打擊頓感怎麼設計,應該是怎樣的呢,我這邊希望給大家十秒鐘的時間思考一下這個問題。相信很快就能想到第一個答案,就是怪物獵人的武器砍到肉的打擊頓感是怎麼設計的。 我相信大家心裡都有一個答案了,而且很容易得到一個答案。那就是在砍到的時候,我可能讓時間流速降低,甚至降到0,然後持續幾幀,或者持續零點幾秒,這樣就夠嗎了?其實並不是的。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

在擊中時讓時間流速為0持續幾幀,然後在後續動作上加速,補回時間差

這邊有幾張靈魂作畫,比如說這是正常的砍擊,正常的砍下來是很順,如果砍到了,在中途HIT了,我們會在HIT的時候,讓時間流速降低,甚至是為零,但是這樣還是不夠的。我們會在HIT結束之後,就是在那個時間流速控制,在卡頓控制結束之後,讓後半段的過程加速,我了解到怪物獵人是這麼做的時候,是非常驚訝的。比如說我這個動作,假如這個動作是一秒,那如果我只做前面的,就是讓時間流速降低甚至為0,我可能觸發了這個打擊頓感,觸發這個打擊感,可能整個對於就變成了1.2秒,或者1.1秒,其實有很大問題的。

為什麼?因為整個動作時間就變了。特別是一整套動作,這一整套動作有非常多的連招,如果正常一個連招,可能砍了5秒,因為這個問題一個正常連招就6秒、7秒等等。這樣的話對於一個動作遊戲,必須要保證一個流暢性,其實還是需要控制到像這樣的,就是在後續的過程彌補到之前卡頓做的時間差。你會驚訝這些大廠對動作遊戲的把控,畢竟他們有幾十年的經驗

常理細節的設計

我也是最近才發現,感覺越來越多的遊戲注意這一點,這邊我也是先以自己的遊戲為例,Lost Castle裡面有一個Boss是一個恐龍,玩家打他的時候可能會想,因為恐龍是肉食動物,Lost Castle裡面有一個恢復的道具,是玩家可以吃的雞腿,玩家想如果我把雞腿丟出來,那恐龍吃不吃,事實上他丟出來,恐龍會吃,而且會出一個硬值,恐龍去吃那個肉,玩家靠這個硬質去揍他。這個細節會對玩家造成非常大的驚喜和成就感,這個也可以提到另一個遊戲,就是最近出的zelda荒野之息,裡面其實有大量類似的設計,我可以隨便舉幾個例子,比如說如果在雪山,玩家會想如果背著一個火劍,就是火屬性的劍,會不會有保暖效果。實際上他去嘗試發現的確會有,會帶來一個極大的驚喜和成就感,而且玩家特別願意分享這種驚喜,特別願意分享自己的發現,這樣的話其實變相會促進這個遊戲的推廣。

然後還要提到一點,就是你對遊戲細節的一個打磨用心程度,玩家會毫無遺漏地感受到。你可能感覺只有玩家10%或者5%的玩家注意某一個細節,但是沒有關係,從一個群體來分析,一個大群體肯定會發現這個細節,而且通過傳播也會讓更多人知道這是一個細節,他們會毫無遺漏地感受到,你做的這些遊戲細節。

意料之外的設計

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

這裡還是Lost Castle為例,圖示這三個都是Boss。Lost Castle裡面每一關,會有一個守關Boss,打到關底就有一個Boss,這個很正常,這是情理之中。最後一關走完正常的流程,會遇到一個Boss,玩家會想當然,前四關都是這樣的,就會覺得這個是最後Boss,打完它就贏了,當他打完會發現,這只是最終Boss的一個看門狗,他就會覺得好意料之外。在這裡有做一些收集,收集玩家對這個細節的一個心情的報告。發現大部分玩家並不覺得反感,第一反應是驚訝,第二反應是刺激。除了這個設計,像比如說最終Boss沒有死還有二形態,中間那個圖是最終Boss的圖,Boss長的類似這個樣子,這個Boss死了之後,會變身二階段像最右那個圖,他們就會被驚訝到,但還是情理之中的事情。

除遊戲自身外的重要細節

剛剛提到第二個主題就是遊戲設計製作方面的一些經驗,我還想分享一些非常重要的東西,就是除遊戲自身以外我們需要注意什麼,很多開發者並不會注意到,這個也是我們摸著石頭過河到現在遊戲上線等等總結出來的東西。

第一點想提的是儘可能支持手柄,而且儘可能地適配手柄。我覺得很多人會不屑一顧,或者說我知道,或者說我不做手柄也可以這樣子的感覺。其實並不是這樣的,特別是我們做PC遊戲,特別做全球市場的PC遊戲。很多歐美玩家非常習慣手柄,有些玩家如果遊戲不支持手柄他們是不玩的。並且,國內玩家使用手柄的數量也正在上升。一般而言,手柄遊玩比鍵鼠更容易代入到遊戲裡面。Lost Castle使用了一個叫InControl的插件,這個也可以在AssetStore里找到,做手柄的適配和輸入接收,感覺還不錯。

適配手柄肯定提到按鍵方面的問題,我們這邊建議對鍵鼠儘量支持玩家改鍵,這個挺重要的,因為一開始我們遊戲上線是不支持玩家改鍵的,但是收到非常多的玩家反饋,需要支持玩家改鍵,特別是動作遊戲,更應該支持玩家去改鍵了。對手柄呢,我們建議一次性做到最佳的按鍵設置,不支持改鍵。因為手柄的話,鍵位就這麼多,應該做到最好。其實這個也很不容易,今天玩一個遊戲,就是外面有一個展商的遊戲,那個遊戲的製作人我和他關係也很好,因為我之前玩Demo都是鍵鼠玩沒有支持手柄,今天支持手柄了,但是我覺得按鍵適配不是很好,晚點我私下也會跟他提。這個很重要,如果以這樣的按鍵適配上線的話,肯定會收到非常多玩家的反饋或者噴的。

這邊,我們總結了一些手柄適配的情況,因為可能有些特別是國內的開發商可能覺得我支持主流手柄,PS4或者XboxOne,或者Xbox360手柄,把主流手柄適配了就可以了,事實上不是這樣。可能跟我們環境有關,據我所知,有些玩家他用國產手柄,可能去玩黑魂、古墓麗影,會發現不支持,他們會百度去找,怎麼去用XXX手柄去玩XXX遊戲,會幹這種事情,最後東搞西搞,真的能玩了就很開心。但是對我來說不一樣,為什麼?他知道我們是國產遊戲,會直接找到我們製作組,跟我們說,你怎麼不支持XXX國產手柄,這種人不是一個兩個,非常多,他覺得你是國產遊戲支持國產手柄是應該的,那沒辦法,玩家是上帝,我們就去支持。這邊列舉了一些,我覺得需要去支持的手柄的型號,有一些更加雜的,可能就會因為支持圖示的手柄,然後也支持了,大概如圖這些我們覺得比較重要的。

《Lost castle》製作人何斌:小團隊遊戲開發製作技巧

這裡的話,如果記不住,也沒關係,大家想可以去看這個表。

第二點想提我們需要做好語言本地化的拓展設計。可能有些開發商不會注意,他覺得我支持中文,支持英文,夠了,其他語言就不支持了。一開始我也是這麼想的,我也想遊戲支持英文支持中文夠了,但是事實上不是這樣。開發初期,考慮並做好本地化的框架設計,不要心存僥倖。需要在開發初期就考慮到本地化拓展的框架,不然的話後面等內容多了,再回頭做本地化拓展的話,那就非常痛苦了。

為什麼我們需要做本地化呢?就是剛剛提的問題。因為玩家有母語依賴,這個在全世界範圍內都通用,國內玩家經常說支持中文就買,這個現象其實全世界都是一樣,全球都有母語依賴,語言的本地化,就是第一個推廣手段。沒有廣告沒有宣傳,其實語言方面的本地化就是第一個推廣宣傳。圖示是Lost Castle的商店頁面截圖,看到支持四個語言,簡體中文、英語、西班牙語、俄語,後面我們也會加入德語和日語,我們非常看重這一點,本地化真的非常重要。

第三點是我想提越早建立玩家社區是越好,對遊戲的疊代也非常好,有些開發者會一開始蒙頭開發,最後快上線前,一個星期就拉玩家來測試,拉一個玩家群測試,其實這樣做是非常低效,而且非常有風險。多久呢,早到什麼時候?其實我們有一個小標準,就是發布前三個月,至少發布前三個月,更早也可以,你要建立遊戲的玩家社區。

還有什麼好處呢?其實在遊戲開發後期,我們常常會產生奇怪的直覺,感覺這個遊戲這裡不對,或者那裡不對,需要改,甚至對自己遊戲的感覺已經到麻木,就像鳳翔之前開發Icey,也是產生過非常多奇怪的感覺,很正常,我們做Lost Castle也是,開發的中後期經常感覺這裡不對,那裡不對,其實並沒有什麼不對。收集玩家的反饋,使遊戲的疊代不會走偏走彎,一方面可以刺激開發者,一方面可以讓開發者更清醒,不會亂想,因為最終遊戲上線是面向玩家的。

然後這裡的玩家也不是說,就是剛剛提的,遊戲上線前的測試玩家,而是指更核心,是更有意願參與到整個遊戲開發過程的玩家群體。你可能覺得這樣的話會不會這個玩家社區維護成本很高,或者這個玩家社區要經常管理等等之類的問題,其實也不用擔心。因為類似這樣的玩家社區,玩家本身非常有願意參與到這個遊戲開發過程,包括測試反饋等等,也有玩家非常樂意管理這個玩家社區,相當於自治區一樣的良性生態,你並不需要管理太多的事情。

第四點,我還要提一下,支持在線聯機,對遊戲傳播幫助很大,為什麼?因為中國玩家很寂寞。因為很少中國玩家可以線下找到朋友一起玩遊戲。國內玩家更容易接受線上聯機的模式,而且他們非常想要線上聯機。我這邊列了一個Lost Castle的訪問量統計,我想通過這個訪問量統計想表達一點,只是在線聯機對整個遊戲傳播幫助是很大的。一開始Lost Castle的購買用戶跟願望單用戶,願望單用戶就是說,有些遊戲你看到了,覺得很好玩,但還是不想購買,點一個加入願望單,就是相當於購物車的感覺,等到以後再買它。一開始的話Lost Castle購買用戶跟願望單用戶,呈現比是1比1左右。但是目前為止,到現在購買用戶和願望單用戶呈現2比1。2的話是購買的,1是願望單用戶,基本呈現2比1了。為什麼?為什麼一開始半年都是1比1,為什麼突然變成2比1了,其實變化點就是在我們去年9月份、10月份左右更新了在線聯機之後,它的那個增長量就是不一樣了,呈現不一樣的變化趨勢。

這邊訪問量統計也可以看一下,只看白線就可以了,白線總的訪問量,除去很高的波峰點,波峰點有一些特殊事件,比如你正式版上線了,或者搞促銷了,就有波峰點,我們就看平均的白線,可以看9月份、10月份以前,除了波峰點之外的白線都是處於比較低水平的,但是9月份、10月份之後,你會發現,就是後面的那些白線,跟之前的白線不是一個量級了,就說明推出了聯機之後,其實對整個遊戲的傳播會非常有幫助的。

第五點提一下Unity的一個Service措施報告收集。我們小團隊可能不會專門去搞個伺服器收集錯誤。UnityService有一個錯誤報告的收集,可以幫助你做這個事情,很有幫助,特別是遊戲上線之後,你可以從後台直接去查,玩家反饋的這些錯誤到底是什麼造成的,可以查到時間點等等之類的信息,可以幫助你在遊戲發布之後做持續的測試跟修復,非常有幫助。

最後我還想想說一些雞湯。目前大環境下,國內付費單機玩家數量的確不停增加,通過Steam的數據可以看到中國Steam玩家接近兩千萬,這個在2015年初只有三四百萬,現在已經翻了四五倍了。這個數量估計還得再持續增長。第二是各種遊戲載體平台越來越開放,包括Steam,包括PS4、Xbox、NS等等觸手可及。大家知道老任(任天堂)以前對小廠商都不怎麼理,現在已經改變了,這對我們開發者當然是個好事情。第三個是 Unity3D越來越強大,功能越來越完善,當然要感謝U3D。 最後也是最重要的是,不管中間過程怎麼樣,我們的終極目標是做好玩的遊戲。