作者NDark (溺於黑暗)
看板Soft_Job
標題Re: [請益] 想寫遊戲的話該從哪裡下手?
時間Thu Jan 10 00:51:02 2019
※ 引述《neo5277 (I am an agent of chaos)》之銘言：
: 我是從 .NET 起家的
: 之前一直都在寫網站跟服務，前端就是angular 跟 傳統jquery
: 感覺電商上的流程跟環境都小小的跑了一圈。
: 自己對於打造出一個可用的產品越來越有想要嘗試的感覺。
: 多方研究下覺得遊戲這塊可以說是一個完全體。
: 不管是單機，還是網路營運，在技術上可以說是整合了目前所有我能想像的到的
: 軟體技能，以及非軟體能力，也因為是從.NET 大概會先從 UNITY開始吧。
先分清楚 你是哪一種
1.喜歡玩遊戲
2.喜歡做遊戲相關技術
3.喜歡開發遊戲
4.希望有一個遊戲產業的工作抬頭
5.希望能有一個知名遊戲的工作抬頭
6.希望能在遊戲產業討飯吃
7.希望能在遊戲產業站著還能把錢掙了
從問的其他問題看來我覺得 偏向2.
那麼這些問題多半都是電腦圖學這門課可以回答.
所以其實去大學旁聽就是正解.
以下是碎碎念
最近的體悟是 遊戲軟體是一個一不小心就很容易做出反智系統(Anti-Pattern)的專案.
以往所認定優秀的軟體系統都是在需求穩定的情況下開發.
所以可測試性/可延展性/穩定性等等才隨之而來.
在遊戲軟體傳統開發的做法是:
做一個系統,讓數值人員填表來擴展.(一行數值代表多一種怪物/多一種武器/多一種道具)
在這個系統開發之始,軟體人員必定會問清楚,這個系統的極限(功能)在哪裡?
砲彈是直射,雷射,拋物線,是撞擊即傷害,還是爆炸後才傷害.
"可是" 系統完成後之後數值人員填表就"不會"超出這些類型範圍
也就是說這個系統無法填表填出"讓玩家覺得驚訝"的跳脫設計.
也就是說當系統完成或上線後的一個月後,
設計人員說要加"遙控飛機(Drone)"型的武器.
因為原先並沒有開這個規格,所以就無法經由填表產生這樣的功能.
軟體人員抱怨歸抱怨.
給出的答案就是下一版版更 把這個類型的武器
再"實作"(從某種程度看來就是 hard-coded) 到 遊戲裡面.
這件事情(超出原先設計規模)重複幾次之後,code就會爛到不行.
因為原先在設計系統的時候沒有想到要做成這樣.
(同時也因為營運端需求來的通常是ASAP,最好不要更新就能做到.
玩家在論壇上的建議也真的都是最好我點餐完一個禮拜之內就有.
可是瑞凡,蘋果審版本最短也都要兩到三天)
每次當從這個時間點回頭看每次開始做系統時候的規劃,就會覺得當時年少太過天真.
所有的遊戲引擎製作團隊都會講到一個反智的經驗談:
引擎/函式庫 是結果不是原因.
多半都是在專案中先做出這個功能,
然後歷經多個專案之後才把這個功能拆出來標準化,成為引擎工具.
衍生出來的一個悖論是:
有了引擎的幫忙,或是當引擎提供了某項功能,
代表成千上萬的遊戲可以快速實裝這個功能,代表軍備競賽的標準又往上推了一層.
有了引擎事情不會變少,時程反而會因此變多,
因為工具加大了效率,要求或標準反而會再提高.導致目標更加遠大.
共勉之
--
"May the Balance be with U"(願平衡與你同在)
遊戲設計教學，討論，分享。歡迎來信。
黑水溝歷史文庫
https://ndark.wordpress.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 176.205.16.49
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1547052669.A.916.html
1F：推 cheryl89531: 這不限於遊戲軟體吧，聽起來制度差的公司都會發生 01/10 01:12
不是有沒有制度.
而是這個到底賺錢重要還是程式碼品質重要?
如果前者永遠都壓倒後者.那麼程式碼會越來越歪幾乎是100%會發生的事情.
很遺憾的 遊戲產業是一種流行. 所以能趕快撈錢的就要趕快實作.
未上線產品 開發週期最好能壓在一年之內就有一個產品.
上線產品 的開發週期就是一個月內二十天要連設計開發測試都做完.
2F：推 vn509942: 軍備競賽 01/10 01:16
3F：→ NDark: 玩家會因為驚喜這種情緒而付錢 而不會為了穩定而付錢． 01/10 03:08
4F：→ NDark: 而商用軟體通常要穩定 不會求驚喜 01/10 03:09
5F：推 bakedgrass: 蠻不錯的分享 01/10 03:39
6F：→ superpai: 這個問題讓數值人員寫code就解決啦 01/10 04:08
7F：→ neo5277: 這個用oop應該可以解決吧? 01/10 05:47
8F：推 neo5277: 抽象成武器，然後繼續分下去就開枝散葉了 01/10 05:49
9F：→ neo5277: 感謝回覆，想做也喜歡玩 01/10 05:49
繼承反倒容易產生 "一開始沒想到" 的問題
(因為子類別需要的功能,父類別設計的時候並不一定都能想到)
不過繼承出現的問題在 2007 年前後陸陸續續被解決.
現在遊戲界都推Component-Base. 比較少人推薦用繼承寫功能了.
[翻譯] Evolve Your Hierarchy
https://wp.me/pBAPd-fj
10F：推 ShadowInWind: 推軍備競賽 01/10 09:04
11F：→ stkoso: 現在玩家的胃口不是多幾把武器就能滿足的 01/10 09:48
12F：→ stkoso: 這種軍備競賽要求的是質變而不是量變 01/10 09:51
13F：→ stkoso: 跟OOP的概念正好背道而馳 01/10 09:51
14F：推 WorkForFree: 推推推 01/10 09:53
15F：→ pttworld: 把引擎的地位想像做web的開源框架就是了 01/10 10:41
16F：推 bakedgrass: 比方說劍三當年增加的輕功就得改寫底層 01/10 12:48
17F：推 TAKADO: 所以現在很多3A大廠也開始用Tick-Tock策略，一個工作室專 01/10 14:28
18F：→ TAKADO: 門塞新技術/改引擎，另一個工作室次年沿用，然後改內容跟 01/10 14:28
19F：→ TAKADO: 精煉玩法出新作。例如刺客教條跟極限競速就滿明顯的。 01/10 14:28
20F：推 askaleroux: 心有戚戚焉 做完一個系統企劃才被雷打到 01/10 14:29
21F：→ NDark: @stkoso 深得我心 01/10 18:35
22F：→ NDark: @superpai 我們連tester 都改code 就知道這 code會變怎樣。 01/10 18:37
修改一些寫不好的地方.
※ 編輯: NDark (176.205.16.49), 01/10/2019 23:25:21
※ 編輯: NDark (176.205.16.49), 01/10/2019 23:26:08
23F：推 neo5277: 所以再加上interface這樣 01/11 01:52
24F：推 SmallpTsai: 這篇值得 M 起來 01/11 14:47
25F：推 jasonwung: 推推 01/11 21:51
26F：推 TurnV: 推推 這篇內文精彩，推文更棒 01/19 12:16
27F：推 mistystream: 完全反應了真實的遊戲開發經驗 01/28 14:34