在頂級遊戲開發的過程中需要怎樣的編程實力？

01-03

在3a大作以及頂級ip的遊戲開發中。程序員的實力如何？比起頂級程序員有哪些差距？頂級程序員是否不屑於開發遊戲？
---
遊戲開發過程中，最需要大批水平一般的碼農還是坐鎮大拿？
----
在如《荒野之息》這種系統複雜的遊戲中，普通程序員是否有瓶頸？

在如育碧式開放世界的遊戲開發中bug頻出，是否源於程序員實力不足？
在性能羸弱的掌機遊戲開發中，一個優秀程序是否能創造神跡？

做遊戲技術主要講究的是套路，以及對套路的掌握程度。比如說你要搞個體積光，那麼從用mesh+uv動畫，到volumetric scattering你都得知道，而且要知道這些方案的優缺點，以及具體的實現細節，比如camera會不會到體積光裡邊之類的，這種細節的了解會讓你更加有信心做出各種技術決策。

所以3a級遊戲的大神技術也是對各種領域的套路玩得比較溜，這裡我也分享一些做遊戲20來年自己領悟出的一些套路吧。

美術用工具輸出的3d模型，材質一定要做一個導出插件，否則做出來和進引擎效果不一樣，就只能做做手游這種無光照的手繪貼圖質量的產品了。

動畫要想不滑步，就只能用animation driven的方法，這個需要跟策劃做好深度的溝通，得讓策劃知道移動不是說配置一個速度就可以了，得去找動畫師一起調整移動的動畫。

動態天氣的困難不是製作上的困難，是可以用lightmap的物件會少很多，性能不一定扛得住，這個要在項目初期一定得和製作團隊溝通清楚。

球類遊戲要達到非常自然的動畫，一方面動畫肯定是要動捕的，另一方面更重要的是搭建一套動畫選擇機制，然後根據運動中的球類位置來選擇最合適的動畫來匹配，再加上小部分的ik。

頭上冒字和冒血這種hud就應該用hud的標準方法來製作，切記不能塗省事用ui的方法，對性能效率會有非常大的影響。

音頻對最終品質影響很大，一般遵循46原則，即圖像資源在最終包中佔6成，音頻資源佔4成。給音頻設計師配置一個獨立的程序來達成音頻的設計需求。

狀態機最好是用可視化的方法來實現，遊戲中80%的bug都是和狀態沒切對有關，有個可視化的狀態機對於找bug非常方便。

control是最需要狀態機化設計的（不同的情況下按同樣的按鍵達成不同的邏輯）

做面部表情，如果不是捕捉就用骨骼簡單搭搭就好，如果是捕捉，製作成本會變得非常的高（製作各種morphing target）

對最終畫面影響最大的是鏡頭效果，所以盡量節省渲染時間留給鏡頭特效。一般影響最大的是校色，如果硬體平台允許盡量給美術提供帶深度校色的工具。

有比較寬廣視野的遊戲，室外可以用一些很取巧的方法來模擬mie scattering和rayleigh scattering，加上哪怕是假的對畫面的提升也是巨大的。

對於不同的數據採用不同的配置方法，不要什麼數據都用excel，對於有可視化需求的配置，比如ui或者角色身上需要裝配一些武器的，提供可視化的工具。對於需要描述父子關係的例如技能樹解鎖之類的用json或者xml來描述，對於純數字邏輯的就用csv就好了。

場景的材質如果製作normal map對於你們團隊比較複雜，多加一層detail map也能對效果獲得較大的提升。

角色的材質，如果性能有限或者說製作成本無法承受的話specular map比normal map的效果要好。

如果角色會近距離看臉，臉部的眼睛一定要單獨拿出來處理，臉可以糊，眼睛一定不能糊。

腳步聲的標準做法是在地面上放一層低模做和腳的碰撞檢測（腳步聲如果追求真實，最少得有3個以上的樣本隨機）

如果要提升動畫效果，考慮主角的前臂加上twist骨骼，左肩和右肩不要從脖子上搭建骨骼，要從胸口開始（做head lookat的時候效果會更好）

