[Spine]使用Spine處理不同角度時該直接該直接換圖還是換骨架?

如題，Spine雖然可以用mesh變形等方式做出轉面的效果，
但是轉面角度過大，例如正面轉成背面時，還是只能換一張圖。
所以此時有兩個方案可以選擇：

方案1. 同一個骨架上準備不同面向的圖

以上圖為例，角色從正面45度轉到背面45度，
至少頭部，軀幹與臀部就得準備正面45度與背面45度的圖，
然後在動作過程中換圖。
動作速度快的話，換圖的破綻就不容易被發現。

雖然說這樣代表轉面時
但角色動作量大的話，
一個骨架每個插槽會有許多圖，
某種程度來說會增加編輯動作的複雜性。

下面連結中有討論到換圖的範例：

http://zh.esotericsoftware.com/forum/DISTURBING-THE-VERSE-zero-gravity-fighter-7774


方案2. 不同骨架對應不同面向

上圖分別為正面與側面的骨架，
假如在同一個動作中只有正面或只有側面的話，
便分別交由不同骨架去處理，編輯起來複雜度就比較低。

但是換骨架會多一些其他的時間成本得花：

1. 每個角色需要多架一副以上的骨架（廢話）

2. 為了讓兩個骨架作用在同一個角色上，可能得請程式人員想辦法

3. 不同的骨架沒有辦法混合動作

那要怎麼選擇什麼時候該怎麼做？

以下純粹是個人的想法，自己也正在摸索中。

狀況允許的話，花點時間分析一下單一角色預期要作到的所有動作有哪些。

例如看2D格鬥遊戲的設定集，
都會看到輕拳重腳必殺技等要做哪些不同的動作，
藉此就可以先分類規劃動作，用來決定自己該如何綁骨架。

假如角色轉向的狀況少，一個面向就可以處理大部分的狀況，
那剩下一點點的轉向動作就用換圖處理掉。

假如角色動作量大，且每個面向動作都很多，就可以考慮分不同面向的骨架。

假如動作量很少，那也不需要另外架骨架，換圖做掉就好。

假如希望美術人員想自行處理轉面的問題，減少溝通的成本，就考慮用換圖的方式；
反之若是美術人員與程式有足夠時間可以溝通，可以考慮另外架骨架。
.
換圖跟換骨架也可以並行，分骨架後，個別需要連貫的轉面動作另外用換圖處理。

上面列出一些不同狀況，其實我想說的事就是case by case，
重要的是知道自己想做什麼，握有有哪些資源，來找出最適合自己最省工的方式來處理吧。

TGDF2017心得筆記 - Day2

續上一篇把心得補完，
第二天花比較多時間逛indie space，所以內容比較少。
另外要說的是TGDF照慣例過沒多久就會放出影片，
所以我這邊寫的也是比較偏個人的感想，內容細節就不做太多紀錄。

Day2 - 透過『Rez Infinite』讓未來成為現在

https://gnn.gamer.com.tw/8/149148.html

上面連結有該場次詳細的報導。

這場演講有幾個點讓我有點感慨：

1. 要做自己喜歡的東西。

有時候工作上的內容因為時程、壓力或喜好不同，
變得容易妥協，甚至隨便應付，不把自己做的內容當成自己的心血。
不是熱情作為燃料，是很難在工作上持久衝刺的。

2. 喜歡聽音樂是人類本性。

好的音樂可以讓遊戲增色不少，甚至可以作為遊戲的核心內容。
回想我特別喜歡的遊戲，大部分的背景音樂或插曲都是高品質的，
音樂好聽且配合上遊戲內容的氛圍調性的話，更能讓玩家帶入遊戲內容。

聽完演講本來有股衝動去學點樂器，增加一些音樂素養，
但我技能點數已經點太雜了，只好作罷XD


Day2 - 紅魔導師的求生之路：不是程式也能製作遊戲的PlayMaker運用技巧

講師簡介Unity PlayMaker插件的用途。

其實不只企劃美術，若是要很快的兜出prototype，
個人覺得都可以使用類似的插件，減少來回時間，又方便讓美術企劃臨時修改。
等到prototype過關，再來拆解內容，設計較完備的架構。

Day2 - 『返校』美術風格設計

講師介紹『返校』中的美術風格如何發想。

怎麼讓遊戲畫面能夠跳出來，跟其他遊戲做出區別，是首要目標。
還有就是所有內容都要符合所設定的調性，不要加入太跳tone的內容。
使用符合時間預算的製程，也是小團隊得優先考慮的事。

Day2 - 角邊中的風景 - 『Qubot像素戰機』的視覺創作雜談

講師介紹『Qubot像素戰機』的創作到上市過程。

