一直很喜歡《奧術》那種筆觸感強烈的風格化渲染,雖然懂部分原理但從未親自實踐,這次在專題組員的協助下總算有可見成果了。

前言

大家好!我們是 4a.m.就寢 ,是來自南臺多樂系的遊戲製作團隊。

今天要來分享我們在大二升三的暑假期間做的實驗專案《太空漂流》,主要目標是研究風格化的美術製程和渲染技術,為專題長期計劃的準備工作之一。

成果展示

先上成果,圖中所見都是由團隊成員製作的歐!

image display error, please report: [/devlog/stust-project/research-project-1/result-1.gif]

左邊是 Unity 編輯器檢視,右邊是遊戲視角(gif)。

※團隊成員

成員一共有六人,工作分配如下:

  • 小呈(筆者):企劃 / Planner&Designer、技術美術 / Technical Artist

  • Snoweve:程式 / Programmer

  • Avis Shih:概念美術 / Concept Artist(Art Director)

  • izumige:概念美術 / Concept Artist

  • YukiO3O:3D 美術 / 3D Artist、UI/UX Designer(Art Leader)

  • Natsu37:3D 美術 / 3D Artist

註1:文中使用「我」等第一人稱代詞代表的是筆者小呈自身,提及隊員時會各別標註。

註2:我查了一下 Art Director 和 Art Leader 的差別,前者好像是針對美術風格的管控,而後者是對人員的管理,學生團隊通常會用「主美術」統稱,但我在這裡想做出區分,理解有誤再麻煩前輩指出。

※團隊社群

這是我們的 FB 粉專,文章最後會再放一次連結:4a.m.就寢

團隊粉專目前還沒有任何東西,主要會配合後續計劃發文,如果對我們的後續發展感興趣,或想第一時間接收新資訊的話都歡迎追蹤噢!

注意事項

本文會簡單介紹遊戲機制、設計等基本資訊,並分享美術成員在過程繪製的作品與解釋相關技術原理。主要想跟大家分享團隊協作心得與踩雷紀錄,並用筆者個人名義宣傳團隊。

註:雖然我們是大學生,但內文展示的成果大多超出學校範圍。提醒一下,怕有人以為學校教那麼深 XD

專案目前廢棄,主要原因是規模與後續計劃,文章末尾會再解釋。

以下正文!

專案介紹

《太空漂流》是一款太空x奇幻的劇情向放置手遊,故事講述的是一位迷失在太空中的孩子,他搭乘浮空島嶼在宇宙中漂流,將在與不同星球的交流中解開自身謎團。

image display error, please report: [/devlog/stust-project/research-project-1/intro-reference.jpg]

尋找的參考和用 AI 生成的示意圖,故事氛圍很大程度參考了《小王子》

選放置遊戲(Idle Game)是為了配合專題計劃,因為根據本系機制,我們三年級上下需要各製作一個指定題目的小專題。

而我們根據歷屆資訊猜測題目是「有内購功能的手機遊戲」,所以為了把重點放在美術研究上,我們決定選相對單純的放置類型製作。

遊戲機制

因為設計門檻的問題,我們選擇製作「非增量型」的放置手遊,簡單來說就是不把堆疊數值當核心,而是透過劇情與蒐集物品推動遊戲進程,類似遊戲《旅行青蛙》《天國旅立》

遊戲核心迴圈如下:

  1. 放置採集:資源會隨時間累積生長,玩家需要上線採集獲得基本貨幣。
  2. 放置探索:玩家需要決定探索地點並出發,並等待角色抵達地點觸發事件。
  3. 獲得物品:事件回報為資源或物品,玩家的目標是蒐集完一系列任務道具。
image display error, please report: [/devlog/stust-project/research-project-1/intro-loop.jpg]

但為了豐富度內容我又加了三大遊戲系統,主要圍繞探索與養成設計。

  • 地圖系統:地圖會隨機出現可前往的地點,可能是主線、支線、隨機事件或交易地點。
  • 事件系統:玩家抵達地點時觸發的互動事件、劇情演出等等。
  • 布置裝扮:讓玩家改變小島布景和角色裝扮,會提供數值加成。
