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

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曲線,就搞定了。

內容未完結,請點擊「第2頁」繼續瀏覽。