進入遊戲行業1年的總結

　　從我知道有編程這回事以來，就把編程做爲理想職業了，惋惜我直到大二才知道有這回事。並且因爲悟性不高見識不夠，在成爲一名真正意義上的程序員的路上走了很多彎路。直到我進入遊戲行業以後，才找到了做爲一個程序員的感受。其實真正的程序員都是但願開發系統軟件的，操做系統、編譯器、數據庫之類，不過遊戲做爲一種軟件算是離系統開發最近的一種商業軟件了，而遊戲引擎也算是一種系統軟件。入行晚就要多接觸多理解才能趕得上你們的節奏啊，我一年內換了三個工做，來到如今這家公司的緣由是想參與一個從頭開發的項目。不得不說工做和生活仍是息息相關的，工資低、離家遠、項目對本身沒幫助，都有可能讓人沒法忍受。

　　下面進入正題，我作的是手遊服務器開發，目前手遊服務器的特色是：短鏈接、高併發、輕邏輯。和網站服務器的要求很是一致，以致於你們都用網站服務器稍微改裝一下就搞起了。咱們的server底層用的是端遊改裝的，簡單的ping-pong測試也能達到1w的併發(系統功能開發前的測試)，不過一旦加上系統功能邏輯，連2k的併發都達不到。因此這樣的底層只能做爲開發版本，過完年必須換血。如今有不少基於Nginx的網絡服務器框架，應該是很是適合手遊項目的。這個我也決定不了，暫且不提。

　　我是作邏輯開發的，慢慢來吧。幸虧手遊項目小，邏輯簡單週期短，我大概作了15個系統功能，並且具體實現比較符合我對程序的理解。爲了記念這個愉快的過程，我把整個項目開發的過程歸納一下吧。

　　項目開工以前的準備工做：

　　1.招人。整個項目週期內普通的團隊都要經歷人員流動的問題，項目負責人的性格和領導能力決定了團隊的氛圍。因此公司老大要先搞定項目製做人和程序主管這倆職位，而後是主策劃，先後端主程，咱們團隊的配置就是以這5人爲核心的。因此公司給他們分配的資源也最多，畢竟這個項目缺了其餘人就如同少了個工具，缺了這幾我的就像缺了胳膊腿同樣。因此沒辦法你們仍是努力成爲骨幹吧，7分技術3分運氣，畢竟遊戲行業還算是科技領域，技術水平業務水平仍是硬道理。

　　2.遊戲定位。一個項目總得有個吸引人的地方纔有吸金能力，咱們這個項目有個自然優點就是ip很火。可是光有一個好ip沒用，這個ip之前也作過頁遊和手遊，都石沉大海了，不知道是運營問題仍是做品差。最終項目製做人肯定的玩法是「第一人稱射擊類手遊」，融合卡牌遊戲和rpg的元素，說白了就是主角帶着小夥伴打殭屍的遊戲。

　　3.策劃總綱。這個就是考驗製做人的經驗和創新能力了，手遊不能作得太大，也不能太普通，要結合ip的特色進行取捨和創新。策劃總綱裏面指定了遊戲要完成的基本功能和基本效果，還有收費原則（坑要多要深，兼顧平衡）、吸引留存的方式（簡化註冊登陸，全部功能設計沒有理解成本但要有創新）、付費方式（簡化付費流程，多種vip等級）等。

　　4.項目工期。這個是程序主管的工做，根據工做量肯定須要多少人，工期進度計劃，對有經驗的程序來講問題不大。這個階段要把先後端選用的技術方案大體定下來，好比前端unity3d，後端C++ lua這種典型方案。而後是人員配置前端6~8人，後端3~4人，對於手遊項目已經比較豪華了（看水平。。）

　　基本人員到齊，項目工期已定，進入項目的前期Demo階段：

　　1.招人。仍是得擴充軍備，人齊了才能儘快進入穩按期。

　　2.運營宣傳。這年頭都是兵馬未動，聲勢先傳出去，給人宣傳個一年半載的纔看到廬山真面目。搶眼球的時代。