衣服的標準做法是通過貼圖來控制哪些頂點受skin和物理影響的權重比，那張貼圖還可以用一個通道來控制流汗的時候哪些地方的smothness要提高。

搭建一個運行時資料庫，並且遊戲中經常需要訪問的數據都放入資料庫，可以類似redis那樣非常簡單的提供一個set和get就行了，運行時資料庫可以幫助你找到絕大多數bug。

製作ai盡量使用行為樹，並且花時間一定要讓策划具備編輯和調式行為樹的能力。

頂點色可以各種花式使用，無論是用來bake ao還是決定detail map的權重，都可以用很低廉的代價來獲得非常棒的效果。

動畫不是在任何時候都可以blend的，要想效果好，牢記：左腳落地的時候只能blend到左腳落地開始的動畫，右腳同上。

做上下樓梯的locomotion的時候，用橢球碰撞體會非常簡單的獲得還不錯的效果。

如果畫面會經常快速的運動，可以加入一個vector based motionblur，效果會出奇的好。

要想場景生動，一定要使用decal，一個方便美術的decal工具可以讓美術一天之內讓整個場景提升幾個檔次。

暫時想到這些，不說了，休息好了繼續幹活。

~~~~~繼續更新一波套路

解決alpha透貼排序的標準方法是兩次繪製，第一次在不透明隊列里渲染一次alpha test（cutout），打開zwrite，第二次在transparent隊列里開alpha blend不開zwrite，ztest lessequal渲染就能還原美術在maya里看到的效果。

彈簧是個非常好用的物理組件，其虎克係數可以有效的模擬力的衰減來做出很多感人的效果，從乳搖，臀搖，尾巴，頭髮馬尾，布料，臉上被重拳擊中的肌肉變化都可以看到彈簧的身影。

adobe fuse cc + mixamo可以非常快速的搭建模型和動畫來幫助策劃找到劇情的場景的感覺。

腳下ik從程序來講是很方便實現的，大多數引擎都有ik功能，但是工作流程我發現很多公司都沒有正確使用。正確的流程是對輸出的動畫有一個左右腳高低的分析工具，逐動畫生成每個腳步離水平面的高度曲線，然後運行時根據腳步的高低來決定ik和skin的權重。

鏡頭的設置很重要，最好給美術一個和相機鏡頭類似的演算法來反過來計算fovx和fovy，我看到很多產品的fov都是一水的60之類的。

對於類似鐵絲網或者其他半透物體的mipmap的標準做法是先自動生成mipmap，然後要美術手動的來降低不同lod貼圖的alpha，換句話說近處看有鐵絲網，遠看就只有框中間近乎全透了來降低鋸齒感。

dx10以上的平台上特效的shader加一句根據當前depth和已經繪製的depth的差來控制alpha可以實現簡單且效果不錯的軟粒子效果。

頭髮的物理效果可以參考衣服的做法，髮根受skin影響多，發梢受物理多一些即可。（額前劉海受物理要關掉重力）

如果實時sss負擔太重，可以簡單的把模型厚度信息烘培在頂點色的某個通道上，然後只需三兩行代碼就可以讓皮膚有sss效果。

看到好多項目用雙面材質只是在shader中簡單加一句cull none，這個是完全錯誤的實現。正確的做法是需要把三角形索引信息走vs傳遞進來，然後判斷是否順逆時針，對於反面需要把法線反轉才能獲得正確的渲染結果。

先更新到這。

完了，感覺思緒開始打開了，又更新一些，怕一會會忘。

動畫驅動的模式下，轉向最少需要8個動畫，原地左轉90，右轉90，左轉180，右轉180，移動同樣四個，然後根據控制器的輸入來決定混合的權重，一般神海這種級別的產品光locomotion牽扯到的動畫會在40-50個這種量級。

對於衣物和皮膚，detail normal十分重要，可以瞬間讓你的衣服能看出針織的材質。

處理聲音的時候，遠處的聲音混響需要程序來手動提升，近處降低混響，對臨場感增加很多。

