製遊

2019年10月6日星期日

[Unknown] #1 Base1 level 更新

繼上次筆記後這 2 周來好像只摸不到半天的時間
能空出來做自己私事的時間實在太少了
真的讓我常有想要乾脆辭掉所有工作
不想負任何責任
只想開開心心的專注於自己喜歡的事業

總之地下室 (Base1) 地板, 牆面, 斜坡車道已經初步定案
順便上簡單的 vertex color 方便日後辨識地形設計

之後針對地下室還需要加入各個設備如:
機械車位系統
停車格標示
儲藏室
抽水馬達及供水槽
汙水池
發電機配電控制室
高壓電配電室
電梯

.....等

2019年9月28日星期六

Shader Graph custom lighting + PBR master node + stripping unused

最近開始熟悉 Unity SRP 和 shader graph (SRP 還不算熟)

上過課之後

看官方的部落格介紹文章也很快進入狀況

https://blogs.unity3d.com/2019/07/31/custom-lighting-in-shader-graph-expanding-your-graphs-in-2019/?fbclid=IwAR387bG0VVwX7nF0vwRZL_7_Qmf2ZgsoXWhRL0eJnuUfTYZqQQ2XGZjobkk

差不多有感覺可以駕馭 shader graph (至少針對 LWRP)

另外延伸看到有人分享文章

https://medium.com/@larsbertram1/lwrp-and-custom-lighting-in-shader-graph-6a7c48008a1d
====
The shader compiler comes to our rescue, as it will strip all code, it thinks, which will not contribute to the final pixel. So if we set albedo to constant 0,0,0 or black the entire diffuse lighting pass will always result in 0,0,0 and thus the shader compiler will strip it, right? Setting occlusion to 0.0? Ambient diffuse and specular lighting will always be 0.0, so these parts should get stripped as well. What’s about direct specular lighting, which includes the most expensive calculations? Setting smoothness to 0.0 and specular to 0.0 as well should do the trick.
====

使用 Unlit shader 製作 custom lighting shader 無法運用 Unity 內建的 global illumination / lightmap / cascaded shadow 功能, 使用 PBR Master Node 的話又會顧慮到做多餘 PBS lighting 的 shader codes/calculations.
因此將 custom lighting 的結果直接指定給 PBR Master Node 的 Emission input, 其他用不到的 feature 就歸零, 這個方式就可以透過 Unity stripping shader codes 功能將 PBR Master Node 多餘的計算相關 shader codes 排除.

非常有用的資訊.

2019年9月24日星期二

[Unknown] #0: 首次筆記

老樣子, 一直以來沒有時間做自己想做的遊戲

我也不知道現在算不算開始動了

總之最近開始練習 Probuilder, 打算先把 prototype level 做出來

初次更新

我想做的是有地面也有坑洞用來放置立體機械裝置

比如說機械車位系統

希望未來能持續投入時間

加油一下吧

2019年5月13日星期一

Next step

2019年5月7日星期二

Tests in Unity

過去幾年接觸過 TDD (Test-Driven Dev)的概念後
就一直想要在自己的專案中實現 unit test實作
但礙於時間不夠充足之類的前提讓我一直沒有動工

最近工作上的專案算是比較有空下來的時間
所以針對 Unity 官方提出的 test環境進行一番研究與探索
算是準備的差不多可以執行自己的 test programming了吧

當然也歸功於 Unity官方準備的開發環境與說明文件真的很方便
所以感覺要實現 TDD概念開發這點也不是那麼難了

幾個關鍵可先參考官方文件
Unity Test Runner
https://docs.unity3d.com/Manual/testing-editortestsrunner.html
https://docs.unity3d.com/Manual/PlaymodeTestFramework.html
這份則是比較舊版的官方中文翻譯文件
https://docs.unity3d.com/Manual/PlaymodeTestFramework.html

基本上簡易的unit test script可說是無痛實現
照著官方說明操作就可以建好完整的 test環境
但事情總是不會只有這麼簡單
像我目前的專案經過長期粗暴醜陋的"封裝"
我想進行測試的大部分內容已經牽涉到 internal / private / protected封裝
所以在 [Test]函式中是無法存取到該內容的

這一點算是老問題了, 所以 .NET官方早有解法
[assembly: InternalsVisibleTo(“UnitTests”)]
http://anthonygiretti.com/2018/06/27/how-to-unit-test-internal-classes-in-net-core-applications/