　　3.策劃分解。根據總綱分解出系統策劃、數值策劃、關卡策劃的工做範圍，而後出一個策劃案demo版本。

　　4.程序框架。先後端都要制定技術框架，前端unity3d比較薄弱，須要先解決技術問題才能出方案。後端比較成熟，只不過須要敲定用哪些技術，結合運營部署的要求給出部署服務器方案、開服合服方案、統一管理接口。這裏必須吐槽的有兩點：一是先後端開發分離，這會致使先後端開發不一樣步問題、先後端對接問題、不一樣人的對接方式不一致問題，可謂是萬惡之源，極大的拖慢開發進度。但也沒辦法，前端的程序不會C++，後端的lua接口又沒接上；後端的程序不懂unity，自己前端就有沒解決的技術問題；致使開始的時候無法按功能把先後端工做都分給一我的，只能兩邊配合，說白了仍是碼農水平的問題。二是server跨平臺，在我看來，除了通訊協議和語言標準是平臺無關的，其餘的東西都是平臺相關的，POSIX不過是一廂情願。跨平臺不是一件簡單的事情，可是人們都有這樣的願望，因此除非咱們已經有了跨平臺的支撐框架（好比QT對於GUI）不然千萬別自討苦吃。windows和linux版本的程序寫的越好就越沒有類似性，其實他媽原本就是兩套代碼。至於爲啥咱們選擇跨平臺捏，說出來讓人很無語，linux適合作server（免費+穩定），可是程序員不會在linux下開發，尼瑪仍是碼農水平的問題。我能說在linux下開發其實比在vs下更有效率嗎，vs除了complate和reflact是優點，其餘方面和linux比(工具鏈方面)甚至稍遜一點。關鍵的問題在於程序運行機制的問題，linux下是統一的思路：server程序作成Deamon進程（windows下通常不作成服務進程，多是很差管理），輸出日誌能夠用tail實時查看（windows下要打印到屏幕上一份），shell啓動和中止腳本完美配合（windows下能夠用腳本啓動中止，可是無法傳遞消息給程序，只能在cmd上Ctrl+C讓程序捕獲），程序宕機自動dump（windows下須要藉助SEH的特殊處理方式產生dump文件），等等問題吧。

　　5.流程和規範。

工做流程有：

　　　　每週總結會、每週週報、天天站立會

　　　　svn權限分配

　　　　從策劃草案-定案-程序執行-策劃驗收-測試版本-測試驗收的整個流程

　　　　每一個人的任務分配方式，任務時間評估

　　　　測試bug管理流程

制定規範：

　　　　策劃文檔、程序文檔、美術文檔、測試文檔等的命名規範和格式模版

　　　　前端代碼規範

　　　　後端代碼規範，這個是我出的，基本和google的C++規範差很少，作了點擴展，而後定了一套我以爲好的命名方案。我以爲比較成功的一點就是規定了代碼註釋必須用中文，說實話能用中文寫明白註釋的人都很少。

　　7.服務器壓力測試。首先要有一個可用的服務器底層，這個底層上面也說了，是從一個端遊抽出來的，僅保留網絡鏈接和數據庫鏈接兩個功能。而後要作一個壓力測試機器人，這個是我作的，初版的機器人是單機模擬一組機器人併發。由於要有界面反饋，我選用C#的wpf作的UI，確實很強大。第二版的機器人就牛逼了，我作了一個控制中心鏈接全部的機器人客戶端，而後統一下發配置和啓動測試。目前已是第三版，能夠用真實的客戶端服務器交互信息，在server端錄製交互報文（這應該在client端錄製，惋惜先後端是分離的，我改不了前端的代碼），而後做爲機器人的測試腳本作壓測。有了機器人，我把服務器的登陸部分初版完成（基礎邏輯就是玩家登陸的時候發送一個設備id到gateserver，若是已經緩存此設備id就返回對應的guid給客戶端，表示已經登陸。不然去db查找設備id對應的guid，若是找不到就建立一個guid綁定設備id，存入db；找到則通知gameserver從db查找玩家數據初始化，初始化完成後通知gate，再通知client）。