image display error, please report: [/devlog/stust-project/research-project-1/intro-mechanism.jpg]

發想時用 miro 拉的示意圖與畫面關聯性

雖然還有細節想分享,因為專案廢棄就不多介紹了,接著說故事概念吧!

劇情故事

劇情概念是組員 Avis Shih 提供的,我再進行細節填充,這裡也簡單介紹過。

image display error, please report: [/devlog/stust-project/research-project-1/intro-story-history.jpg]

補完劇情設定的世界背景,示意圖,不用細看沒關係

宇宙中的一個高等文明因為看見「真相」而分裂,內戰不斷最終走向衰亡,部分遺族利用星際庇護島將後代送至宇宙邊緣避難。經過無數時光後,主角在宇宙一隅的小島上甦醒,此時新興種族已讓過去的遺址再次繁榮。

玩家扮演的「並非」主角,而是一個能控制小島的意識體,是來自異世界的協助者。玩家能控制小島的移動,但無法與主角互動,而主角則視小島的移動為命運,帶著自己漂流宇宙。

image display error, please report: [/devlog/stust-project/research-project-1/intro-story-concept.jpg]

組員 Avis Shih 在前期繪製的視覺圖

玩家的任務是帶領主角踏上歸鄉之路,並在途中見識宇宙的壯闊與豐富的文化,探索太空文明的遺址、與宏偉的宇宙生物相遇、與異種族交流互動、見識各種思維的衝突,並隨著經歷了解自身文明的歷史真相。

總之是個宏大旅程 :P

美術設計

接著分享美術在研究期間的成果,包括概念藝術、物件設計與 3D 模型,點擊圖片可以放大噢!

概念藝術

首先是概念美術,這裡是對遊戲風格的嘗試,由團隊藝術總監 Avis Shih 繪製,我們也會盡可能將其重現進遊戲,包括用色方式、筆觸效果等。

image display error, please report: [/devlog/stust-project/research-project-1/art-concept-1.jpg]

組員 Avis Shih (Art Director) 繪製的遊戲風格概念圖

除了美感與風格,遊戲的功能性畫面也交給她繪製,下面這張是遊戲地圖介面的概念圖,玩家可以旋轉圓盤改變目的地。

image display error, please report: [/devlog/stust-project/research-project-1/art-concept-2.jpg]

組員 Avis Shih (Art Director) 繪製的地圖畫面

以及供玩家採集基本資源的畫面,我們使用「星星」作為遊戲的貨幣,而採集工具是天文望遠鏡,畢竟這是一款超現實主義的遊戲。

image display error, please report: [/devlog/stust-project/research-project-1/art-concept-3.jpg]

組員 Avis Shih (Art Director) 繪製的資源採集畫面

還有事件演出與特殊資源採集的畫面,這裡把所有圖再合併展示一次。

image display error, please report: [/devlog/stust-project/research-project-1/art-concept-all.jpg]

組員 Avis Shih (Art Director) 繪製的概念圖總覽

物件設計

物件設計,指遊戲中會用到的物件,例如小島上的家具、可蒐集的道具或是可以探索的地點等,由 IzumigeAvis Shih 兩位美術一起進行。數量較多這裡就節錄部分展示。

image display error, please report: [/devlog/stust-project/research-project-1/art-object-izum.jpg]

組員 Izumige 繪製的傢俱、道具、奇幻生物與星球

image display error, please report: [/devlog/stust-project/research-project-1/art-object-avis.jpg]

組員 Avis Shih 繪製的道具、小島與功能傢俱

我們在這裡踩了很多雷,其中之一是美術設計的(初版)奇幻生物太可愛,與遊戲整體風格不符,以及部分功能型傢俱的樣貌與預期差異過大。

image display error, please report: [/devlog/stust-project/research-project-1/art-object-cute.jpg]

第一版奇幻生物

問題主因還是我(企劃)的需求不夠明確,因為需求描述只有:「太空奇幻生物,可以參考深海生物如鯨魚、水母等,或將天體與天文現象擬人化。」而已,而世界觀的基礎設定也很模糊,只有說「奇幻」、「超現實」。