經驗豐富的團隊，美術與程式都十分強悍，角色編輯器讓人印象深刻。
針對目標市場玩家設計對應的美術風格與玩法，讓玩家與遊戲密切互動。
要增加耐玩度的與變化的話，玩家自製內容這個方向的確得好好研究一下。

Day2 - 遊戲軟體工程師生存守則

講師分享軟體工程師在遊戲產業中如何發揮專業。

主要內容我覺得『Clean Code』系列書籍應該可以涵蓋這次演講大部份內容。
另外呼應『要做自己喜歡的東西』這件事的話，
軟體工程師也該追求『寫出高品質的程式碼』這件事，
這樣的話，就算沒辦法完全認同目前工作專案的內容，
但還是能找出自己能夠努力去追求的目標，進而發揮自己的專業。

以上，等影片開放後再來把沒聽的場次補完一下。

TGDF2017心得筆記 - Day1

這兩天會去聽2017台北遊戲開發者論壇，

就我有聽的場次簡單地寫個心得筆記。

Day 1 - Google最新訊息搶先看

講師分享Google提供跟遊戲有關的最新服務。

我對工具的態度，通常是先知道有這樣的東西就好，
等有需求的時候再去研究，所以就不多說了。

總之就是以後有遊戲要測各種android平台的話，
直接找google提供的服務比較方便。

Day 1 - VR & AR邁向實境之路

講師分享AMD對VR的產品發展。

除非是有一定要VR才能實現的功能，我大概才會想多研究。
假如是為了想先站在浪頭上而去接觸，那要投入更多資源，
對我來說不划算，也不是我想做的事。

Day 1 - 以小型獨立工作室塑造 3D 日式動畫畫質

講師分享其所屬專案的美術製程。

由於是電子小說，攝影機角度比較固定，
建模（包含人物）可以只針對攝影機會照到的角度處理，
人物的五官可以直接用2D方式畫上去，
色塊著色的方式主要就是製作工具控制切分色塊的臨界值
場景氛圍則用工具控制色調與對比度，或用一些後製效果去處理，
同時把主角相對於背景突顯出來。

至於減少成本的方式，可以多放靜態場面，還有減少人物轉角度的狀況，
讓美術素材能夠盡量重複利用。
總之可以參考看看新房昭之的作品XD

Day 1 - 遊戲人工智慧與關卡難易度

教授介紹拆分遊戲內容來定義難度進而訓練AI的方法論。

遊戲流程其實就是有限狀態機，是狀態、對象、輸入輸出的集合，
所以要先從遊戲流程中拆解出狀態機，再來找出與難易度有關的要素，
便可參數化這些要素，進而以data driven的方式調校AI。

教授用撞球遊戲為例介紹了整個流程：
決定難易度的要素主要是AI要能判斷球的好打程度，
球與球間的距離、夾角、球的聚合程度等等，
然後可能也要考慮下一顆球的好打程度。

再來是根據輸入讓AI有預測輸出的能力，
最直接的方式是AI用遊戲裡的物理模擬去算不同結果，
但考量效能這並不是合適的作法，
於是便用機器學習的方式，
去預測擊球的結果與最後停下來的位置，
訓練到預測的結果與實際物理模擬的結果盡量接近。

這樣AI就有選球打的能力了。
讓AI根據難易度去做不同的輸入選擇，
笨一點的AI就選容易輸的輸入，強一點的AI就選容易贏的輸入。

所以回過頭來，最重要的是如何拆解出遊戲的狀態機，
建立難度與遊戲機制的對應關係。

而且這個對應關係有機會是可逆的：
假如可以設計關卡來對應不同難度，
那也有可能輸入難度自動產生關卡。
只要盡可能量化各項要素，
依特定樣板自動產生的遊戲內容是很有機會可以實現的。

Day 1 - 《地下城物語》─再滾燙的紅海都有屬於你的一條活路

講師分析所屬專案從開案、設計、到營運的策略
主要就是以遊戲機制為主，並盡量透過玩家意見回饋來改善內容。

另外，雖然有些細節要試了才知道，
但目標跟方向是需要先確定的，
且遊戲中內容都盡量不與此目標與方向牴觸。
因為遇到過不少反例，所以就特別心有戚戚焉 orz

（待續）

[Unity]2D橫向捲軸遊戲的角色的移動與物理模擬筆記

關於標題，官網上有許多範例，這邊就只揀選我有用過的方法作個紀錄。


要用內建的物理模擬功能嗎？

https://www.assetstore.unity3d.com/en/#!/content/11228

首先，在實做前可以先把上面的範例找來試試，
其中有不少可以參考的地方，例如攝影機或捲動的背景等等。

至於角色移動，也可以參考範例中的方式，使用內建的物理模擬方式，
調整參數達到操作角色進行移動，跳躍等行為。

但這可能會有幾個狀況需要考慮：

1. 必須要很了解內建物理模擬功能的參數影響，才能調整出接近自己想要的效果。

