做遊戲與web的區別
在一間遊戲公司的兩個部門待過， 前一個部門以做web開發為主，後一個部門做遊戲開發，我在兩邊都是做後端的。
在遊戲部門待的時間不長， 不敢說已經深入瞭解遊戲開發技術細節，我僅把我已經接觸到的內容與之前擅長的web技術做對比，一來作為工作日誌記錄， 二來希望能給想從web轉游戲的同學提供一個預先學習的方向，少走一些彎路。
這一系列內容我會連載釋出，而不是一次性講清楚所有內容， 畢竟當前還不敢狂妄的表示已經瞭解遊戲開發的種種細節。
通用性
即使不同型別的軟體開發也是具有一定相似性的，這種相似性隨軟體型別的不同而不同。 如web前端開發與web後端開發差異就挺大， 前端程式執行在瀏覽器中，後端程式執行在伺服器上；前端程式操縱的目標是網頁元素，後端程式操縱的目標是儲存在伺服器上的資料。前端和後端相似的地方估計也就程式語言使用的一些基礎概念了，所以前後端程式設計師崗位轉變存在一定難度，比如讓一個沒有任何後端經驗的前端程式設計師立馬上手寫後端程式，幾乎不可能。
然而web伺服器和遊戲伺服器的差異就沒這麼大了，它們用的是相同的程式語言， 比如說java；它們用的是相同的資料庫軟體，比如mysql和redis；它們都執行在伺服器端，比如linux server和windows server，且對穩定性要求及其嚴格。擁有這幾處相同點兩種程式在巨集觀上是完全相似的，對應程式設計師工作的轉換也不存在硬性的技術障礙， 如果程式設計師技術基礎紮實，完全可以平滑過渡。
差異性
因為業務的不同，web伺服器和遊戲伺服器勢必存在不同之處，然而這種不同並非技術上的不同，而是套路上的不同。
伺服器型別的不同
web程式使用http服務，瀏覽器和伺服器之間是http協議通訊。遊戲伺服器通常是一個socket伺服器，與遊戲客戶端之間保持長連線，如果是網頁H5遊戲，那麼使用的也是全雙工的websocket協議。通常，使用http協議的web伺服器不用程式設計師費事去管理網路連線，程式設計師只要專注業務邏輯即可。而使用socket或者web socket等協議進行長連線通訊卻需要程式設計師手動程式設計管理，比如說斷線重連遊戲狀態恢復機制，就需要手動處理網路連線。這表示socket程式設計難度大於http程式設計，從而導致遊戲伺服器程式設計大於web伺服器程式設計。可這並不能表示遊戲伺服器程式設計不同於web程式設計， 如果一個web程式設計師不瞭解socket程式設計原理，那也不能算一個優秀的web程式設計師，畢竟http是以socket為基礎的。
傳輸資料格式的不同
在web前後端傳輸資料除了使用http標準的鍵值對格式以外使用最多的是json，json被使用的一個最重要的原因是與JS無縫相容，高效方便。然而，這種優勢在遊戲客戶端中不存在，人家遊戲客戶端又不使用JavaScript程式設計，所以遊戲客戶端和伺服器之間有更合適的資料傳輸時格式存在。
我接觸到的是穀人希家的protocol buffer協議， 它相對於json的優點是
體積小。經我測試，同樣的資料內容，使用protocol buffer格式儲存大小隻有使用json儲存的三分之一甚至更低，即使在某些特殊情況下也不會超過json的一半。
嚴格驗證資料格式，有xml xsd的功效。而json資料格式驗證相對寬鬆，只要符合json語法就行，因此容易出錯。反之，protocol buffer則更加穩定。
至於缺點最嚴重的是使用麻煩， 需要藉助穀人希的第三方工具才行。
protocol buffer的使用細節，這裡不作講解。
分散式處理業務
我接觸到的遊戲伺服器是微服務的一種形態， 整個遊戲伺服器的邏輯被分割成很多服務模組，分別執行在不同的伺服器上。然而，我無法理解的是每個模組之間的通訊居然使用socket，而不是更流行的http。遊戲客戶端與伺服器之間使用socket連線可以理解， 然而，伺服器各模組之間也使用socket卻有些使我莫名其妙，雖然這會使伺服器之間通訊效能有所提升，卻會帶來編寫程式碼任務過於複雜，穩定性下降等問題，為了些許效能提升而喪失專案的維護性，有點得不償失。 不過也有可能我還沒有理解其中奧祕，判斷過於片面。
極端的效能敏感
遊戲中實時對戰模組必須使用c/c++實現，原因是JVM執行垃圾收集時會造成虛擬機器停頓，也就是stop the world。在虛擬機器技術發展日新月異的今天， gc停頓依舊會對遊戲體驗造成影響，因而必須使用老掉牙的c++， 這使我感到震驚。
另外， 遊戲中大多數資料被放在redis中而非mysql也使我意外，資料持久化儲存顯然不是redis的優勢，拿效能換穩定和安全，這種做法略顯激進。
以上內容是我當前對於web開發與遊戲伺服器開發不同之處的見解，如有謬誤請指出。 此外，在之後的學習和實踐中的心得體會，會在之後的文章中繼續釋出。