Hello everyone,  Happy New Year!

我國現出土文物中，最早的劍出現在殷周時期。

玄幻小說閱讀指導

總體構想：
　　當前游戲的總體發展趨勢是利用硬件提供的一切可能性來提升游戲的仿真性，而且似乎這是唯一吸引人的追求；因為當人們有了高配置的計算機以后，傾向于認為如果運行不能占用全部資源的游戲就是一種浪費，既然那些更加復雜、更加占用資源的游戲可以做到更好的仿真性，那么不用到這種計算機的處理能力似乎本身就代表了不好。這是廣泛存在的思維誤區。雖然我們并不能扭轉用戶的這種心理，而要善意地去理解；但是我們不能忽視這樣一個現實，那就是編制技術復雜的、充分耗用CPU及其他計算機資源而達到極高仿真度的游戲是非常困難的，對一個缺乏經驗和天才的游戲制作公司來說，尤其如此，象尚洋公司和他們編制的《血獅》就是這樣一個典型的例子。
　　并不是所有的用戶都有機器的迷信，仍然有相當多的玩家更加注意游戲的可玩性，而可玩性并不多取決于游戲的仿真度，而是取決于游戲的內涵。雖然這是老生常談的問題，但是真正注意到的公司并不多。那么什么是游戲的內涵呢？說法與解答都很多。我認為游戲的內涵就是虛擬世界和用戶的夢的結合，而且用戶的夢是兩者的重心所在。不關心當前的人們在想些什么，不做這樣的調查，是不可能知道用戶想要什么樣的游戲的。  

　　中國社會正處在轉型期，人們的心理狀態異常復雜。社會大眾對純文學的疏遠并不表明當前的人不需要一種心靈的撫慰，而是恰恰相反，這方面的供求缺口非常之大。如果有一類游戲能反映當今的社會現實，回應人們的內心訴求，提供一種嚴肅的思考過程，那么它在商業上的成功是可以期待的。

　　這一類游戲的重心將放在人性的刻畫上，主要通過文字和情節取勝，不需要太高的編程技術和機器配置，如果在劇本的編寫上能做到精益求精、盡善盡美，相信可以在市場中占有相當的份額。

 

游戲名稱：在鋼筋叢林中

游戲類型：單人/經營類

游戲行進方式：強制劇情+即時+回合

游戲主題：大城市中的個人奮斗

游戲角色：可選六人中之一人進行游戲。

　　角色1林強男24歲原在一家制鞋廠做行政助理，工資少得可憐，所學非所用，單位人際關系復雜，心情苦悶。此時從大學起就相愛的戀人提出分手，絕望的主人公決定背水一戰，離開原來的環境，到外面的世界去闖蕩一番。目標是實現自我價值，找到真愛。
（特殊失敗條件：回原單位、到42歲還未完成目標、）

　　角色2李蘭女23歲在某個廣告公司工作，本來工作很令人滿意，但其上司不斷對她進行性騷擾，且這個上司在城市廣告界有絕對的威勢，李蘭被迫離開這個公司之后，她無法在其他廣告公司找到職位，只能轉行。目標是真正擺脫她討厭的上司的糾纏并且找到真愛。
（特殊失敗條件：離開這個城市、到32歲還未實現目標）

角色3姚奉男37歲某紙箱廠下崗職工，學歷很低，沒有積蓄，上有病弱的老父，下有還在讀書的14歲的女兒。為了一家老小的生活，不得不自謀出路，開始自我創業。目標是存款達到20萬。
（特殊失敗條件：無）

　　角色4陳小勇男18歲某商貿中專畢業生，在學校沒有學到任何實用技能，只知道吃喝玩樂。喜歡同班的白楊，但白楊一點兒也看不上他。受此刺激，他決心好好地干出一番事業來。目標是成為千萬富翁，并且娶到白楊。
（特殊失敗條件：到21歲時，聽聞白楊已經嫁人）

　　角色5張娜若女19歲美麗的鄉下妹，隨在建筑工隊打工的男友到城市，為一戶人家做保姆。進了城以后，她的觀念有了很大的變化。她不滿男友楊火對她提出的性要求，以及以后婚后自己可能的處境，與他分手。雖然如此，她還是愛著他，期待著能在城市里以另一種方式與他重逢。
（特殊失敗條件：答應楊火的要求，道德指數低于20）

　　角色6顧蕓女22歲相貌一般，在電腦公司工作。她在網上認識一個男友，開始了網戀。兩人都是真心相愛，但又恐懼著網戀的破滅，一再推遲見面的時候。對顧蕓來說，能和男友現實地相愛下去，是最關鍵的事情。目標是美夢成真。
（特殊失敗條件：男友不再愛她）

　　共同失敗條件
　　生命值為0、信心為0

游戲模式
　　每個角色在游戲開始后都將進行一段強制劇情模式。強制劇情模式中含有少量的分支選項，玩家不同的選擇對應著最終不同的結局。完成劇情模式以后，每個角色以一定的身份，一定量的資金在城市中為了達到自己的目標，開始自己的奮斗。這時游戲的模式改變為象《臥龍傳》那樣的即時模式。角色將進行各種各樣的經營活動，自我培養。當角色的某些數值達到劇情設定的時候，會再穿插劇情模式。這是一般經營活動和養成而言，角色要完成最終目標，還必須要達成相當數量的特定目標。游戲將采用回合制的方式，讓玩家就某個特定的目標和電腦在某個劃定區域里進行周旋。這也是這個游戲唯一需要編制機器AI的地方。

　　虛擬的城市
　　本游戲設定在某一個城市內部進行。游戲將展現完整而細致的城市環境，包括建筑、機構、人。

　　建筑
　　斜45度的假3D造型，比如象《模擬城市2000》的場景，但比例應該更大，由手工繪制，能夠看出建筑物類型。在操作上，如果能用鼠標點選建筑的方式進行一般移動，將會很方便玩家。

　　機構
　　政府行政機構、商業組織、金融機構、服務行業。完全模擬一個大城市的這些情況是完全不可能的，但數量上應該盡量多，主要是提供給玩家選擇不同的奮斗道路。

　　人

　　劇情相關人物、一般人物。預計有姓名者總共300人以上。

　　角色的數值體系

　　角色的數值體系對經營類和養成類游戲的成功非常關鍵。本游戲角色的數值包括：
　　一類：現金、存款、票證
　　二類：信譽、生命、信心、運氣、道德
　　三類：各種技能經驗等級

　　多結局
　　在強制劇情模式里，玩家不同的選擇，在即時模式里的成果，以及在回合制模式里的勝敗將會有多種不同的結局。

　　仿真性
　　本游戲的仿真性不在游戲畫面上，而在于各種數值的真實性與行進手段的真實性上，同時還必須注意它的游戲性。如何把三者有機地統一在一起，將是這個游戲成功的關鍵。

　　結語
　　本游戲應該注意劇本編寫中的人性刻畫、情節曲折；數值設定上的平衡合理；美工上的特色風格；操作界面的友好。

　　嚴格地說這個游戲策劃并不是一個mud，但是我認為要改成mud也是很好的，期待能打動你。

經典游戲制作教程

peng


1.游戲制作的主要流程
-------------------------------------------------------------------------------

電腦游戲開發小組中的任何一個人（這個角色通常有策劃擔任），只要有了一個新的想法 或念頭，就孕育著一個新游戲的誕生。在這個創意被充分討論之后，再加上對其操作過程的趣味性及市場銷售的可行性的預測等因素的準確判斷，一個完整的策劃方案才可能產生。在經過充分的討論后，策劃人員必須將討論的重點寫成文字，也就是提出完整的策劃方案，經決策者同意認可后，才能進下一步的工作。這份策劃方案就像一部電影的劇本，它必須完整地涵蓋整個游戲的故事、流程、內容、方式、游戲畫面、角色造型、 場景規劃、人工智能、硬件配備、市場評估等。對整個游戲過程的詳細描述及實施規劃都應 記錄在案。 當進入創作過程之后，策劃還必須隨時和美術設計師和程序設計員保持聯系，以免游戲程序的編寫失控。策劃應能對游戲設置的內容與精神了如指掌，與各個小組及時溝通，并且控制整個游戲制作的進程。



2.游戲設計基本論
-------------------------------------------------------------------------------   

   要設計一個游戲，首先你必須要確定幾個重要方針，第一是你要設計的游戲是屬於那一種類型，第二是時代背景，第三是模式，第四是程式技術，第五是表現手法，第六是市場定位，第七是研發時間，在掌握上述七個方針之後，你就可以再做詳細的規劃內容及調配資源，那麼何謂是七項方針呢? 筆者以范例來說明之!
一、類型：
   所謂的類型是指這個游戲所著眼的一個游戲方式，通過這個方式來使玩者達到娛樂的目的，這個游戲方式有專有名詞來各別予以命名，茲如下述：

(1) RGP角色扮演：
   這個類型的游戲以通過故事劇情牽引來使玩家能溶入主角所存在的一個世界，這類型態的游戲多半透過戰斗升級系統及人物對話的方式來一步步完成設計者所布下的劇情路線，最具代表的作品有日本史克威爾所設計的 "太空戰士系列" 及國內大宇資訊所設計的"仙劍奇俠傳"，當然還有很多部作品例如"神奇傳說"等也是此中的佼佼者。
   在RGP的類型中，在近幾年來又分支了幾個類似的型態，例如說Blizzard的"暗黑破壞神"Dirblo"被定位為"動作RPG"，因其動作成分相當高所至，而"神奇傳說"、"超時空英雄傳說"則被定位盡"戰略RPG"，只因戰略成分比重較高所以又有別於傳統RPG。

(2) SLG戰略：
   談起戰略游戲，大家最耳熟能詳的應是日本光榮公司所出品的"三個系列"，KOEI的三國志風靡東亞，從一代進化到現階段的六代皆為玩家們所津津樂道，而所謂的戰略游戲則是透過經營→戰爭→擴大領土三個手段來蠃得游戲最終目標，一般而言動態成分少，最較偏重於花費腦力的游戲，但從WestWood的新型態戰略游戲"沙丘魔堡"問世之後，戰略游戲也有了重大的分野，一是以KOEI代表的三國志系列被稱為回合制戰略游戲，一是以WestWood代表的C&C及Blizzard所代表的魔獸爭霸被稱為即時制戰略游戲，和回合制所不同的是，即時制擁有較多可由玩家與電腦互動的機會，比較不花費腦力，所進行的 方式是建設→生產→攻擊→殲滅，在業界有句俏皮話是這樣說的：「玩回合制游戲像是自己當了個大將軍(元首)，運籌帷幄決勝千里之外，而玩即時制游戲則像是個士官長(部隊指揮官)，只能一味的打打殺殺」由此你可以了解到這兩個型態的異同的了。



(3) ACT動作：
   所謂的動作游戲其實就完全靠玩家的反應來做過關的條件，較有名的像DOOM、古墓奇兵、QUAKEⅡ 等，在動作游戲中也分支了相當多的類型，例如快打旋風、鐵拳Ⅲ等被定位為格斗型態，主要游戲方式就是二人到四人互相對打一直到分出勝負為止，而DOOM、古墓奇兵則被定位為3D動作冒險游戲，主要目的為殺敵闖關，再來像阿比逃亡記、黑暗之心被定位為橫向卷軸游戲，游戲方式就是以攻擊跳躍等動作來走過一連串的關卡，表現方式多為2D卷動畫面的方式在進行，再如飛龍騎士、極上瘋狂大射擊則被定為動作射擊游戲，游戲方式就是閃躲射擊沖過火網進而殲滅守關魔王為止，這些分支型態有共 通特點卻又那樣的不同，這也是動作游戲吸引人的重要原因。