2. 有些非現實的移動方式，要靠內建物理模擬來實現的話，可能需要使用比較間接的方式。

上面並不是說內建物理模擬不好，而是適不適合的問題，
想像一下，假如我們要做像小精靈一樣的遊戲，
我們也不需要用到物理模擬，只需要適當的碰撞偵測即可。

若我們需要的操作不複雜，只要加上適當碰撞偵測後，
移動行為就只是對物件做單純xy座標計算，
這樣就不用太花時間了解內建物理模擬的方式，
也可以準確做出自己想要的移動行為。

反之，假如熟悉內建物理模擬功能，很清楚要怎樣調整才能達成自己需求，
那也不需要重造車輪，直接用內建的功能吧。

再重申一次，不是好壞的問題，而是適不適合的問題。

以下的說明是不使用內建物理模擬的狀況。


那什麼是適當的碰撞偵測？

當然還是看需求而定，就我所使用到的例子來說可以參考上圖，
當預期角色朝特定方向移動時，便將此方向拆分成水平與垂直分量，
各自打出射線去偵測是否打到其他碰撞體。


幾個打出射線需要注意的點：

1.射線長度跟每個frame想移動的距離有關

射線長度並不需要太長，因為其實我們想知道的是下個frame會不會碰到東西，
所以射線長度應該跟每個frame角色會移動多長的距離有關。

2. 射線的間隔依實際需求決定

每個分量需要打多少射線？還是依照狀況而定。
像上圖，假如射線剛好沒有打凸出來的地方，角色便會認為凸出來的地方可以走進去。但也不是射線打越密越好，理由下述。

3. 射出射線這件事每個frame都得做

上列發出射線的行為是每個frame都在做的事，所以假如場景上有很多角色，每個角色在每個frame都打出很多射線，某種程度來說對效能會造成負擔。

所以射線的數量與長度還是需要根據需求來做調整。

那上面的內容是否還得自己寫程式碼實現呢？

https://github.com/prime31/CharacterController2D

上面剛好有別人寫好的功能可以直接套用，
裡面也有範例，有興趣就抓來試試吧，
甚至修改一些功能(例如把boxcollider改成其他的collider或組合起來的collider群組)。

使用上述連結功能，加上一些國中物理來做座標計算，
就可以實現很基本的2D橫向捲軸操作了。

[Spine][Unity][筆記]使用Spine製作2D遊戲攻擊判定

如題，最近剛好試到這個功能，作個簡略的筆記，操作的細節就不多提了。

主要流程就是Spine提供功能，可以圈選出一個區域，
匯入Unity後，便可透過某些方式自動產生一個會跟著bone的polygon collider。

Step 1. 在Spine中設定bounding box

如上圖，在想要綁定bounding box的bone上新增一個socket，
在socket中新增bounding box。

Step 2. 在Spine動畫模式中控制bounding box產生跟消失的時機

攻擊判定只有在攻擊瞬間才為出現，
所以需在動畫模式決定bounding box產生跟消失的時機

Step 3. 輸出Spine資料匯入Unity

略

Step 4. 在Unity 用spine骨架資料產生game object A，並建立一個子game object B附加於A

略，另外做一個game object的原因後面會提

Step 5. 在B上新增Bounding Box Follower，並且選定對應的骨架資料與socket

如圖，把上圖SpineAnimationSide1當作A，BB_Side1_FrontFoot當作B，
在B中新增Bounding Box Follower Component，
便可選擇要指定骨架跟Socket，
可以看到上圖的下拉式選單中，沒bounding box的socket都反白沒得選。

上述動作還會自動幫增加rigidbody 2D還有polygon collider 2D兩個component，

若是在A上增加Bounding Box Follower Component，會有提示訊息要使用者另外新增在B上，
就我自己理解，在我們製作攻擊判定的case中，
可能不會希望攻擊判定的碰撞效果，佔用A的rigidbody，
影響到原來角色A的各種行為(例如移動)，
所以會變成另外產生一個B，讓碰撞判定有自己的設定。

Step 6. 在B上新增Bone Follower，並選擇對應的bone

只做Step5碰撞體還不會跟著動，要讓它跟著骨頭才行。
所以需要新增bone follower並選定對應的bone。

上述事情做完後，再寫腳本於OnTriggerEnter2D中設定好動畫演出，
就可以讓角色產生攻擊判定了。

參照影片，現在角色的攻擊動作，就有對應的攻擊判定了。

[首頁]這裡是歐美加的遊戲製作筆記儲藏室

如標題所述，此處用來放一些遊戲製作筆記，
讀書心得，或其他有的沒的。

總之就是想留下一點紀錄，一來可以看到自己走過的路，偶爾感嘆一下，
二來是看有沒有機會多跟相同興趣的人多交流。

以上，歡迎參觀指教 <(_ _)>