　　8.先後端對接。先後端都會完成幾個基本系統功能，好比主角系統、武器系統、副本系統，經過這幾個系統，實現系統功能和關卡玩法對接，前端表現和後端邏輯對接。對接成功以後算是基本的技術開發流程走通。而後是打包發佈apk和ios版本測試，因而乎Demo完成。

　　OK，通過第一個Demo版本，團隊配合也差很少磨合出來了，進入鋪量開發期：

　　上個階段由於處於磨合期，不少流程規範是逐步創建的，會留下不少問題。這個階段會把全部的系統重新設計一遍，按照流程逐個開發，直到完成一個各方面符合預期的版本。這個時候先後端開發是並行的，前端系統開發和關卡開發是並行的。這個週期比較關鍵，先後端都要出來一個邏輯上的框架統一管理全部模塊。前端須要管理場景、預設、美術資源、聲音、邏輯模塊劃分、怪物ai狀態機等等。後端須要管理client-gate-game通訊模型、日誌輸出、數據庫操做封裝、玩家管理（登陸、踢出、封號、解封）、配置文件管理、邏輯模塊劃分、公共數據管理、時間管理（定時器和計時器）等等吧。解決完這些問題以後，整個開發過程就順暢了許多。不過這個時候先後端配合開發的問題就暴露出來了，不一樣的人對先後端的分工看法不一致，最終致使了最後開發高級功能的時候各類接口不一致。以此爲鑑吧你們，要想先後端配和開發，必須有很強的預見性，對通訊協議和邏輯劃分都全面考量。對推脫責任消極怠工的員工陷害踢出（招人的時候幹嗎了）。

　　說說這個階段的完成的功能模塊，登陸-武器-副本-夥伴-主角-任務-揹包-簽到-競技場-排行榜-圖鑑-成就-vip-隊伍-商店-裝備-解密-傭兵團-GM-招募-修煉-信息提示-新手引導。。大概這些，可能有忘了的，不過不要緊，作系統功能的特色是，作10個和作20個差很少。有時候好幾個功能一塊作，都分不清誰是誰了。我以爲只要把系統功能背後的支撐框架作出來，或者找到一個適合表達的模型出來，剩下的就是往上面一套。說白了就是機制和策略分離的原則，系統功能會不斷添加，因此必須把新功能向目前的功能系統框架下正交分解，若是無法分解，就加強系統框架。

　　鋪量開發的後期是出問題的階段，由於開發模式的問題，先後端不少邏輯層次的劃分不一樣致使了開發綜合功能的時候不能統一處理。前端尤爲嚴重，好比前端的數據同步，A系統使用了B系統的數據，而B系統可能沒有從服務器同步數據，這時候A怎麼辦？向server請求B的數據顯然不對；在A系統加載以前加載B系統會致使登陸的時候要加載大部分的系統；登陸的時候分步請求全部系統的數據會致使登陸延遲或者server承載過大。目前的解決方案就是第二種，不過我以爲仍是第三種好點，只須要前端把登陸分兩步，一步是loading核心數據，第二步是彈出公告信息和玩家登陸後的收益什麼的，先進界面再說。整個過程實際上仍是在後臺加載數據（好像是windowsxp的做風）。再吐槽一個例子，A系統調用了B系統的功能，B系統界面關閉以後，A系統不知道B系統幹了什麼。這是由於每一個系統單獨開發的時候，都是依賴後臺通知的，前端系統互相之間沒有創建數據接口，致使這種簡單的增長一個數據接口或者回調接口就完成通知的事情，變成了問題。這就是先後端開發沒有邏輯上劃分清楚，致使前端只管表現，後端只管奶媽的狀況。

　　暫時寫到這裏吧。項目還沒開發完，和平臺對接的大戰還沒開啓，估計又是各類扯皮的問題了。