Code Liquid 為何採用 HDRP

等等…好久不見!你們去哪了?

呀吼 —— 不看還好,一看才發現我們已經九個月沒有新的文章了。雖然這段時間開發日誌都沒有更新,不過我們確實是有進展的!這段時間我們都做了什麼呢?

2018/10 – Code Liquid 計畫開始
2018/11 – Code Liquid 從 Built-In Render 改為 HDRP
2019/04 – Code Liquid 第一個測試版本完成
2019/05 – @yamiodymel 當兵,企劃暫停
2019/08 – @yamiodymel 退伍,企劃繼續

我們在 2019 年初開始,花了近四個月的時間從完全不熟悉 Unity 到做出了可以玩的測試版本。裡面有簡易的角色自訂編輯器、一個 H 過場動畫、一張開放地圖、人物操作系統。但很可惜遇到主程式 Yami Odymel 需要當兵入伍,企劃只好先暫停一陣子。

2019/04 Code Liquid 第一個測試版本開發畫面 (有興趣可以到我們的 Discord 看看喔)

認識 SRP、LWRP、HDRP、URP

近期有在關注 Unity 消息的人可能會被一堆 RPRP 的名字搞混,但其實事情沒有這麼複雜。Unity 2018 開始導入了一種叫 SRP (Scriptable Render Pipeline) 的功能,故名思義就是可以透過 C# 腳本控制「畫面如何渲染」,SRP 可以讓開發者有很多對畫面控制的自由,例如可以刪減不必要的功能來達成效能增加,或是增加原先沒有的功能來達到更好的畫面。

而 Unity 為了推廣 SRP 自己率先推出了兩種 SRP 的 Preset (範例),也就是

  • LWRP (Lightweight Render Pipeline) 輕量化渲染管道
    • 現名 URP (Universal Render Pipeline)
  • HDRP (High Definition Render Pipeline) 高畫質渲染管道

而這兩個 RP 為整個 Unity 生態帶來了不小的改變,LWRP 主要目標是給手機、一體機 VR 等效能較低的設備而生,刪除了一些原先內建渲染的功能,讓任何風格的遊戲不管是 2D、3D 或是 VR 在所有裝置都能流暢運行。而從 Unity 2019.3 開始 LWRP 重新命名為 URP (Universal Render Pipeline),未來將會漸漸汰除原先的 Built-In Render 改為預設 URP。

而 HDRP 主要目標是給新世代家用遊戲機、高階電腦、Real-Time CG 動畫製作,採用了 PBR、Ray-Tracing 等功能,犧牲了一些效能,但提供了更多畫面設計上的彈性。

2019/04 Code Liquid 第一個測試版本開發畫面

為何採用 HDRP ?

至於說到為何 Code Liquid 要採用 HDRP,底下是我自己的兩點理由:

– 畫面好看

– 適合我的工作流程

我們先從第一點開始好了!說到畫面就…真的很好看,這裡放張 Built-In Render 和 HDRP 的對比圖(幾乎同樣的光源和設定值下的比對)

當然不是說 Built-In 無法做出好看的畫面,而是我本身對 Unity 不熟,雖然我有兩間遊戲公司的工作經驗,也用 Unity 做過一些東西,但幾乎沒有程式底子的我要用 Build-In 做出好看的畫面實在是非常非常困難。

我自己的工作是動態影像設計 (Motion Design),平常和 3D 軟體打交道,大多用的是 After Effects、Cinema 4D、Octane Render 這類 Offline Rendering 的軟體,在這類的軟體由於不需考慮效能問題,我可以很靈活的控制畫面該如何呈現,塞滿各種 4K 解析度的材質貼圖、幾百萬面的模型、好幾十顆燈光等等。

我平常用 3D 軟體做的作品 J!VA – the deviant one.

但做遊戲是另外一回事,有太多需要考慮的東西,對沒有程式底子也不會寫 Shader 的我,起初我一直以為我沒有辦法做出我心目中理想畫面的遊戲。

而就在這時我遇到了 HDRP。