(4) PZL益智：
   這類型的游戲以趣味性的思考為游戲的主軸，內容可以包羅萬，思維模式也可朝物理性及邏輯性方向著眼，具代表性的是大宇資訊的"臺灣十六張麻將"、"大富翁"、"倉庫番"等，而棋盤式的思考方式著名的有"決戰中國象棋"及光譜資訊的"五子棋大師"等，這些游戲入手容易且不分男女老少皆喜歡的特性，使得益智型態的開發較有市場，成本也較低。

(5) ADV冒險：
   冒險游戲的內涵多半脫離不了解謎的成分，是的!這類型的游戲讓玩家抽絲剖繭的找出設在游戲背後暗藏的謎底，以順利完成游戲，具代表作有惡靈古堡、異星搜奇、幽魂等，這類型的游戲年齡層較高，比較不適合國內廠商來研發。
   當你在構思一個新的游戲企劃時即應預先想的所屬意的類型，然後才進行下一步的計劃，一般而言國內市場接受度最高的莫過於 RPG角色扮演類型，這也是為何國內廠商會如此的大力研發RPG型態的游戲。

二、時代背景：
   對於游戲美術來說是一個很重要的方針，因為決定一個時代背景所意味的是資料的搜尋工作方便與否，與美術人員在制定造形時需依據的范例；以國內市場來說多半能接受中國古代時代背景，基本上時代背景有好幾種，例如說WestWood的紅色警戒架構在公元2000年左右的未來，而魔獸爭霸則定在虛幻的歐洲中古世紀中，三國志定位在漢朝末年，星海爭霸架構在外太空世界，軒轅劍則定在春秋戰國時代等。
時代背景絕對是企劃人員在第一階段規劃整個游戲時已先決定好了，如此美術人員才能放心的去搜集資料。

三、模式：
   當決定好類型及時代背景之後，再來就開始要去構思游戲中所要呈現的模式，如假設你的背景訂在古代中國，而類型是定為即時戰略，這時你必去思考出游戲內容的進行方式，可能你的游戲需要生產的因素，這個因素是什麼? 可以是糧食、礦產及木材，也可以是火山能源、石油、太陽能或天然氣等，隨著你故事情節上的需要而去制定項目，在作戰方式上你所設計的模式可能會去考慮到地形因素、天候因素及資源因素，而且會大量運用到各種戰術及攻擊方法等，因為如此所以同一種類型的游戲雖多，但模式上卻各有特色各有偏重的游戲路線，也各自聚集了擁護者，這就是模式設定的一個重要性，切記千萬不可去抄襲他人所定的模式，因為這樣一來，當你所設計的游戲完成之後，眼尖的玩家們會把你的產品以過時抄襲為由而棄如敝履，這在這劇烈競爭的國內市場而言是無法存活太久的。

四、程式技術：
   無論你對一個游戲想得多好，架構設計多龐大，如果程式人員本身的技術無法配合的話，那其實一切還是流於空談，所以在設計一個游戲之前必要先去徵詢程式人員的意見，在現在這個環境中不僅程式人員要會Windows98及Wi-ndows NT相關技術，一個完整的系統分析及系統規劃是不可缺少的，如此可以避免掉在程式中不可預期的錯誤出現，而且在一個游戲設計中最好有二個程式人員在運作，一個負責內部程式 (游戲核心引擎) ，一個負責外部程式(介面程式)，這樣方可發揮完整的戰力。

五、表現手法：
      在這個環節中，企劃人員、程式人員、美術人員要做完善的溝通及討論，一般我們知道大部份的電腦游戲是256 色的系統，在這些游戲中對於色盤的控制有相當嚴苛的要求，為了達到最好的視覺效果，美術人員通常會向程式人員要求多重色盤的資源，而程式人員則會考量到切換時的狀況及記憶體配置是否能完全充份，在系統上的問題確定之後，企劃人員會提出呈現效果的建議，例如說爆炸效果的表現方式，由內而外擴張到消失的火焰激烈型或包容大量煙霧的燃燒型，這要由企劃人員依故事內容來給予定義，同時以物理性邏輯給予美術人員一個建議，再由美術人員前去繪制。
   還有一個例子，以"C&C之紅色警戒"與"AGO Empir世紀帝國"的海岸來說明，在"AGO Empir 世紀帝國"的海岸表現是靜止的，海水不會流動，最多只有魚在海中央跳躍，而"C&C"之紅色警戒"的海岸表現手法是會流動的，但海中沒有任何的特異之處，這兩種表現手法各有各的好處及考量，但以筆者而言仍較偏愛"C&C之紅色警戒"。
    游戲內容的表現手法通常伴隨著同類型游戲間的相異處而有不同的評價及支持者，而不光是美術效果的表現手法，企劃人員構思的游戲玩法及程式人員的程式表現都有密切的關系。

六、市場定位：
   不論你所設計的游戲構想如何的好，如果你沒有去清楚的定位出你的市場走向，那麼到時制作完成的游戲軟體可能會面臨到銷售不佳的窘狀，所以在設計游戲之前你得知道你所定位的族群在那里，從下表中你可作一個市場定位的叁考：
年齡層               教育程度適合的類型內容

7~12歲 國小動作、益智較多趣味性、教學性
13~18歲 國中、高中動作、益智、 較多思考性質、圖形精美化同 角色扮演、戰略時又較多反射
19歲以上 低知識水平益智、動作較暴力及冒險、趣味性質，操 作簡單
19~30歲 大專、大學以上角色扮演、戰略富含多重思維性，可以影射周 、冒險、模擬、 遭事物，解謎及創造性運動 

七、研發時間：
      這是企劃人員在初步規劃中的最後一個項目，針對上述的制作方針你必須對美術人員及程式人員安排一個完整的SCHEDULE，從這個SCHEDULE中去研判律發時間，從企劃的角度來說，為了不使良好的點子被其他游戲公司搶先推出，同時也要避免推出後模式已落伍，一個游戲的研發最好在一年內，最多不可超過18個月，以成本控制的角度來說比較符合獲利標準。
       假設你規劃這個游戲需要一年的時間，那麼你就要去區分出美術制作時間 (第一線)及程式制作時(第二線)間的差異，并考量推出DEMO 版及游戲完成的時間，在適當時機打出游戲知名度，為游戲銷售上打下一記商機。

制作流程
   一個游戲的制作如果不能充份控制整個作業程序，那即有delay 的危險，大家都知道游戲軟體delay對於銷售上的影響會有多大，所以如何盡量避免de-lay是每個游戲設計者應極力去避免的，而要去避免游戲開發作業上delay的情況最重要的是嚴密控管作業流程及計劃表。
   那麼究竟游戲制作流程是一個什麼樣的情形呢? 首先企劃人員在執行制作的前一個月即要定出企劃大綱及搜集可用資源，并經程式人員及美術人員確認後開始執行，我們以一個即時戰略的游戲來說明，在制作分期程式人員即投入地圖編輯器的撰寫，而地圖編輯器的邏輯設定要由企劃人員先期規劃，然後程式人員才根據企劃人員的規劃而進行程式寫作。
   在此同一時期美術人員即開始分工合作，一般一個游戲工作小組會有四位美術人員，他們分別負責造形、人物動作、介面、地圖四個部分來制作，但這只粗分法，國內游戲公司較常使用這樣的組合，在國外美術人員分為造形、人物動作、介面、地圖、片頭、過場、後制分鏡、場景等九大部份，每個部份皆可能都有二人以上在作業，并有一名監制在執行風格及水準的品質控管，這些人統一由後制人員來與程式人員做交圖及配合修圖等溝通上的交流，所以說後制作美術人員的成敗實關系到整個游戲品質的高低。
由於程式人員在設計地圖編輯器時需要利用到一些圖素來做測試，所以地圖圖素設計人員要先一步繪制出程式人員所需要的圖素，
   在程式人員測試通過之後方可進入大量生產的階段，由於地圖編輯器的設計者多半直接負責游戲引擎的制作，所以在初期企劃人員便開始著手人工智慧AI的邏輯判斷作詳細的敘述，以期在程式人員撰寫地圖編輯器之後能立即作人工智慧AI的撰寫，而在此同時負責撰寫介面的程式人員亦與負責介面設計的美術人員作密切的配合，開始著手制作各個介面，因為介面不僅在游戲中是一個主司控制整個游戲的操作盤，同時也是一個游戲的外觀，一個擁有優良創意的介面是很受 玩家喜歡的。 在測試地圖編輯器時，程式人員亦需要利用移動物件(人)來測試地圖上的障礙物判斷及最短路徑搜尋法，所以設計人物動作的美術人員在此時要先去做出一組人物動作供程式人員作測試，待程式人員把地圖編輯器制作出來之後，人物動作設計的美術人員則只要不斷的做并不斷的把圖給程式人員即可。




3.游戲設計十誡律
-------------------------------------------------------------------------------


Travis S. Casey


1. 編寫你所喜愛的游戲
不要人云亦云。只要你和你的朋友喜愛就可以了。 同樣道理，不要編寫某個游戲主題僅僅因為它當前流行而已。編寫你所喜歡的題材， 這樣才能激發你的熱情。

2. 經驗是最好的老師
學習游戲編程最好的方法就是閱讀大量的游戲程序。玩和分析這些游戲，然后設計 你自己的游戲或擴展游戲。我最主要的經驗都是角色扮演類游戲，我的許多游戲范 例也來自它們，但思路卻適用于所有類型的游戲。 我閱讀過大量的RPG類游戲，粗略算算大約有七十多個。其中大部份我都玩過，精 通四十多個。不但玩和精通這些游戲，我還分析它們。是什么使得這些游戲好或者 不好？我如何修改它？哪些部份表現的出色？哪些部份不盡人意？為什么？ 玩和分析過其它游戲后，我把這些知識用于我自己的游戲。比如在“超級英雄”類 游戲中，“斗士”和“英雄”在使用了“指數特性的換算法”取得較好的效果。如 果我想設計“超級英雄”類游戲時，我就知道“指數換算法”很可取。這樣的分析 能給你許多被驗證過的思想用于你的工作中。

3. 測試、測試、再測試
測試你的游戲，盡可能多次的玩。最好當你不在場的情況下，讓別人來玩，過后再 告訴他們。(讓別人當你不在的時候玩游戲稱為：“盲測”) 還有，推敲你的規則。考慮假設情況，解決概率復雜性。比如，如果你正在設計一 個RPG，試著找出平均人們用弓箭從一米、五米、十米、五十米和百米范圍內射中 人形大小目標的百分機率。對于二戰游戲，檢測你的監視器和解決一個小步兵摧毀 一輛坦克的機率。反復計算在不同的條件下，如：不同的地形、夜間等等。這將有 助于你找到在數學中出錯的地方或建立了一個不好的假設。

4.學習背景知識
如果你想編一個中世紀的神奇游戲，就要去讀中世紀的文學和歷史。讀有關魔法的 書及現有的中世紀傳奇游戲。對其它類型的游戲也是如此，如果你想做一個越南戰 爭的游戲，就應去讀有關戰爭的正史及野史，特別是戰略、戰術的分析。 所有的背景知識可以用于幾種途徑：首先，能幫助你創造出逼真的角色。另外它能 減少你在術語及背景知識方面，出現重大錯誤的可能性。當然，資料應該本身就很 有趣。如果對于所要學的都不感興趣，那為什么還要編寫這方面的游戲呢？

