推 onelife:推那句"在發生之前沒人相信" XD 09/25 18:17
推 LayerZ:每次看到那種BUG 第一件事就是先翻誰改的 阿哈哈哈 UCCU 09/25 19:31
※ 引述《chenglap (無想流流星拳)》之銘言：
: ※ 引述《NDark (溺於黑暗)》之銘言：
: 雖然我想過用推文的, 不如說回文好了.
: 遊戲製作最麻煩的地方是「技術世代交替」, 技術世代交替就是, 因為
: 外在市場的變化, 導致了開發平臺的大變化. 遊戲開發, 往往需要一年
: 半載, 可是資訊世界和其他產業不同的地方是, 一年半載足夠讓風水輪
: 流轉.
: 出現技術世代交替, 你就會遭遇到這些問題:
跳脫問卷
終究的問題在於 遊戲產品 的生存週期太短，
以至於
續作（或下一款遊戲）開發時，引擎可能已經完全不同，
引擎不同可能程式語言也完全不同，
這連帶造成：即便程式人員想要讓他們的程式碼re-use，也是徒勞無功。
因為程式無法re-use，所以每次都是從頭做起，
也就導致每次專案的開發都被時程所追趕，更惡性循環無暇做未來的規劃。
正因為軟體的生命週期是如此的短，
在我看來
那些軟體工程的偉大智慧，如測試，反而帶給遊戲開發一個災難。
測試就像買竊盜險，如果沒有真的發生車子被偷，保險費反而變成開發的負擔。
尤其是我們是把時間這項成本付給死神。
「一個平均的自動化測試要打平它的開發成本，至少要可執行約17次。」
（請參考軟體版"軟體測試自動化"一文）
如果你的產品是一年準備，兩年推銷，然後打算賣個五年十年，
我相信核心模組的測試是正確的方向。
但是對初代產品，沒有人能保證會長賣。
多半被期待是一年就要看到回收。
另外可以再提一點，
資淺程式人員與資深程式人員的最大差異就在於：
資淺程式人員只看得到現在，只看得到現在被交付的工作，
"只"想把工作完成的慾望是如此的強，導致腦袋中沒有空間擺放一個"未來"。
我看過太多程式人員豪氣干雲："這件事很簡單，我兩小時就做完了"
好像不這樣講，在老闆眼中的地位就會矮一截一樣。
但是若事後透過仔細的紀錄工時，都會發現，
"做完之後"的修改與維護多半都是以天（工時再乘以八）為單位
"反正到時候再修就好了嘛。"
資深軟體人員的經驗就像預言家一樣：
"我知道會發生什麼事。但在發生之前，沒人會相信我。"
--
"May the Balance be with U"(願平衡與你同在)
視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.164.65.106