身為企劃,我得把想法表達的更清楚才行 D:

3D 建模

我們要做的是 3D 遊戲,有設計圖後還要建模與繪製貼圖,由美術組員 YukiO3ONatsu37 負責。我挑了幾個物件讓他們做來實驗用,但因為拋棄式的就沒要求面數、佈線之類的規格。

首先是組員 Natsu37 製作的傢俱模型,包括星象盤、書櫃、桌子與天文望遠鏡,使用 Substance Painter 繪製 PBR 貼圖,並放進 Unity 渲染(預設材質)。

image display error, please report: [/devlog/stust-project/research-project-1/art-object-natsu.jpg]

組員 Natsu37 製作的傢俱物件

再來是組員 YukiO3O 製作的星球與小島,貼圖是用 Substance Designer 輔助製作的風格化筆觸圖,製作細節會在後面解釋。圖片同樣是在 Unity 渲染出的(預設材質)。

image display error, please report: [/devlog/stust-project/research-project-1/art-object-yuki.jpg]

組員 YukiO3O 的小島和星球物件

介面設計

這裡是沒有圖能放的篇章,因為我們在溝通上踩了很大的雷 D:

應該先畫出概念圖?還是先設計完 UI/UX?

我們的問題是,概念美術與介面設計是由不同組員負責的,兩位擅長的部份不太一樣,如果先畫概念圖可能缺少必要的介面資訊,但先設計介面又可能與概念美術想要的感覺對不上。

這個問題我在規劃時就苦惱過了,當初問組員以及前輩們的結論是…都可以,但我還是不知道該怎麼辦,所以沒特別處理,讓雙方同時進行,有問題再互相討論,最後才發現會互搶到職責、同時畫面也缺東漏西。

image display error, please report: [/devlog/stust-project/research-project-1/art-ux.jpg]

組員 YukiO3O 繪製的功能地圖(Functional Map)

後來因為一些機緣與綺麗前輩約了面談,尋求建議時就把發生的狀況再具體敘述一次,而答案也是——都可以,無論介面或概念圖誰要先都沒差。

因為問題在我(企劃)對遊戲樣貌的想像不夠明確、沒辦法給出完整敘述。

遊戲領域的 UI/UX 會被分開,因為 User Experience 涉及遊戲的體驗問題,而顯然體驗設計是企劃的責任 ,所以通常狀況是企劃處理完介面原型再讓美術直接繪製成品。

註:其實第一次問的前輩也解釋過,但當時還沒辦法理解。

當時想說自己不了解 UI/UX 就全部交給組員做了,同時讓兩位美術同步畫圖,然後就出事了。交給組員也不是問題,真正的錯誤是我沒先跟組員討論…

image display error, please report: [/devlog/stust-project/research-project-1/planner-mene.jpg]

遊戲開發梗圖,出自台灣糾結

總之,最後組員們討論了下個專案要用的新流程:

  1. 企劃先給出功能地圖(Functional Map)後跟 UI/UX 討論,釐清想法。
  2. UI/UX 接手進一步整理並製作線框圖(Wireframe)的原型,並跟企劃、程式討論功能能否實行。
  3. 線框圖(Wireframe)設計完整後再讓概念美術參考,繪製出遊戲最終樣貌的預期。
  4. 最後 UI/UX 根據概念圖繪製更精細的 icon 結果。
image display error, please report: [/devlog/stust-project/research-project-1/art-ux-flow.jpg]

組員 YukiO3O 繪製的流程示意圖

學到教訓了,還好這次只是實驗性質的專案,至少踩過的雷不用再踩一次…痾…還是踩了…但至少踩的沒那麼大力。

技術美術

文章後半的壓軸就是技術美術(Technical Artist)部分啦,嘿對是後「半」部分噢 :P

避免大家忘記,這裡再插一次團隊社群的連結,對後續發展感興趣的話歡迎追蹤噢 >///<

Facebook: 4a.m.就寢

接著就比較技術向了,部分內容沒有先備知識可能無法看懂,篇幅問題這裡也不會逐一解釋,但我會適度插入一些註解補充,並多放圖讓內容看起來有趣一點。

