做次世代的遊戲真是難阿！要畫面好看又要能跑的順，真恨不得自己改主機，把記憶體加大，把CPU和GPU變快。這當然是辦不到的事，只好想破腦筋來試試各種方法來加快減少系統的負擔。
其實不管做什麼樣平台的遊戲，一個畫面最多可以畫多少個東西往往是最難評估與測試的。這要考慮到面數，貼圖數量、還有Pixel Field Rate等等的瓶頸所在。既然是開發次世代遊戲，畫面當然不能太差，因此貼圖、面數等等往往都是高標準，再者為了表現場景的壯闊與美感，場景上的物件數量與複雜度都是很可怕的數據。更何況在加上特效與AI等等，這都是效能的瓶頸所在。
遊戲之所以是遊戲，就是要跑的動，讓玩家能夠順暢的遊玩。畫面再漂亮，Gameplay設計的在怎麼好，FPS不到30甚至只有10，只會讓玩家想折片罷了。當然，要讓遊戲跑的動，絕對不是企劃修改規則或是美術把model做的很Low(當然如果資料有問題也是要修改)就可以跑的動。曾經聽過有人一個畫面2萬面FPS還不到10，而且還是用9600來開發，可見效能不彰程式佔了很大的因素。畢竟寫不好的Code，再怎麼優化資料結果並不能改善許多。
要提申效能沒有不二法門，往往在於經驗與不斷的修改與測試，以程式人員來說：
1. 首先就是要最佳化自己的程式碼，能夠預先計算好的資料，就不要在每個Frame都計算或是在每個迴圈裡都做相同的計算等等。
2. 盡量使用硬體加速的指令集。比如說向量的運算，以Dot來講是X1 * X2 + Y1 * Y2 + Z1 * Z2。看似很簡單的運算，卻需要CPU幾十個指令的價格，如果真的只有處理一次那都無所謂。但是遊戲中對向量的計算是很頻繁的，這樣的計算往往每個Frame要做幾百幾千次，這樣看起來就不便宜了。如果能用硬體加速的指令集，將三次乘法和兩次加法用一個指令來取代，哇！是不是快很多ㄚ。
3. 提供更多的技術支援給其他部門。
4. 不斷的進修，提升自己的專業能力。
以美術來說：
1. 所做的資料要以能放進遊戲中執行為主，實際去看問題所在，並與程式和企劃討論修改方向。
2. 製作的檔案要符合規定，面數，頂點數，貼圖格式，記憶體大小，Bone的數量等等都要依據程式給的規範來製作。
3. 製作模型時要在前製時期就做好彈性，避免修改過多，也不要害怕修改。畢竟玩家不是美術，對於美感的呈現見仁見智，不需要位了堅持而降低了遊戲本質。
其實不管做什麼樣平台的遊戲，一個畫面最多可以畫多少個東西往往是最難評估與測試的。這要考慮到面數，貼圖數量、還有Pixel Field Rate等等的瓶頸所在。既然是開發次世代遊戲，畫面當然不能太差，因此貼圖、面數等等往往都是高標準，再者為了表現場景的壯闊與美感，場景上的物件數量與複雜度都是很可怕的數據。更何況在加上特效與AI等等，這都是效能的瓶頸所在。
遊戲之所以是遊戲，就是要跑的動，讓玩家能夠順暢的遊玩。畫面再漂亮，Gameplay設計的在怎麼好，FPS不到30甚至只有10，只會讓玩家想折片罷了。當然，要讓遊戲跑的動，絕對不是企劃修改規則或是美術把model做的很Low(當然如果資料有問題也是要修改)就可以跑的動。曾經聽過有人一個畫面2萬面FPS還不到10，而且還是用9600來開發，可見效能不彰程式佔了很大的因素。畢竟寫不好的Code，再怎麼優化資料結果並不能改善許多。
要提申效能沒有不二法門，往往在於經驗與不斷的修改與測試，以程式人員來說：
1. 首先就是要最佳化自己的程式碼，能夠預先計算好的資料，就不要在每個Frame都計算或是在每個迴圈裡都做相同的計算等等。
2. 盡量使用硬體加速的指令集。比如說向量的運算，以Dot來講是X1 * X2 + Y1 * Y2 + Z1 * Z2。看似很簡單的運算，卻需要CPU幾十個指令的價格，如果真的只有處理一次那都無所謂。但是遊戲中對向量的計算是很頻繁的，這樣的計算往往每個Frame要做幾百幾千次，這樣看起來就不便宜了。如果能用硬體加速的指令集，將三次乘法和兩次加法用一個指令來取代，哇！是不是快很多ㄚ。
3. 提供更多的技術支援給其他部門。
4. 不斷的進修，提升自己的專業能力。
以美術來說：
1. 所做的資料要以能放進遊戲中執行為主，實際去看問題所在，並與程式和企劃討論修改方向。
2. 製作的檔案要符合規定，面數，頂點數，貼圖格式，記憶體大小，Bone的數量等等都要依據程式給的規範來製作。
3. 製作模型時要在前製時期就做好彈性，避免修改過多，也不要害怕修改。畢竟玩家不是美術，對於美感的呈現見仁見智，不需要位了堅持而降低了遊戲本質。
程式研究 (6)