TopChoco'sLearning

 23.3.31    物理材質球中動與靜摩擦力的區別 以上課教材做數據測試，並且為了測試球體滑行距離我將底下的地板大幅擴展至1000000的寬度 在這個狀態下去測試小球的X軸位移量 並且為了測試方便 我先以Power = 10，靜摩擦力為0，動摩擦力只有0.05 的數據下測得小球位移量為101.83 將位移量102視為最接近無重力阻力狀態(太空狀態)的數據 因此本文進行的任何實驗在小球位移量超過102以後的現象都視為無重力阻力狀態 懶人包： 動摩擦力(Dynamic Friction)決定物體用同樣的力可以在這個表面上移動的距離 靜摩擦力(Static Friction)可以理解在物體遇到靜摩擦力時，會被吃掉一部分的力(Power) 以下是各種實驗與結論 第一項實驗、測試靜摩擦力與Power和Mass的關係： ## 以下實驗中動摩擦力皆為0.2 ## 在實驗中我為了先釐清Mass質與靜摩擦力的關係 先將Power = 10，靜摩擦力 = 10，Mass = 1 結果：位移量為24.036 隨後Power = 10，靜摩擦力 = 10，Mass = 10 結果：位移量為24.036 最後Power = 10，靜摩擦力 = 10，Mass = 0.1 結果：位移量為24.036 沒錯，不管Mass質是多了10倍還是只有1/10，位移量都絲毫不差 因此我得到的第一個結論是： Mass的值與靜摩擦力沒有任何關聯。 排除了Mass以後就可以來測試靜摩擦力與Power的關聯了 以下我將會開始測試Power與靜摩擦力的值個別為多少時，小球的位移量 並且有一個我已經測試出來的大前提，靜摩擦力的值 > Power的五倍時，不管大多少 小球的位移量都會只剩0.0016，這個現象與下面順移的現象應該是相同的原理。 如果靜摩擦力的值等於或略小於Power五倍時，小球不會用滾的，而是變成順移 因此這個現象出現時可以回來注意一下靜摩擦力與Power的值 Ex . Power = 10 ， 靜摩擦力 = 49~50 ， 位移量皆為0.1995 推測可能是因為靜摩擦力的值到達會or不會動的閥值，因此給的力只夠讓小球動一偵就得停 注意 ：： 這個現象意味著今天如果把Power設為100000000之類高到破表的數字，此時就算你的靜摩擦力是他的五倍以上，那他就算動個...

 23.3.26  昨天想搞的音樂遊戲判定出事了，2D的物件在碰撞上出問題 明天用3D的試試看 複習區 float.ToString("F2") 可以將小數或常數之類的換成字串 F2就是指顯示小數點後兩位 button可以直接在onClick區輸入腳本指令 但這種拖拖拉拉工程師的行為要盡量避免 之後btn一多起來要檢查bug很麻煩 所以要觸發btn的話還是盡量用 btn.onClick.AddListener(delegate () { Reset(); }); 的這種功能比較好 實際做了作業才發現碰撞相關的腳本指令超不熟  笑死 穿透系的OnTiggerEnter要用(Collider hit) 碰撞系的OnCollisionEnter要用(Collision hit) 真的有夠常搞錯的 課本上的第四課的停車遊戲做完了 只能說自己買的課本上交的內容 跟線上教的課比起來，真的有點太簡單 做本體的時間大概只花半小時，剩下的時間都是在鑽研有沒有更好或簡單的寫法 課本上有用到的新玩具： this.car = GameObject.Find("car"); 這個可以直接按照自己打的字串去找某個遊戲物件 ("car") 疑似會使用遍歷，所以保險起見還是先繼續用public去拉物件就好 this.text = GameObject.Find("text"); this.text.GetComponent<Text>().text = "string"; .....意義不明的寫法，要用GetComponent去改不如直接 public Text text; text.text = "string"; 有可能是這本書出來的那個年代 text 還沒優化過，才會用GetComponent去叫 也有可能是純粹為了演示GetComponent這個功能才這樣寫就是了......

23.3.25 unity學習紀錄 老師指定絕對不要用的寫法 obj = GameObject.FindGameObjectWithTag("TypeA"); 這個寫法用於直接搜尋Tag 類型為("TypeA")的物件 若有復數，則只會顯示一個 objs = GameObject.FindGameObjectsWithTag("TypeA"); 這個寫法是建立一個List出來，也就是可以顯示"所有"的Type A物件 ///<whyNotUseIt> ///這個寫法在運行時，會搜尋整個場景內的"所有"物件，之後才會將符合類型之物件歸類 ///(這個作法被稱為遍歷) ///因此若製作大型專案時，場景內有幾千幾萬個物件時，每一偵都會搜尋一大堆物件 ///所以這個寫法超級吃效能 ///<whyNotUseIt> 遇到的白痴狀況：腳本寫完以後物件上的參數沒有變更 一開始為了測試方便直接public int atk; 後面要初始化設定public int atk = 10; 寫完以後發現物件內的atk沒變 //要對物件內有變更的腳本reset以後才會更新參數 今天學到了物體碰撞偵測 OnCollisionEnter、Stay、Exit 物體穿透偵測 OnTriggerEnter、Stay、Exit 明天先是試著用穿透寫一個muse dash那種打擊判定系統 預想：除了穿透偵測以外 如果是要對判定好壞做出great、perfect、miss等區別的話 great可能要使用pos座標相減取距離的機制下去判定 以距離差距來進行判定應該是比較方便的寫法 miss的話可能就要做一個miss區出來 物件生成還沒學的關係所以打擊點可能要自己先設好 (預計設計時間2hour)