製作時的參考資料也會提供噢,有相關知識的人要重現不是難事。

筆觸貼圖

我們主要的參考對象是《奧術》、《96 號公路》與《極樂迪斯科》這種筆觸鮮明的風格,但會更著重在整體氛圍的奇幻感。

image display error, please report: [/devlog/stust-project/research-project-1/brush-reference-1.jpg]

引用自《奧術》、《96 號公路》與《極樂迪斯科》的視覺圖

原以為可以用 Shader 與數學搞定一切(因為我美術底子不好),但研究後發現還是得靠美術,終究是逃不過的。

總之,先下個過於簡略的結論:

物體的筆觸真的是用「筆刷」刷上去的,可以用 Photoshop 畫在貼圖上,或用 Substance Designer、blender 直接對模型繪製。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-1.jpg]

其實就跟 2D 電繪一樣,很多質地效果都是靠特殊筆刷完成的,不過 3D 物件是繪製在表面貼圖上。

最好理解的是基本色(Base Color),畢竟是直接反應物體顏色的貼圖,所以只要用適當的筆刷繪製就能讓模型有筆觸感。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-1_1.jpg]

但 3D 渲染會受到模本體形狀影響,物體表面與光源的角度會影響亮度,只有基本色會讓物體在受光時看起來很「平滑」,畢竟模型表面就是平滑的,如下圖左邊的範例。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-2.gif]

筆觸法線貼圖對比,左邊是沒有修改法線,右邊是修改過的(gif)

想讓光影與筆觸一致就要靠法線貼圖(Normal Map)把物體的表面朝向也畫成筆觸的樣子。這裡截出一張明顯的對比,可以看到兩者光影交界處的差異。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-2-2.jpg]

筆觸法線貼圖對比,左邊是沒有修改法線,右邊是修改過的

註:法線貼圖是一種用圖片改變模型表面朝向的手段,在這裡可以想成是在「欺騙」系統,說模型長的跟筆觸一樣所以光影應該跟著改變。

嗯…

情況開始詭異了起來,「畫」法線貼圖聽上去不是什麼好點子,畢竟他儲存的不是真正意義上的顏色,而是表面朝向的向量資料,更別說常見的法線圖還一片藍,要怎麼畫?

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-3-1.jpg]

專案中使用的法線貼圖

貼圖呈藍紫色是因為它儲存的是切線空間(Tangent Space)…總之與向量、數學和資料儲存方式有關,這裡就不展開解釋了。

但除了切線之外,還有另一種的法線儲存方式用的是物件空間(Object Space),看起來就不是一片藍,而是像彩虹一樣的漸層色,代表表面的各個方向。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-3-2.jpg]

總之,想「畫」法線得從物件空間進行,筆觸就只是把漸層抹開而已,加上特殊筆刷就有更精緻的效果了。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-4.jpg]

圖片引用自 Making 3D animation look painterly

修改法線後物體受光就會有筆觸效果,但麻煩的是筆觸走向要與基本色一致,否則兩者效果會不匹配。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-5.jpg]

圖片引用自 Making 3D animation look painterly

雖然 Substance Painter 支援多貼圖繪製,但這還是相當折磨人。總之…做是能做到,但讓美術手刻所有東西顯然不明智。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-6.jpg]

我們需要更有效率的做法,例如程序生成!

目前最主流工具是 Substance Designer 吧,但台灣好像沒什麼人提?我也是買對岸場景課的教學才知道的。

離題了,總之經過某些懶得描述的設置後,我使用 Tile Sampler Color 完成工作,能自動生出筆刷一致的貼圖。

image display error, please report: [/devlog/stust-project/research-project-1/brush-explained-7.jpg]

程序化減少了九成開銷,而且效果還不錯,UV 交界之類的缺陷再手修就好。

image display error, please report: [/devlog/stust-project/research-project-1/brush-result-1.gif]

展示使用筆觸貼圖的猴子模型(gif)

