UNITY多工並行

UNITY中所有程式碼都是一行一行執行，想要做時間延遲顯得很麻煩

1.一般時間延遲 UNITY提供 Invoke( "呼叫程式" ,delayTime);  但這無法帶參數很GG

2.另一方法就是UNITY 提供 WaitForSeconds(delayTime); 官方直接用協程方式製作，簡單來說有點像是開啟新的小程式，他跑他的，主程序一樣進行。

這樣寫法也算奇妙，為了一個時間延遲執行開啟協程功能，另外筆記 IEnumerator 需要  yield return 來跳出這個協程。

UNITY 另一個大坑 material

最近開始研究材質球了，material是一個大坑，一張圖片要做點特效就要套上材質球，這邊幫自己筆記一下，材質球有很多渲染模式與選項，後期研究完也算是完成3D貼圖的攻略了。

後續有空再補一些使用心得吧

開發心情速記

今天來保養廠，利用等待時間來記錄最近開發感想。

Unity也摸了兩年了，最近終於能比較上手一些，做遊戲是團隊戰，很多東西如果一個人自己來會拖累專案，像是做特效這部分，一個人要弄美術還有程式，做好特效元件在還要測試實裝有無Bug,常常一個環節有問題時後面進度停滯。

有經驗的製作團隊是最棒的，很感謝一直讓我有機會不斷製作，製作流程也越來越清晰了