5. 正規教育
選一門介紹概率和統計的課。試著讀一些游戲方面的數學理論。你可能覺得那沒什 么用，但它能幫助透視算法的掌握。斟酌你的英語(或其它你發表游戲所用的語言) 當游戲描寫得好的時侯，就更容易學，至少不能有大量的語法錯誤。 如果你想制作電腦游戲而沒上過任何編程課時，不妨學幾門。你可能學不到什么編 程序的具體東西，但一門好的課程可以教會你如何組織程序使之更容易維護和發現 錯誤。 建立一個“參考文獻庫”，它是一系列和你所制作游戲工程相關的游戲、書籍資料。 當你清晨三點突發靈感而圖書館卻已關門的時侯，它將是非常有用的。

6. 抽取些時間
一個游戲就像孩子，當它剛出生時，它的父母總認為它是完美的。從你的游戲中抽 出些時間去得到一些新的觀點，避免都耗在上面。一遍遍的重復這一過程。

7. 保留記錄
確定你有一份以上的游戲拷貝。如果你是在電腦上輸入的，就各保持一份硬盤和軟 盤拷貝，另外再打印出一份清楚的最近版本(如每月打印一份，如果你干得快的話每 星期打印一份)。你不會覺得拷貝太多，因為你的好朋友們會來向你借或者想擁有拷 貝。而且這些拷貝能夠減少你因為硬盤癱瘓或丟失筆記本等原因造成的丟失機會。 同樣道理，保留舊版本的拷貝是有好處的。如果你在游戲測試時發現新的辦法還不 如舊的好，而你卻已將舊版本的扔掉了，這該怎么辦？至少保留一份最后版本之前 的拷貝，同你當前版本的拷貝放在一起。

8. 其它注意事項
優秀的規劃和書寫是好的，但精美的視覺化說明對你的銷售大有益處。如果你要自 己動手，就學一些桌面出版，或找一些現成的插圖(比如：剪輯藝術或政府出版物) 或找別人幫你畫些插圖。 找個從事印刷業的人，和他探討一些盡可能廉價的方法。低價格可以有助于銷售， 低成本則有利于你的收益。

9. 記住這只是個游戲
不要因為制作游戲而忽略你的現實生活。如果有人不喜歡你的游戲，別介意。不用 擔心別人竊取你的創意。記住第一條誡律，從你的所做中得到樂趣就行了。

10.沒有第十條了 :-)

另外，這里有一些來自湯姆(“棱鏡游戲”的主持者)的額外忠告，感謝湯姆！：
1.不斷的創新是非常好的。如果你游戲中的所有東西都令人似曾相識，就好像是 偷來的。如果所有東西都與眾不同又會讓人感到陌生。常見題材單一獨到的構思是 好的，但會使得你的游戲看來像個“變體”，而兩個熟悉題材精明的創意則會使游 戲有新鮮感同時容易上手。因此不要試圖徹底從新發明某樣東西，而應把當前所擁 有的主意清晰化、簡潔化的用于擴展關鍵觀念的創新和趣味方面上。
2. 修正和雕琢你的游戲創意。測試不僅僅為了清除游戲和規則介紹中的錯誤，而 且就像一個討論會，對照他們已經取得的東西，游戲設計師能夠發現什么是真正所 要表達的。如果你將測試留到最后，這一發現將對你沒有什么好處。如果你進行早 期的測試和經常從眼前試著發現這一游戲真正要表達的，你就能常常很大的改進這 一游戲。 “ Alpha”測試就像在問：“是否真有這個游戲？”“我得到它了嗎？”“ Beta ” 測試看來在問：“是否用了最好的方法達到這一效果？”，“這是游戲的精煉嗎？ 或者它是否能被簡化或刪除？”“是否所有主要的游戲系統協同工作，給予了我所 期待的游戲體驗？”“ Gamma ”測試又像在問“如何才能改善游戲的收支平衡 和介紹呢？”許多設計師停留在Alpha(生產一個吸引人但卻是次品的游戲)之后或 者從Alpha直接到Gamma，跳過了Beta(生產一個好的但還不夠完美的游戲)。 通常有必要靠你的親密朋友/游戲小組及早的進行足夠的批評性分析，幫助你發現如 何才能改進一個已經相當不錯的游戲。

我的一些其它建議：

在我制作游戲過程中，從沒有清晰明顯的測試“階段”。我傾向于每個階段都做一 點。我修改一些系統，拋棄或替換一部分，改善其它的收支平衡和介紹，差不多是 在同時做的。這些部分來自于我所從事的主要游戲類型的設計-宇宙類RPG，你必須 在一個時間內干一個部分的事情。 關鍵在于去尋求達到你最好的作品。用不同的方法嘗試，直到找到適合你的方法， 然后用它鉆研下去。



4.游戲的劇情
-------------------------------------------------------------------------------


游戲劇情的重要是不言而喻的,特別是RPG游戲,相信廣大玩家對"仙劍奇俠傳" 熟得不能再熟了,這個游戲以劇情取勝(他的音樂也相當不錯),各大媒體對他的 評價也都是以劇情為主,這個我就不多說了.
我也曾看過許多文章提到劇情的重要,這些文章說的相當好,相當有價值,但基 本上講述的是劇情的要點及注意事項.而我將從另一個方面去分析游戲的劇情.
游戲的劇情是游戲的靈魂(當然除少數不需要劇情的游戲,如體育類,賽車等), 游戲通過各種各樣的方法讓玩家融入到設定的劇情上以打動玩家,但如果游戲 的劇情不吸引人,那么無論游戲的表現手法有多好也不能達到目的,但是怎樣 的劇情才吸引人呢.
事實上中國與外國玩家有著很大的文化差異,這一點可以從各地所出產的游戲 上看得出來,歐美的游戲大多重視人物與場景的直實性,看上去就像電影,而東 方的游戲普遍追求漫畫式的效果.但這兩種風格哪種適合我們呢?答案是兩種 都適合.不要忘記我們的玩家基本上是青年一代,對新事物的接受是相當快的, 對歐美的游戲我們的玩家接受得很快,從這可以看出國外的游戲制作是相當出 色的,就拿我自己舉個例子,前兩天我得到一款"生化危機2"的游戲,游戲開始 的動畫可以說是扣人心弦,并且很好的襯托出了主題.而第二種風格的代表作 品就是"仙劍"了.
游戲所要表現的內容必須能夠被玩家接受,而且還要有創新,這樣的劇情才說 得過去.現在我們有一個很好的觀察點,那就是電影,外國的制作精良的大片 擠進中國后給我們的沖擊多么大,而中國傳統題材的作品也給我們留下難忘 的印象.
我們不得不承認,在技術上我們與國外的游戲制作公司相比還差了一截,這 使得許多很好的題材我們不敢用,因為以現有的技術還不能很好的將他表現 出來,如果勉強還可能會起反作用(這是有例子的).
在這里我只是起一個開頭的作用,什么樣的劇情適合大家也不是一下能說清 楚,希望廣大游戲愛好者能積極討論這個問題,這也是我們中國游戲業現階斷 的一個重要的有待解決的問題.



5.角色扮演游戲的升級系統研究
-------------------------------------------------------------------------------




在一般的角色扮演游戲中，人物的成長是一件相當重要的事，無論是角色扮演游戲或是目前熱門的策略型角色
扮演游戲（簡稱RSLG），這些升級系統都是游戲的一個重要部份。不過在一般的角色扮演游戲中，人物的升級
以及成長卻有著很多種的處理方式。在本文中，筆者將為各位介紹各種角色扮演游戲中常用的升級方式，并且
分析各種作法的優缺點。

在一般的角色扮演游戲中，最常用的升級方式就是亂數式的成長方式。在這種模式中，當一名角色獲得升級的
時候，程式會使用亂數來決定升級的各項指數，也就是說所有的升級數值都不是在控制中，而是依據一個亂數
表來決定提升的數值。這種升級的方式是如何處理的呢？

當人物到達升級的標準時，就會進入處理升級的副程式中，在這個副程式中程式會依設計者所定出的一個亂數
范圍，來計算出這名角色所得到的升級指數，然後將這個數值加到需要增加的屬性上。

在這種亂數決定升級的情況下，玩者所能夠獲得的升級數值，完全是由設計者訂定的范圍中求出，無論是升級
的上限或是下限都是在這個范圍內，絕對不會有意外的情況發生，就算是設計者如何提高上限與下限，都不會
改變這些。這種作法雖然可以讓設計者很輕松的訂出升級的上下限，但是卻不能控制升級時的不利因素，那就
是亂數的成份實在是太高了。若是有一名角色因為運氣不好一直只有獲得下限的升級數值，那麼它可能會比一
個一次就獲得上限升級數值的角色要弱。舉例來說，當這個亂數的范圍是一到五的時候，若是角色甲和角色乙
分別獲得上限和下限的升級數值，那麼會發生以下的狀況：

┏ ┳ ┳ ┓
角色甲 角色乙
┣ ╋ ╋ ┫
ＬＶ１ １０ １０
ＬＶ２ １５ １１
ＬＶ３ ２０ １２
ＬＶ４ ２５ １３
ＬＶ５ ３０ １４
ＬＶ６ ３５ １５
┗ ┻ ┻ ┛

各位看看上表，是不是可以看到角色甲在第二級時的數值就已經和角色乙第六級的數值是相同了。由於亂數式
的升級方式會有這種不公平的情況發生，因此常會使得玩者的努力需要有一些運氣的成份在里面；若是運氣不
好，可能原本的努力都無法發揮所要的功效。

由於亂數式的升級方式有這樣的缺點，因此有兩種不同的改進辦法，首先就是百分比制的升級方式。在這一種
辦法里，角色在升級的時候還是使用亂數來進行，不過在每一個數字的出現比例上卻做了一些調整。例如同樣
的升級的范圍還是從一到五，但是每一個數字的出現比例調整如下：

┏ ┳ ┓
數值 出現比例
┣ ╋ ┫
１ １０％
２ ２０％
３ ４０％
４ ２０％
５ １０％
┗ ┻ ┛

各位從上表中可以看到，在這一種處理方式上，每一個數字出現的比例做了一些調整。原本的亂數式中，每一
個數字的出現比例都是相同的，就以上面的例子來說，每個數字出現比例是百分之二時，因此上限和下限的數
值比較容易出現，發生不幸的情況比較多；但是在這樣子調整後，上限和下限的數值出現的機會就減低了不少
，會發生不幸的情況就降低了。

雖然這樣的作法可以降低不幸的發生機會，但是還是無法完全的克服所有的狀況，因為還是有可能會發生相同
的狀況，使得玩者陷入屬性不佳的情況中。因此另外一種改良的方式～修正值升級方式就這麼出現了。

其實修正值的升級方式和原本的亂數處理法在計算的時候是完全相同的，只不過是它在升級到一個程度的時候
，會來做一次計算并且取出一個修正值，以免玩者因為運氣不好無法達到升級的功效。

在這種作法上，上半部和亂數式的做法完全相同，唯一的不同是下半部的副程式。而這個副程式的作用就是在
幫一些升級時運氣比較不好的玩者取得一點修正值。

我們就以前面所說的升級的數值是從一到五來做個例子，讓玩者每升五級時就可以取得一點修正值。因此若是
一名角色在五次升級中都只有獲得一點的升級值，那麼目前它的數值就是：

10 + 1 + 1 + 1 + 1 + 1 = 15

不過在我們的升級表內中等的數值是三，因此當角色升了五級之後，應該可以獲得以下的數值：

10 + 3 + 3 + 3 + 3 + 3 = 25

這麼說來這名角色因為前五級的升級運氣不好，因此少獲得了十點的升級指數，所以我們就在這一次把這個缺
少的數值以修正值的方式補足，從修正值的計算式中可以得出：