總結,我們的製作流程大致如下:

  1. 建模、拆 UV、烘培 Object Space NormalMap、繪製 BaseColor
  2. Substance Designer 生成 NormalMap 筆觸和 BaseColor 筆觸
  3. Substance Painter 修正生成筆觸後產生的問題
  4. 烘培 Tangent Space NormalMap
  5. 放進引擎渲染

3D 美術們也根據製程將製作貼圖,下面是組員 YukiO3O 的作品。

image display error, please report: [/devlog/stust-project/research-project-1/brush-object-yuki.jpg]

以及組員 Natsu37 的作品。

image display error, please report: [/devlog/stust-project/research-project-1/brush-object-pjie.jpg]

實際應用的過程發現不少問題,這裡也分享我們的解決方式。

※問題1:物件角度過大

物件角度過大時生成的法線表現不理想,解決方法為手動繪製倒角,此修正由組員 YukiO3O 獨立完成。

image display error, please report: [/devlog/stust-project/research-project-1/brush-issue-1.jpg]

※問題2:生成筆觸汙染

UV 太接近時,生成出的筆觸可能覆蓋到其他部分,修正方式是在 Substance Designer 添加 ID Mask 後合併。

image display error, please report: [/devlog/stust-project/research-project-1/brush-issue-2.jpg]

※問題3:過於細小的物件

細長條物件的筆觸效果不理想,解決方式為手動繪製精細的筆觸,此修正由組員 YukiO3O 獨立完成。

image display error, please report: [/devlog/stust-project/research-project-1/brush-issue-3.jpg]

下圖是由組員 YukiO3O 製作並完成多項修正後的小島物件。

image display error, please report: [/devlog/stust-project/research-project-1/brush-result.gif]

小島物件的引擎渲染圖(gif)

我們有一份製程的逐步教學文件,是由組員 YukiO3O(Art Leader) 學習後獨自編寫的,但屬於團隊資產就不公開了 :P

※參考資料

Making 3D animation look painterly

Painterly Blender Shader Technique You should know about

3d paintings in blender! My two cents on hand-painting normal maps.

Auto-Painterly look on 3D animation (Shockingly Easy!) Blender + krita tutorial

Paint on Normal Map: Painterly Texture Maya/Substance Painter

場景光照

模型做好就能進引擎佈置了,我用 AI 生了一些氛圍參考圖,讓組員 izumige 分析並繪製參考圖、提供拆解後的樣貌。

image display error, please report: [/devlog/stust-project/research-project-1/scene-analysis.jpg]

雖然是技術美術,但本人的美感素養相對匱乏,需要讓美術組員分析後才知道實作方向。

※場景

剛開始只是把主體星球放進場景,然後用 Substance Designer 生成一張背景放在畫面後方,再拿一些星星貼圖點綴而已。

image display error, please report: [/devlog/stust-project/research-project-1/scene-build-1.jpg]

※光照

但我發現預設材質效果不理想就用做了新的,主要是增加邊緣光(Rim Lighting)和減弱背光面亮度,除此之外還用 2D Sprite 加了背版光,並添加額外光源給小島。

image display error, please report: [/devlog/stust-project/research-project-1/scene-build-2.jpg]

有試過陰影投影,但覺得效果不理想就放棄了。

image display error, please report: [/devlog/stust-project/research-project-1/scene-shadow.jpg]

組員 Avis Shih 也根據當前畫面繪製了優化的參考圖,包括陰影差異、筆觸效果與氛圍混色等。

image display error, please report: [/devlog/stust-project/research-project-1/scene-director.jpg]

氛圍混色

Avis Shih 繪製的參考圖有告示一些氛圍渲染用的混色,遊戲中最簡單的實現方式就是疊半透明,於是我給物體前後加了帶有筆觸的圖片。

image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-effect.gif]

開關氛圍混色的對比圖(gif)

2D 遊戲蠻常用這種方式堆疊場景氛圍,光影雲霧等等,而那些技巧也適用於固定視角的 3D 遊戲。

但混用可能會遇到圖片裁切的現象,需要用深度圖做交界淡出,是煙霧、火焰特效的常用技巧。

image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-fade.jpg]

※圖層混合