聲音如果樣本有限，也一定要做隨機，哪怕就一個腳步聲樣本，播放的時候也應該隨機pitch和volume。

給策劃提供一個調整動畫曲線的工具，橫軸是動畫時間，縱軸是動畫播放的速度，策劃通過這個工具可以調整出情緒非常飽滿的動畫效果（例如：攻擊前搖動畫速度變慢，攻擊過程加速之類的）這個需要和動畫師溝通清楚，要求他們只需要k好幾個相關pose即可。

卡通渲染的時候有一步是非常關鍵也是很多公司都忽略的，就是手動調整模型法線，這一步得在美術工具內完成，通常是定義toon shading的光方向之後，通過調整法線來讓一些部位有「看起來」較為舒服的受光，主要是鼻子，腋下和兩個胯這三個位置。

遊戲載入的正確做法是，在出包的時候對各資源的單位載入時間進行預計算（適合配置固定的主機遊戲）。之後在運行時載入的時候，根據每一幀cpu的可用空閑時間來決定當前幀可以載入的資源類型和數量。

渲染陰影的時候，很多人都會忽略繪製陰影那個pass的優化，以前做上一代遊戲機的時候所有會有實時陰影的模型都會做一個低模和專門的材質（如果有透貼陰影的需求）。

對於寫實類型的遊戲，decals的正確製作方法是拿相機去拍，比如地上的水漬，牆上的裂痕，車上的劃痕之類的，開閃光燈拍照，然後回來在ps裡面摳出來。

有很多arpg的遊戲中都有霸體的設計，霸體中不會受擊，其實這個的正確做法是動畫新增一個受擊層，在播放霸體動畫的同時輕微的blend一個受擊動畫，打擊感會舒服很多。

午飯時間！

反響不錯啊，再來一波=）

寫實風格的貼圖，推薦盡量使用Substance製作，打包不同目標平台的時候，可以根據目標平台的實際硬體情況，決定是Bake出Texture還是用Procedual Texture，其實很多時候會發現很多PBR貼圖除了Google圖片出來修改之外，只有Substance才能比較好的製作出來。

有一個關於Animation Driven的系統中，AI的製作問題，主要是因為動畫狀態機自己有自己的行為準則，所以傳統的AI設計思路就變得比較無力，比如說我希望我的NPC每0.3秒攻擊一次，但是攻擊動畫本身就超過0.3秒了，怎麼辦？或者說狀態機的邏輯無法響應到0.3秒的攻擊。這個時候需要跟策劃溝通，在Animation Driven的系統下，要完全的分開設計，NPC的大腦是AI，NPC的體格是動畫狀態機，很多時候AI的設計要根據體格的情況來酌情調整。要在行為樹里增加一些檢查身體體格的節點，比如說，我要轉向某個方向，那麼在適當的時候需要檢查自己的身體是否真的轉到指定方向了；同時對於大腦向身體發送的指令要分優先順序，優先順序的實現方法是該指令的有效時長，比如說我的身體在受擊的狀態中，但是我的大腦仍然下命令讓我攻擊一次對方，這條指令優先順序存在時間0.2秒，如果受擊狀態在0.2秒內復原了，則該指令身體可以執行一次，如果0.2秒內身體仍然無法攻擊，就丟掉此次指令。

Volumetric Cloud/Fog/Light的使用一定要提前和美術進行商量，因為計算過程中牽扯到大量的Depth sampling，所以畫面中多大會存在多大面積的這類效果一定需要嚴格控制，否則到了後期不得不移除這些效果的時候會讓整個產品瞬間降低一個檔次。

在一些中低端設備上可以用一些簡單的壓縮演算法來把RGB + Luminance除以一個除數來壓縮到32bits的顏色空間中來獲得非常划算的HDR效果，相比較RGBM，用除數可以免費獲得「假」正確的alpha blend效果。這一條無需和美術溝通，直接上就行。（移動平台可用，效果很好）