HDRP 有很多以往很難在遊戲內做到的效果,例如 表面散射 (Subsurface Scattering) 、體積光霧 (Volumetric)、玻璃折射、物理攝影機等等的功能,可以讓我比較容易的調出和 3D 軟體內能做到差不多的效果。例如底下的表面散射示範,開啟後可以讓衣服、頭髮、皮膚之類的材質有些微透光的效果,讓整體畫面更自然。

HDRP 表面散射 (Subsurface Scattering) 範例
HDRP 的玻璃折射

HDRP 實作遇到的困難

那說了這麼多,其實我現在還不建議大家使用 HDRP 作為正式的專案製作,他距離 Production-Ready 還有一段非常非常大的距離。

由於 HDRP 是 Preview 測試版,砍掉重練是時常會發生的事情,例如底下圖片的範例是我們剛開始使用 HDRP 時,使用不同 HDRP 版本就算開同一個專案、用一樣的數值也會產生完全不同的畫面,每次更新都必須耗費大量的時間和精力重新調整所有的材質、燈光參數。

2018/11 Code Liquid 早期開發畫面

最初 Unity 2019.1 正式版時的 HDRP 其實到處都是問題和 Bug,動不動就破圖甚至比 2018 的版本更不穩定,我猜測是為了支援 DXR (Ray-Tracing) 和 VR 而做大規模的砍掉重練,所以最初我是沒有打算更新專案的。

直到 Yami Odymel 退伍後才再給最新的 Unity 2019.3 一次機會,發現大部分的問題都已經修正,也多了很多很棒的功能才決定升級。

Unity 2018 (HDRP 4.10) 與 Unity 2019 (HDRP 7.0) 的 Volumetrics 對比

Code Liquid 的未來規劃

時間很快來到了 2019 年八月底,在企劃暫停這四個月內環境變了很多,Unity 2019 從 Alpha 進入了穩定版、HDRP 從 4.0 更新到了 7.0 並支援 VR、Ray-Tracing(DXR) 之類的功能,在經過一番評估後我們決定將專案搬移到 Unity 2019.3 + HDRP 7.0。

當然不管是升級 Unity 或是升級 HDRP 都會有一點陣痛期,有很多相容性需要測試,甚至很多東西需要重做,但我們的團隊成員又重新聚集了,未來將會持續更新 Code Liquid!

如果大家對我們的開發進度有興趣的話歡迎加入 Discord 和開發團隊聊聊天!我們有 Unity Collab Bot 和 GitHub Bot 會回報開發狀況,也會不定時舉辦開發實況或問答。

Discord 伺服器連結:https://discord.gg/6mzKmJV

我們下一篇文章見!

Code Liquid 是什麼?

TL;DR,給很忙的人的結論:

Code Liquid 是一個成人向的 3D RPG H Game

Code Liquid Reboot 開發中畫面

一切的起源…

幾個月前我案子剛忙完,正愁著沒什麼事情做的時候,剛好和 Yami 聊到遊戲開發的話題。他說道:

是什麼…阻止了你自己開發一款遊戲?

「噢酷…有道理。」我雖然在兩間遊戲公司工作過,也從小就熱愛遊戲,我卻從來沒有想過我應該自己做一款遊戲試試看。自從開始自學寫 After Effects 腳本後,現在我有了一部份程式基礎、也對 3D 製作的流程有更深入的了解,何不趁空閒時間試試看呢?

但不得不說我的程式基礎差到不行,雖然寫得出簡單的 JavaScript,但對其他程式語言一竅不通,大部分的 Code 都是東拼西湊「能跑就好」的東西。我實在不認為這樣的狀況可以好好用主流的遊戲引擎做一款像樣的遊戲。於是我決定邀請他合作,協助程式方面會遇到的問題。

Code Liquid Reboot 開發中畫面

為什麼是 H Game?

因為最快。

決定要製作 Code Liquid 的時間是 2018 / 09 / 26,我們都各自有自己的事情要做,例如 Yami 的 始春,而我也有可能隨時接到影像案子而必須將精力花在工作上。所以我們決定只花大約一個月的時間完成這個 Side Project。

比起其他類型的遊戲,例如 射擊遊戲、冒險遊戲、動作遊戲 等等…不是對劇情完整性要求很高,就是對操控手感、甚至關卡的編排要求很高。對時間與經驗都不夠的我們來說,要在一個月內從完全沒做過遊戲到做出一個像樣的遊戲幾乎不可能。

