【Gamystery 】EP3 我的第一個產品 - Light Memory
- 彥澤 廖
- 2024年3月11日
- 讀畢需時 2 分鐘
前言
本篇為技術取向, 分享開發上的盲點與經驗。
第一個自產自銷的產品，歷經大約一個月的時間，終於要脫離發展階段。
接著準備進行「上架」與「教學」。過去在組織內，有專責的人協助，現在必須自己動手。
往好的一面想，UE Marketplace 的品質參差不齊，尤其在與編碼相關的功能上，注重功能為主。
在分享開發的心路歷程前，簡單介紹我製作的產品 - Light Memory
在所有3D軟體中( Unreal, Unity, Blender….. )，Light 是不可或缺的重要功能。
而Unreal 的Lumen，比同類型工具，能維持品質的情況下，運算速度快上不少。
Light Memory
想法源自於之前學習Light的經驗，有鑑於自身並美術專業，在調整環境的光源配置容易來會嘗試，卻無法有效率地做出不同版間的對比。
解決痛點: 「難以比較多組燈光參數與擺位之間的差異」
核心功能: 針對Light, 進行「快速保存」和「還原整組」
開發的過程還算順利，沒遇到太大的瓶頸。
分享幾個”規劃”與”結果”不同的地方 :
儲存資料的方式
UE場景上物件的最基礎單位為Actor, 引擎資料面最基礎的單位為UObject。兩者共通點就是只要關閉遊戲或是編輯器，就資料就會消失，要讓資料能夠儲存下來，就必須轉換成Asset。
最初的規劃是以UObject儲存有關Light的相關的參數的數值，這面臨兩大問題:
過度依賴於Light不同類型的Light各自有不同的參數，當參數變動( 新增、減少、改名... )的時候，就必須手動修改，整個設計並不利於未來的變化。
資料無法保留 UObject在關閉引擎後，資料就會消失。（用UObject 實作後，才學到這個教訓）
最終依靠「建立Blueprint」( 想法源自於某次與對UE抱有熱愛的朋友 )解決上述問題，不僅能在有限的時間內解決問題，甚至還能額外的效益。
「建立Blueprint」提供的優勢 :
解決過度依賴於Light種類與參數變動，因為採用Blueprint可以直接建立與場景上對應的Component，直接封裝的資訊
增加還原燈光效果的手段
利於轉移或應用在不同專案
關閉Editor後依然保留
應用資料的方式
這個問題發生於開發後半階段，
不同燈光的特行影響到產品使用規格的設計。
先簡單介紹一下UE的燈光系統。
基本可分為全域、區域兩種不同類型( 全域: DirectionalLihgt, SkyLight, 區域: PointLight, SpotLight, RectLight )。
基本上在製作場景時，全域類型不同種只會有一個，為了避免衝突或是過於複雜的疊加。
而區域則可以大量布置在場個場景當中。
起初規格沒有還蓋到全域燈光的使用習慣，造成在應用情境測試階段的使用體驗異常詭異。
最後，不管在程式或產品面，清楚的切割全域、區域兩個差別。也發現需要再把一些基礎的全域元件( VolumnCloud, SkyLight ), 一同納入支援的類型當中，創造更符合需求的解決方案。
Epic 的開發者帳號蠻好申請的, 但產品的審核來回了一個禮拜，進行中~