關於差值，差值計算最大的問題是需要和策劃溝通清楚，越是符合現實生活運動規則的，只能使用物理的方法進行差值，物理的方法是沒有辦法精確的保障差值的最終位置和時間，但是卻可以獲得完美的差值效果。這裡有一個非常小的tips來實現物理差值：一個物體從旋轉R0，位置P0，差值到旋轉R1，位置P1，需要差值的時候，在物體上掛一個彈簧，彈簧的另外一端掛在位置P1上，另外物體的運動規則增加兩條：1，每幀運動轉角不能超過XX度；2，物體的實際運動位置是當前朝向 * 力矩；即可，差值出來效果棒棒噠，無論是飛個火球還是跟蹤導彈都可以用這個。

美術資源的優化，這件事情比較好的方法是要嚴格的關注，但是盡量不要過早的修改這些問題，因為開發的過程中始終要留一些空間用來提升畫面效果，所以過早的修改掉性能瓶頸，可能會導致到最後不得不放棄已經集成進版本的一些效果，非常不划算。所以等大家都對畫面比較滿意了之後，再進行一輪性能優化，結果還能再增加一些效果，對於美術大兄弟們來說就變成一件很好的事情了。

本來沒打算寫這麼多，只是開始寫了個頭，就發現還有很多類似的問題也都可以羅列出來，於是出現這麼多雜亂的內容，回頭有時間會仔細整理整理，比如說配個圖什麼的，如果有朋友對於一些tips有疑義或者想知道一些詳細的實現細節，歡迎私信單聊。

應某同學的要求

更新一波手游的經驗ヽ(??ω?? )ゝ

貼圖進版本的時候做一個alpha通道的剝離，一方面可以比較方便的適配安卓ETC1壓縮格式，另一方面後期要壓包的時候alpha通道可以隨意縮大小，美術基本無感知。

如果是UI資源比較重的遊戲可以採取layout和資源分離的方式來獲得大量的性能提升。針對unity引擎來說就是遍歷ui里所有用到的material，把裡面的貼圖替換成4*4的空白貼圖，另外建立一個從材質對應貼圖的索引。因為手機是ssd的緣故所以磁碟io讀取貼圖的速度是非常快的，這樣就可以把整個ui的layout都留在內存中不用切場景釋放，不同場景對應載入不同的貼圖做一個運行時的對應即可，載入ui的時間能提升80%。這一步建議新項目中前期使用，後期項目做這種級別的修改不划算，風險高。

如果是動畫資源比較重的產品，建議使用自定義的動畫格式，採取float16的四元數儲存關鍵幀數據，然後載入時還原引擎需要的動畫數據，以前做wii上的產品，1000個左右的人形動捕數據可以壓縮到23m左右。

經歷過很多手游項目的全屏大圖比較多（推廣圖，loading圖），有的會佔到整個貼圖量的30%甚至更多，這時候一定要優化大圖的製作工藝，和美術溝通把背景，文字和前景拆開製作，一方面可以更好的壓縮（方形，2的次冪），另一方面背景圖可以採取比較極端的壓縮參數。

載入的過程中往往最後會卡一下，這個是第一次shader提交到gpu產生編譯消耗的時間，可以通過在屏幕上繪製一個透明的三角形來完成warmup，這一步基本上主流引擎都有介面，如果單幀消耗過高，可以考慮分布在若干幀里完成。

打擊感的一個小trick，擊中的一瞬間把時間tick調成0持續個0.1秒左右，又輕巧效果又好。

搭建UI框架的時候給每頁ui增加一個fadein和fadeout的介面並且管理好狀態機的切換，今後可以很方便策劃或者美術增加ui打開和關閉的動態效果。

謝邀,這個話題挺喜歡的, 但是題主這個問題有把複雜問題簡單化得傾向,我這裡定向為資深程序員的作用好了.

&>遊戲行業和其他行業的資深程序員對比

首先這個"資深程序員",就是單純指技術綜合實力強的程序員,和年齡,從業時間,頭銜都無關.