遊戲功能製作也越來越有信心，像是要做新功能時，我會先想像結構如何製作，然後利用功能插件做不重要的部分(通常是動畫和聲音），核心碰撞和邏輯則是自己寫，讓程式碼變得更好管理,反而不喜歡整個插件包使用。

接下來要面對就是生計問題了，我也不指望能靠做遊戲生活，畢竟遊戲體驗是相當複雜，但要做出更好的遊戲只能不斷製作下去，至於賺錢生活就要在想想了 ，接下來希望有機會遊戲募資，當然有更棒的方法籌措資金會在分享出來。

unity 物理碰撞問題

Q.使用unity物理運動時常出現穿過、反彈問題，而且使用update似乎無法精準控制

A1.unity使用物理時請用 FixedUpdate，這是每一次物理運動都會被所使用的，跟Update是不同的。

A2.使用物理盡量不要用Time.delatime 控制座標，請用 AddForce 來推動物件，還有velocity(速度)控制物件，避免許多抖動問題

A3.Rigidbody 可以更改 Collision Detection ，讓碰撞更快速

A4.碰撞物體速度不要太快，不然會穿透....

結語: unity物理似乎要好好練習，有許多網友也表示，需要精確度的物件不建議使用物理來實現。

Unity PlayMaker 值得使用嗎? [3小時完成小遊戲]

PlayMaker 值得使用嗎?

優點:

為了追求更有效率的開發，我花了三天入門playmaker，然後又愛又恨，簡單來說，在物件移動、縮放上我覺得超好用，基本上小遊戲可以用它快速開發完全沒問題!

1.快速開發
2.可視化程式流程
3.很多三方插件有跟他在做整合

缺點:

1.有點不穩定，UNITY感覺有點變慢

2.功能很多.....但有些還是要自己進程式自己補足

3.因為可視化，連最基本的判斷都用拖拉方式.....不夠熟會覺得拖泥帶水

結論:

我還是會繼續用下去，但是核心部分還是自己寫，不然複雜一些的程式不見得比較好，PLAYMAKER大概會用在角色移動和ui部分上，自己撰寫就寫些資料的處理和邏輯

。

後記補充，用久了就上癮了，把playmaker

拿來做簡單功能就好，太複雜的話那流程圖看了也眼花。我最愛他的呼叫事件，自己寫的元件去傳送事件很好用喔！

遊戲專案時程預估，試玩版 Prototype 的重要性

Q. 我手上在做的RPG遊戲已經延遲很久了，上網爬文找找看到底問題出在哪?

A. 老話一句 [ 開發經驗 ] ，把遊戲功能寫出一個簡單的預估時間，然後把[有做過]與[沒做過]
分開來，沒做過的把預估時間x3，加總起來就是真正的預估時間。

為啥要把沒做過的預估時間x3，因為在製作過程中一定會出現除錯與測試問題，往往處理的時間會較多。

反推，已經做過的部分可以用很少的時間測試，與一開始的預估時間會較接近。

A.良好的分工以及人事調動，把遊戲架構寫好可以分工來協作，但最忌諱人事調動，因為不管再優秀的人員一經過變動，製作上要銜接是非常不容易的
(這點也是看網路分享的，打個比方，自己養的小孩再怎麼換父母也不可能短期間比原來的父母了解他，更別提對小孩的關愛了...)


Q. 試玩版的重要性比你想的還多?

A. 開發遊戲就怕bug、延遲時程、玩家反應不好這三個，試玩版是奠定這三個的重要過程，甚至可以說是遊戲原型( Prototype 觀念 )，下面寫到試玩版製作流程

1.最初的原型( 內部測試用 ):

   可以操作的試玩版、不追求美術

   這版本要奠定遊戲的核心體驗、把玩法先做出來，盡量符合企畫的理想，只給內部人員使用。

2.測試體驗版( 對外蒐集意見用 ):

     這版本要把核心用最少的關卡展示出來，並且美術也是要在這版奠定風格，讓外部人員遊玩，最重要的是蒐集遊玩中數據來做分析(功能使用次數、時間、遊玩心得....等)


3.正式體驗版( 找資金用 ):
   這版本要把上一版的數據改良後的版本，主要用來對外宣傳與找尋資金用，寫到這裡....我要來個總結，我私心覺得.....遊戲走到這邊已經算完成一大步了，大部分功能開發都有雛型出來了，所以不會擔心遊戲正式版製作時程問題，前面提到已經做過的部分可以用很少的時間整合，試玩版的重要性可以減少專案失敗的機率，以上就是我想說的。

Unity C# Interface 新手常遇到整合的小問題

Q.這幾天在製作專案時遇到一個大麻煩，我把去年度撰寫的戰鬥系統，要整合新資料，過程發現問題很多，去年撰寫概念是用表單來抓取資料，最新版都已經class化，但要整合時會發現不好修改，常常到處跑BUG。


A.問題在於撰寫時沒有更好的結構化，程式和程式之間呼叫變得很亂
   
     解決方法，把每個功能獨立出一個 程式，在撰寫時只呼叫功能程式

    關鍵字 Interface 概念

     在這概念下制定規格，像是汽車一定要有方向盤、煞車....等，每段功能程式有共同規格
     
     目前因為我很菜，常常不小心把邏輯寫在主結構中(if...for...等)導致後面修改不易。

Unity class 複製 無法複製

1.發現問題: 在實作unity時常會複製變數以及其他資料，但我發現用自己寫的class有些問題，簡單來說要複製class會變成無法複製。

2.解決問題: 參考C#複製問題網址
  https://msdn.microsoft.com/en-us/library/system.object.memberwiseclone(v=vs.110).aspx

   簡單來說要把複製的指令自行寫入，他有分淺層複製ShallowCopy() 跟深層複製DeepCopy()
  我自己是用淺層複製就OK了

3.哈哈哈，這問題我卡超久....因為像字串那種東西都直接弄就複製啦~沒想到class要在處理處理QQ

Unity 使用c# 委派事件做簡單引擎

為什麼要用委派事件來做引擎?

最近在寫些小遊戲，遊戲流程規劃不外乎固定流程的呼叫與回傳，目前用到委派方法來做簡單的事件系統，好達成後續程式之間傳遞。

如何做?

1.先寫好一個class做服務器端，整個遊戲流程就是由物件去訂閱服務器的委派事件，由服務端發出所有遊戲中的改變給已訂閱物件。

2.撰寫一個父類別，用來訂閱服務器端的委派。(這個類別包含訂閱、回傳訂閱...等)

3.遊戲中所有物件都繼承父類別，並在物件中調用父類別寫好的訂閱/接收委派事件。

4.這樣寫可能還是不清楚，簡單來說服務端委派了多個不同事件(升級事件、得分事件、遊戲結束事件)，遊戲物件根據需要，把不同的事件訂閱進去，這樣只要遊戲發生"升級事件"，有訂閱的物件就會收到反饋，這樣就完成簡單引擎製作了。

這樣有什麼優點?

1.程式間的傳遞規則化，可變性高

2.不用在Update寫一堆程式偵測條件達成沒(我是初學者之前真的這樣做...)

這樣有什麼缺點?

1.製作簡單遊戲時，這樣寫有點長