透明度混合的問題是前景會吃掉背景色,導致畫面細節被弱化,為了解決我也嘗試了繪圖軟體中的圖層效果,例如柔光、加亮顏色等等,Shader Graph 有 Blend Node 可以直接完成計算。

image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-blend-1.jpg]

問題在與螢幕顏色的混合上,片段著色器(Fragment Shader)無法像 Blend mode 可以用 Src, Dst 之類的關鍵字直接混背景色,需要先取得色彩緩衝區(Color Buffer)中的像素顏色才行。

雖然 URP 可以取得渲染完不透明物件後的畫面顏色(Opaque Texture),但無法像 Built-in 的 GrabPass 一樣取得「當前」的畫面顏色。

image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-blend-2.jpg]

這就導致混色效果會把其他不透明渲染吃掉,而不同的混合效果重疊時也會互吃。

image display error, please report: [/devlog/stust-project/research-project-1/atmosphere-blend-3.jpg]

雖然可以自己寫 Render Pass 處理,但重複抓整個畫面的資料不是好主意,這可能也是 URP 拋棄 GrabPass 的原因?總之這條路可能不通我就沒繼續深入了。

植被濾鏡

毛茸茸的草地與花朵是風格化渲染的重要部分,我們主要參考 View Finder 中出現的油畫場景,經過一些分析後我得知他們是靠 Alpha Card 植被與濾鏡達成的效果。

image display error, please report: [/devlog/stust-project/research-project-1/filter-reference.jpg]

花草植被因為組員 YukiO3O 先做過就拿來用了,雖然這次是手動複製貼上的,但有用 GPU Instance Material 讓效能不至於炸裂。

image display error, please report: [/devlog/stust-project/research-project-1/filter-grass-1.jpg]

最麻煩的還是濾鏡,我真的看不出 View Finder 是怎麼算的,最後決定找現成的來用:Image Effects | Part 6 - Painting Joy,我只把他整合到 URP 中並做一些強度控制而已。

image display error, please report: [/devlog/stust-project/research-project-1/filter-grass-2.gif]

為了展示效果有特別調高強度,看草會更明顯,雜訊是 gif 壓縮造成的(gif)

目前的效果差強人意,除了模型本身還有小島表面的貼圖要調整,我們也讓組員 Avis Shih 畫了後續方向的參考。

image display error, please report: [/devlog/stust-project/research-project-1/filter-director.jpg]

雲霧粒子

星球設計圖有把雲畫出來,我首先想到的就是粒子效果。找教學做了簡單的風格化雲,用球體模型加頂點變形著色器做出雲,再用 Unity 粒子系統生成。

image display error, please report: [/devlog/stust-project/research-project-1/cloud-particle.gif]

雲粒子的展示(gif)

我還試過使用筆觸貼圖卡片,但效果不理想就沒深入了。

image display error, please report: [/devlog/stust-project/research-project-1/cloud-brush.jpg]

※參考資料

Creating stylized clouds with Shader Graph and Shuriken in Unity3D

Ultimate Clouds with Shader Graph in Unity, Made Easy

體積透明

最終項目是半透明,與前面氛圍混色不同,這次是要給冰塊之類的物件使用。我想讓星球的冰柱在剔透的同時具有厚度,但一般的透明混合會讓物體看起來很薄,即使雙面渲染仍感覺是空心的。

image display error, please report: [/devlog/stust-project/research-project-1/trans-default.jpg]

註:後來想想發現,就算材質是透明的在星球尺度下也不可能真的看透過去。

※深度體積

首先想到的就是根據物體「厚度」改變透明度,所以我嘗試用兩顆材質球(或兩個 pass)渲染物體的兩面,靠深度差計算出厚度。這個手段在渲染不透明物件(Opaque)中有效,但在透明物件(Transparent)上則會引發一些…奇怪的結果。

image display error, please report: [/devlog/stust-project/research-project-1/trans-error.gif]

詭異的顏色跳動問題(gif)

再試了幾種方法(如 ColorMask、VFACE)仍未果後我就放棄了,決定另找方案。

註:而且這種方式在凹物件上可能有其他問題。

※菲涅耳體積

