遊戲開發所需要的知識（1.6萬字）
從放棄求職回傢已經一個半月瞭，一直都在備考事業編。發現這玩意比遊戲開發簡單太多瞭，沒有人刁難，沒有人催促，幾個月舉辦一次，一天隻需要學習3-4個小時，其餘時間都是自由安排，太舒服瞭。考上編後也很不錯，早上8.30-11.30 下午2.30到5.30，一天6個小時，一周5天，一個月就能稅前5000瞭。比在外面被壓到3000一個月的崗位好瞭不是一點半點。
PS：太感謝國傢的六保六穩瞭，從來沒有遇到過考事業編能夠這麼少人，這麼多機會的。
有瞭時間後，開始努力考慮未來的人生（事業編基本上算是一眼望到頭的職位，除瞭評職稱，沒有別的提高工資的方法瞭）還好的是，事業編比公務員開朗點，允許自由創業或者接外包。所以經過思考後，我決定就算沒有好結果，甚至隻是徒勞，也要往獨立遊戲的方向搞一搞,不然一輩子就這樣渾渾噩噩的就過去瞭。（現在已經過去四分之一）
目前程序基本上不算大問題，就是需要多接觸別人的項目和從別人的視頻中瞭解技術。美術確定好2D像素畫，也在努力畫自己喜歡的東西（目前原畫還在不斷學習中，並不是最終原畫~）
頭發以自己的發型為原型，太難畫出來瞭
並且畫2D的一大好處，就是想怎麼畫就怎麼畫，不需要想的太復雜，可以參考《哆啦A夢》，隻負責復現竹蜻蜓樣子和實現功能即可，不需要關註具體的物體細節，這點比3D簡單很多。（主要是解放瞭想象，可以自由的發揮主觀性，3D要關註武器的細節處理，感覺很難）
然後策劃部分，這個算是一大難點，方案出來不難，想達到好玩，甚至能帶來快樂就需要一定的經驗。畢竟從沒進入過公司工作，手上有沒有別人的遊戲數據，隻能慢慢摸索遊戲的框架和設計，錯瞭也可以重新開始制作。（畢竟現在什麼都沒有，就是有時間）
介於以前做過的文章不夠嚴謹，這次打算補充知識點。
進入主題，先看個短視頻：
回傢總結後，發現遊戲開發不是一朝一夕的事情，真的需要相當多的知識點才能做出好的作品，難怪外面的世界充滿瞭挑（nei）戰（juan）。
1.硬件知識
曾經的我還建議過買什麼硬件，現在的我覺得硬件也就是個擺設，因為買的好不如用的好。隻要用的好，什麼硬件都能跑。！任何CPU搭配任何GPU都可以開發遊戲！，隻不過硬件好點機器運行起來就快點，但是並不能真正提高開發效率，效率永遠取決於自己的科學規劃！
開發遊戲過程中，真正制約運行速率的是CPU不是GPU，因為大部分遊戲都以單線程開發為主，所以一般調試運行的時候基本也是考驗單線程能力。購買CPU核心可以買多核的，但是單核頻率一定要高，否則運行很慢（我現在極度嫌棄R5 2600瞭，每次調試都得3秒鐘~），MAC除外。
GPU的目的是加速圖形計算，也就是3D開發中可以加快渲染速率，越強的GPU渲染越快，但是~~隻開發3D才有的好處，我做2D遊戲的，基本上所有的核顯都能運行，（除非沒有核顯，不然現在的核顯應該不差於90年代的小霸王瞭吧~）。曾經的我以為開發遊戲需要的是一個很好的顯卡來應對未來的光追，實際上開發者的本質是程序本身，如果過度的關註那些畫面美術的話就會導致自我定位的錯誤。開發者就應該註重程序開發，而不能盲目的追求美術效果。遊戲開發中美術是服務於遊戲本身的，不是服務其他東西的。盲目的跟別人競爭美術會本末倒置的。所以開發遊戲盡量避免糾結買什麼顯卡，開發什麼著色器，做到什麼美術效果。如果真用到那個技術，到時候應該也不會作為一個普通的開發者瞭，肯定有一定的項目或者團隊或者到公司就職，錢都不會是問題。
固態的話就不多說瞭，現階段應該不會有人還用舊的機械開發瞭吧？
註意！
我猜很多人都看瞭老黃的RTX30系列發佈會瞭，然後有人問我，需不需要為瞭未來的遊戲準備買RTX系列的顯卡來學習開發。這裡需要回答幾個問題。
未來光追會不會用的越來越多？會，因為NVIDIA是行業巨頭，老黃做什麼下遊就得跟著做什麼。所以光追也是要學習的內容（內卷的資格）。
未來RTX會不會越來越多，GTX越來越少？肯定的，因為PC巨頭基本上就老黃壟斷瞭，AMD發力還是不太OK，老黃帶大傢進入瞭RTX時代，大概率未來顯卡都會是RTX。
那麼需不需要為瞭未來而現在買RTX做開發？
沒必要！沒必要！!沒必要！！!
首先我得好好的回答這個問題。現階段大傢產生瞭一個錯誤的概念就是要買RTX才能有光追，AMD的沒有光追單元，因此PS5上的是個假的光追。實際上~
現在所有的顯卡，都無法實現光追本身！！！！！！！！！！！！！！！
光追本身是個物理現象，光帶有波粒二象性，偏振周期，能量等一系列物理性質，想要在計算機上實現光追，隻需要把光的物理性質輸入物理引擎，並弄好場景和發射點，哪怕是核顯也能實現光追現象，光追不依賴於某一硬件產生，光追是物理現象~
為什麼老黃的顯卡和遊戲都那麼真實的光線，原因就在於PBR（Physicallly-Based Rendering）材質，基於物理的渲染。也就是說RTX實現的隻是渲染結果，而光追本身的物理現象根本沒實現，也沒法實現（因為算力太大瞭）。所以顯卡中的光追，都是基於PBR材質做的渲染，依賴於DX12提供API。
各位如果不相信的話，可以看看INTEL，PS5，cryengine，UE5，都放出來過相關的光追視頻，但是從沒有依賴於RTX本身。並且知乎上也有挺多大佬，也沒有依賴於某一硬件就實現瞭光追的項目。
關於電腦的維護，一年下來因為電腦崩潰的情況大概率隻有10次左右，但是大部分都是硬件問題，具體出在瞭哪裡呢？
- 機箱散熱不行。散熱可以說是電腦負載過度崩潰的最罪魁禍首，很多人不註重電腦內部的風道設計，導致熱量無法順利排出而讓核心溫度過高。（筆記本同樣也要註重散熱），一旦高熱降頻下來就直接導致系統卡頓，這在我跑3D項目上出現過無數次瞭。（因為經常一打開就是幾十個程序和網頁，一旦降頻就崩潰瞭）
- 內存胡亂的超頻。現階段，如果說最多出現的硬件問題，大概率就是超頻瞭。在0202年的今天，如果還有人說自己的電腦無法超頻，那就趕不上時代瞭。AMD的普及讓所有硬件都可以超頻，但問題就是很多人超頻隻跟著貼吧和廠傢建議，而主板往往不同的型號，性能都不一樣（主要體現在供電模塊）盲目的超到瞭3200很容易崩潰，但是兼顧瞭打遊戲的需求，很多人又不得不妥協。開發遊戲一般建議2400就足夠，實在覺得打遊戲不行就換C15內存吧
- 功耗的判斷失誤。一般來說，很多人選購電源不會有太大的問題，普遍超出硬件的200 -300W左右，但是主要就在工作環境的功耗判斷。經常性的斷電對開發工作是個致命打擊，在2020年的今天斷電已經是個低概率事件瞭，往往發生都是因為功率不夠，極大概率是競爭用電（比如電腦+空調都用一個排插，比如宿舍裡一個人煮水，基本上就會停電）
以上三種是一年來遇到過最多的問題，經常性的突發導致開發中斷，丟失瞭好多個版本。所以一定要學會用git進行版本控制，保存好自己的備份。
2.軟件知識
曾經的我，太年輕，深入的學習之後才發現，基本上把計算機所學的全部知識都復習瞭一遍~
先開始逐一探討。
1.語言和引擎
這個大傢都知道TS+COCOS，C#+unity,CPP+UE,但是這隻是基本中的基本。
但是說隻懂兩樣東西的話，也就是個小孩子的玩具罷瞭，自己玩無所謂，出去找工作會被各種鞭策，各種吊打。大人的社會，太不容易瞭~
學習語言需要根據專門的引擎決定，但是萬變不離其宗的一門就是C++，基本上無論走哪個技術，用哪個引擎，最終都會回到C++的問題上來。做遊戲久瞭，才明白優化的重要性，要優化好遊戲，就得回到C++的內存管理上。
我本來還以為C#可以包攬萬物，但是當我真正接觸GC時，單純在C#上可以說無從下手，因為C#本身是個完全面向對象語言，很多東西都封裝實現瞭，讓我根本上忽視瞭兩樣重要且致命的東西，構造函數和析構函數，我當時為瞭優化碰撞器，但是一直懷疑著一樣東西。
刀刃腳本，觸發器進入生成一個對象，來判斷碰撞體身上是否含有IDmage接口
那就是腳本運行結束後，這個生成的idamage是否有釋放掉，但是圍繞瞭C#的書，我看瞭又看，基本沒講過這個，測試瞭好幾遍也發現對象也正確回收瞭。但是我遲遲得不到答案，一直陷入無限的糾結中。然後~
看過這本書後，我才發現（應該說想不起來知識點瞭），原來一個函數裡面有構造器和析構器，C#/JAVA從來沒跟我說過析構器的存在（書本知識點也就簡短的一小章節，老師基本不講~），導致我一直陷入沉思，看瞭C++才明白，哦，原來結束瞭還需要手動釋放內存的~~
C#居然沒跟我講過~
所以，很多時候用一些高級語言，而不去紮實C/C++的基礎，真的很容易在某些地方陷入糾結的。雖然APP在現在硬件發達的手機上運行沒壓力，但是遊戲可不一樣，因為每一滴性能消耗都有可能有一個玩傢流失。
然後就是熱更語言（更新用的），大部分都是選擇LUA作為熱更，因為成熟的方案多。熱更新成為瞭現在的潮流，很多開發商都為瞭避免遊戲下線到app商店更新而影響遊戲體驗。遊玩遊戲時後臺自動下載更新包的做法非常符合現在的玩傢需求，雖然大版本還是要自己手動更新，但是小版本或者一些腳本的修改就不需要那麼麻煩瞭，也可以提高玩傢遊玩時間。而且越來越多廠商用熱更作為腳本語言，（因為部分遊戲都是換皮的框架，實際上隻需要做簡單的修改就可以讓遊戲運行，所以用LUA方便不少，百試不爽~），既能繞過IOS，又能方便用戶，更能節省開發商的麻煩，何樂而不為呢。
LUA也分為很多種類，我目前圍繞的是XLUA，其實LUA都差不多的，按不同項目確定。
關於引擎的選擇
這個問題其實不用太糾結，清晰自己的定位，身為開發者就是程序為主，無論用哪個都不能被引擎和語言所限制，要明白引擎隻是個工具，哪個工具好用就用哪個。
Unity對於我來說開發2D好很多，並且有相當多的項目和視頻可以參考。但是Unity缺點也很明顯，就是自己得為自己做一大堆工具：比如我自己做的控制時間工具，控制出生工具，都是挺累人的，一有新的需求舊的工具要麼修改，要麼重寫。想過用別人的插件但是別人的又不一定合適自己（壓根就看不懂別人的代碼）。簡單來說，經常造輪子~
UE大部分用來開發3D遊戲的（貌似用UE做2D遊戲的沒見過吧~王者是2.5D），渲染是UE的強項，見過很多人單單用UE的藍圖就做出各種吊炸天的CG或者遊戲。其實我也考慮過用UE做遊戲，問題在於做個項目出去投簡歷找工作不難，但是做個獨立遊戲就得自己兼顧3D建模和美術，不太現實。能瞭解程序，策劃，又得把美術精通，這樣的人有沒有呢？肯定有，但是問題在於很少，大部分都是外包，外包的美術各位都有目共睹，新出的網遊一堆一堆的
（看著這樣的3D，說實話，我已經看出我自己做3D遊戲最終的結果會怎麼樣瞭~~）
況且為瞭獨立開發而用UE4，未免顯得技術太重瞭~雖然U++也封裝的跟C#差不多瞭，但是畢竟U++也是C++過來的，調試起來肯定沒有C#方便，並且C++最大的問題在於，遊戲開發到後期，甚至都沒察覺程序有問題的，直到出現崩潰。這太考驗程序員的能力瞭。
3D是個很龐大的遊戲項目，個人開發更需要非常大的功夫，廠商也都是有著一條生產線的，每個人基本上都是一顆螺絲釘，各司其職。所以不是真的很有技術和錢，我不太建議個人搞3D項目，拿去面試的沒問題，但是獨立開發個人搞3D真的太難瞭。（隻針對入行開發的人）
cocos目前來說國內不少崗位還在招聘，但是很少有人建議用Cocos瞭，因為天花板很明顯。
CryEngine這個挺好玩的，不過感覺國內應該不會有人用這個引擎吧~
總結，引擎的選擇就以自己的項目（需求）出發，哪個簡單順手就用哪個。
2.數據結構與算法、設計模式、開發模式
這個內容是個非常重要的內容，無論是獨立開發還是面試工作，這三樣是肯定得學會的。很多人對這三樣東西滿不在乎，或者避而遠之，實際上這三個內容不難，覺得困難主要是講解的太難，結合遊戲案例講解的太少。逐個結合講解
數據結構：數據結構無非是數組，鏈表，棧，隊列，字典（也可以說散列表，作用差不多的），樹，那麼每一個結構會在哪裡使用呢？
數組：在遊戲開發中用的較多，特點就是訪問快，擴容簡單，缺點插入難，刪除難。經常用的就是批量生成變量，比如背包：
一開始為背包生成三個格子，但是實際上隻有一樣物品生成一個，但是顯得有點單調直接調成16個，讓UI界面沒那麼單調瞭
基於上面可以發現，數組批量生成的都是功能相同的對象，至於內部的是刀還是劍亦或者其他裝備不需要管（解耦瞭裝備和背包，後面會講解耦)，UI隻需要提供足夠數量的格子和觸發使用的功能即可。
鏈表：鏈表的特點就是更新插入刪除節點容易，但是訪問必須得一個一個節點來尋找（因為隻有知道一個節點，才能知道它的下個節點）而數組可以通過下標直達相應的元素，所以鏈表可以看作是數組的對立面的。遊戲中鏈表用的也很多，但是很少以鏈表本身呈現（後面講）。
棧和隊列：如果說數組和鏈表是個真實寫出來的物理結構，那麼棧和隊列就是想象出來的邏輯結構，棧和隊列一樣，既可以通過數組實現，也可以通過鏈表實現。
棧的特點就是先入後出，後進入的數據先出，概念網上很多，說太多很多人不理解，那就結合遊戲講解。（以下例子其實可以用字典實現，但是為瞭方便講解，把我自己遊戲中的一個思路展開談論）
我們經常見過很多遊戲關卡設計有 拿到一定的條件——打開對應的門或通道 這樣的流程，但是在遊戲高手面前，很多人有著種種不一樣的通關模式，（畢竟沒人規定過通關必須得拿到鑰匙對吧，隻要遊戲佈局有漏洞，就有人通過不一樣的方式通關）
922bf09e302efb4d8be21ef382cb8141比如某湖南長沙人經常利用作圖者忽視終點高度比如空洞騎士的速通利用瞭武器的後坐力
這樣的通關其實並沒有錯，畢竟是關卡制作者沒想到的，但是身為開發者就需要盡量避免這樣的情況，幸幸苦苦做出來的流程，別人30分鐘就通關瞭，然後退款~這就的得不償失瞭。那麼怎麼做到讓玩傢必須通過達到條件並且條件一定要一一對應才能開啟下一關呢？這裡面方法有很多，我個人在自己遊戲中探索到用棧來實現。
靈感來自Leetcode上的一道典型題目：有效的括號
這個實現方法很多，但是最簡單的方法就是棧，無論你前面有多少個左括號，我隻看你最後的左括號開始能否從後到前一一對應右括號就可以判斷是否達到條件。這個方法在遊戲中也有缺點，不能用在鑰匙通道上（邏輯可以自行思考一下）。這個設計我是打算用在怪物身上，強迫玩傢按照固定順序殺怪，否則無法通關，要麼重來要麼放棄。主要是挑戰下極限（折磨玩傢），防止如今大眾過度追求拋瓦（power）的現象。還想一招秒天秒地，趕緊給我學習微操~（果然遊戲開發想怎麼做就怎麼做，不要你覺得，我要我覺得，打不過不是我的錯~）
是你的原因~
隊列：隊列的結構是先進先出，最先進入隊列的數據會因為後續數據越來越多進入隊列而導致數據超出隊列的容量，繼而從隊列出去。還是繼續用例子解決。
格鬥遊戲，拳皇大傢都玩過，拳皇有個著名的東西那就是出招表，我猜經歷過搓招的人應該記憶幽深。
一開始我設計自己遊戲的出招表隻想到瞭最簡單的方式，那就是逐一判斷，間接的導致瞭幾個問題：
- 多重if判斷語句寫法非常繁重
- if判斷速度太快，很有可能鍵盤輸入都跟不上而得開啟協程（協程過多不是好事）
- 限制瞭出招數
最主要的就是太過繁重瞭，頻繁的if else判斷，看著都頭疼。那麼就得引入臨時結構——隊列來幫忙。
還有必須用到隊列的原因，那就是因為玩傢本身。
鬼泣大傢應該都聽過，ACT的動作巔峰，鬼泣的連招也是出瞭名的多，但是有個問題出現瞭
3cd29638f7a42888455ac1131b5af4c6
實際上大部分玩傢玩遊戲是
相對應的，也有很多其他遊戲的玩傢甚至從頭到尾都沒按過攻擊鍵，全程就↑↓←→↓←↓←↑↓←→→↓←↓←→↓←↓←↓←↓←→↓←↓……然後遊戲就通關瞭~~
所以ifelse判斷在我瞭解過現實情況之後才明白，不能用這麼愚蠢的方法，必須用智能點的。
怎麼在出招表上用隊列呢？眾所周知，拳皇的出招一般最長的就是→↘↓↙←五鍵加上一個觸發鍵位A或者B，那麼隊列隻需要記住最後玩傢輸入的五個鍵位+觸發攻擊鍵位就可以瞭，畢竟前面說過瞭玩傢是真的很多人都會亂按一通（當年拳皇有多少不知道技能表的人都是胡亂按出來技能的~不知道各位有沒有）。隊列的特點就很好的在這裡體現，先進先出，先前進來的操作就會被後進來的擠出去，隊列裡面隻保留相對匹配的技能觸發鍵。然後~
如何匹配對應的技能呢？？？？
這裡就會說到另一個數據結構，字典（亦或者說散列表）！
現實中字典的作用就是為瞭查找，根據現有信息，快速查找自己需要的字。顧名思義，那麼數據結構裡的字典也是一樣的，根據你傳入的key（→↘↓↙←+A），來找你要的value（相應的招式）並傳入狀態機觸發對應的招式（我記得這招好像是拳皇大部分角色的大招瞭吧）。如果能夠在字典裡找到那麼就直接觸發，否則把隊列刷新。所以字典也是個在遊戲開發中，非常常見的數據結構，隊列負責存儲玩傢最後的輸入指令，字典匹配對應是否觸發出招，兩者的搭配可以做成出招表。
最後一個數據結構，樹，請看圖
是不是跟現實中樹很像
樹是個一環接著一環的邏輯結構，以鏈表作為物理結構（還記得前面說過的鏈表嗎？就是大部分用在樹身上），看著這個圖是不是很迷茫，實際上換另一個圖大傢就很熟悉瞭。
4ba6e8f4197278542282fdf3fb8b598b敵人的AI邏輯圖
樹在遊戲裡可以用來制作敵人的AI的，現在遊戲的敵人已經很聰明瞭，都是多虧瞭樹的存在。想要敵人越聰明，就給敵人添加更多的條件，讓敵人面對各種情況做出種種判斷，樹的數據結構解放瞭策劃的思想，想加什麼就加什麼，想讓敵人怎麼做就怎麼做。
至此，數據結構就簡單講解完畢瞭，其實有簡單的也有困難的，但是我想說明的是數據結構本身並不難，隻是大傢被那些書本搞得太過於復雜。
算法：算法本身就像我們曾經的數學一樣，1+2+3+4+……+99+100等於多少，如果逐個逐個加的話得計算99次，如果我用前面第一個數加後面最後一個數這樣的做法，這樣就會49個101+50瞭吧，是不是節省瞭一半的計算量。然後我再用等差數列公式（n×（n-1）/2）計算的話就可以得出最終的結果，整個過程計算瞭多少次？1次。所以說算法就是一個邏輯數學題，好的邏輯可以讓計算機用最短的時間得到最終的結果。算法的目的就是為瞭優化計算過程而存在的，當然算法可以離開計算機而廣泛存在於物理界。
想要深入的學習算法的話，建議就是在leetcode上把簡單的算法題一天刷一題，一個月後就小有成就瞭。（面試才刷中等難度）
設計模式
設計模式是一個衡量開發人員水平的考卷，能力好不好就體現在設計模式上瞭。設計模式的概念看著一大堆一大堆的，實際上結合遊戲內容就可以簡單的理解瞭。下面說說我用過的設計模式，不分先後順序，設計模式隻為瞭解決實際問題而存在的。
命令模式：大傢玩遊戲時應該見過跨平臺遊戲吧，那種發佈在PC/XBOX/PS/NS上的遊戲，不同平臺的主機對應的IO設備都不相同。（PC大部分用鍵鼠，其他的三傢都是用手柄，並且PS與XBOX有鍵位上的差異）但是遊戲本身的功能鍵位是相同的啊，比如奔跑，跳躍。難道要開發者為瞭4個平臺一一制作對應的鍵位嗎？這種脫褲子放屁的行為顯然增加瞭開發者的麻煩（反正都是放屁，為啥還要脫褲子呢？），所以就引入瞭一個概念，操作指令與輸入設備解耦，遊戲隻需要提供瞭操作指令，至於傳入的硬件操作是鍵盤還是手柄，那就不是開發者定瞭，而是由使用的戶來決定瞭。當然開發者還是得專門為平臺設備做適配，（震動反饋很重要，做不好會讓對應平臺的玩傢體驗極差），但是指令的本身就不需要綁定設備瞭。
命令模式還有一個很重要的功能就是序列化操作，比如現在的競技遊戲都有著回放功能，回放功能實際上就是從服務器下載擊殺者死前所有玩傢的操作指令，而不是下載別人電腦的顯示畫面（要是LOL需要同時下載另外9個玩傢的畫面那得炸掉多少服務器啊）。下載好9個指令，然後讓本地計算機根據指令模擬死前發生的事情就可以瞭。
觀察者模式：以前從來沒鳥過觀察者模式，單看名字覺得就是個多餘的。然後真正理解過概念後才明白，觀察者模式是非常重要的。當數據變化時，及時通知需要數據的對象。常見的例子，就是遊戲中成就系統，一旦達到某一成就，就會及時彈出來。這裡面呢觀察者並不是一直常駐內存中時刻檢索信息的，而是像任務系統一樣。比如有個存儲殺敵數1000的任務，哪怕存儲殺敵數到瞭999，觀察者還是無動於衷，當到達1000時立刻就把成就發出來，基本上算是個蹲點做事的。這裡面觀察者就是計算機，被觀察者就是殺敵數。所以觀察者的響應速度是最快最及時的，因為全程就這麼一個任務，而且成就任務又不是常有的，一局遊戲下來最多也就3-4個成就，但是就是得有個這樣跑腿的傢夥給玩傢提供成就信息。（玩過PS都知道，玩著玩著突然就彈出一個成就，有時候成就內容本身都沒人在意是否有過這樣的操作~）
單例模式：遊戲中有著各種各樣的系統，比如音樂，物理，任務，對話等。這些系統各司其職，互不影響。單例的描述是一個類隻有一個實例，目的是避免過度的讓程序糅雜在一塊，但是單例在許多遊戲中經常被濫用，經常被濫用的就是結合瞭靜態類常駐內存中，讓內存一大部分處於運行狀態，（電腦8個G，除去系統，開個遊戲占瞭7個多G）。單例在遊戲中最常用的就是音樂瞭，遊戲有的一關到底，有的地圖無縫銜接，更多的還是不同的加載場景。經常性加載場景，並不需要把所有東西都重新加載，比如音樂，最多就是播放的BGM不同，大部分打擊怪物的音效都是相同的，每次都重新加載就會相當耗費實際，那麼就需要寫個靜態單例讓音樂系統常駐內存就足夠，反正全程遊戲下來音樂都是要播放的。靜態單例的好處就是把簡單的，常用的功能常駐於內存，讓系統調用方便，但是如果把所有的獨立系統都做成單例，那麼就會讓內存瞬間被占滿。所以單例一定要慎用，盡量把單例留給那些簡單的功能而不是留給全部的獨立系統。
狀態模式:這個內容我以前的文章有講過，就不再贅述。想看的可以去看
狀態機其實做給主角的攻擊動畫或許比較好，但是做給敵人AI在2020年的今天就沒那個必要瞭。當然狀態機結合樹一起使用可能更加棒，畢竟數據結構不是死的，用的好可以讓計算占用更小。
對象池模式：我們遊玩過許多FPS遊戲，都可以發現，遊戲中用的最多的就是彈藥和特效瞭。如果說每一次都新生成彈藥，那麼當交火非常激烈的時候就會導致電腦突然卡住。原因在於現在的開發語言都是高度封裝的，如果沒有準確的釋放內存的話，不斷新生成的子彈就有可能沒法正確的銷毀從而導致一直在內存中，並形成碎片。這樣的話不管加多少內存都不夠解決這個問題的。因此就引用瞭對象池瞭，大部分人玩CS時有沒有想過第一個彈夾打的30發子彈其實就是後面3個彈夾打的子彈呢？（或許CS有別的處理，我還沒瞭解過）對象池就做到瞭，反正打來打去開的槍也就是一個彈夾，為啥不把同樣的30發收回留給後面的彈夾使用呢，大傢覺得如何？
設計模式其實還有很多，暫時我就把上面的說的全部用過瞭，好不好不知道，但是解決瞭我遇到的問題。
開發模式
開發模式讀於標準的碼農，一般不需要這個，這都是產品經理管轄的內容。開發程序是有目的的，有需求的，有需求就得科學的規劃。身為獨立開發者，如果連軟件開發的開發模式都不瞭解一下，就會在開發中遇到各種軟件問題。
總結一下開發模型的幾種：瀑佈模型，迭代模型，敏捷開發，增量模型，模型定義很多，但是遇到過的就四種。
我的專業雖然有軟件設計師的內容，但是還是缺乏大廠經驗，無法深入的理解開發模式，然後就在開發項目中遇到過非常多的棘手問題。
問題1：開始的時候以為自己是迭代模型，實際上是瀑佈模型。
瀑佈模型存在瞭幾十年時間，經得起時間的考驗，哪怕現在沒人用瞭，但是瀑佈模型的思想依然符合大部分的開發者。大部分人開發遊戲都是立項——確定方案——設計框架——編寫框架——反復測試——產品發佈，這一流水線。但是問題就是獨立開發者如果也采用這個方案會有著致命的缺點：因為經驗的不足會導致產品以為會按照自己的方向發展，其實大部分產品的方向都是會偏離方案的。瀑佈模型的致命缺點就是一旦到瞭後續發現問題瞭，那麼想回去重新修改內容將會非常困難，因為反復測試階段不能立刻條回到方案階段，必須得從框架推導回去，否則一大段遊戲代碼將作廢。（我第一個立項做FPS遊戲就是這樣，因為知識還沒開始鞏固就做瞭FPS，導致後期整個項目耦合太過嚴重）
問題2：忽視瞭敏捷開發帶來的好處
一開始總覺得，做遊戲就得詳細的規劃，不應該隨便，但是後面發現，如果在原遊戲上嘗試新的功能，極有可能導致遊戲崩潰或者出意外，而且這個崩潰大概率會導致一連串的反應比如全部腳本變量崩潰（所以可以的話盡量不要依賴別人的插件）。這時我就在想如果單獨剝離出來遊戲裡的一塊內容，放在一個測試環境中那得多好。然後就探索出來瞭兩條路，一條是用GitHub進行版本控制，可以怎麼折騰都行。另一個就是敏捷開發瞭，敏捷開發的概念也很多並不具體，不過顧名思義也就是輕便開發，為瞭達到某一目的用最短的時間進行開發。我就經常為瞭實現各種工具而做這樣的開發，實際上很多小項目隻要完善起來又可以做新遊戲瞭。（曾經想要單獨實現AI，就用瞭第一個2D遊戲做，結果遊戲耦合太過嚴重，導致我又得重新設計敵人的框架,額外花瞭10多天)
迭代模型的話就比較符合遊戲開發的邏輯瞭，搭配GitHub就可以任意的折騰項目。下圖為迭代的概念
所以不難分析迭代最大的問題就是風險，但是獨立開發遊戲基本上免除瞭所有的溝通成本，並且獨立開發遊戲中獨立制作者是全程能把握開發進度的人。按需求來講其實獨立制作人的需求既是確定的，也是模糊的，確定的就是遊戲的風格和遊戲的玩法，唯獨不確定的就是能不能夠實現玩法的相關功能，並且要做好功能無法實現而需要為原本的遊戲玩法進行修改的準備。
最後就是增量模型瞭，增量模型其實跟迭代模型都是非常相似的，唯獨不同的就是增量模型必須得是需求明確的。
一旦出現需求不同，或者需求修改，基本上增量模型就會失效。增量模型比較合適有諸多項目的開發者去做，因為有深厚的經驗可以直接就明確出來遊戲的需求能通過增量模型實現開發者速度效率最大化，而獨立開發者極大概率不能夠把握開發的方向，甚至都不知道會進入何種方向。
總結：開發模型是死的，人是活的，不必一步一步跟著模型的概念去做，要從失敗中總結經驗，早日摸索出合適自己的開發模式就是最好的。
4.數據存儲，計算機網絡，信息安全
這塊內容偏向的是遊戲後端，跟前端是可以獨立區分開的模塊，但是無論前後端，都是以服務遊戲為主。
數據存儲：這個太常見瞭，人物的屬性，裝備的屬性，背包，倉庫等等，都是一系列的數據存儲。存儲的方式也有很多種，表格，文件，數據庫，那麼遊戲開發如何取舍呢？這裡就得看項目的要求瞭。比如用unity，隻是簡單的一些劇本，對話之類的需要用到json嗎？不需要啊，直接用軟件自帶的scriptableobject就可以做瞭，還好用。然後就是武器屬性，裝備屬性類的，這些需要根據測試反饋頻繁地修改，甚至發佈後也得因實際情況而經常更新的，那麼就得用xml瞭，但是xml不安全啊，很容易被惡意修改，那就用可以加密的json咯。需不需要數據庫呢，這裡我覺得按照工作量來說，沒必要，數據庫一般面向的是超大量數據，用來存儲裝備屬性有點像殺豬焉用牛刀，能減少工作量就不錯瞭，難道還有人為瞭秀技術而用sql的嗎？這不是沒事找事幹嘛。
這裡要單獨來討論數據庫，如果需要用數據庫存儲那遇到的可不是小問題瞭，而是會面向大量的數據才需要用到（幾百萬數據或者幾千萬以上）。一般在網絡遊戲中用到數據庫是非常多的，因為既要確保數據安全，又要與客戶端不斷地存儲讀取大量的數據。它可不是簡單的增刪查改，他的本質是數據結構化，數據之間具有聯系，面向整個系統；數據的共享性高，冗餘度低，易擴充；數據獨立性高。總之數據庫是個很龐大的系統，工程量也很大。
開發者可不能簡單的說自己用的是數據庫，因為一說到自己用數據庫，別人就會想到用的是配套的Linux作為服務器（商業好像是centOS版本，不是Ubuntu版本），並且得專門的去學習shell的寫法，然後在Linux上懂得處理進程（這個可不會有window任務管理器這樣的好東西的），並且得為服務器制作好日志表，分配好權限，配置好防火墻，這一套系統下來的學習成本也不亞於C#+Unity瞭。
至於為啥不用MSSQL呢，主要是收費的問題，業界大部分都是喜歡開源免費的東西，Linux+mysql就成為瞭國內最喜歡的數據庫系統，也有配套的成熟方案和視頻。
所以獨立開發者我的建議是盡量避免數據庫，當然如果實在需要數據庫的話得時刻確認自己有沒有資金支撐起來一連串的技術成本。
計算機網絡：在這裡也可以叫做遊戲網絡，這個我才剛剛開始研究，但是我開發遊戲絕對會放棄聯網模塊的，因為我沒有錢支撐服務器。不過總得瞭解一下，網絡傳輸有TCP和UDP，一個是安全傳輸，一個是快速傳輸（兩者對立的）。一說到網絡，又要說到服務器，遊戲服務器有狀態同步和幀同步，狀態同步的邏輯處理端在服務器上，然後下發到各個客戶端。大傢熟悉的LOL就是這樣的，邏輯處理端在服務器上，那就避免瞭外掛滿天飛的現象（因為服務器會自行判斷玩傢傳來的操作是否合理，不合理就駁回），所以LOL還是挺公平的遊戲（不是絕對公平，因為如果敵方用的AI腳本的話，基本上玩傢沒法對抗的）。幀同步的服務器，隻負責把客戶端傳來的指令轉發出去，不負責處理裡面的邏輯細節。這樣就會導致另外的問題，外掛太可怕瞭~什麼無影腳，原子彈啊，坦克啊，隻要能想到的，外掛都給你做出來。直接把一個遊戲都能毀瞭。
目前市面上的遊戲服務器得根據遊戲運行環境而定，比如CS,LOL這種遊戲，因為玩傢普遍在PC端，PC端網絡連接很穩定，那麼可以用狀態同步。而王者榮耀在手機，手機的信號時高時低，非常不穩定，那麼就用幀同步傳輸，那王者榮耀是不是可以開掛滿天飛瞭呢？這個我猜各位打過手遊，可以想想外掛現象多不多，也不用我解釋瞭吧~
現在的網絡，其實已經很混雜的地步瞭，一言半語說不清。但是有個地方想說的
註意！5G是不是未來雲遊戲的強大助力？
很多人問5G會不會引發下一個革命，讓遊戲進入雲時代。這個問題必須要探討5G的本身。5G是什麼東西？5G網絡（5G Network）是第五代移動通信技術可以讓下載速度非常快，並且擁有低延遲特點。聽到這裡，很多人就想到瞭5G可以解決遊戲很多問題。
1.雲遊戲問題。
很多人想象中的5G概念是這樣的，傢裡的電腦遊戲->5G上傳->5G傳輸->5G下載到現在的設備->實時在顯示器中顯示遊戲當前進度。然後操作的流程是這樣的
現實鼠標輸入操作->5G上傳->5G傳輸->傢裡的電腦5G下載操作指令->電腦遊戲實時操作
是不是聽起來很完美的解釋方案，但是這裡有個致命的問題。誰負責把畫面調用出來，誰負責接收數據，誰負責上傳數據，誰負責讀取傳入指令？
中央處理器（又名為CPU）！！！！千萬別說5G能幫你包辦所有，哪怕兩端是單純的IO設備，中間也得有一個專門負責處理事情的對象，那就是CPU。說到這裡我猜很多人應該明白一件事，自始至終5G隻是個傳輸的技術，它的作用在於傳輸速度快，傳輸時延低但是真正處理事情的並不是5G本身，而是中央處理器才有這個能力處理的。
回到探討這個方案的可行性上，以後用雲玩3A大作，一張4K圖片多大？按照遊戲畫面，普遍一張高清無壓縮的4K圖片大概有800多萬像素最低也得8M大小，往上不封頂。然後一秒鐘要生成60張圖片，也就是一秒鐘得上傳480MB的文件大小，（當然可以進行壓縮，也可以60幀換成PS4的24幀，但是這裡暫時不討論）面向端也得同時間瞬間解碼出來480MB的圖片文件。
這裡有個知識點，數據傳輸是必須經過編碼把數字信號轉換成模擬信號，然後在終端把模擬信號解碼出數字信號才能顯示畫面的。數字信號可以看成計算機的數據，模擬信號可以看作網絡，光纖，電磁波。
這個數據量可以說非常龐大，還是在理想狀態下。處理如此眾多的數據讓CPU單獨處理顯然不太現實，CPU是廣但是不精，真正精通編碼解碼還得看GPU，GPU可以極大的提高解碼效率。所以傳到顯示器上也是可行的（索尼已經實現過雲遊戲），但是問題來瞭，本質上我們玩遊戲的流程是這樣的。
電腦輸入操作->通過鍵鼠傳入CPU->CPU計算邏輯，然後發送指令到GPU->GPU進行圖形計算把畫面傳到顯示器->顯示器反饋給玩傢當前的遊戲狀態。這個順序可以不用來回傳。
但是雲電腦在最後這一步添加瞭一系列操作，又要順帶把編碼發送過去，終端接收到也得快速解碼出來~這樣玩一個雲電腦，不但要付5G的費用，又要花兩套以上的主機設備錢（一端負責編碼，一端肯定得有硬件負責解碼才能顯示，來回傳的消耗很大的），這麼有錢還不如直接買個3500塊錢的PS5，隨身攜帶還方便，又能實時8K60幀，又好玩。
然後從這裡延伸出一個問題，全部都讓中間商（提供服務的運營商）的處理不就完瞭，不需要兩套設備啊。這個問題我想說的是，各位以為的服務器是是怎麼樣的？？？
CPU是I9-10900K的集合，GPU是堪比RTX3090的存在，內存幾百G以上。這樣還不能解決我前面的問題？這裡我得問，這個電腦是隻有你一個人用的嗎?
雲電腦普遍都是想著搞兩套主機方案的，一套主機方案的就是馬雲的殘影瞭。但是一套主機方案非常考驗服務器運營商的壓力問題。這樣的高端配置，如果隻為瞭玩傢而設立，大概率會虧到老底都沒得剩。運營商開放的價格親民吧，中國14億人口，我就算主機遊戲玩傢100萬好瞭，100萬個人分攤下來的服務器還能得到多少的算力，100萬個I9還是100萬個3090？？有哪個運營商有這麼雄厚的財力，幾百個億做瞭個雲電腦，我還不算這個天價的維護費。中國的玩傢大傢也不是不知道，看看《黑神話：悟空》的提問可以看出來，出錢是不可能出的，白嫖就有自己份。一個一個說中國的希望，結果不斷地壓到200都嫌貴，這樣的環境能給運營商帶來什麼收益？還不如雲電腦開給馬雲老板，人傢分分鐘幾百萬收入。所以服務端雲電腦出現本來就不是為多數人準備的，而是少數領域使用的。別再幻想瞭。
2.5G能解決超大規模戰鬥嗎？有的人應該是玩過那種幾百人國戰的遊戲（遊戲名我就不說瞭），覺得5G可以解決這個問題，但是這個問題本身考驗的不是傳輸速度，又是CPU的處理能力。幾萬人的大規模戰鬥假設用FPS為例，我就用UDP+幀同步來計算好瞭，讓服務器瘦身。一個UDP包的大小我最小最小按照200B算吧（現實肯定KB乃至MB以上），兩萬人，那麼加起來一幀動畫就有200B×20000個文件，一秒就得×60，服務器一秒鐘受到200B×20000×60個包，我也當作服務器能容納瞭。但是接下來的操作是什麼呢？有沒有想過？？那是得為每個用戶提供另外的19999的包，也就是要轉發200B×20000×60×19999，哇這得多大啊。就算服務器能處理過來，個人計算機不會炸掉啊？然後說用魔獸世界的那種局限地圖咯。我真的很無語~我明白那個意思，（所謂的超大規模的戰鬥其實就像打一場現代戰爭這樣，真實又刺激的那種），但是如果能實現業界早就出相關的作品瞭，但是戰地現在不也才64個人實時對抗嗎？這個問題本質上並不是傳輸速度不夠快，也不是傳輸有沒有延遲，而是現階段的CPU根本無法處理這麼龐大的東西~要是真的能處理早就出對應的遊戲瞭，使命召喚都可以出到現代戰爭10瞭，活脫脫的一個新時代紅色警戒~
這麼蠢的問題，信不信我用鋸齒刀砍你
3.說的5G很沒用，為啥（國）推動5G發展（有點像杠精）？這個問題非常好解答，這個不是必然正確的問題，也不是什麼技術問題，而是現階段全球經濟下行必須推進的方針之一。 我從警校學習瞭四年學會瞭一樣東西，隻要存在私有制的地方，都可以嘗試用推導利益關系的方式來找到收益方和吃虧方。
碰巧遇到一個提問，已經符合瞭我去年的猜想：
大基建計劃大傢都應該聽說過吧。目前全球經濟下行，破發的貨幣已經把整個世界的未來都透支瞭。當年經濟危機直接導致瞭二戰的發生，但是戰爭是沒法解決問題的，隻是把矛盾暫時轉移瞭。這時期有個人出來，提出瞭復蘇計劃，這個人就是羅斯福，他帶來瞭羅斯福新政。美國街頭大量無業遊民，新政府通過幹預經濟的方式，讓底層人民重新獲得工作的機會，獲得瞭收入的人民就會去消費，隻要能消費，社會經濟就能重新運轉起來。也就是流動性，隻要有流動性，資本市場就不會枯萎。
今年的環境我猜各位有目共睹，六保六穩，地攤經濟，一系列的倒閉潮，我就不再多說瞭，有體會的就深刻明白現狀，沒體會到的可能傢裡有礦或者傢裡有人吧。（找工作是真的難，要求達到天際至少中級工程師，工資壓倒最低3000，還早9上到凌晨1 2點，大小周，我卷不動瞭~）
國一直註重基建，哪怕貼錢也要基建，翻新又翻新，造瞭又造，其實本質就是把錢取之於民，用之於民，把錢重新花在勞動人民身上，讓人民去消費。（雖然槽點多多，但是我是由衷地支持國傢的政策，底層的勞動人民是很辛苦的，我還有時間考編考公都是因為老爸還有一份司機的工作）。但是本意是好的，到瞭下面就開始變味瞭，大部分人開始爆炒房地產，把泡沫吹的高瞭又高。基建成瞭，帶動瞭物流，運輸，互聯網一系列發展，但是房子升到瞭天價，泡沫大到一戳就破，人民被房貸壓得喘不過氣，消費都被極大壓制瞭。現階段的問題跟當年的經濟危機像又不像，都是底層消費不足，經濟流動不起來。為瞭軟著陸，那麼就得讓錢真正流入到底層人民手上，隻要人民有瞭錢，才能去消費，所以就有瞭新基建。新基建的是為瞭避免再發生錢流入房地產，把錢用在實用的地方。
新基建的項目
然後回到5G上面來講，5G本身成功與否其實並不重要！！
它帶來的技術有概率產生新的科學技術，但是它失敗也無所謂。按照上面我說的利益推導，得利的是誰？國與民營企業與底層勞動的人民，虧得是誰？三大運營商的錢包。也就是說5G本身來帶來所謂的技術革命並不是國真正關心的重點，重點是推動5G建造的話，錢可以讓民營企業，勞動人民獲得，這樣就足夠瞭。（隻要人民有錢就不怕人民不消費）至於結果會如何，這就得以後再討論，是提升還是噱頭，當經濟衰退的危機過去以後沒人會再關註這些問題（大傢都會朝著下一個風口前進，還有誰管當年的東西）
開發者不但要有技術，還得時刻關註國傢的動向，不然稀裡糊塗的就跟著搞5G遊戲瞭。
最後說到一個內容，就是信息安全。學過瞭信息安全才知道這個世界上存在著兩種軟件，一種是已經被破解的，一種是不知道自己已經被破解的。任何軟件都是可被破解的，隻是成本問題。
unity的遊戲被反編譯是很簡單的，知乎上搜索 “空洞騎士的素材”，不管怎麼加密的文件，都可以被反編譯出來，這裡的具體細節我就不再贅述瞭，具體可以學習一下ILdasm的用法。
你懂的，我就不多說瞭哦~
如果這個遊戲真的對自己很重要，那麼必須得尋找一些大公司提供軟件保護。如果覺得保護費過高過貴的話，那最低最低也得學會《計算機軟件著作權》這本書，想辦法申請一些專利，小公司盜版無所謂，遇到4399那些抓包盜版的就立刻舉報。PS：版號就不要考慮瞭，這玩意還是未來有紅利再說吧~
遊戲被盜被破解是必然現象，所以不要再幻想用什麼D加密，什麼達文西密碼能保護自己的軟件。一定要在軟件有限的生命周期裡完成自己的目的，這才是獨立開發者必須清楚的。
5.計算機圖形學，架構
其實這兩塊是未來的方向，現在談論這個還算比較早。但是也知道遊戲開發走到最後要麼搞渲染，要麼搞架構，不然就隻能轉崗瞭，幾年後還搞邏輯開發的可能也就我這樣的獨立開發者瞭。
說內容前就得說一下渲染，其實渲染這個內容，歸屬於TA（也就是技術美術的范疇），T為輔，A為主，我這種還是懂得寫一些著色器就算瞭，真的要探討美術的話（我可能真的沒那個天賦）
計算機圖形學：其實涉及到這塊內容就得學好數學中的矢量（也或者叫向量），坐標系，點積與叉積，最主要的就是矩陣！矩陣可以說是計算機圖形學的核心，我一直以為圖形學的核心是矢量，結果看瞭矩陣後才發現，短短的4×4就可以把所有的矢量囊括瞭。同時矩陣也是數學領域最難的地方，有天賦的小學就能明白，我這種無天賦的，可能一輩子也不會明白吧。
天才是百分之99的頭腦+百分之1的汗水。——愛迪生
架構：架構師很多人都聽過，架構師就是有著豐富的開發經驗的人（有點像經驗豐富的軟件設計師的感覺），搭建架構讓手下開發者按著架構來開發，可以事半功倍。現實中有沒有著名的架構可以提高效率呢？肯定有的。
遊戲一般以單線程為主，因為遊戲不需要比拼計算機處理速度，比的是順序邏輯處理。多線程在遊戲中就是個附屬品，用在加載場景，下載資源等簡單的用途之上，這就讓其他核心無事可幹。現在有瞭新的架構，著名的例子就是《守望先鋒》采用瞭ECS，這個架構可以解決多核問題，核心越多，遊戲運行的越流暢。當然ECS架構目前隻是公開瞭概念，而源碼暫時還是不公開的。所以業界中也仿照ECS做瞭嘗試，比如unity的dots，就是一種嘗試。但是並不多，因為實現的場景有限。隨著未來CPU核心越來越多，我覺得ECS架構應該也會成為未來的重點。但是我一直強調過的，任何的程序和架構都是服務於遊戲為主的，單線程雖然消耗性能，但是能讓遊戲順利的運行，就已經足夠瞭，殺豬焉用牛刀！？
最後，一年下來，遊戲開發得讓我學會很多東西。策劃，程序，美術，音樂，法律，邏輯。
音樂，不要求會做，但是得會聽，不要胡亂的選擇BGM和音效。
法律，一直以來大傢都說法律是隻會保護有錢人的。
而我的學校一直有句話，法律從來隻會保護懂法的人的。
邏輯，不講邏輯的人極大概率在溝通上會浪費相當多的時間，懂邏輯的人可以更加的明事理。不懂邏輯連國傢意志和政策都看不懂~~
知識是無限的，時間是有限的，學到老活到老，學會瞭遊戲開發也算是多一項技能，畢竟我也不知道未來何時會被裁員，被下崗，甚至未來會不會發生戰爭。居安思危才能驅使人類進步，等到危機來臨時，再多的財富可能也會轉眼瞬逝，真正還屬於自己的就剩下思維敏捷的大腦和強壯的身體瞭。
