Re: [請益] 如果案子可能不保

[Killercat (殺人貓™)]

※ 引述《riveranb (River)》之銘言：
: 最近有風聲說老闆可能停掉手上做到一半的專案
: 該專案已進行很長一段時間
: 績效的確不能說好
: 但也有做出一些基礎了
: 並且戰友們也努力的讓它越來越穩健
: 突然聽到這種風聲消息
: 自己是蠻沮喪的
: 畢竟自己把它當成自己的作品在看待
: 當然也有感情了
: 這篇純粹只是想問各位大大碰到這種情況時會有何心情或反應
這個...以比較冷血的研發角度來看
被砍其實是個很好的機會，讓你重新檢視一下這個案子有沒有做到可重用
可重用度有多少

美術可能比較難做到，畢竟這些都是專案導向的東西，能回收的可能很有限
不過可能可以加到自己的作品集累積自己的資本
（這個每家公司政策不同 不過私有的作品集通常都ok 美術往後談薪水就是靠這個）
企劃應該是最容易回收的，很多所謂的玩法啊，數值作用的實驗演算啊
這些都可以相當輕易的apply到往後的專案，即使是最專案導向的storyline跟設定
其實都很容易成為下一款作品的基石

重點就是程式了

程式回收是最需要技巧，也最需要設計的。
當你為了這個遊戲寫了一個廣播server 你會讓他綁死一大堆專案物件大量耦合
以至於無法回收以後再利用？還是得花極大心力回收？
還是可以輕鬆的整個回收走等著下次再用？
骨架動畫綁死一大堆專案物件以至於沒辦法再用？
Game Object/Character寫了一大堆嚴重耦合的東西以至於下次都要重寫？

這些就是仰賴於一開始的設計。設計的夠不夠模組化

當你要開始寫一個game server的時候 你會怎麼寫呢？

1) 恩這個game server需要一個loop, 恩我們在loop裡面做所有的game object update
所以我們可以用一個header把所有遊戲相關需要update的都放進來..恩可能還需要管理
連線，所以我們也得把連線機能做進去...啊這game需要特殊封包，我們把它寫到裡面。
阿server需要計算兩個game object的距離，恩演算法也寫進去....

2) 恩這個game server需要一個loop，我們可以寫一個基本的game server把所有的
連線的pooling的方式都做成一個class，然後update用delegate給外面的人做我們就
不用include她，或者讓外面的人繼承這個server來做自己的game server...啊他們可
能需要特殊封包，那我們做個plug in架構讓他們自己implement自己的封包...阿Server
需要計算兩個game object的距離，恩我們做個界面讓他掛上去...

前者可能寫起來只要10小時 後者可能要15小時，但是前者每被砍掉一次就是重來，
後者可能只需要每次重來都花2 3小時繼承寫plugin就可以跑起來

專案被砍掉不是歸零，而是讓你檢視有什麼東西能夠回收的好日子
久了，自然就會朝「盡可能做出可以回收的東西」前進，這才是砍專案真正的價值

---
這樣講應該沒很冷血吧 ＸＤ 好歹我也被terminate掉好幾個專案說



--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 59.124.251.135
推 chenglap:畢竟重點是有薪水發給你. 老闆一定比你痛得多.
→ Killercat:er...這話很難講 老板狀況外的情況可多得很... XD
推 chenglap:你試過賠幾百(千)萬還能夠狀況外嗎...
→ Killercat:唉，以我個人標準我以前呆過的某公司的確很狀況外
→ Killercat:不過狀不狀況外員工觀點不見得準啦...只是...
→ Killercat:也真的是一千多萬快兩千萬的在燒的 也是說停就停
→ Killercat:不過老板怎麼想我管不著 該回收的東西有回收到就好...
→ Killercat:他有錢他愛砍 我可是想讓我下個專案輕鬆點 XD
推 NDark:後者應該比較接近五倍的時間，但是初版彈性可能只有兩倍。
→ NDark:但是程式功力會因此而進步,這才是有價值的地方
→ Killercat:其實manager有push有帶的話不用那麼久 這也是程式頭該有
→ Killercat:的責任，而不是定個目標以後放任下面的人亂寫...
→ Killercat:很多程式頭自己也身兼功能提供者 其實這是不太好的...
→ vamper:IoC
→ blockcat:可以寫成物件包啦，好用的物件常常不同專案都能用到