但在 Unity Test Runner環境下要如何實現這一點呢?
我首先必須把 assembly正確區分出來, 這個屬性才能派上用法
因此查過官方文件後, 我該做的就是針對所有 scripts設定正確的 assembly definition asset
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html

好啦, 問題來了, 誠如官方文件所說, 如下圖
Predefined versus manually defined assemblies

Predefined versus manually defined assemblies

手動設定的 assembly (.dll)都無法參考到預設的 Assembly-CSharp.dll
因此如果我想要為專案正確設定 assembly definitions,
等於要將整個專案所有的 scripts做一次完整重構了吧
是說這一步驟也是該做, 只是當初一開始只想著輕鬆實現 unit test開發環境
沒想到還是得先經過大規模的重構才有可能完成有意義的 unit test

如上所述如果整個專案都正確區分成正確的 assemblies,
應該就會有個對應的 test assemblies (Tests.dll)去參考想測試的部分 (如 Main.dll, Stuff.dll, ...)
然後在 Tests.dll中實現 unit tests

當然總是還是有更偷懶的做法
準備一個 Editor資料夾, 在其中建立 test scripts
如此一來 test scripts便會被加入預設的 Assembly-CSharp-Editor.dll
因此整個專案仍然維持最原始單純的 Assembly-CSharp.dll 與 Assembly-CSharp-Editor.dll
因此接下來只要在某個想被測試的 script file中,
設定上面提到的 InvernalsVisibltTo attribute
我自己測試都是在 namespace外側設定該 attribute, 如下所示

using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("Assembly-CSharp-Editor")]
namespace MYWORK
{ ... }

如此做後, Assembly-CSharp-Editor.dll 中所有 scripts
都可以看到 Assembly-CSharp.dll裡面所有的 internal內容,
至於 private/protected內容的話則可以透過 Reflection手段取得
之後我有深入玩過的話再另外分享一篇吧
我知道這招很髒, 不過偷懶嘛, 只是為了先求快
之後真的要實現完整的 unit test, scripting結構重構還是逃不了的

2019年4月12日星期五

繼續, processing..., waiting...

閱讀, 練功, 發想, 遊戲開發?...
目前還是一直在無限循環

這次在看這個系列主要還是以 Unity底層技術為主的技術文章

http://geekfaner.com/unity/index.html

雖然部落格作者本身做了很多佛心的心得分享
但主要以他本身研讀 Unity相關的底層文件/coding經驗為主
所以在沒有經自實作相關技術前, 閱讀這類文件的幫助有限

一系列文章探討著 Unity如何實現
Physics Based Shading,
Standard Shader,
Command Buffer,
Scriptable Render Pipeline,
Post Processing Stack 等

系列快要看完了, 但還是必須找時間親自研究實作出來,
才算是把技術學起來, 練功成功

雖然一件自己的 indie案子都還沒開始但 keep going.

2019年2月16日星期六

無方向

寫一堆心得, 是當成個版周記了逆

ㄟ....這本來就是我的個版厚

這兩周....不對....這兩年(這8-10年)來還是持續一成不變的作息

滿腦子想著我該做點什麼遊戲了

但完全想不到可以做什麼題材? 或該從哪些點子開始動手出發

然後還是不停的在挑以前累積看不完的學習筆記

有時當作學新知識/技術, 有時想把以前挑戰失敗的技術重新看懂/練習

反正時間還是都花在閱讀上了, 連真正動手練習的次數都超少

從開始想認真開始 indie develop計畫時, 真的會有種我到底都在幹嘛的心情

突然可以理解到前幾個月前同事勇敢想跳進 indie坑的時候

跟我聊到每天都不知道在幹嘛的那種空虛恐懼感覺

.
.
.

嗯....還真的只有這些, 我連該寫些什麼都想不太到

最近還是重覆花時間看 computer graphics pipeline / Unity engine底層相關技術文獻

(不過其實也花了幾周認真把 Bloodborne破完一輪就是了)

只是這些跟真的要開始動手都還是兩回事

所以我到底現在要寫什麼?

大概只是想表達我還在猶豫我應該先開始動手做哪件事吧..

訂閱：文章 (Atom)

2019年10月6日 星期日

2019年9月28日 星期六

2019年9月24日 星期二

2019年5月13日 星期一

2019年5月7日 星期二

2019年4月12日 星期五

2019年2月16日 星期六