3a大作中尤其是強技術類型的,其規模複雜度和技術深度的挑戰都非常高,另外大量的作品在多年間保持一代代的出, 中間在不停的進化, 對開發效率要求也不低.橫向對比,不輸於大型的商業軟體,能夠hold住這些的程序員,起碼不比這些領域中的程序員差.

另外像cppcon,siggraph這種會議上,也能看到領域重疊的其他程序員和研究者的成果,也是一樣的結果.

"不屑於開發遊戲"的頂級程序員,如果來開發遊戲的話也不會成為真正頂級的程序員,真正頂級遊戲程序員對遊戲的熱愛和理解是必要條件.

&>遊戲開發過程中，最需要大批水平一般的碼農還是坐鎮大拿？

應該說是需要普通程序員和資深程序員以正確方式配比,形成有效的團隊, 不要把程序員想像成樂高積木,簡單量化. 團隊更像一個生物,是一個複雜的有機體.

好的程序員會提升這個生物的dna水平.

具體在開發中的資深程序員呈現是:

決定技術高度:這裡高度包括規模的把控能力, 重要技術的突破(比如育碧系遊戲中的動畫,圖形和破壞等等), 棘手問題的處理等等
技術槓桿:資深程序員在大量的技術方案制定中起到重要作用, 最後可能程序是普通程序員寫的, 但是其中融合了資深程序員的設計在其中,這個對團隊來說是性價比極高的一件事
技術基因打造:技術文化營造,底層代碼質量把控, 這些決定了團隊的進步速度, 以及給定技術方案下實現的質量和開發效率.

然後就是不要把複雜問題簡單化,這裡只是談到很有限的一部分,大量情況下你會發現沒這麼大的作用,比如團隊就處理很簡單的小遊戲的時候,所謂資深程序員是一個不愛打交道的人,團隊因為各種原因限制了資深程序員的發揮...具體問題具體說了.

&>在如《荒野之息》這種系統複雜的遊戲中，普通程序員是否有瓶頸？

普通程序員的瓶頸:可以通過模塊的設計,把大問題分治成這個程序員能夠承受的松耦合的小模塊,這樣複雜的遊戲就簡化成可控的簡單模塊了,如果不能分離處理(這種情況有的),普通程序員處理不來,那就是會成為瓶頸.

&>在如育碧式開放世界的遊戲開發中bug頻出，是否源於程序員實力不足？

遊戲質量是一個函數的話,中間有這幾個變數, int GameQuality(程序員實力, 團隊綜合實力, 遊戲複雜度, 開發周期);

程序員實力強,確實就會寫出bug更少的代碼, 甚至會驅動QA團隊更有效的測試,進而導致更高效的產出高質量的結果.

但如果QA團隊不行, 遊戲規模太大, 很短的時間上線, 那就沒辦法了.

&>在性能羸弱的掌機遊戲開發中，一個優秀程序是否能創造神跡？

性能羸弱的掌機或者說現在對於性能要求更高的手機, 相比console和pc, 遊戲規模會降低, 那麼單人的影響會上升.

能否創造神跡...何為神跡呀?

準確說資深程序員更會創造出, 這個平台上, 比競品更卓越的遊戲了.

個人認為，跨領域的職能發展路線，對於目前的遊戲行業，其實比什麼進入管理層更值得我們去追逐。不懂技術，那麼就無法直面技術進行流暢交流，不懂美術也無法與美術直面交流；同理，技術、美術也一樣。無論遊戲行業流水線的哪個環節，在不知曉其他環節的操作方式的時候，盲目評價其他節點的工作質量、工作效果，都是無理取鬧，都是神經病。

最後，我覺得，我們策劃每天都要琢磨琢磨，程序小夥伴是否值得我們去配合，更重要的是，我們是否給程序小夥伴造成了困擾；我們是否做得足夠好，學習到足夠多的內容，來配合程序小夥伴的工作。別把自己當成填表的機器，而程序小夥伴也不要把自己當成碼農。

---------------------------------------------------臨時分割，補充描述，以下正文-----------------------

我以策劃的立場看待這個問題...我回憶了一下自己的過往經歷，接觸的一些程序方向的技術人員...