25 - 15 = 10

就將這個數值加到角色的屬性中，讓角色不會因為運氣太差而有不利的情況。若是角色在升級中都獲得比較高
的數值，那麼修正值就是負的，也就表示不需要有修正值的存在了。

這種作法完全是為了不讓玩者因為升級時運氣不好使得屬性太低，因此只能算是修正部份數值的作法，雖然不
能完全解決亂數式的問題，但是可以將不利的因素降低，因此在某些游戲里的確有采用這樣的作法。

除了亂數式的作法外，還有一種是表列式的升級方式。在這種升級方式中，每一名角色的升級數值都是設計者
已經訂好的，完全不會有任何的變動。它的好處是設計者可以完全掌控所有的升級狀況，但是相對的這樣子的
表格需要占掉較多的程式空間。

舉例來說，某個游戲若是采用這種升級方式，那麼在它的記憶體中就需要有這樣子的升級表格。若是游戲中有
七項屬性會獲得升級，等級共有一百級的變化，那麼基本上它就需要有七百個不同的數值表放在程式中。若是
一個數值用了兩個位元（BYTE），那麼就需要用到1K左右的記憶體。如果說游戲中有四名角色，它們升級情況
又都是不同，那麼占掉的記憶體就將近有5K了。這麼算起來各位可能覺得不會很多，但是當這種資料越來越多
的時候，記憶體的消耗也就越來越多，使得程式的空間也越來越小了。

由於表列式的作法會使得升級的情況比較單調，因此大多數的游戲并不愿意采用這種作法，再加上這一類的作
法對於記憶體的占用空間也比較高，因此如果不是必要，大多數都不會用這種作法。

除了以上這些作法之外，還有一種就是指數型的升級方式。這種作法其實就是表列式的改良，因為它將升級的
表格簡化成一個叁數，在升級的時候就依這個叁數來計算能夠獲得的升級值。現在我就舉一個例子來示范。目
前有一名角色的屬性以及升級指數如下：

o 生命：１０ 生命指數：１０
o 法力：１０ 法力指數：１０
o 力量： ３ 力量指數： ２
o 智慧： ２ 智慧指數： ２
o 反應： ２ 反應指數： ２
o 體能： ４ 體能指數： ２
o 運氣： １ 運氣指數： ３

那麼當他獲得升級的時候，程式就會依這個升級指數來計算升到下一級時的各項屬性值。因此在升了一級之後
，各項屬性的數值就是以下的數字：

o 生命：２０
o 法力：２０
o 力量： ５
o 智慧： ４
o 反應： ４
o 體能： ６
o 運氣： ４

用這種作法，在程式內不需要復雜的升級屬性表，只需要幾個簡單的叁數就可以，若是能將各項叁數之間的關
系加以變化，并作一些運算，那麼可以使升級時的變化更多。舉例來說生命的增加和體能有關，或是法力的增
加和智慧有關，那麼在計算起來時會有比較多的變化，使得整個升級的表現不會太單純。

以上這些作法大部份的變化程度都不會很多，沒有辦法表現出一個人的成長情況。就像我們有時候會形容一個
人「大器晚成」或是說他「小時了了」這樣子的情況都不能表現出來。因此後來又有一種成長曲線的升級方式
。在這種升級方式中，我們首先要訂出幾種不同的升級情況。像是：

A. 平衡成長
B. 大器晚成
C. 小時了了

要達成這種效果，我們需要將升級的總等級數分成幾個階段。我們以一個可以升到一百級的游戲來說，將每十
級分成一個區塊，就可以訂出這三種成長情況各要給它多少的數值。

其實這種曲線式的升級方式，在處理上和指數式的作法差不多，只不過指數式的作法一個人物每一種屬性只會
有一個數值，這個數值是不會改變的。但是在曲線式的作法中，會依不同階段有不同的升級指數，才可以造出
不同的成長情況。我們就以一名「大器晚成」的角色來說，這一類的角色在開始成長的比較慢，但是當人物成
長到一個階段後，成長的速度就會加快，因此我們可能在前兩個階段只給他們一點的升級指數，後面幾個階段
再給他們較高的升級指數，使這名角色會在游戲後期升得比較快。

反過來說，若是要設計一名「小時了了」的角色，那麼我們在初期可以給他較高的升級指數，但是到了後期就
要給它較低的指數，如此一來就可以表現出這樣的情況。

事實上，在游樂器中的「光明與黑暗續戰篇」就曾經用過這一種作法，使得游戲中的每個角色都有各自不同的
特色。特別是有些屬於大器晚成的角色，曾經因為初期成長的速度太慢而被玩者拋棄，但是後來知道這名角色
的特性之後，再回過頭來訓練的這種情況，正是這種曲線式升級的特色。這種作法使得角色除了單純的數字屬
性之外，還增加了一些隱藏的特性，會讓游戲更有味道。

如果以筆者個人的喜好來說，我是比較欣賞曲線式的升級方式，因為這種方式比較可以隱藏角色的特色，也不
會因為數字的變化太過單調而讓玩者覺得過死板。比起亂數式的不定性和升級指數式的單純來說，這一種作法
可以說是兼具了兩種的特色，同時還有全新的表現，是一種不錯的升級方式。只惜目前國內的游戲很少使用這
種作法，大多還是采用亂數式的作法，對於國內玩游戲的玩者來說，實在是有些可惜，因為大家沒有辦法體會
到這種作法的優點。



6.游戲中的智能系統處理
-------------------------------------------------------------------------------



游戲中的智能對手
　AI在游戲中最普通的形式是創建計算機控制的對手。因為大多數游戲是單人游戲，所以要設計游戲者在游戲中必須戰勝對手。為了達到這個目的，你可以使用某種類似A*搜索的簡單AI算法，以幫助對手穿過迷宮向游戲者發起進行。你也可以使用簡單的算法預測游戲者的反應。
　但是，記住沒有必要創建世界上最強大的對手。你的對手只要能給游戲者提供足夠的挑戰性就可以了。還有，要注意游戲的內容。例如：一個戰棋式RPG游戲中策略占的是主要地位；而在純RPG中故事情節和角色開發就更重要一些。千萬不要因為計算機對手太強大而讓游戲者們陷入失敗的泥沼。

游戲中的非智能對手
　通常，在游戲開發中AI技術是與計算機對手緊緊聯系在一起的。這是因為早期的大部分類似角棋的游戲是一對一的。但是，任何好的探險游戲或RPG 游戲開發者都知道，AI同樣可以用于非對手角色。例如：如果你正在建立一個RPG游戲并且你想讓你的世界活起來，這就是說，讓城市里的人以智能的方式活動，那么你可以使用某種算法確定在一天中的某個時候，角色應該在那里。你可以使用類似于AI算法如A*來輔助你將一個對象從一處移動到另一處并繞過障礙物。

游戲中的智能系統
游戲中的AI在本質上是最具有模仿性的，但它們基本上是依賴一些AI要素。 你可以將所有具有決策功能的對象在一個游戲中融合為一個整體。例如：在一個戰爭游戲中，你的各個部分可以依據各自所處的具體環境來作出各自的AI決策。
　　使用這種方法，你得把精力集中于怎樣在各個獨立的決策個體之間建立聯系，以及這些聯系怎樣才能使游戲成為融會貫通的整體。是用一個高級決策影 響其它決策，還是各個決策個體之間平等地互相影響呢？舉個戰爭游戲來說， 你有十輛坦克，它們的思維模式基本相同。所以它們都決定去攻擊敵人陣營中 HP值最低的一輛坦克。但是這時其中一輛坦克說：“這個敵人歸我了！”那么 剩下的九輛坦克就應該依據這條信息各自調整下一步的攻擊目標。當你建立智能個體時，要考慮在一個智能系統整體環境下，它應該如何行動。




7.電腦游戲中的人工智能制作
-------------------------------------------------------------------------------


　電腦游戲隨著硬件執行效率與顯示解析度等大幅提升，以往很多不可能或非常難以實現的電腦游戲如此都得以順利完成。雖然電腦游戲的呈現是那么地多樣化，然而卻與我們今日所要探討的主題，人工智能幾乎都有著密不可分的關系。
　在角色扮演游戲中，程序員與企劃人員需要精確地在電腦上將一個個所謂的“怪物”在戰門過程中栩栩如生地制作出來；所以半獸人受了重傷懂得逃跑，法師懂得施展攻性法術。
　目前能讓人立刻想到與人工智能有密切關系的游戲有兩種：
一是所謂的戰棋／策略模擬游戲，二則是棋弈游戲。人工智能的比重與深淺度，在不同的游戲類型中各有不一。有的電腦游戲非標榜著高人工智能不可，不然沒有人買；有的則是幾乎渺茫到讓玩家無法感覺有任何人工智能的存在。　　　　　　　　　　　　

　導向式思考

　AI最容易制作的的方式，同時也是早期游戲AI發展的主要方向就是規則導向或稱之為假設導向。在一些比較簡單的電腦游戲中，程序員可以好不困難地將游戲中的規則與設定轉化成一條條的規則，然后將它們寫成電腦程序。讓我們以角色扮演游戲為例。決大多數的企畫在設定所謂電腦怪物時，所設定的屬性通常有以下幾種：

　　生命值　攻擊力　防御力　法力　 屬性

　最后一個“屬性”是我在設定時喜歡增加的項目之一。透過這項屬性的設定，我可以把怪物設定成“貪生怕死的”，也可以把戰士設定為“視死如歸”。以目前我們所掌握的資料，在戰門系統中的大綱如是誕生了：　　　　　　　　　　　　　　　　　　　　　　　　　　

規則一

if (生命值< 10) // 邊臨死亡了嗎　
{　 if (屬性== 貪生怕死)　　　　　　　　　　　　　　　
　　　結果 = 試圖逃跑　　　　　　　　　　　　　　　
　　if (有任何恢復生命值的物品或法術可用)　　　　　　
　　　結果 = 使用或施展相關物品或法術　　　　　　　
}　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

規則二
　
if (可施攻擊性法術 && 有足夠法力)
{　　　　　　　　　　　　　　　　　　　　　　　　
　　　結果 = 施展攻攻擊性法術　　　　　　　　　　　　　
}　　　　　　　　　　　　　　　　　　　　　　　　

　由以上一連串的“如果－－就－－”規則設定，建立了最基本的ＡＩ。說這樣的制方式只能建立基本ＡＩ其實并不當然正確。只要建立足夠及精確的規則，這樣的方式仍然有一定水準的表現。
　規則導向的最大優點就是易學易用。在沒有深奧的理論概念的前提下，仍有廣大的使用群。所以很多老道的玩家常常沒兩下就摸清楚敵人的攻擊策略，移動方式等等。

　推論式思考

　相信曾經接觸過電腦語言課程，或是自習過相關書籍的朋友們，都曾曾經聽過一個著名的程序，那就是井字游戲。用井字游戲作為討論AI的入門教材，我個人覺得是最適當的例子。或許有人還不知道井字游戲怎么玩。只要任何一方在三乘三的方格中先先成一線便勝利了。我們在前面談過的規則導向，在這里也可以派得上用場。

　if任何一線已有我方兩子&&另外一格仍空//我方即將成一線嗎
　　結果 = 該空格　　　　　　　　　　　　　　　　　　　　　
　if任何一線已有敵方兩子&&另外一格仍空//防止敵方作成一線　
　　結果 = 該空格 　　　　　　　　　　　　　　　　　　　　
　if任何一線已有我方一子&&另外兩格仍空//作成兩子　　　　
　　結果 = 該空格