而一般 H Game 並不對這些東西的要求很高。例如 Illusion / Kiss 這類日本一線的 3D H Game 廠商,劇情都不太是主要賣點,而是「實用度」。

當時我手上有很多可以使用、甚至是可以商用的角色模型素材,我自己因為習慣也收集了很多 MMD 的動畫檔,於是我們一開始決定用手上現有的素材與最底線的完成度標準來製作。而我本身也因為影像製作的專業,對自己能掌控 H 場景的「實用度」也滿有信心的。於是 Code Liquid 就這麼開始製作了。

Code Liquid Reboot 的一部份角色陣容

Reboot 是什麼?

其實 Code Liquid 開始開發兩個禮拜後,整個遊戲的雛形已經差不多完成了。我們有四、五組 H 過場動畫,有一個小小的村莊場景,和一些基本的程式系統。

Code Liquid 第一個版本畫面

就在我們打算發佈第一個 Code Liquid 版本的時候,我無意間發現了 Unity 正在測試中的新功能「HDRP (High-Definition Rendering Pipeline)」,這是一個新的畫面渲染模式,針對次世代遊戲主機與高階電腦開發,畫面相較一般的模式漂亮很多。

使用了 HDRP 渲染流程的畫面

( HDRP 有關的技術細節之後會再開一篇文章 )

我和 Yami 都同意採用 HDRP 模式的畫面比之前類似 Toon Shading 的卡通渲染好看很多,於是我們經過討論後決定放棄原先的 Code Liquid 雛形,開新的專案全部重新開始。

( 不選擇升級現有專案,而另外開專案的原因會在 HDRP 文章中說明 )

所以… Code Liquid Reboot 呢?

為了熟悉更多的新系統、排解新問題,於是時間來到了 2018 / 11 / 30,撰寫這篇文章的同時 Code Liquid Reboot 正在開發中,對引擎、新功能已經有了更多的熟悉,也排除了大部分製作過程會遇到的問題,開發正在慢慢步上軌道,後面應該會更順利一些。

如果關心 Code Liquid 的開發狀況,歡迎各位到 Discord 伺服器。我們有 Unity Collab Bot 和 GitHub Bot 會回報開發狀況,也會不定時舉辦開發實況或問答。

Discord 伺服器連結:https://discord.gg/6mzKmJV

我們下一篇文章見!

以有條理與 ECS 的思緒正確地撰寫 MonoBehavior 邏輯

在 Unity 中,目前分為兩個撰寫遊戲的方式:ECS(Entity、Component、System)與傳統的 MonoBehaviour

前者是 Unity 在 2018 年所推出的新程式結構撰寫理念,主要是為了解決多數的程式碼都在主執行緒上執行,而導致 CPU 分配率不彰、程式效率降低、執行緒鎖死的問題。但 ECS 基本上到年底,都還不是一個完善的狀態,更不是萬能仙丹;事實上,ECS 就算進入了正式版,也有可能是在下一個產物出來之前的過渡期設計。

話雖如此,ECS 的設計理念還是值得參考與借鑒的。在前端網頁設計中,其實已經運用了類似的理念有至少二、三年之久,那東西耳熟能詳的名稱是:VuexRedux

Vuex 是個設計理念而不是特殊軟體,其用意是為了集中資料、並且明確地劃分修改與存取邏輯。

簡單來說,ECS 嘗試地想要將:「把所有邏輯全部塞進同一個 MonoBehaviour 元件」的這種問題給解決。

設想看看,如果遊戲內有一百個物件,而且那些物件都是 NPC 玩家,但角色大多都是相同的邏輯與行為方式,在傳統寫法這會造成每個元件都有自己的邏輯,而導致效能不彰。

說到每個元件都有自己的邏輯,ECS 的解決方法顯而易見:

讓元件本身只保有狀態資料,而邏輯獨立成一個中央系統。

如果這聽起來牛頭不對馬嘴、不曉得到底是在說什麼東西,那麼你一定會喜歡接下來的程式碼範例章節。 閱讀全文〈以有條理與 ECS 的思緒正確地撰寫 MonoBehavior 邏輯〉