我發現，頂級程序不是不屑於開發遊戲，而是他們大多數的工作在產品的前期籌備過程中，就做了好多了，這些準備工作促使策劃、美術在產品裝配的過程中，準確、流暢、返工率低...而他們隨產品推進而帶來的工作內容，更多的是在結構上的完善維護...

我接觸的比較牛逼的程序(我沒做過3A，我不懂那裡的程序是什麼樣)

1.可以搭建一個足夠應對大部分策劃腦洞的架子，這個架子大多數時間都是非常穩固的，足夠應付大多數的腦洞。比如戰鬥技能設計，我可以在他提供的平台上，編輯出大多數技能，並且腦洞夠大的也可以實現出來。而他的主要工作，可以理解為，就是在完善框架，避免框架應付不了我的腦洞。

2.他可以為我和美術提供一個可視化的展示，我和美術完全可以脫離技術，完成一些資源的裝配體驗，獲取反饋之後，進行設計調整。這裡的可視化，並不是一個限定環境的可視化，我記得很多需要技術支撐的步驟，他的結構都為我們準備好了，很多都是引擎自主完成的，我們只要導入就好，即使是以錯誤的操作方式，都能應對，總之就是讓沒技術相關知識的人，可以進行無腦操作。

3.實現的內容實際上超出策劃、美術的預估，我個人大多數時間的設計，並不是一成不變的，很多時候，在沒有可視化支撐的情況下，我並不知道自己的設計是否是一個可執行很高的設計。而頂級的技術，往往看到我第一版的設計的時候，可能他會根據自己的遊戲經驗、工作經驗，加入自己的設計，無非是這些設計我不用，他關閉掉。而往往就是他加入的這些內容，促成了我的設計進行順利的返工。

與頂級的程序合作，我感覺自己非常自由，他的工作量不是表面上的那些。在與他們交流的時候，獲得的大多數反饋，都是這樣的，「我教你一個辦法，這裡有一個小功能，你拿去，按照我說的辦法，你就可以看見你想要的東西了。然後，現在你別來煩我，我有更重要的事情要去做」；而與一些比較差的程序合作的時候，大多數都是這樣的，「你這個想法不成，太難實現了，框架不容許，要麼就是重新搭框架，這得返工」，然後就是一頓撕逼...

一個產品要上3A的級別，我作為策劃，經驗告訴我，瓶頸在於技術提供的支撐，可以讓美術、策劃的設計放大到什麼程度。無論是表現力的處理、邏輯過程的處理，技術限定了策劃、美術的發揮，比如一個常見的問題，「同屏20人的客戶端效率，可以流暢的展示同屏50人么？」

頂級技術可以最大限度的為設計團隊提供支撐，這不是一個小程序員能夠托起來的一個大盤子...

反對下樓上說技術不重要的。技術是否重要要看項目類型。何況樓上回答都偏題了。

遊戲開發與藝術創作一樣有兩條不同的驅動方式，一條是技術驅動，一條是內容驅動。所有項目都有內容和技術，根據項目驅動方向的不同站的比例也不同。對於內容驅動的項目，技術並不是很重要，只要能表達內容就可以。技術驅動的項目則相反，只有達到特定標準的技術才能體現出遊戲樂趣。

但是技術與內容不同的是，技術很容易傳播和重複使用，一個技術出來不出一兩年就會有一大波遊戲公司在使用，而內容你要是這麼干，一幫人會告你抄襲，而且玩家也沒興趣反覆體驗。

回到問題。

如果只是一般程序員，代碼和API/常用庫熟悉，能根據問題合理選用數據結構和演算法，邏輯和代碼清晰乾淨，能跟同事正常溝通，對工作認真負責，基本就能完成自己的任務了。還有就是遇到正常問題能通過 google github stackoverflow 解決掉。

高級點的程序，要解決項目中的各種問題。

需求分析，要能將項目需要實現的口頭說明和文案轉成對應的程序功能，劃分模塊，規劃製作內容。要考慮需求變更和擴展，要考慮通用性。