沒有真正的體積就只能偽造了,我想到的是菲涅耳透鏡(Fresnel effect)在球體上的漸層效果,只要反轉就跟厚度很像了。至於與其他物體的交集就用深度圖(Depth Buffer)計算即可。

image display error, please report: [/devlog/stust-project/research-project-1/transparent-Fresnel.jpg]

註:更精確的厚度算法是用射線與球體交集,但菲涅耳比較簡單 :P

用菲涅耳計算體積的問題是只在球體上有效,不適用複雜結構,我花了幾個小時仍無果決的不該再花時間就放棄了…?也不算,因為我想通一件蠻重要的事。

既然效果只適用於球體,那就乖乖用球體,因為星球的透明效果也不是必需的,不如為現有的成果另尋用途,例如用額外的球體包裹星球,利用透明度做出冰層、大氣或濃霧的效果。

image display error, please report: [/devlog/stust-project/research-project-1/transparent-atmosphere.jpg]

即使研究目標沒達成,我們還是得到了意外收穫。

image display error, please report: [/devlog/stust-project/research-project-1/jappy-accidents.jpg]

※參考資料

Models using transparent shader are overlapping themselves

Rendering Object Thickness/Volume with Two-Pass Shader

效能…

沒概念 (´・ω・`)

image display error, please report: [/devlog/stust-project/research-project-1/performance-idk.jpg]

說來慚愧,我對效能和優化是相當不熟悉,因為自身還沒什麼實踐技美知識的經驗,所以也沒遇過真正的要解決的效能問題。有時間可能碰碰 Memory profiler 吧,但除非效能問題超嚴重,不然專題也沒什麼優化需求。

成果總結

總結暑假三個月的成果就是開頭展示的圖片!

image display error, please report: [/devlog/stust-project/research-project-1/result-1.gif]

搭啦~最終成果畫面(gif)

這次研究核心還是在貼圖製程上,也把過程的畫面跌代排列給大家看:

image display error, please report: [/devlog/stust-project/research-project-1/result-Iterate.jpg]

心得感想

自己從遊戲程式起家的,從高中自學到現在也花了不少時間在程式上,但專題會逐漸轉向企劃、專案管理和技術美術,基本等於踏入新的領域了。

最後再盤點一次期間的收穫!

※企劃

發想機制、遊戲設計、系統企劃,我在企劃時也向前輩們尋求了不少建議,最後在第四版補上時間預估、人力分配、設計策略等等內容。

image display error, please report: [/devlog/stust-project/research-project-1/end-planning.jpg]

系統企劃中的某些清單

這是我首次在實作前想那麼遠,不然以前有想法就直接開始寫程式了,但也是試過才知道弄清楚自己的想法有多困難,很多自以為清楚的東西寫出來才知道是模糊的。

雖然企劃書還有很多缺陷,但也不能一直寫下去,畢竟暑假的首個月都花在相同工作上了。

除此之外,暑假時間我也報了夢想方舟(CGArk)的課程,是由雷亞總監 Tony 大大主講的企劃入門課《遊戲企劃思維:從創意到現實》,學了更多企劃應有的思考方式和知識,企劃職位、產業蓋覽、遊戲循環、敘事、美學到最後的行銷和創業都有,受益良多。

image display error, please report: [/devlog/stust-project/research-project-1/end-cgark.jpg]

在 CGArk 那裡拍的照片

※程式

這裡也補充一下程式組員 Snoweve 的工作內容。

由於專案的研究性質,規劃時我把重點放在學習上,所以程式部分比較多讓他接觸 Google Apps Script、SQLite、Zenject 與乾淨架構這些超出學校範圍的知識,所以正文才沒提及程式工作。

對程式工作內容感到好奇的人可以到他的巴哈姆特小屋(snoweve99183 的小屋)觀看噢,後續也會進行一些開發日誌更新。

而對我來說,則是要克服想做習慣工作的慾望。

畢竟程式職位已經交給組員了,得把時間花在只有我能做的事上,幫助隊友要透過調整設計、寫清楚文件與降低溝通成本之類的方式,從企劃層面降低其他人的工作量。

※專案管理

我們是用 Trello 分配工作、Miro 發想和 Notion 留存文件,而 PM 的內容就是考慮工作項目、時間安排、進度規劃和分配組員工作,並確保阻塞不會發生。

image display error, please report: [/devlog/stust-project/research-project-1/end-pm.jpg]

專案用的 Trello 與 Miro 截圖

這方面的知識又更難找了,主要是邊做邊學,然後靠網路資訊和前輩的建議修正方向。

我們也用了 git 做版本控管,這也是第一次特別做分支管理,不然自己做都嘛全推到 main。有分支就能同步讓程式開發功能、技美研究與美術更新素材了,不怕動不動遇到衝突。

image display error, please report: [/devlog/stust-project/research-project-1/end-git.jpg]

分支示意圖與版控工具 fork 截圖

※技術美術

最後就是技美相關,正文講完了硬知識,這裡分享一些軟知識收穫,主要是思考方式的變化。

先前個人在學都是遇到某個有趣項目就不計代價的深入,嘗試解決難題或完成某些很酷的成果,但這次身為團隊技美、企劃、專案管理,新的身份讓我考慮更多現實的問題,例如時間。

所以要先思考「該花多少時間研究技術方案?」

畢竟真的沒必要重複造輪子,要克制住追根究底的好奇心,研究出次優方案就收手,有現成解方就用,有插件能解決就買。

有時也要質疑某些問題「真的有必要解決嗎?」或「真的有這種需求嗎?」

很多時候也沒必要執著於原本的目標,方案有缺陷也沒關係,因為「需求能改」,技術缺陷可以用設計彌補,而且失敗品也不用拋棄,可以另尋用途,就像正文提到的透明效果,畢竟所有資源都很珍貴。

之前就在專案或工作中用過 Shader 知識,但從這次經驗後我才認為自己開始接觸到技美這項「職位」,主要是思考方式上的成長。

而它的範圍之廣,這次的工作也只是偏向 Shader 與 Workflow 的一小部分,希望專題過程能逐漸把技能樹點開。

image display error, please report: [/devlog/stust-project/research-project-1/end-ta-skills.jpg]

圖片引用自 Technical Artist Job: How To Prepare, What To Expect

總之技美真的是很酷的職位 :D

後續計劃

《太空漂流》目前處於廢棄狀態,原因是規模過大,這也是前輩們看過企劃後的普遍觀點,複數系統加宏大的敘事野心都不是專題數月内能完成的規模。

拋棄成果很可惜,但原先目的就是學習與研究,這只是專題計劃中的第一步而已,重要的是所有知識與技術都能被帶到後續專案中。

新專案會配合學校進度執行,名稱暫定《太空生態球》。

這次會縮減規模並讓機制簡單許多,我們沒打算深入新專案的遊戲玩法,而是要把重點放在團隊磨合與熟悉開發流程上,畢竟學習仍是三年級專題的首要目標。

image display error, please report: [/devlog/stust-project/research-project-1/end-next.jpg]

土炮出的引擎示意圖與 Miro 發想截圖

至於最終會做到什麼程度?我不確定 :P

理想情況當然是做出能完整展示內容的 Demo,但也不強求,敬請期待之後的分享文章 :D

※社群經營

社群方面,我們會在官方帳號釋出專案的穩定成果,而過程中的零碎進度則透過成員的個人身份分享。最後再放一次粉專連結,歡迎各位點讚追蹤!

Facebook:4a.m.就寢

image display error, please report: [/devlog/stust-project/research-project-1/end-facebook.jpg]

特別感謝

感謝好友 ROB 以及 chiaoho、燈塔、shanzeng 與言靈幾位前輩提供的建議和回饋!

感謝走鹿前輩的企劃建議和接受我各種專案管理問題轟炸!

感謝綺麗前輩提供的各方面建議,包括企劃、專案管理、美術流程、UI 和概念圖、工作效率、時間評估、AI、專題建議和出路等等!

感謝 CGArk 和 Tony 大大開設的企劃入門課程!

感謝可靠的組員與閱讀到這裡的你 (´▽`ʃ♡ƪ)"