　有一次我在某本電腦書上，同樣地也看到某些以井字游戲為介紹的范例。不同的是，我幾乎看不到任何規則導向的影子。但在仔細分析該程序碼后，我得到了極大的啟發，原來AI是可以不用這么多規則來制作的。它用的方法正是在電腦AI課程中重要的概念：極大極小法。我在這里只說明這法則的概念。繼續以井字游戲為例，電腦先在某處下子，接著會以假設的方式，替對方下子，當然，必須假設對方下的是最佳位置，否則一切則毫無意義。在假設對方下子的過程中，自然又需要假設我方的下一步回應，如此一來一往，直到下完整局游戲為止。 底下是節錄書中的程序片段：　　　　　　　　　　　　　　　　　　　　　　　
　
bestMove(int p, int*v)
{　 　int i;　
　　　int lastTie;　　　　　　　　　　　　　　　　　　
　　　int lastMove;　　　　　　　　　　　　　　　　　
　　　int subV;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
/*First, check for a tie*/　　　　　　　　　　　　
　　　　if (isTie()) {　　　　　　　　　　　　　　
　　　　　*v=0;　　　　　　　　　　　　　　　
　　　　　return(0);　　　　　　　　　　　　　　
　　　};
/*If not a tie, try each potential move*/
　for (*v=-1, lastTie=lastMove=-1,i=0;i<9;i++)
　　{
　　　/*If this isn't a possible, skip it*/　　　　　　　　　　
　　　if (board[i]!=0) continue;
　　　/* Make the move. */
　　　　lastMove=i;　
　　　　board[i]=p;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　/* Did it win? */　　　　　　　　　　　　　　　　　　　　　　　
　　　　if (hasWon(p)) *v=1;　　　　　　　　　　　　　　　　　　　　　
　　　　else{　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　/*If not, find out how good the other side can do*/
　　　　　bestMove(-p,&subV);　　　　　　　　　　　　　　　　　　　　　　
　　　/* If they can only lose, this is still a win.*/
　　　　　　if (subV==-1) *v=1;　　　　　　　
　　　/* Or, if it's a tie, remember it. */　　　　　　　　　
　　　　　　　else if (subV==0){　　　　　　　　　　　　　　　　　
　　　　　　　　　　*v=0;　　　　　　　
　　　　　　　　　　lastTie=i;　
　　　　　　　　　　};　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　};　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
/* Take back the move. */　　　　　　　　　　　
　　　　 　　　　　　board[i]=0;　　　　　　　　　　
/*If we found a win, return immediately
　　　　　(can't do any better than that)*/　　　　　
　　if (*v==1) return(i);　　　　　　　　　　　　　　　　　　　　　
/*If we didn't find any wins, return a tie move.*/　　　　　　　　　
　　if (*v==0) return(lastTie);　　　　　　　　　　　　　　　　　　　　　　
/*If there weren't even any ties, return a loosing move.*/　　　　　
　　else return(lastMove);　
};　　　　

　國外的一些論壇曾舉行過256字節的游戲設計比賽。作品非常多，其中有一件作品正巧也是井字游戲。作者用區區兩百多行就寫了與上述程序演算方式完全相同的作品，可見功力確實了的。另外，我也很希望類似的活動能在國內推展起來。對了，在這樣的比賽條件限制下，除了匯編語言外，幾乎沒有其它的選擇了。　　　　 　 .386c　　　　　　　　　　　　　　　　　　　　　　　　
　 code　　　　　　segment byte public use16　　　　　　
　　　　　　　　　 assume　cs:code, ds:code　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 org　　 100h　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 tictac　　　　　proc　　far　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 start:　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 push　　cs　　　　　　　　　　　　　
　　　　　　　　　 pop　　 ds　　　　　　　　　　　　　
　　　　　　　　　 mov　　 ax,0B800h　　　　　; 清除屏幕
　　　　　　　　　 mov　　 es,ax　　　　　　　;　　　　
　　　　　　　　　 xor　　 di,di　　　　　　　;　　　　
　　　　　　　　　 mov　　 cx,7D0h　　　　　　;　　　　
　　　　　　　　　 mov　　 ax,0F20h　　　　　 ;　　　　
　　　　　　　　　 rep　　 stosw　　　　　　　;　　　　
　　　　　　　　　 xor　　 cx,cx　　　　　　　;　　　　
　　　　　　　　　 mov　　 dl,5　　　　　　　　　　　　
　 loc_1:　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 call　　printBoard　　　　　　　　　
　 loc_2:　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 ah,8　　　　　　　 ; 等待按鍵
　　　　　　　　　 int　　 21h　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 movzx　 bx,al　　　　　　　　　　　　

　　　　　　　　　 sub　　 bl,31h　　　　　　 ; 如果不是1..9
　　　　　　　　　 jc　　　loc_2　　　　　　　; 則重新輸入　
　　　　　　　　　 cmp　　 bl,8　　　　　　　　　　　　　　
　　　　　　　　　 ja　　　loc_2　　　　　　　　　　　　　　
　　　　　　　　　 cmp　　 data_1[bx],al　　　　　　　　　　
　　　　　　　　　 jne　　 loc_2　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 byte ptr data_1[bx],'x'　　　　　
　　　　　　　　　 dec　　 dl　　　　　　　　　　　　　　　
　　　　　　　　　 jz　　　short loc_3　　　　　　　　　　　
　　　　　　　　　 mov　　 al,'o'　　　　　　　　　　　　　
　　　　　　　　　 call　　bestMove　　　　　　　　　　　　
　　　　　　　　　 mov　　 [si],al　　　　　　　　　　　　　
　　　　　　　　　 call　　isWin　　　; 判斷是否已取得勝利　
　　　　　　　　　 jnc　　 loc_1　　　　　　　　　　　　　　
　 loc_3:　　　　　　　　　　　　　　　　　　 　 　　　　　
　　　　　　　　　 call　　printBoard　　　　　　　　　　　
　　　　　　　　　 mov　　 ax,4C00h　　　　　　　　　　　　
　　　　　　　　　 int　　 21h　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 data_1　　　　　db　　　'12'　　　　　　　　　　　　　　
　 data_2　　　　　db　　　'3456789'　　　　　　　　　　　　
　 data_3　　　　　db　　　0　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 tictac　　　　　endp　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 printBoard　　　proc　　near　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 si,offset data_1　　　　　　　　
　　　　　　　　　 mov　　 di,548h　　　　　　　　　　　 　
　　　　　　　　　 mov　　 cl,3　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 locloop_4:　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 movsb　　　　　　　　　　　　　　　　　　
　　　　　　　　　 add　　 di,5　　　　　　　　　　　　　　
　　　　　　　　　 movsb　　　　　　　　　　　　　　　　　　
　　　　　　　　　 add　　 di,5　　　　　　　　　　　　　　
　　　　　　　　　 movsb　　　　　　　　　　　　　　　　　　
　　　　　　　　　 add　　 di,133h　　　　　　　　　　　　　
　　　　　　　　　 loop　　locloop_4　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　
　 printBoard　　　endp　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 isWin　　　　　 proc　　near　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 bx,1　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 bp,3　　　　　　　　　　　　　　
　　　　　　　　　 call　　sub_3　　　　; 檢查橫向是否完成　
　　　　　　　　　 inc　　 bx　　　　　　　　　　　　　　　
　　　　　　　　　 inc　　 bx　　　　　　　　　　　　　　　
　　　　　　　　　 dec　　 bp　　　　　　　　　　　　　　　
　　　　　　　　　 dec　　 bp　　　　　　　　　　　　　　　
　　　　　　　　　 call　　sub_3　　　　; 檢查縱向是否完成　
　　　　　　　　　 call　　sub_4　　　　; 檢查斜向是否完成
　　　　　　　　　 clc
　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　
　 isWin　　　　　 endp　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 loc_5:　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 stc　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 sub_3　　　　　 proc　　near　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 ah,3　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 si,offset data_1　　　　　　　　
　 loc_6:　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 di,si　　　　　　　　　　　　　　
　　　　　　　　　 call　　sub_5　　　　　　　　　　　　　　
　　　　　　　　　 add　　 si,bp　　　　　　　　　　　　　
　　　　　　　　　 dec　　 ah　　　　　　　　　　　　　　　
　　　　　　　　　 jnz　　 loc_6　　　　　　　　　　　　　　
　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　
　 sub_3　　　　　 endp　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 sub_4　　　　　 proc　　near　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 di,offset data_1　　　　　　　
　　　　　　　　　 inc　　 bx　　　　　　　　　　　　　　
　　　　　　　　　 call　　sub_5　　　　　　　　　　　　　
　　　　　　　　　 mov　　 di,offset data_2　　　　　　　　
　　　　　　　　　 dec　　 bx　　　　　　　　　　　　　　　
　　　　　　　　　 dec　　 bx　　　　　　　　　　　　　　　
　　　　　　　　　 call　　sub_5　　　　　　　　　　　　　　
　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　
　 sub_4　　　　　 endp　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 sub_5　　　　　 proc　　near　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 cl,3　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 locloop_7:　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 cmp　　 [di],al　　　　　　　　　　　　　
　　　　　　　　　 jne　　 short loc_ret_8　　　　　　　　　
　　　　　　　　　 add　　 di,bx　　　　　　　　　　　　　　
　　　　　　　　　 loop　　locloop_7　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 add　　 sp,4　　　　　　　　　　　　　　
　　　　　　　　　 jmp　　 short loc_5　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 loc_ret_8:　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　　　　　
　 sub_5　　　　　 endp　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 bestMove　　　　proc　　near　　　　　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 bx,31FEh　　　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 cl,9　　　　　　　　　　　　　　　　　　
　　　　　　　　　 mov　　 di,offset data_1　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 locloop_9:　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 cmp　　 [di],bh　　　　 ; #empty?　　　　　　　　
　　　　　　　　　 jne　　 short loc_12　　; #no, skip　　　　　　　
　　　　　　　　　 mov　　 [di],al　　　　　　　　　　　　　　　　　
　　　　　　　　　 pusha　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　 call　　isWin　　　　　 ; #CY: Win　　　　　　　
　　　　　　　　　 popa　　　　　　　　　　;　　　　　　　　　　　　
　　　　　　　　　 jnc　　 short loc_10　　;　　　　　　　　　　　　
　　　　　　　　　 mov　　 bl,1　

    回想起當年我玩各種網絡游戲的時候，一進游戲，什么都沒有，眼前看著一堆穿著金光閃閃的漂亮裝備的人跑來跑去，看到有人在不停的刷屏叫買叫賣的打著各種廣告，有一種和現實社會截然不同的感覺，實打實的覺得自己在這個虛擬社會里面是個新手。雖然游戲都設置有密語等功能，但是這些對于新手來說，幾乎是多余的，一開始總是一個人在孤單的打低級的怪物，這個時候的同伴只可能有兩種人，一種是和你一樣的新手，另外一種，則是練小號的人。（練小號這種現象非常有趣，在以后會詳細討論。）新手的生活是郁悶的，經常會被怪獸欺負，或者是被了解游戲比自己多一點的人所瞧不起（實際上等自己有機會接觸到了解游戲比自己還少的人的時候，也會瞧不起別人）。有數據證明，在這個時期的玩家最容易退出游戲。 

    而另外有些玩家，運氣比較好，碰上了一些對游戲了解得比較多的，又不會瞧不起他的玩家，然后會獲得物質上的（裝備，金錢）和文化上的（初等社交圈子）的一些幫助，慢慢的開始有了自己的社會關系（Social Relationship）。到了這個時候，玩家才會比較努力的開始練級，因為有了自己的社交圈子（Social Group & Organization），會想成為這個社交圈子中被大家公認的強者，最簡單有效的方法，就是練級。但是從Feminist的角度來看，對于男性玩家，一般會比較喜歡成為某個社交圈子中的強者，要成為強者，就要擺脫其他的競爭者的威脅，這是男性一些天生的特性。而對于女性玩家，一般不太會喜歡這種激烈的直接競爭，而會選擇一些間接的競爭，比如說裝備，對好的裝備的追求，因為這種追求并不會影響到社會圈子中其他的人。 

    慢慢的對游戲了解得越來越多，認識的人越來越多，基本上就脫離了新手這個范疇，然后才真正開始體驗游戲本身提供的各種活動，即使游戲設計的是單人完成的活動，你也經常會喊上朋友來看你完成。總之，從現在開始，你的一舉一動都屬于Social Interaction了，就好像連現實生活中的“走路”這種行為都被定義為Social Interaction，因為這種行為都是受到社會的影響而造成的。而你，則在不停的努力保持和提高你的社會地位，一般的游戲中，用來衡量社會地位的東西一般是級別，而在某些設計得比較好的游戲中，級別不一定是最主要的衡量社會地位的東西。別的游戲我不太了解，說個我玩過的，《騎士Online》這個游戲，雖然目前狀態并不理想，但是其中的形成的虛擬社會卻是一個比較健康的社會。在這個游戲里面，用來衡量你的社會地位的東西，是一種叫國家貢獻值的東西，實際上就是PK的殺人數和被殺死數的一個比例值。因為對于比較好的用來衡量的東西，一定要是大家都可以接觸得到的，你的級別再高，在外表上體現不出來，或者大家不知道的話，就基本上沒什么意義了。再說說《傳奇》，其中也有個設計得很好的地方，就是大家都可以互相看到別人的級別和裝備，如此一來，級別和裝備就成了衡量社會地位的主要因素，因為大家都可以很便利的互相了解到這項參數。同樣在現實社會中，在學校這個社會群體中，每個人都有GPA，每個班都有Top Student，成績就成了大家都最容易access的參數。 

    當你成了老玩家了，再回過頭來看看那些剛剛接觸游戲的新手，他們就像自己當年一樣，什么都不懂（這里提個概念，Power的定義就是對社會資源掌握的程度），對游戲，對游戲中的社會群體，什么都不了解。然后偶爾你也會心血來潮去幫助他們，就好像某人當年幫助自己一樣。就像在現實社會中一樣，看到路邊的乞丐，偶爾也會幫助一把，但是，自己也會想，這么多乞丐，一個人怎么幫助得過來呢。實際上，這個問題在社會學里面是這樣來看待的：這里要提出一個名詞：Altruism。越是程度越高的社會階級，Altruism這種現象就出現得越頻繁。如果一個游戲的處于社會層次頂級的人越少，那么這個游戲的幫助新人的現象之會越少，不管你如何用其他的機制來激勵玩家幫助新手，就如同有一些網絡游戲，采取獎勵幫助新手的人的政策，如果這個游戲處于社會頂層級別的人還是很少的話，同樣是沒有效果的。因為這種幫助人，是基于有目的性的，目的不是在于幫助新手，而是在于獲取獎勵，不但沒有好效果，還會造成玩家利用這套系統的漏洞，作弊之類的后果。要讓大家都喜歡幫助新手，就是讓游戲在社會層次（Social Hierarchy）在高層的用戶比較多一些，這樣自然就會有很多Altruism的現象了。同樣在現實社會中，有數據表明，相比較發展中國家，發達社會的人更喜歡幫助他人一些。 

    下面談談Bureaucracy和Government在網絡游戲中的一些事實，Max Weber說過官僚系統分為理想的和現實兩種情況，在理想的情況下，官僚系統是可以做到絕對公平的，而實際上經常因為個人的性格不同之類的因素，常常會造成不好的，甚至是負面的影響。這點在國內的網絡游戲運營中體現的尤其突出，其實這個問題在現實中也是不可避免的問題，唯一比較好的處理方法，就是相信群眾的眼睛的雪亮的，而提供各種投票和選舉機制，并且鼓勵玩家對一些事件或者改動的投票和選舉。 

    接下來是Deviance 和Discrimination，這兩個現象雖然是大家都不想談起的，但是確實是網絡游戲中或者是現實社會中比較嚴峻的問題。在網絡游戲中，這兩者造成的最嚴重的問題就是會導致某些玩家離開這個游戲（社會）。剛剛翻了翻書，找到一個Strain Theory，里面主要的意思就是講玩家在得知自己肯定達不到某個目標的時候會感覺到Strain，比如說玩游戲玩了半年了，發現自己天生的屬性沒有選對，然后后天無法更改，導致自己比別人低一等之類的。這一點好像每個網絡游戲都做得還不錯（洗點？）。另外一個是叫“機會理論”（Opportunity Theory），這個很簡單，實際上就是指當你發現你可以用非法的途徑獲取到合法途徑獲取不到的東西的情況下，你會鋌而走險。這個在網絡游戲中最典型的例子就是黑客，騙子，盜號之類的。還有最后一條理論，就是叫“控制理論”（Control Theory），這個在網絡游戲中體現得最明顯的就是引怪害人之類的人，他們的行為的產生的原因，是因為他們無法被一般的社會機構所接受，就好象一個玩家，玩了2，3個月游戲了，對游戲也了解得比較熟了，但是由于在游戲中大家都不愿意理他，就會造成他的Deviance的傾向。當然，這種人絕對不在少數，為什么其他人不會違反規則呢？因為有一些人找到一些能夠收容，并能提供給他們一些成就感的場所。這就是為什么國家政府一直沒有明著反對網絡游戲的原因，有明擺著的數據證明，自從很多人接觸網絡游戲之后，社會治安好了很多。同樣，在網絡游戲中也需要這樣的場所，要不然違法規則的人只會越來越多。 

    再談談前面談到過的練小號的現象。練小號的人有兩種，一種是由于游戲設計得不合理，導致高級別，或者越到后來之后，獲取游戲資源的難度會比剛剛開始還要麻煩。所以就會有一批玩家來利用這個漏洞來比較快的獲取資源。另外一種人，就是完全想創造一個新的自我，在游戲中扮演不同的角色。我這個學期的論文就是關于互連網絡和社會學，所以對這個的資料了解得多一點。其主要的原因就是因為大到整個互連網絡，小到一個網絡游戲，最吸引人的地方之一，就是可以很隨便的修改自己的Social Identity。可以完全按照自己的意愿來創造一個自己想象中的人物，而且可以隨時完全重新來過。第二種練小號的人，就屬于對自己在當前虛擬社會中的程度不太滿意，進而想從新創造一個新的角色的那一類人。  

場景管理之消息發送

    好久沒有寫東西出來和大家共同揣摩，真是對不住大家了。現在終于騰了一些時間來繼續和大家研究網絡游戲制作技術，在這一節中，我就要向大家介紹網絡游戲服務器中World場景劃分和場景中消息分發問題。

    在前面我基本向大家講述的都是一些基本的技術問題，從某種意義上講。屬于純技術范疇的東西，但現在要向大家講的，應該是屬于服務器功能設計范疇的。在這里，我未必講的很好，有遺漏之處就請大家諒解和指正。

    對于有一定游戲服務器開發基礎的朋友而言，應該都明白一個網絡游戲服務器和客戶端之間的一個基本關系： 玩家客戶端是游戲服務器一個局部COPY表現。這個說法聽起來可能有一些繞口，簡單的解釋下也就是說：客戶端所具備的區域信息也就是游戲服務器相同區域數據的一份COPY，而表現的意思，也就是說，CLIENT端將這樣的數據信息圖形化，并且通過屏幕來進行顯示，從而來呈現出一個多姿多彩的游戲世界。這樣說大家應該能夠聽懂了吧？再不懂的話，就自己琢磨了。

    說了上面那么多，大家一定要問“SERVER和CLIENT這種關系和我們的消息發送又有什么關系呢？”。其實，我們要討論的問題點也就在這里。但現在我還不說場景消息到底該如何進行分發。我們還是再來研究一個問題：什么能夠使我們的游戲世界變的內容豐富？
大家先不要看我所說的，先自己想想。

    大家應該都思考過了，我就來說一下我的個人想法和理解，可能和大家不一樣（我想到的你沒有想到的你補上，反之，我補上）。

    在我們的MMOPRG游戲世界中，造成游戲世界變的豐富多彩一般無外乎兩個大方面：NPC動作、玩家動作。呵呵，看起來就只有簡單的兩個方面，但具體分析這些動作起來，可就會讓各位包括我都會頭大的。先我們來說NPC動作吧，NPC動作通過AI邏輯進行控制，一般情況可以分為一下幾個動作：待機、移動、物理攻擊、技能攻擊、魔法攻擊、死亡等，而游戲中玩家動作的產生是由現實中玩家進行操控的，動作類型基本上也不外乎以上幾種。既然在服務器游戲世界中存在這樣的一些動作，那是如何進行獲取的呢？其實就只有兩個字：消息（Message）。而消息的產生方又分為兩種：Client消息，Server消息。既然有消息產生，我們就將涉及到另外一個問題：如何將產生的消息分發出去呢？

    下面通過我自己的實現經驗來簡單介紹場景消息的分發原理（詳細介紹寫的太多，有點懶！！），應該不是最佳的，我只是提一個開頭，更好的處理實現方式還是需要大家來共同研究。有好的想法也希望告訴我下，我也從中學習些新的東西。

    先看場景示范圖（我畫的，比較土，只是表明一個意思。呵呵）

 
    通過上面設計示范圖，我來具體介紹：關于場景消息分發，我的設計和分析過程：
    第一步：將場景網絡化，也就是說將我們的游戲服務器大場景進行邏輯上的區域劃分，每個單獨區域所占的面積可以考慮比屏幕區域稍微大點。同時為每一個單獨的區域創建Player標志信息（SOCKET或者其他）列表。

    第二步：將單獨區域四分化，也就是說對于每一個小區域，再次劃分為四個更加小的區域，同時為每一個小的區域建立一個包含三個對象的整數數組。數組的作用是為了保存此小區域的親緣區域。例如： 小區域1的親緣區域就是： A、B、H，小區域2的親緣區域就是：B、C、D等。

    第三步：在上面兩步基礎上，就是實際處理消息分發了。如果Player/NPC在區域中進行消息動作，我們通過Player/NPC的當前位置就可以首先確定Player/NPC所在大地圖中的具體區域。在我們確定好了具體的區域后，我們要繼續確定在那個具體的小區域。在這些小區域都確定后，我們就可以將我們的動作消息發送到親緣區域中的Player(玩家)。

    第四步：對于第三步的改變優化，用CPU處理量來換取消息數量，具體做法也就是，在親緣區域中繼續區域化。也就是說消息不是發送到親緣區域中的所有Player(玩家)，而是有選擇的發送到自身一定區域的玩家。這種優化改革從某種意義上講，可以減少服務器總消息數量，但增大CPU處理量，而對于具體實現，就需要大家去權衡了。

    以上也就是這個分析和處理過程了。同時關于這個場景處理的.h文件，我也就簡單的寫下，大家參考了。

Class    GmapRegion
{
   public:
GmapRegion();
~ GmapRegion();
void   GetBoardCastMsgList(POINT current_pos,LIST *);  //獲取當前位置廣播消息的Player列表。
……..
   private:
        void   Init();
        voud   Release();
        bool   InitMapRegion(int  map_wis,int map_hei);         //地圖區域化
        
   protected:
}

 

線程同步和服務器數據保護

最近因為自己主持的項目出現些問題，太忙了，所以好久都沒有繼續寫東西和大家進行探討制作開發部分了。在這一節中就要向大家介紹另外一個重要的部分，并且也是最頭疼的部分：線程同步和數據保護。

關于線程的概念我在前面的章節中已經介紹過了，也就在這里不累贅—“重復再重復”了。有一定線程基礎的人都知道，線程只要創建后就如同脫韁的野馬，對于這樣的一匹野馬我們怎么來進行控制和處理呢？簡單的說，我們沒有辦法進行控制。因為我們更本就沒有辦法知道CPU什么時候來執行他們，執行他們的次序又是什么？

有人要問沒有辦法控制那我們如何是好呢？這個問題也正是我這里要向大家進行解釋和說明的，雖然我們不能夠控制他們的運行，但我們可以做一些手腳來達到我們自己的意志。

這里我們的做手腳也就是對線程進行同步，關于同步的概念大家在《操作系統》中應該都看過吧！不了解的話，我簡單說說：讀和寫的關系（我讀書的時候，請你不要在書上亂寫，否則我就沒有辦法繼續閱讀了。）

處理有兩種：用戶方式和內核方式。
用戶方式的線程同步由于有好幾種：原子訪問，關鍵代碼段等。

在這里主要向大家介紹關鍵代碼段的處理（我個人用的比較多，簡單實用）。先介紹一下它的一些函數，隨后提供關鍵代碼段的處理類供大家參考（比較小，我就直接貼上來了）

VOID InitializeCriticalSection(    //初始化互斥體
  LPCRITICAL_SECTION lpCriticalSection  // critical section
);

VOID DeleteCriticalSection(        //清除互斥體
  LPCRITICAL_SECTION lpCriticalSection   // critical section
);

VOID EnterCriticalSection(         //進入等待
  LPCRITICAL_SECTION lpCriticalSection  // critical section
);

VOID LeaveCriticalSection(         //釋放離開
  LPCRITICAL_SECTION lpCriticalSection   // critical section
);

以上就是關于關鍵代碼段的基本API了。介紹就不必了（MSDN）。而我的處理類只是將這幾個函數進行了組織，也就是讓大家能夠更加理解關鍵代碼端
.h
class   CCriticalSection                //共享變量區類
{
public:
CCriticalSection();
virtual ~CCriticalSection();
void   Enter();                   //進入互斥體
void   Leave();                  //離開互斥體釋放資源
private:
   CRITICAL_SECTION  g_CritSect;
};
.cpp
CCriticalSection::CCriticalSection()
{
InitializeCriticalSection(&g_CritSect);
}

CCriticalSection::~CCriticalSection()
{
DeleteCriticalSection(&g_CritSect);
}

void  CCriticalSection::Enter()
{
EnterCriticalSection(&g_CritSect);
}

void  CCriticalSection::Leave()
{
    LeaveCriticalSection(&g_CritSect);
}
由于篇幅有限關鍵代碼段就說到這里，接下來向大家簡單介紹一下內核方式下的同步處理。
哎呀！這下可就慘了，這可是要說好多的哦！書上的羅羅嗦嗦我就不說了，我就說一些我平時的運用吧。首先內核對象和一般的我們使用的對象是不一樣的，這樣的一些對象我們可以簡單理解為特殊對象。而我們內核方式的同步就是利用這樣的一些特殊對象進行處理我們的同步，其中包括：事件對象，互斥對象，信號量等。對于這些內核對象我只向大家說明兩點：
1．內核對象的創建和銷毀
2．內核對象的等待處理和等待副作用

第一：內核對象的創建方式基本上而言都沒有什么太大的差別，例如：創建事件就用HANDLE CreateEvent(…..),創建互斥對象 HANDLE CreateMutex(…….)。而大家注意的也是這三個內核對象在創建的過程中是有一定的差異的。對于事件對象我們必須明確指明對象是人工對象還是自動對象，而這種對象的等待處理方式是完全不同的。什么不同下面說（呵呵）。互斥對象比較簡單沒什么說的，信號量我們創建必須注意我們要定義的最大使用數量和初始化量。最大數量>初始化量。再有如果我們為我們的內核對象起名字，我們就可以在整個進程中共用，也可以被其他進程使用，只需要OPEN就可以了。也就不多說了。

第二：內核對象的等待一般情況下我們使用兩個API：
DWORD WaitForSingleObject(        //單個內核對象的等待
      HANDLE hHandle,        // handle to object
      DWORD dwMilliseconds   // time-out interval
);

DWORD WaitForMultipleObjects(     //多個內核對象的等待
      DWORD nCount,             // number of handles in array
      CONST HANDLE *lpHandles,  // object-handle array
      BOOL fWaitAll,            // wait option
      DWORD dwMilliseconds      // time-out interval
);
具體怎么用查MSDN了。
具體我們來說等待副作用，主要說事件對象。首先事件對象是分兩種的：人工的，自動的。人工的等待是沒有什么副作用的（也就是說等待成功后，要和其他的對象一樣要進行手動釋放）。而自動的就不一樣，但激發事件后，返回后自動設置為未激發狀態。這樣造成的等待結果也不一樣，如果有多個線程在進行等待事件的話，如果是人工事件，被激活后所有等待線程成執行狀態，而自動事件只能有其中一個線程可以返回繼續執行。所以說在使用這些內核對象的時候，要充分分析我們的使用目的，再來設定我們創建時候的初始化。簡單的同步我就說到這里了。下面我就將將我們一般情況下處理游戲服務器處理過程中的數據保護問題分析：

首先向大家說說服務器方面的數據保護的重要性，圖例如下：

用戶列表

                                  用戶刪除

                                  用戶數據修改
                                  
                                  使用數據

加入隊列

對于上面的圖例大家應該也能夠看出在我們的游戲服務器之中，我們要對于我們用戶的操作是多么的頻繁。如此頻繁的操作我們如果不進行處理的話，后果將是悲慘和可怕的，舉例：如果我們在一個線程刪除用戶的一瞬間，有線程在使用，那么我們的錯誤將是不可難以預料的。我們將用到了錯誤的數據，可能會導致服務器崩潰。再者我們多個線程在修改用戶數據我們用戶數據將是沒有辦法保持正確性的。等等情況都可能發生。怎么樣杜絕這樣的一些情況的發生呢？我們就必須要進行服務器數據的保護。而我們如何正確的保護好數據，才能夠保持服務器的穩定運行呢？下面說一下一些實際處理中的一些經驗之談。

1．我們必須充分的判斷和估計我們服務器中有那些數據要進行數據保護，這些就需要設計者和規劃者要根據自己的經驗進行合理的分析。例如：在線用戶信息列表，在線用戶數據信息，消息列表等。。。。。

2．正確和十分小心的保護數據和正確的分析要保護的數據。大家知道我們要在很多地方實現我們的保護措施，也就是說我們必須非常小心謹慎的來書寫我們的保護，不正確的保護會造成系統死鎖，服務器將無法進行下去（我在處理的過程中就曾經遇到過，頭都大了）。正確的分析要保護的數據，也就是說，我們必須要估計到我們要保護的部分的處理能夠比較快的結束。否則我們必須要想辦法解決這個問題：例如：
         
         DATA_STRUCT  g_data;
         CRITICAL_SECTION  g_cs;

         EnterCriticalSection(&g_cs);
         SendMessage(hWnd,WM_ONEMSG,&g_data,0);
         LeaveCriticalSection(&g_cs);
以上處理就有問題了，因為我們不知道SendMessage（）什么時候完成，可能是1/1000豪秒，也可能是1000年，那我們其他的線程也就不用活了。所以我們必須改正這種情況。

         DATA_STRUCT  g_data;
         CRITICAL_SECTION  g_cs;

         EnterCriticalSection(&g_cs);
         PostMessage(hWnd,WM_ONEMSG,&g_data,0);
    LeaveCriticalSection(&g_cs);

或者        DATA_STRUCT  temp_data;

         EnterCriticalSection(&g_cs);
         temp_data = g_cs;
         LeaveCriticalSection(&g_cs);
         SendMessage(hWnd,WM_ONEMSG,& temp_data,0);

   3．最好不要復合保護用戶數據，這樣可能會出現一些潛在的死鎖。

簡而言之，服務器的用戶數據是一定需要進行保護，但我們在保護的過程中就一定需要萬分的小心和謹慎。這篇我就說到這里了，具體的還是需要從實踐中來進行學習，下節想和大家講講服務器的場景處理部分。先做事去了。呵呵！！有好的想法和建議的和我交流探討，先謝謝了。

 

服務器程序設計部分

續上在這里我將要向大家簡單介紹一下游戲服務器中必須要處理另外一項主要技術：
內存分配處理技術也可以稱為內存池處理技術（這個比較洋氣，前面通俗的好，呵呵）

開始向大家介紹一般情況下我們對于內存的一些基本操作。簡單而言，內存操作就只有三個步驟：申請、使用、銷毀。而對于這些操作我們在C和C++中的處理方式略有不同:

在C中我們一般用malloc(….)函數來進行申請，而對應銷毀已經申請的內存使用free(…)函數。
在C++我們一般使用new操作符和delete操作符進行處理申請和銷毀。
大家一定要問了，我們一般都是這樣處理的呀！！沒有什么可以說的哦！！呵呵，我感覺就有還是有一些東東和大家聊的哦。先聊簡單幾條吧！！
1．Malloc(…..)和free(….), new ….和 delete …必須成對出現不可以混雜哦，混雜的話，后果就不可以想了哦！！（也沒有什么，就是內存被泄漏了，呵呵）
2．在我們使用new …和delete ….一定要注意一些細節，否則后果同上哦！！什么細節呢？下面看一個簡單的例子：
char  *block_memory  = NULL;
block_memory  = new  char[1024];
delete  block_memory;
block_memory = NULL;
大家沉思一會。。。。。。。。。
大家看有錯嗎？沒有錯吧！！
如果說沒有錯的，就要好好補補課了，是有錯的，上面實際申請的內存是沒有完全被釋放的，為什么呢？因為大家沒有注意第一條的完全匹配原則哦，在new 的時候有[ ]，我們在delete 怎么就沒有看見[ ] 的影子呢？ 這就造成了大錯有1023個字節沒有被釋放。正確的是 ： delete []block_memory;

關于內存基本操作的我是說這兩條，其他要注意還是有的，基本就源于此了。

了解了上面那些接下來就想大家說說服務器內存處理技術了。上面都沒有弄清楚了，就算了。呵呵。

大家都知道，我們的服務器要頻繁的響應客戶端的消息同時要將消息發送到客戶端，并且還要處理服務器后臺游戲World的運行。這樣我們就必須要大量的使用內存，并且要進行大量的內存操作（申請和銷毀）。而在這樣的操作中，我們還必須要保證我們的絕對正確無誤，否則就會造成內存的泄漏，而內存泄漏對于服務器而言是非常可怕的，也可能就是我們服務器設計失敗的毒藥。而我們如何進行服務器內存的正確和合理的管理呢？那就是我們
必須建立一套適合我們自己的內存管理技術。現在就向大家說一說我在內存管理方面的一些做法。
基本原理先用圖形表示一下：

回收內存塊
超大塊內存
       現在要申請的內存塊

上面的意思是：我們在服務器啟動過程中就為自己申請一塊比較大的內存塊，而我們在服務器運行過程中需要使用內存我們就到這樣一塊比較大已經申請好的內存塊中去取。而使用完后要進行回收。原理就是這么簡單。而最重要的是我們如何管理這個大的內存塊呢？
（非常復雜也比較難，呵呵）
首先 就內存塊操作而言就只有申請（類似 new）和回收（類似 delete）。
其次 我們必須要清楚那些內存我們在使用中，那些是可以申請的。

關于上面我簡單將這樣的一些數據結構和class定義在下面供大家參考使用。

   typedef  struct  MemoryBlock           //內存塊結構
{
    void  *buffer;                      //內存塊指針
    int    b_Size;                      //內存塊尺寸
} MemoryBlock;

class   CMemoryList                  //列表對象類（相當于數組管理類）
{
    public:
        CMemoryList();
        virtual ~ CMemoryList();
        void   InitList(int  data_size,int data_num);//初始化列表數據結構尺寸和數量
        void   AddToList(void *data);           //加入列表中
        void   DeleteItem(int index);            //刪除指定索引元素
……………..
private:
    void   Init();
    void   Release();
private:
    void  *memory;
int    total_size;
int    total_num;
    protected:
};

classs   CMemoryPool                                   //內存池處理類
{
    public:
        CMemoryPool(); 
        virtual ~ CMemoryPool();
        bool   InitMemoryPool(int  size);                 //初始化內存池
void *  ApplicationMemory(int size);               //申請指定size內存
void   CallBackMemory(void *,int size);            //回收指定size內存

    private:
        void   Init();
        void   Release():
        MemoryBlock  *UniteMemory(MemoryBlock  *block_a，MemoryBlock  * block_b);                                                  //合并內存

    private:
       MemoryBlock  memoryPool_Block;                 //內存池塊
       CMemoryList  *callBackMemory_List;              //回收內存列表
       CMemoryList  *usingMemory_List;                 //使用中內存列表
       CMemoryList  *spacingMemory_List;               //空白內存列表
    protected:
};

以上就是這個內存管理類的一些基本操作和數據定義，class  CMemoryList  在這里不是重點暫且就不說了，有空再聊。而具體的內存池處理方法簡單敘述如下：

   函數InitMemoryPool（）：  初始化申請一塊超大內存。
   函數ApplicationMemory（）：申請指定尺寸，申請內存成功后，要將成功申請的內存及其尺寸標示到usingMemory_List列表，同時要將spacingMemory_List列表進行重新分配。以便于正確管理。
   函數CallBackMemory（）：回收指定尺寸內存，成功回收后，要修改spacingMemory_List列表，同時如果有相鄰的內存塊就要合并成一個大的內存塊。usingMemory_List修改使用列表，要在使用列表中的這一項刪除。

以上就是一些簡單處理說明，更加詳細的就需要大家自己琢磨和處理了。我就不細說了。呵呵。不足之處就請大家進行指正，以便讓我們大家都提高。先謝謝了。

 

線程池處理部分

續上在這里我將要向大家簡單介紹一下游戲服務器中必須要處理另外一項主要技術：

線程池技術

開始 我來向大家簡單來介紹一下線程池的概念，先簡單了解下線程先，線程可以理解為一個function , 是一個為了進行某一項任務或者處理某一項具體事務的函數。例如：

UINT  WINAPI  FunctionCtrl(void *)              //線程處理函數
{
    進行某一項任務或者處理某一項具體事務
    ………….
    return  EXITFUNCTION_CODE;               //退出碼
}

而我們的線程池自身可以理解為是很多線程的一個管理者也可以說是一個很多線程的統籌者。因為我們的線程池具有生成線程功能也具有撤消線程的權利。這就是簡單的線程池的概念（我的理解，呵呵！！）接下來就來具體介紹線程池了！！

首先 介紹我們為什么要使用線程池技術呢？大家都知道我們的游戲服務器端要處理大量的用戶請求,，同時需要發送大量的游戲數據到客戶端，從而來驅動客戶端程序的執行和維持游戲的進行。那我們的服務器端是如何進行處理的呢？其實在這里我們就充分用到了線程池技術。
那么用這種技術有什么好處和優點呢？以下就來簡述這些，有不足之處和不當之處希望有心人指正，呵呵！！

大家都了解在我們服務器整個運行過程中，我們將整個運行時間分成很多個時間片。而對于這些已經分成的各個微小的時間片而言，在各個不同時間片中要處理的用戶請求和需要發送到用戶端的游戲數據量也將是不一樣的。而處理用戶的請求和發送數據到客戶端的工作都是由一系列的線程來執行的。

鑒于上面，這樣我們就可以感性的設想下服務器運行中的兩種情況：
第一種在我們服務器運行到某個時間片需要處理大量的用戶請求和發送大量數據，有這樣繁重的工作任務，我們就需要有很多的工作者線程來處理完成這樣的任務，以此來滿足我們的工作需要。這樣說我們就必須擁有很多工作者線程。

第二種在我們服務器運行到某個時間片需要處理的用戶請求和發送數據工作量比較小，由于任務比較少，我們用來處理任務的工作者線程也就不需要很多。也就是說我們只要有少量的工作者線程就可以達到我們的工作要求了。
    
對于上面的兩種情況，我們可以說明這樣的一個事實，也就是說我們服務器在運行過程中運行狀態是動態改變的，呼忙呼閑，時急時慢的。服務器的這樣的行為動作和性質可以做一個如下比喻：服務器就是一個企業，在企業業務非常忙的時候，公司的員工數量就必須要增多來滿足業務的需要。而在企業不景氣的時候，接的業務也就比較少，那么來說就會有很多員工比較閑。那我們該怎么辦呢？為了不浪費公司資源和員工自身資源，我們就必須要裁減員工，從而來配合公司的運行。而做這樣工作的可能是公司的人力資源部或者其他部分。現在就認為是人力資源部了。呵呵。

對于上面的比喻我們來抓幾個關鍵詞和列舉關鍵詞和我們主題對象進行對照，以此來幫大家來簡單理解服務器運行和線程池。

企業        ：  游戲服務器
人力資源部  ：  線程池
職員        ：  工作者線程

在說了這么多的廢話后，就具體的將線程池模型  ThreadPool.h文件提供以供大家參考：

class   GThreadPoolModel
{
friend static   UINT WINAPI  PoolManagerProc(void* pThread);  //線程池管理線程
friend    static   UINT WINAPI  WorkerProc (void* pThread);       //工作者線程
enum SThreadStatus                                        //線程池狀態
{
BUSY,
NORMAL,
IDLE
};
enum SReturnvalue  //線程返回值
{
MANAGERPROC_RETURN_value  = 10001,
WORKERPROC_RETURN_value  = 10002,
…………….
};
public:
GThreadPoolModel ();
virtual ~ GThreadPoolModel ();
    virtual bool  StartUp(WORD static_num,WORD max_num)=0;   //啟動線程馳
virtual bool  Stop(void )=0;                                //停止線程池
virtual bool  ProcessJob(void *)=0;                          //提出工作處理要求
protected:
virtual bool  AddNewThread(void )=0;                        //增加新線程
virtual bool  DeleteIdleThread(void)=0;                       //刪除空閑線程
static  UINT WINAPI PoolManagerProc (void* pThread);        //線程池管理線程
    static  UINT WINAPI WorkerProc (void* pThread);            //工作者線程
GThreadPoolModel::SThreadStatus  GetThreadPoolStatus( void ); //獲取線程池當前工作狀態
private:
void    Init();
void    Release();
protected:
………………………..
private:
};

以上是線程池模型的一個簡單class，而對于具體的工作處理線程池，可以由此模型進行繼承。以此來滿足具體的需要。到這里就簡單的向大家介紹了線程池的處理方式。有不對之處望指正。同時歡迎大家和我交流。

消息打包處理部分

續上在上面我簡單的說了一下服務器完成端口處理部分，接下來我想大家介紹一下關于如何建立服務器和客戶端的聯系規則，也就是服務器和客戶端的游戲協議部分。有不足之處希望大家和我進行交流。

首先解釋一下這里協議的概念，協議大家都了解是一種通信規則，例如：TCP/IP，UDP等等，這些是我們在網絡通信過程中所處理使用的協議。而我們這里的協議是我們的游戲服務器和客戶端的通信規則。簡而言之，也就是客戶端發送到服務器的數據包和服務器發送的數據包雙方解釋規則。下面就通過幾個部分來具體介紹這種協議的建立和處理。

消息頭定義

如果我們能夠解釋雙方的數據包的意義，我們就必須為雙方數據包定義一個統一規則的消息頭，我是這么定義消息頭的。服務器數據包和客戶端數據包分別定義不同的消息頭。以下就是雙方消息頭的簡單定義。

struct    ServerMsg_Head             //服務器消息頭
{
   WORD  s_version;                //版本信息
   BYTE   s_flages;                 //消息標志
   BYTE   s_who;                  //消息驅動者
   BYTE   s_sort;                   //消息類別
   BYTE   s_value;                 //消息值
   WORD  s_len;                   //消息長度
} ;

struct    ClientMsg_Head             //客戶端消息頭
{
   WORD  c_version;                //版本信息
   WORD  c_flages                  //消息標志
   WORD  c_sort;                   //消息類別
   WORD  c_value;                  //消息值
   WORD  c_scene;                  //場景信息
   WORD  c_len;                    //消息長度
};

以上是我個人簡單定義的消息頭，具體的各個參數意義，就是需要規劃設計的人來定了。這些我就不多說了。

在我們處理完我們的消息頭后，我們就可以將我們的具體游戲數據進行打包。關于數據打包，我們必須要處理兩件事情：數據打包，數據加密。為此我就建立相應的class來處理這樣的一些操作。DataCtrl.h處理如下：

class  Ppackage類可以拆解為兩個單獨處理類，打包類和解包類。而此處我就用下面一個類來進行處理。只是給大家開個頭，要設計的更好還是靠大家共同來進行斟酌呀！！

class   PPackage                                   //游戲數據包處理類
{
public:
PPackage(BYTE msg_type);                      //設置所打包消息類型
virtual ~PPackage();
//消息數據打包部分
void  SetMsgHead(void  *);                    //設置消息頭
void  AddByte(BYTE  data);                   //加入一字節
void  AddWord(WORD  data);                 //加入二字節
void  AddDword(DWORD  data);               //加入四字節
void  AddPoint(POINT  data);                  //加入八字節
void  AddBuf(char * data ,int  data_len);          //加入多個字節
//消息內容獲取
void  FinishPack();                            //完成打包
char  *GetPackage();                           //獲取數據包
int   GetPacketLen();                          //獲取數據包長度

//消息數據解包部分
void     SetMsgPackage(char *buf,int _Len);       //將獲取消息進行錄入
void    *GetMsgHead();                        //獲取消息頭數據
BYTE   GetByte();                            //獲取一字節
WORD  GetWord();                            //獲取二字節
DWORD GetDword();                           //獲取三字節
POINT * GetPoint();                            //獲取四字節
char  *  GetBuf(int buf_len);                    //獲取多字節
bool     IfFinishGet();                         //是否完成解包

private: 

void     Init();
void     Release();
void     StartBindPakage();       //開始打包
void     StartUndoPackage();     //開始解包
    bool     MessageEncrypt();       //消息加密
    bool     MessageUndo();         //消息解密

private:

private:
    BYTE   msg_type;               / /{1-SERVER_PACKAGE=1,2-CLIENT_PACKAGE=2}
char  *  msg_buffer;
char  *  buffer;                 //后備緩沖區
int      msg_len;
//消息內容長度
Server_Msg_Head  msg_Head;     //消息頭
int      buf_Len;
int      current_pos;             //指針的當前位置
protected:
};

以上就是關于服務器和消息打包類的一些建立和解釋，這些方面知識其實也沒有什么，主要是“仁者見仁，智者見智”了。而對于網絡游戲的制作最重要的還是在于Game World的規劃和設計，同時這個方面也是最難和最不好處理的。隨后將和大家進行探討。。