進度管理，要能根據需要實現的功能估算項目時間和進度，合理安排人員和功能實現，根據當前進度和項目里程和需求變更情況進行調整，取捨，重新規劃。

技術，解決自己專長方向的技術問題，配合項目需求。通常面臨的技術問題圖形圖像，優化顯示效果，跟概念設計人員一起研究性能開銷允許下的最好實現標準，實現特定的藝術效果等。根據平台機能優化運行效率和內存管理。網路的話還涉及到數據處理，延遲，同屏最大人數之類的。

人員管理，感覺管理不應該算到程序員技術這裡，不過國內公司好像挺喜歡把人事也塞到主程組長之類的職位上。

頂級遊戲沒有這樣的說法的，或許你說的3a級大作？

那麼問題就很簡單了。3a大作從來不是程序員的事情。

其中劇本，腳本，美工等，一個遊戲最直觀感受到的部分不是程序員的活兒。

遊戲引擎的維護和編寫則不屬於具體某一個遊戲項目。

反而是一些小工作室作品，程序員的佔比比較大，因為往往不止要寫邏輯，還要承擔其他工作。

另，育碧那種情況純粹是遊戲檔期趕的，測試覆蓋不到位，跟程序員水平關係不大。

以下單從技術角度出發來說。

眾生皆有佛性，頂級遊戲的開發也是一樣。出發點很重要，就是你有沒有立志要讓你的產品達到行業頂級的水準。如果帶著這樣一個決心去驅動開發工作，對每一個開發中遇到的問題都零容忍，對每一個程序細節一定程度上極致考究，只要能做到這樣，每個程序員都能是頂級遊戲的開發者。

別太迷信所謂優秀的頂級技術，君不見縱使雲風或葉勁峰這種公認的遊戲行業技術大牛，也沒能直接決定某個頂級遊戲的現世，也從來沒有某個遊戲因為某個大神程序員而封神。技術的高低不是決定因素，舉個簡單的例子，基礎不差的話，如果能下苦功去讀讀一些關於遊戲開發前沿領域的相關PAPER，再花個半年一年時間做個研究做個實際案例或編寫個相關開源庫，我相信你也能就這個領域跟大牛們圍坐在圓桌旁侃侃而談，但這並不是開發頂級遊戲的必要條件。很多別具匠心的大作，往往出自名不經傳的團隊或個人開發者，所以匠心和執著才是真正決定一款作品，有這樣的心態，哪怕經驗經歷尚有不足，頂級開發者之名，亦當之無愧！

一哥們

畢業以後直接進遊戲公司

一混就是十年

從打雜做到主程

用他的話說

遊戲開發中

碼字的是最不重要的

能讓策劃隨意改需求的程序員大概就是頂級的程序員了吧.

有朋友從事過，其實技術團隊也就一般。撇開設計，最突出應該是美術了，那個成本跟國內的不是一個量級。

作為一個ship過兩個主機遊戲的前從業人員來講，心目中的大神都是在自己的專業領域很牛逼的人物。他們很喜歡鑽研新的技術，並且把它應用到遊戲里，其實在我們廠的時候，很多時候大家都在吐槽這些代碼有多落後，但是正是因為有了這些牛逼的人物的存在，他們能非常好的根據producer的需求做任何技術改進。雖然兩年的時間我連皮毛都沒學到，但是很敬佩他們的態度跟精神。

優秀的程序員可以保證遊戲沒有bug。

而優秀的遊戲，最需要的是優秀的策劃。

能真正火起來的遊戲，

比如俄羅斯方塊，貪吃蛇，超級瑪麗，warcraft，wow，lol，王者榮耀，等等都是一種玩法，影響了一批人。

謝邀我用unity開發，基本編程知識即可開發遊戲

玩文字遊戲，忽悠玩家指鹿為馬的功力。

雖然自己是程序員，但還是要說在頂級遊戲製作中，編程應該是最不重要的環節。按重要性排序應該是策劃、美工、編程、測試

你達到之後就知道了。

有人說錢能解決的問題都不是問題，同樣，遊戲開發中能用編程解決的問題都不是問題。