編者按：
這篇
文章脫胎于一個叫《游戲人成功學》的系列文章，它是作者長期身處游戲開發行業、親歷游戲行業痼疾后不吐不快的
隨筆。世界上的任何事情都是這樣，當一個人對某個事物了解越多，他也就越能清晰地看到這個事物的缺陷。編者報道游戲行業也有數年時間，覺得作者這篇文章雖然有過于“專業”的嫌疑，但比起那些行文淺顯、美化游戲行業、特意以“玩家”為對象談論游戲行業本象的文章來說，這篇文章對我們的讀者和游戲玩家也更有意義。從刊物的角度說，盡最大可能展現、記錄這個行業的方方面面，本來也是媒體份內的責任。以上就是我們選登這篇文章為本期專題的原因。
由于原文涉及到的專業術語很多，我們對之進行了幅度較大的修改，以期能使讀者更好地理解本文。
“游戲開發成功論”？
我曾寫過幾篇類似《給進入游戲行業新人的八個忠告》的文章，被個別朋友吹捧了幾下之后，自己頗有點傳道育人的成就感。但后來仔細琢磨，發現應該被教育的恰恰不是新人，而正是如我一般或比我高大睿智的所謂的老人、前輩、制作人和領導。新人終究有超過一半的機會通過試用期，但勤奮刻苦的中國游戲制作人們所領導的上百家開發公司，窮多年之力，到今天為止，真正成功的產品仍寥寥無幾，其中世界級的產品，數量等于零。對比可見，老人、前輩、領導和偽高手們比新人更需要教育。有了被教育的覺悟，首先做的是反省和自我教育，本文即是一個從業有些年頭的冒牌高手——我的幾點零碎感悟，希望能以點博面，給讀者少許啟發。
是為序。
一、從D&D看游戲的底層設計
把一個所謂的游戲意義上的偉大創意在游戲產品上付諸于實現的前提，是所有的設計應該符合游戲工業設計規范。
——龍云峰《EEE&Lumines: Design for Business》
這是我第一次看到有人這么明確且重視地提出游戲工業設計規范。在中國游戲發展這么多年的情況下，到2006年才由一個入行不久的“準老人”提出，對于所有在職的“老人”和“大師”們，都是一種絕妙的諷刺。
可能很多玩家都奇怪，為什么一個國產游戲會拖期再拖期呢？為什么拖期之后出來的卻是個
Bug不斷的半成品呢？為什么一款網絡游戲開發到后期，連畫面風格都要做出調整呢？游戲開發目前幾乎所有項目的癥結，歸根結底都與游戲設計的架構和流程有關。其實玩家們不知道，在國內游戲項目的進程中，下面這些糟糕的狀況經常會出現：
1）項目中期發現，如果編輯器支持一個特殊功能將能節省美術1/3的
工作量；
2）做到第25個月發現所有美術風格相比某游戲已完全落伍，不得不重做；
3）你和所有的人都知道游戲有什么功能，但沒有人能說出游戲為什么好玩；
4）一個程序的離職導致全部渲染底層需要重寫；
5）你的MMO內測中，發現玩家只要1星期就能練到100級，而這是游戲的最高級別；
6）游戲最終版本與提案書對比，只有不到30%的功能得以實現。
這些只是幾個我曾經聽到的例子，而很多更加荒誕的情況都在不斷上演、不斷重復。我曾經跟一個在做
項目管理的朋友說過，我們一直在重復你們過去曾經犯下的錯誤。似乎所有團隊都必然要交這樣或那樣的學費，可悲的是更多的人交了學費仍不反省，仍然采取僥幸態度忽視游戲初期設計的作用。也因此，我們今天看到的國產游戲成功者仍然寥寥無幾。
要避免后期開發中的混亂局面，在游戲設計的初期，就需要首先建立軟件工程規范化的概念。什么叫軟件工程？它是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟件的學科。它有三大要素。
1.目標：生產具有正確性、可用性及開銷合宜的產品。
2.過程：生產一個最終能滿足需求且達到工程目標的軟件產品所需要的步驟。
3.原則：是指圍繞工程設計、工程支持及工程管理在
軟件開發過程中必須遵循的原則。
游戲軟件的開發與其他軟件開發相同，都要符合軟件工程的規律。游戲的最根本本質是一個軟件，文化產品只是軟件完成后的附加屬性——很顯然的，OpenGL不僅能用于開發主視角射擊游戲，也能開發工業CAD軟件甚至遠程醫療軟件。商業軟件的系統分析是針對用戶實際的特點，來決定用戶的現實需求如何能在軟件開發中實現，而游戲軟件的開發也是同樣的道理。一款游戲是否能順利開發完成，取決于它的結構是否符合軟件工程規范，這是降低游戲開發難度和項目復雜度的前提。因此，我將游戲設計符合軟件工程的要求，定義為游戲工業設計規范的一個基本條件。
而這對現在的中國游戲人而言，無疑是一個非常苛刻的要求，或許更有人會說這在目前的國內游戲行業也是個空想。但我們不妨仔細研究一下D&D這種老牌的桌面游戲規則吧！它至少符合一個嚴格的軟件工程所需要具備的基本特征。仔細研究D&D，你會發現，所有的對象，通過基本屬性、天賦、適用規則等（內涵構件）進行定義；通過規則操作，如魔法攻擊（接口）進行相互作用；通過模板、種族、職業（類關系）進行衍生和統一。由于設計者將本來錯綜的游戲世界高度概括成數字化的規則（生物/人造/自然物件的基本屬性和基本屬性作用規則），因此在面對整個游戲世界這個巨大的復雜系統時，D&D具備幾乎無限的擴展能力，可以適應不同科學發展度，不同文化的背景設計。
理論上，構建一個虛擬的世界，它的基本要素越是高度概括和定義的，那么底層設計工作的重用性就越高，擴展性也越大，同時，由于每次依靠本層次控件和規則構成往上一個層次時都可能與最初的設想有極小的偏差，因此最終層次的表象控制就越難。如果我們把當前的宇宙視為一個游戲項目，那么，上帝至少在設計之初將“夸克”視作最底層的材料，而我們看到的整個世界都是由幾種基本的“夸克”構成的（看來上帝的美術工程師很省工）。由于層次非常多，這個世界最后的面貌很可能與上帝的提案書差距非常大。當然，上帝可以在最高層直接添加規則來更改這個差距。
D&D代表了目前游戲設計能夠高度概括到的極限（或許《進化》能打破這個紀錄，還沒有看到游戲，不知道具體情況）。我們做游戲設計，沒有必要做到這個層次，只需要抽象到玩家看到的具體控件的下面一層就可以。例如MMO中有設計紙娃娃的需求，里面有襯肩，那么，我們只要比常用的做法更進一步，將襯肩再向下一個層次，分為貼圖風格、形狀、特效種類、特效顏色4個基本控件，那么，只要每個控件做少量幾種就能組合成很多種類的襯肩，這樣規劃可大量減少美術的工作量。而常規做法只能是一個個襯肩去建模和繪制。
概括和定義底層是游戲設計對商業需求分析后最簡單的一個步驟。在分析商業需求過程中，我們可針對各個方面抽象出類似的關鍵問題：
1）NPC、怪物、Boss和玩家角色是否屬于共同的類？如果是，這個類如何定義？其子類如何定義和區分，基本屬性、骨骼、模型、紙娃娃、動作是否通用？各子類是否有必要定義各自的子類？這些所有定義對于美術和程序工作的影響何在？
2）職業、種族作為通用模板如何對上述的類中的對象進行作用，其作用是否與子類的定義相關？
3）作為場景設計的需求，有多少建筑對象以構件組合方式可以作出變化？如是，組合需要支援多少種風格？有必要單獨設計的建筑有多少？
4）有無可能以一種統一的升級規則操作基本屬性來控制所有的平衡？
這種問題還有很多，根據游戲類型的不同，進行設計時的需求也有很大變化。
游戲設計符合軟件工程的要求，需要項目負責人有基本的軟件工程知識，并有相應領域的專家加以配合。很多Boss和Leader喜歡拿到提案書就開始督促手下人干，事實上，如果給大家幾個月的時間實現一個規范的工業設計，就能避免以后無數的問題，節省大量返工的成本。
前面說到的是游戲開發這個項目的初步設計問題，接下來我想談一下我對于游戲設計過程具體管理的看法。
游戲工業的理想狀態，應該是流水線生產、精益生產、個體創造的結合，在策劃階段、游戲架構階段、試生產階段、測試階段需要采取不同的策略，從而最大程度降低風險、降低成本及控制開發時程。注意“面向過程的管理”這個精益生產的實質，正是游戲開發未來所必須追求的目標，也是實施游戲工業設計規范所不可缺的部分。長久以來，游戲業內的管理是“面向人的管理”或“面向目標的管理”，甚至有的連目標管理都沒有，而不用說進行真正的過程管理。
肯定有讀者會說：誰說中國游戲開發沒有過程管理？沒有月表么？沒有開發計劃么？沒有工作日志么？我要說的是，并不是表述了過程就可自認為進行了過程管理，也不是每天跑去問程序進度如何就是做了過程控制。“面向過程的管理”包括非常多的技巧和細節，這需要管理者去研究、規劃和控制。
二、項目開發中的混沌和秩序
我們可能都聽說過這些說法：“你不可能不勞而獲”“覆水難收”或“天網恢恢，疏而不漏”。如果這些諺語對你說來不算陌生，而且在日常生活中你也反復有過這樣的親身體驗，那么你就懂得了熱力學第一定律和第二定律。
——《熵：一種新的世界觀》
在游戲開發過程中，很多人應該有過這樣的經歷：整個項目的細節越來越多，但沒人知道整體是個什么樣子；自己做的工作越多，越感到沒有信心和無助；不斷修改、修正和返工。其實，這就是熱力學第二定律所表述的，整個項目的無序性在增加，如果不加以控制，那么最后的結果就是進入最無序的狀態，也就是整個系統的平衡態，即完全裹足不前的狀態。事實上，無論游戲制作人意識到與否，游戲能否正常開發完成、能否達到立案之初的目標，很大程度上取決于游戲團隊對抗熱力學第二定律的能力。
之所以熵增原理對游戲開發影響如此之大，是由游戲開發本身的特殊性所決定的。以制造業為對比，制造業發展到現在非常成熟，其整個工程的無序性和不確定性并不隨著規模的增長而質變，原因在于：
1）產品各部件的質量定義非常清晰（目標清晰，需求明確）；
2）每道工序對于最終產品的作用易于進行量化評估；
3）成熟的流程管理或過程管理機制；
4）專業化的團隊；
5）最重要的，足夠的理論指導和經驗積累；
以上是使傳統制造業免于熵增原理荼毒的幾個關鍵因素，而游戲開發業顯然不具備這些因素。結果就是，制造業常規狀況下都能完成產品的量產和銷售；但只有不足一半的游戲正常開發完成，而達到立案目標的可能不足2成（僅僅從國內的狀況而言可能更少）。
大型的游戲項目從立案到策劃案，到程序架構設計、底層開發、工具開發、上層邏輯編寫，到美術資源制作、到整合、到測試，經歷了一個單向資源流動的過程，這個過程類似一條河流在流動過程中不斷吸納支流，最終匯流入海。在資源傳遞的過程中，由于傳遞的層次很多，在語言和文字的表述無法絕對精確的狀況下，多次的傳遞不僅容易產生錯誤、遺漏，還會不可避免地出現誤解。每個層次資源傳遞中出現一點的偏差，匯總到最后可能出現若干巨大的錯誤，這就是“差之毫厘，謬之千里”。
在缺乏成熟管理機制的游戲開發業，使得熱力學第二定律在這方面有了很大的發揮空間。某些策劃懶得寫必要的文檔，依靠口頭說明辦事；部分團隊沒有工作總結；很多策劃不知道能通過非語言手段（圖片、拓撲等）表述信息；更多公司從來不寫會議紀要和討論紀要；絕大多數制作人都沒有項目關鍵詞定義的概念。
因此，要首先重視定義，才能制定有效的溝通機制。
在論壇里或朋友之間，我們經常能聽到某個朋友說：“如果XX游戲這樣設計就好了”，或抱怨說：“XX游戲為什么沒有繼承前一代的某種優點？”在游戲開發中，我們用“功能模塊”來表示玩家所提到的這種樂趣點。一個功能模塊往往代表了玩法的一個方面，當足夠多的模塊被整合之后，玩家所看到的就是我們希望展示的游戲世界。很多設計者試圖堆砌足夠多“好玩”的獨立系統來形成一個“足夠好玩”的游戲。“好玩”的獨立系統隨著新游戲的推出在不斷增加，因此形成一個“足夠好玩”的游戲需要的部件越來越多了。由于每個游戲模塊都會通過某些接口來操作游戲屬性/游戲進程，從而發生作用，這些操作與其他模塊的操作可能產生相似/互斥的結果，甚至可能改變其他模塊的開關狀態。因此理論上，每個新模塊被整合進入系統時，制作者都必須檢查所有與此模塊具備公共操作區域的原有模塊，甚至必須檢查所有操作可能帶來的屬性變更對依賴屬性的原有模塊的影響，這在系統足夠大的時候是不可能完成的工作。
這帶來了另外一個熵增的根源，項目的復雜度隨著模塊數量的代數遞增作幾何遞增。即制作人對項目的控制力和把握會隨著項目規模的加大而迅速降低，當復雜度到達一個臨界點時，制作者追加任何模塊，其整合成本對團隊都是無力承擔的。在這種狀態下，依靠堆砌的制作人會在一個階段之后突然發現，大量問題突然的、集約的出現。
相對穩妥的做法是：確認核心需求，并圍繞核心設計必要的外圍需求，從底層構架一個層次分明的需求，避免堆砌大而全的四不象，突出重點。
熵增原理作用的一個重要來源是缺乏計劃性。由于缺乏經驗和理論指導，加之相對漫長的開發過程導致市場的快速變化，在開發過程中，游戲制作者經常主動或被迫頻繁地調整策劃細節，這種藐視計劃性的做法直接導致軟件開發目的的不確定性遞增。而不確定性反過來作用于游戲團隊本身，使開發人員泄氣和疲憊，降低工作效率和主動性，最終沒人會相信工作計劃，也沒人會盡力做好自己的工作，因為這個工作隨時會扔進馬桶（被新的需求取代）。一種極端的狀況是，有些團隊連基本的工作計劃和里程碑都沒有，每周的工作完全是項目經理來臨時安排；另一種狀況是，一個既定的計劃不會被尊重，開發計劃幾乎每星期都會推倒修改。很顯然，這兩種狀況下開發已完全失控，其無序性遠遠超出了正常范圍，開發團隊必須付出幾倍的預算和時間才能獲得一線生機。
所以，像對待承諾一樣信守你的計劃——千萬別輕于承諾，但承諾了就要做到。
以上說的是3個常見的現象，本章我們討論的熱力學第二定律，其實代表了項目開發中混沌和秩序的對決，而對抗熱力學第二定律的實質是，追求設計規范所帶來的秩序和控制力，減少無序性和不確定性。
三、游戲設計的量化問題
我們談過了游戲開發過程中面臨的諸多問題，但這里還有一個基本問題是——是不是所有開發工作都能被量化？
很多游戲從業者都對此問題持否定的態度。游戲產業是一個創意產業，創意和藝術創作怎么能被量化？所以就有很多號稱牛人所寫的文章、接受的采訪，大談游戲開發管理的難度，主要根據是，設計工作/藝術創作無法被量化。
真是這樣么？
在長度度量衡沒有被發明之前，我們可以猜想，人類只能使用簡單的表述來說明距離或長度，例如“高”“很高”“遠”“很遠”“非常長”等，在現代人看來，這種表述“十分不量化”，但在當時的人類認知中，長度應該是無法量化的，因為缺乏一種單位標準，可以使得不同的人能對長度進行同樣精確、相同認知的表述。這里，我們可以看出，至少在數學概念的量化上，需要“單位標準”的確定作為前提。
在上面的例子中，一旦加減法被發明出來，度量衡就會出現，人們會定義長度的單位和換算方式，此時長度就變為可量化單位了（看到這里，會不會覺得《文明》系列中的科技缺了不少？）。
所以，認為游戲開發工作不能被量化的游戲開發牛人們，要么是對游戲開發工作根本不懂；要么就是對其他行業的研究成果視而不見，坐井觀天；有更多的混子們覺得“不能量化”是糊弄投資商和Boss最好的擋箭牌。
大家可以去Google查查“量化管理”，這已經是項目管理學最基本的概念，但居然還有這么多游戲業的牛人、老人嚷嚷無法量化，只能說悲哀，這行業的現狀讓人欲哭無淚。
關于如何“量化”的攻略不管是在網上還是網下都已非常多了，也非常系統了，這里且不多說。大家去搜索一下，注意多看廣告和網站的，人家本質上也是創意產業……看完以后你保證有抽那些“無法量化”牛人的沖動。
在整個游戲開發設計過程中，沒有一個階段是絕對無法量化的，不過存在一個量化成本的問題。因為量化需要度量，度量過程需要建立標準、對比標準，對于很多無法用數字表述，必須借助統計甚至拓撲來表述的量化目標來說，這個操作過程的成本很高。所以在游戲最初設計的階段，也就是量化成本最高的階段，不必使用“量化”的概念去管理和操作。但在后續開發中，必須將程序、美術等工作都做到量化管理，這是使游戲成為工業化生產的前提，也是我們進行規范的前提。
四、專業精神
有位被稱為物理學大師的老先生曾經放言：“中國高校對于中國發展作出的貢獻，遠遠大于美國最好的大學對于美國發展作出的貢獻”。先不說老先生如何得出這個結論，單單只看字面的意思，很容易發現一個邏輯常識問題，就是用“中國高校”這個大集合與“美國最好的大學”這個小集合進行對比。這種連小學生都能發現的錯誤居然被多家媒體轉載引用，實在令人匪夷所思。由此可見，現代人對于邏輯嚴謹、謹慎求證的基本研究態度的缺失十分驚人。
一個諾貝爾物理學獎獲得者總說類似如此不專業的話（之前還說過“中國科技落后的原因是易經”“清華學生強于哈佛”等），使我這樣一個物理系畢業生非常慶幸自己沒有資格搞物理研究。但高興未過半，反過頭來一看中國游戲行業，亦如是也！不加考證、沒有數據、沒有案例，太多人開口就可以大肆放炮，提出各種貌似有理的結論，事實上，仔細看看他們的文章或言論，除了結論，什么都沒有……
所以，請在你看跟行業有關的所有文章時（包括本文），仔細看看結論之前的論證過程是否存在，是否合理。
上文似乎與正題無關，但其實關系大得了不得。因為立項、開發中的陷阱，其來源往往是這種看似理直氣壯，卻無法抽象、無法量化、無法證明的結論。舉個例子，根據我的觀察，一旦游戲產品的游戲性在測試中不被認可，大部分“資深”策劃都會歸結于“我們的系統太少，不夠豐富”，結論是“要增加《魔獸世界》（或其他XX游戲）也有的系統，甚至更多”。類似的論調往往能獲得很多贊同和喝彩，而很顯然的，這樣的結論可以洗脫所有人之前的責任，也能為混工資的項目高層多爭取一些時間。但至于這個結論是怎么得出來的卻沒人關心，或以一句“這是經驗”代替了論證——結果常常是項目因此而滑向“全而疏”的失控深淵。
“知其然”重要，“知其所以然”更重要。因為不能“知其所以然”，那個“其然”很可能是某感知力不足人的直覺。兵無常勢，水無常形，在變化如此迅速的行業中，任何只有個別案例的經驗總結，如果不能被抽象、推演或證明，其作用就值得懷疑。
事實上，現階段的年輕人，大抵是喜歡“攻略式”的成功捷徑，樂于研究表象之“術”而并非深層之“道”，因此只有結論的填鴨文章倒成了最受歡迎速成的武功心法。可以想象，如果我寫個游戲開發必勝100招，只寫一堆狗屁結論，必定人氣旺到爆，且留言中的崇拜者、仰慕者、流口水者、要求合作創業者必定多到叫喊“中國游戲業沒有人才”的行業資深人士們羨慕的地步。
填鴨成功學給所有畏懼困難和缺乏鉆研能力的人一個海市蜃樓，這個看似美妙的綠洲幻境后面，掩藏著無數投資者和熱血青年的尸骨，而這些尸骨的游魂如同“為虎作倀”的“倀鬼”一樣，繼續以他們的所謂血淚和經驗拼湊新的填鴨成功學，引誘下批冒險者。
填鴨成功學只是從一個側面反映出我們多么缺乏真正專業的制作者和決策者。
我們先來考慮第1個問題：
黑社會和街頭混混的區別是什么？
我們知道《教父》中的黑社會有很多特征，是任何街頭混混都無法比擬的，列舉幾個：
1）嚴密的組織分工，每個人都有自己的專責（有組織結構和職位說明書）；
2）黑白道的關系網（有行業背景）；
3）固定的灰色收入渠道（有盈利模式）；
4）有專門的用于行業聯絡的黑話（使用行業術語交流）
5）成員有自制力、紀律性、信仰“我們的事業”（有企業文化）；
這些種種特征，加上黑社會成員的事業心和敬業精神，我們其實看到的“專業精神”在行業中的體現，換言之，黑社會和街頭混混的區別是，一為專業，一為業余。
第2個已經不用回答的問題：
游戲從業者和玩家的區別是什么？
我常常問提出建議和意見的同事，你的想法跟玩家有什么區別？
黑島，以“忠于RPG，忠于玩家”聞名，能夠忠于自己的職業和角色，這就是游戲從業者專業最基本的表現。游戲行業的工作涉及到方方面面，游戲外盒設計者是否以專業外觀設計師的標準要求自己？游戲項目經理是否具備軟件項目管理的基本理念和技能？游戲QA是否制定了專業的反饋流程和機制？以這種標準來看，中國不僅缺乏專業的從業者，甚至連專業的公司都寥寥無及。
專業從業者應該首先把自己從玩家的身份中升華出來，能總結玩家的反應，能將玩家眼中混沌的系統分離成為清晰的個體，能將實際抽象為理論，能將感受量化成數據。如果一個從業者的作用只是傳遞玩家的信息或把自己作為玩家感受的信息整理出來，那么這個從業者實質上對于整個團隊是沒有價值的。如果你做的僅僅是玩家能做的，那么組織要你干嗎？
第3個值得我們探討的問題：
我們用什么去定義“游戲從業者的專業精神”？
任何行業的“專業”二字，都不僅僅是技術的體現，按照大前研一的定義，技術精通者應稱為專長者。英文過專八的研究生，未必能進行專業的翻譯；同理，一個會寫策劃案或營銷計劃的人，未必是專業的游戲從業者。
對于不同職位的從業者，我們不能苛求一種專業的標準，但無論GM還是總經理，專業與否最直接的判斷就是，專業者為尋求最精益最科學的工作結果而奮斗。如果考慮到個人與組織的協調，我們可以加上第二層的判斷：專業者為個人工作結果促進組織成長作用最大化而奮斗。
就這么簡單。
可是有幾個人能做到呢？
對希望自己成為游戲業內專業人士的讀者，推薦大前研一的《專業主義》。
五、戰略的價值
戰略的定義和價值問題一直是企業家和專業人士理解不太清晰的幾個事中的兩件事。學者和咨詢公司把它說得神乎其神，實業家﹑經驗主義者又往往對戰略嗤之以鼻，認為它一錢不值，對于戰略家的高談闊論不屑一顧。
——鄭文斌
戰略是一個可以被多層細分的名詞，最被中國企業所常常提到的是“管理戰略”“市場戰略”“企業戰略”等，這些是針對企業不同環節或不同層次對戰略的細化。在游戲行業，我們常常聽到的是“概念”“目標”被冠以“戰略”。例如，盛大曾經提出要做“網上迪斯尼”，被很多人稱為戰略，其實僅僅是個長期目標而已。如果蘇軍在衛國戰爭的戰略僅僅是“打敗法西斯”，我估計二戰的歷史都要被改寫了。中國游戲圈是我所見到的最喜歡通過濫用各種術語以拔高自己身份的自卑群體。而戰略這個詞被濫用造成的結果就是，幾乎所有人都搞不清楚什么是戰略，戰略有什么用。
我們先從戰爭來看看什么是戰略。《戰爭論》對戰略定義為“戰略就是為了達到戰爭目的而對戰斗的運用。”針對戰略和戰術的關系，《戰爭論》提出“戰略是對整個戰爭的籌劃”“戰術是對某一作戰行動的籌劃。”在戰爭中，大本營/總參需要針對自己和敵方的態勢、情況，決定如何達成戰爭的目的，并加以貫徹。在二戰中，德軍的“閃電戰”、蘇聯紅軍的“大縱深”、日軍的“火力優勢作戰”、我國的“人民戰爭”都屬于戰略層面。而相對應的“先鋒旅指揮”“機械化波動進攻”“側翼突破”“游擊戰”就屬于戰術層面。戰術服務于戰略，而戰略則指導了戰術。
在企業中，戰略影響也非常大，往往決定一個企業的盛衰。在游戲業，戰略也有血淋淋的案例擺在眼前，華義、大宇等老牌廠商對于大陸市場的喪失，與其戰略可以說不無關系；盛大的所謂IPTV戰略（稱為戰略還是大了，IPTV應該看作盛大多元化戰略的一個關鍵戰術調整），間接幫助網易成為行業老大。
對于游戲公司，戰略可沿用鄭文斌博士的定義。“戰略是確定企業長遠發展目標，并指出實現長遠目標的策略和途徑。戰略確定的目標與企業的宗旨和使命必須相吻合。”在此定義的基礎上，我認為，游戲開發公司的領導者必須明確以下問題：
1）公司發展的終極目標是什么？對應此終極目標員工的愿景為何？
2）公司的核心競爭力是什么？此核心競爭力如何保持和加強？
3）在游戲行業中，公司的位置和面臨的態勢？未來如何改善這個態勢？
4）保證實現目標的資源有哪些？如何組織這些資源？
5）風險有哪些？如何通過制度和福利降低風險？
6）開發流程的管理采取什么樣的模式才能最大程度發揮核心競爭力？
7）游戲產品的定位，開發什么題材、什么類型的產品？產品之間如何互補？
先明確了這幾個問題，才能制定公司的戰略，戰略應該圍繞目標來制定，同時也要考慮自己公司的實際情況和外部環境。例如最簡單的，有些公司“兩條腿走路”，引進產品和資助開發結合，就是最基本的產品戰略，是總體戰略的一部分。
再強調一遍，戰略是非常重要的。很多戰略經常變動、戰略有問題或戰略落實不足的游戲公司，已經給我們做了反面教材。我曾經聽說，一個大裁員的公司老總抱怨，裁員的原因是，被開的員工腦子全部停留在單機時代的設計理念，根本做不出好網游，只能開掉。理由似乎合理，但其實非常荒唐，員工是誰請來的？公司管理層請的，在公司提出相應戰略之后請的；員工是怎么干活的？是在管理層的意志下干活的，是在公司戰略指導下干活的。做出的項目失敗是管理層的戰略失敗，怎么能怪員工思想保守呢？可現實往往是，高層的戰略失敗，偏偏由員工買單，被裁掉甚至被拖欠工資，這似乎已成了IT的一個規則。
所以說，就算你不是高層也不想做高層，只想進入游戲行業踏實打工，了解公司戰略也是很重要的，不然下次給垃圾戰略買單的就可能是你。
說到底，某些高層根本沒有想過以游戲立業，他們甚至連自己的核心業務是什么都不清楚，他們的規劃中根本沒有長期戰略，更充斥著各種不切實際的短期盈利狂想。在這種情況下，決定公司方向的就是能不能賺快錢，能不能忽悠投資商和股民，也因此很多概念和口號被包裝成為他們的所謂“戰略”。至于游戲業務，只是很多“有奶便是娘”的奶媽之一。
這個行業真正需要是“忠于游戲”“以游戲為業”的公司和團隊。一些公司和團隊無法存活，表面上看來是人有問題（最常見的就是“策劃不夠專業”），但事實上往往是公司的戰略和定位缺失。假使戰略問題繼續得不到重視，我們這個行業將陷入低水平重復的泥潭。
篇后記：
在游戲開發的圈子里，見識了很多被游戲開發所成就或傷害的精英，也看了他們所寫的形形色色文章、書籍、Blog。其中多有怨天尤人的、譏諷謾罵的、自賣自夸的、乞求玩家買正版的、裝大師大談成功攻略的，唯獨老老實實總結點經驗并愿意共享出來的很少。
而很現實的狀況是，幾乎所有中國游戲制作團隊都在重復犯前人的錯誤。
所以起意寫本文的初衷就是想能整理一些給其他業者有用的，也供自己反省的東西。因個人能力和時間所限，斷斷續續寫了很久才攢了5節。
軟件
配置管理是對
軟件開發階段的演化和變更進行管理；貫穿軟件整個生命周期，從立項、需求定義、計劃、設計、實現、
測試再到發行，配置管理需要記錄每一次里程碑轉變的條件和結果，并且要能通過配置管理系統記錄的文檔和過程可以重現某個過程，也就是要能完整的記錄整個研發過程，配置管理系統在定義配置項時要將項目中的每一個變化都反映到配置管理系統中；
目前公司存在的問題是
1、各個階段的配置項依賴關系沒有辦法追蹤，只知道有這些配置項，但是并不知道這些配置項之間的關系，哪個配置項先確立、哪個后確立；
2、各個階段之間的配置項的依賴關系也沒有記錄，只是有各個階段的入口條件；
3、沒有統一的系統來管理諸如代碼、文檔、需求、測試、發行版本等；每一種配置項都存放在不同的管理工具中，如代碼用CC來管理，文檔由PDM來管理，發行版本流程也由PDM來管理，發行版本的存放由windows共享來管理，變更則由CQ來管理；各個管理工具不統一使得基線的創建困難重重，目前我們基線的創立僅僅是文檔的到位，基線創建時對應的版本是什么只能去查找文檔內容，而不能使整個基線內容一目了然；
解決的最佳方案是：
建立單一的配置管理系統，或者各個系統之間能建立自動的聯系；各個配置項的依賴關系也能一目了然；
前段時間做了一個開發，涉及到網絡編程，開發過程比較順利，但任務完成后始終覺得有一些疑惑。主要是因為對網絡協議不太熟悉，對一些概念也沒弄清楚。后來 我花了一些時間去了解這些網絡協議，現在對TCP/IP網絡協議有了初步的認識，在這里總結出來，可以梳理一下我對網絡協議的理解，加深印象.
話說兩臺電腦要通訊就必須遵守共同的規則，就好比兩個人要溝通就必須使用共同的語言一樣。一個只懂英語的人，和一個只懂中文的人由于沒有共同的語言（規則）就沒辦法溝通。兩臺電腦之間進行通訊所共同遵守的規則，就是網絡協議。
那么誰來制定這個網絡協議？
國際標準化組織(ISO)定義了網絡協議的基本框架，被稱為OSI模型。要制定通訊規則，內容會很多，比如要考慮A電腦如何找到B電腦，A電腦在發送信息 給B電腦時是否需要B電腦進行反饋，A電腦傳送給B電腦的數據的格式又是怎樣的？內容太多太雜，所以OSI模型將這些通訊標準進行層次劃分，每一層次解決 一個類別的問題，這樣就使得標準的制定沒那么復雜。OSI模型制定的七層標準模型，分別是：應用層，表示層，會話層，傳輸層，網絡層，數據鏈路層，物理 層。
雖然國際標準化組織制定了這樣一個網絡協議的模型，但是實際上
互聯網通訊使用的網絡協議是TCP/IP網絡協議。
TCP/IP 是一個協議族，也是按照層次劃分。共四層：應用層，傳輸層，互連網絡層，網絡接口層。 那么TCP/IP協議和OSI模型有什么區別呢？OSI網絡協議模型，是一個參考模型，而TCP/IP協議是事實上的標準。TCP/IP協議參考了OSI 模型，但是并沒有嚴格按照OSI規定的七層去劃分標準，而只劃分了四層，個人覺得這樣會更簡單點，當劃分太多層次時，你很難區分某個協議是屬于哪個層次 的。TCP/IP協議和OSI模型也并不沖突，TCP/IP協議中的應用層協議，就對應于OSI中的應用層，表示層，會話層。就像以前有工業部和信息產業 部，現在實行大部制后只有工業和信息化部一個部門，但是這個部門還是要做以前兩個部門一樣多的事情，本質上沒有多大的差別。TCP/IP中有兩個重要的協 議，傳輸層的TCP協議和互連網絡層的IP協議，因此就拿這兩個協議做代表，來命名整個協議族了，在說TCP/IP協議時，是指整個協議族。
TCP/IP協議分為四個層次，但我們并不需要了解所有層次的協議，我覺得主要關注應用層和傳輸層的協議就可以了。拿寄送郵件舉例， A寄郵件給B，A關心的是用什么格式寫什么內容給B（應用層內容），是寄掛號信還是寄平信（傳輸層內容），但是A是不會去關注郵件傳送過程中采用了那條路 線，郵遞員是如何把信件遞送到B手里的（互連網絡層，網絡接口層）。
先說傳輸層，傳輸層有多個協議，但最主要的是TCP和UDP協議。兩則的區別在于TCP協議需要接收方反饋，UDP協議不需要接收方反饋。TCP就像掛號 信，A電腦發信息給B電腦后，需要得到B電腦的反饋，這樣A電腦就能知道B電腦是否已經收到信息。UDP就像平信，A電腦發信息給B電腦后，B電腦并不給 A電腦發聵，A電腦發送信息出去后并不知道B電腦是否已經收到。 因此，TCP傳輸比UDP傳送更可靠，但是TCP傳輸的效率就不如UDP了。至于，在傳送過程中具體選擇哪種傳送方式，需要具體問題具體分析。在不可靠的 網絡傳送過程中一般選擇TCP傳送方式。在講求效率，或者不在乎傳送失誤的情況下可以選擇UDP方式來提高傳輸速率。
應用層的協議有很多，每一個協議代表一種類型的服務。HTTP協議，萬維網服務。FTP協議，文件傳送服務。POP3，郵件服務，SOAP協議webService服務。
在理解TCP/IP協議的過程中，我遇到了三個困惑。
1.什么是socket?
以前有聽說過socket編程這種說法，也有的說套接字編程。我在搜索關于socket的資料時，發現有的說socket是指一個連接，有的說 socket是一指一個端點。拿打電話做比喻，A電話機和B電話機正在通話，那么socket是指的A和B之間的連接線呢，還是指電話機（端點）？
我現在的理解是，socket就是一個連接中的一個端點，一次通訊（連接）a,b端都會有一個socket。一個socket對應一個連接。
2.http協議屬于應用層還是傳輸層？
http 超文本傳送協議，聽上去像是傳輸層的協議一樣。但事實上大家都知道http和ftp一樣都是屬于應用層的協議，我先前很納悶的是，既然是應用層的協議，怎 么就取這樣一個誤導人的名稱啊。在對TCP/IP協議還不熟悉的時候，這很容易讓人誤解和納悶的。后來，我在wiki上發現這么一段話：
http中文譯名問題
HTTP 在中國大陸被翻譯為“超文本傳輸協議”，因為“transfer”在中文里有“傳輸”的含意。但依據 HTTP 定制者之一的 Ro Fielding博士的論文[1]（6.5.3節），作者專門強調“transfer”表示的是“（表述狀態的）轉移” （Representational Stat Transfer），而不是“傳輸”（transport）。故其中文譯名“超文本傳輸協議”恰恰引種反映了這種誤解。更符合原義的譯名應該為“超文本轉 移協議”。
這段話解除了我的疑惑。那么http協議當然是應用層的協議。
3.SOAP可以使用HTTP協議進行傳輸嗎？
在了解SOAP協議的過程中，看到介紹說soap可以通過tcp,udp,http協議來傳送。這也是讓人困惑的描述。一看這句話，就會感覺http怎么 和tcp,udp協議并列了呢？難道http還是屬于傳輸層的協議？再加上http中文譯名的問題，名字聽上去像傳輸層，初學者又要開始頭大了。
事實上，http是應用層的協議，這一點可以毫無懷疑。那么現在新的問題來了。soap和http都是應用層協議，怎么說soap能用http協議來傳輸呢？應用層的協議可以用應用層的協議傳送嗎？
我查閱了資料，是這樣一回事情，soap將信息進行XML的序列化后，再用http協議的方式再打包進行傳送，傳送的方式還是tcp或者udp。做個比喻 就好理解了。tcp 和 udp 都是公路，暫且把tcp認為是一般公路，udp高速公路，soap和http就都是汽車，那么soap和http都可以在tcp和udp上跑。說soap 可以通過http來傳送，實際就是說soap是小轎車，http是裝轎車的卡車，把soap的信息裝到http里面，然后再運輸，當然走的道路還是tcp 或udp。
說soap可以通過http協議來傳輸，這句話不太準確，比較準確第說法是：soap信息可以通過http協議包裝后通過tcp或udp傳輸。
使用Bugfree2.1后發現配置好郵件參數后，在指派
bug時能正常發送郵件，但始終無法使用其定期發送統計郵件和通知郵件的功能，雖然照官網上說的配置了計劃任務，修改了
shell目錄下的兩個bat文件，但仍然沒有解決。后來裝了個php調試器，逐步調試終于找到問題原因：
1、創建項目時沒有填寫“通知郵件”的屬性，導致執行statbug.php文件時找不到接受信息的電子郵件地址；
2、statbug.php文件的第251行中$CSSStyle=出現了多余的字符串‘PWD’刪除后即可；
3、shell目錄下的statbug.bat文件中命令缺少一個默認的參數:http://www.bugfree.org.cn
修改后的statbug.bat文件內容為：
c:/xampp/php/php.exe c:/xampp/htdocs/bugfree/StatBug.php http://www.bugfree.org.cn
這樣再次運行后就可以正常發送統計郵件了，下面是效果圖：
作者在這篇
文章中, 列出了七個項目, 指出怎樣的開發人員, 才是
測試人員心中的好的RD.
1. 不要考驗你的測試人員
即使你和測試人員的關系不好, 也不要故意制造bug, 來考驗你測試人員的程度.
2. 自己做自己的驗收測試
通常開發人員知道要去進行
單元測試, 但是往往忽略了GUI測試以及usability testing. 建議開發人員每次要記得去進行小規模的驗收測試, 來及早發現一些usability的issues
3. 不要一直犯同樣的錯誤
測試人員最討厭的是開發人員老是一直犯樣的錯誤. 每當功能有修改時, 測試人員常常能預測開發人員會忘記處理哪些事情. 開發仁要記得從中學得教訓
4. 他們并不想傷害你
開發人員通常認為測試人員都是在找他們的問題或是麻煩. 所以她們很害怕進行測試, 但是事實上他們需要與測試人員合作, 以確保整個系統的質量.
5. 不要把質量的責任推給測試人員
另一件不好的事情, 是開發人員對于客戶遭遇到的問題不感興趣, 認為這是質量的問題. 必須要記住, 質量是整個團隊的責任, 開發人員不是只是要寫code, 也要負擔起質量的責任
6. 要撰寫批注和可讀性高的程序代碼
7. 提供有敘述性的錯誤警報
若是開發人員在顯示錯誤訊息時, 能夠更具體更有意義, 會幫助測試人員測試
工作的進行. 不要老是顯示相同, 或是沒有意義的訊息.
AJAX = Asynchronous JavaScript and XML (異步的JavaScript和XML)。
AJAX不是新技術 ，但卻是熱門的技術。它可以在不重載（刷新）整個頁面的情況下與服務器進行數據交互并更新網頁模塊。
AJAX的優點有很多：可以局部刷新、按需加載，這樣就減輕了服務器的數據流量。并且在頁面更新的同時，用戶可以瀏覽器網頁的其它內容而不受影響，也減輕了結構負擔。AJAX也不是萬能的，在有以上優點的同時SEO也受到了影響。
在學習AJAX之前，必須先有HTML/XHTML、CSS、JavaScript/DOM的基礎。
AJAX與服務器進行數據交互，必然涉及到服務器端，與此同時也就涉及到了服務器請求對象的創建(new XMLHttpRequest())、確認請求方式(open())、發送請求(send())以及響應請求(responseText)。
創建對象：
IE9+及其它瀏覽器支持使用new XMLHttpRequest()的創建對象方式，而IE8及以下則使用new ActiveXObject()的方式進行創建。
看了網上許多人使用如下代碼進行兼容：
1 try { 2 xml = new ActiveXObject("Msxml2.XMLHTTP"); 3 } catch(e) { 4 try { 5 xml = new ActiveXObject("Microsoft.XMLHTTP"); 6 } catch(e1) { 7 xml = new XMLHttpRequest(); 8 } 9 } |
筆者用IE11調試功能測試IE10及以下不寫new ActiveXObject("Msxml2.XMLHTTP")也是沒問題的，于是在創建對象時可以使用代碼：
var xml = window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
確認請求：
xml.open('get', 'url', true/false);
第一個參數表示：string. 訪問方式，有兩具值：get/post，大部分的時候使用get
第二個參數表示：string. 要連接的服務器網址
第三個參數表示：boolean. 表示是否需要異步請求（true為發起異步加載）
發送請求：
xml.send();
如果需要發送數據則采用xml.send(str);
響應數據：
xml.onreadystatechange = function() {
if (xml.readyState == 4 && xml.status == 200) {
alert(xml.responseText);
}
}
status返回鏈接的狀態，一般返回200與404，200表示成功返回，404表示未找到頁面。
readyState有5個值，分別為：0、1、2、3、4。而每當值改變時都會觸發一次onreadystatechange。
readyState的5個值含義分別為：
0: 請求未初始化
1: 服務器連接已建立
2: 請求已接收
3: 請求處理中
4: 請求已完成，且響應已就緒
也就是當請求完成，并且找到頁面時，然后才獲取服務器上的數據。
定時器—有時也稱為動態定時器或內核定時器—是管理內核時間的基礎。定時器是一種軟件功能，即允許在將來的某個時刻，函數在給定的時間間隔用完時被調用。注意的是定時器并不會周期運行，它在超時后就自行銷毀，這也是定時器被稱為動態定時器的一個原因。動態定時器不斷地創建和銷毀，而且它的運行次數也不受限制。
定時器在內核代碼中屬于一個基礎組件。要想完全弄清楚linux2.6中內核定時器的實現，得先從初始化開始。
在start_kernel(void)-->init_timers(void)
void __init init_timers(void) { int err = timer_cpu_notify(&timers_nb, (unsigned long)CPU_UP_PREPARE, (void *)(long)smp_processor_id()); init_timer_stats(); BUG_ON(err == NOTIFY_BAD); register_cpu_notifier(&timers_nb); open_softirq(TIMER_SOFTIRQ, run_timer_softirq); } 在timer_cpu_notify(&timers_nb,(unsigned long)CPU_UP_PREPARE, (void*)(long)smp_processor_id()); |
中執行
init_timers_cpu(cpu) //初始化本cpu中的timers
初始化的主要代碼是：
spin_lock_init(&base->lock); for (j = 0; j < TVN_SIZE; j++) { INIT_LIST_HEAD(base->tv5.vec + j); INIT_LIST_HEAD(base->tv4.vec + j); INIT_LIST_HEAD(base->tv3.vec + j); INIT_LIST_HEAD(base->tv2.vec + j); } for (j = 0; j < TVR_SIZE; j++) INIT_LIST_HEAD(base->tv1.vec + j); base->timer_jiffies = jiffies; base->next_timer = base->timer_jiffies; |
這段代碼的主體是base，base的定義是：structtvec_base *base;
這個tvec_base是動態定時器的主要數據結構，每個cpu上有一個，它包含相應cpu中處理動態定時器需要的所有數據。為簡化分析僅考慮單cpu。給出這個數據機構：
struct tvec_base { spinlock_t lock; struct timer_list *running_timer; unsigned long timer_jiffies; unsigned long next_timer; struct tvec_root tv1; struct tvec tv2; struct tvec tv3; struct tvec tv4; struct tvec tv5; } ____cacheline_aligned; |
注意：支持將數據從
SQL Server 2000遷移到Microsoft SQL Server 2000（64位）。您可以將一個32位
數據庫附加到一個64位數據庫上，方法是：使用sp_attach_db系統存儲過程或sp_attach_single_file_db系統存儲過程，或者使用32位企業管理器中的備份和還原功能。您可以在SQL Server的32位和64位兩種版本之間來回
移動數據庫。您還可以使用同樣的方法從SQL Server 7.0遷移數據。但是，不支持將數據從SQL Server 2000（64位）降級到SQL Server 7.0。下面分別介紹這幾種方法。
如果您使用的是SQL Server 2005
您可以使用相同的方法從SQL Server 7.0或SQL Server 2000遷移數據。但是，Microsoft SQL Server 2005中的管理工具與SQL Server 7.0或SQL Server 2000中的管理工具有所不同。您應該使用SQL Server Management Studio（而不是SQL Server企業管理器）以及SQL Server導入和導出向導(DTSWizard.exe)（而不是數據轉換服務導入和導出數據向導）。
備份和還原
在源服務器上備份用戶數據庫，然后將用戶數據庫還原到目標服務器上。在備份過程中時可能有人使用數據庫。如果用戶在備份完成后對數據庫執行INSERT、UPDATE或DELETE語句，則備份中不會包含這些更改。如果您必須傳輸所有更改，那么，假如您既執行事務日志備份又執行完整數據庫備份，您可以以盡可能短的停止時間來傳輸這些更改。
1.在目標服務器上還原完整數據庫備份，并指定WITH NORECOVERY選項。
注意：為防止對數據庫做進一步的修改，請指導用戶在源服務器上退出數據庫活動。
2.執行事務日志備份，然后使用WITH RECOVERY選項將事務日志備份還原到目標服務器上。停止時間僅限于事務日志備份和恢復的時間。
◆目標服務器上的數據庫將與源服務器上的數據庫大小相同。要減小數據庫的大小，您必須在執行備份前壓縮源數據庫的大小，或者在完成還原后壓縮目標數據庫的大小。
◆如果您將數據庫還原到的文件位置不同于源數據庫的文件位置，則必須指定WITH MOVE選項。例如，在源服務器上，數據庫位于D:/Mssql/Data文件夾中。目標服務器沒有D驅動器，因而您需要將數據庫還原到C:/Mssql/Data文件夾。有關如何將數據庫還原到其他位置的更多信息，請查看相關資料。
◆如果您想覆蓋目標服務器上的一個現有數據庫，則必須指定WITH REPLACE選項。
◆源服務器和目標服務器上的字符集、排序順序和Unicode整序可能必須相同，具體取決于您要還原到SQL Server的哪種版本。有關更多信息，請參閱本文中的“關于排序規則的說明”一節。
Sp_detach_db和Sp_attach_db存儲過程
要使用sp_detach_db和sp_attach_db這兩個存儲過程，請按下列步驟操作：
1.使用sp_detach_db存儲過程分離源服務器上的數據庫。您必須將與數據庫關聯的.mdf、.ndf和.ldf這三個文件復制到目標服務器上。參見下表中對文件類型的描述：
文件擴展名
說明
.mdf
主要數據文件
.ndf
輔助數據文件
.ldf
事務日志文件
2.使用sp_attach_db存儲過程將數據庫附加到目標服務器上，并指向您在上一步驟中復制到目標服務器的文件。
◆分離數據庫后將無法訪問該數據庫，并且復制文件時也無法使用該數據庫。在進行分離的那一時刻數據庫中包含的所有數據都被移動。
◆在您使用附加或分離方法時，兩個服務器上的字符集、排序順序和Unicode整序都必須相同。有關更多信息，請參閱本文中的“關于排序規則的說明”一節。
關于排序規則的說明 如果您使用備份和還原或附加和分離方法在兩個SQL Server 7.0服務器之間移動數據庫，則兩個服務器上的字符集、排序順序和Unicode整序都必須相同。如果您將數據庫從SQL Server 7.0移到SQL Server 2000，或者在不同的SQL Server 2000服務器之間移動數據庫，則數據庫將保留源數據庫的整序。這意味著，如果運行SQL Server 2000的目標服務器的整序與源數據庫的整序不同，則目標數據庫的整序也將與目標服務器的master、model、tempdb和msdb數據庫的整序不同。
第1步：導入和導出數據（在SQL Server數據庫之間復制對象和數據）
您可以使用數據轉換服務導入和導出數據向導來復制整個數據庫或有選擇地將源數據庫中的對象和數據復制到目標數據庫。在傳輸過程中，可能有人在使用源數據庫。如果在傳輸過程中有人在使用源數據庫，您可能會看到傳輸過程中出現一些阻滯現象。
◆在您使用導入和導出數據向導時，源服務器與目標服務器的字符集、排序順序和整序不必相同。
◆因為源數據庫中未使用的空間不會移動，所以目標數據庫不必與源數據庫一樣大。同樣，如果您只移動某些對象，則目標數據庫也不必與源數據庫一樣大。
◆SQL Server 7.0數據轉換服務可能無法正確地傳輸大于64KB的文本和圖像數據。但SQL Server 2000版本的數據轉換服務不存在此問題。
第2步：如何傳輸登錄和密碼
如果您不將源服務器中的登錄傳輸到目標服務器，當前的SQL Server用戶就無法登錄到目標服務器。目標服務器上的登錄的默認數據庫可能與源服務器上的登錄的默認數據庫不同。您可以使用sp_defaultdb存儲過程來更改登錄的默認數據庫。
#p#
第3步：如何解決孤立用戶
在您向目標服務器傳輸登錄和密碼后，用戶可能還無法訪問數據庫。登錄與用戶是靠安全識別符(SID)關聯在一起的；在您移動數據庫后，如果SID不一致，SQL Server可能會拒絕用戶訪問數據庫。此問題稱為孤立用戶。如果您使用SQL Server 2000 DTS傳輸登錄功能來傳輸登錄和密碼，就可能會產生孤立用戶。此外，被允許訪問與源服務器處于不同域中的目標服務器的集成登錄帳戶，也會導致出現孤立用戶。
1.查找孤立用戶。在目標服務器上打開查詢分析器，然后在您移動的用戶數據庫中運行以下代碼：
exec sp_change_users_login 'Report'
此過程將列出任何未鏈接到一個登錄帳戶的孤立用戶。如果沒有列出用戶，請跳過第2步和第3步，直接進行第4步。
2.解決孤立用戶問題。如果一個用戶是孤立用戶，數據庫用戶可以成功登錄到服務器，但卻無權訪問數據庫。如果您嘗試向數據庫授予登錄訪問權，則會因該用戶已經存在而出現下列錯誤消息：
Microsoft SQL-DMO (ODBC SQLState:42000)
錯誤15023:當前數據庫中已存在用戶或角色'%s'。上面介紹了如何使用sp_change_users_login存儲過程來逐個糾正孤立用戶。sp_change_users_login存儲過程僅能解決標準的SQL Server登錄帳戶的孤立用戶問題。
3.如果數據庫所有者(dbo)被當作孤立用戶列出，請在用戶數據庫中運行下面的代碼：exec sp_changedbowner 'sa'此存儲過程會將數據庫所有者更改為dbo并解決這個問題。要將數據庫所有者更改為另一用戶，請使用您想使用的用戶再次運行sp_changedbowner。
4.如果您的目標服務器運行的是SQL Server 2000 Service Pack 1，則在您執行附加操作或還原操作（或兩種操作都執行）后，企業管理器的用戶文件夾中的列表中可能沒有數據庫所有者用戶。
5.如果目標服務器上不存在映射到源服務器上的dbo的登錄，您在嘗試通過企業管理器更改系統管理員(sa)密碼時，可能會收到以下錯誤消息：
錯誤21776:[SQL-DMO]名稱'dbo'在Users集合中沒有找到。如果該名稱是合法名稱，則使用[]來分隔名稱的不同部分，然后重試。
警告：如果您再次還原或附加數據庫，則數據庫用戶可能會再次被孤立，這樣您就必須重復第3步操作。
第4步：如何移動作業、警報和運算符
第4步是可選操作。您可以為源服務器上的所有作業、警報和運算符生成腳本，然后在目標服務器上運行腳本。要移動作業、警報和運算符，請按照下列步驟操作：
1.打開SQL Server企業管理器，然后展開管理文件夾。
2.展開SQL Server代理，然后右鍵單擊警報、作業或運算符。
3.單擊所有任務，然后單擊生成SQL腳本。對于SQL Server 7.0，請單擊為所有作業生成腳本、警報或運算符。
您可以用右鍵單擊選擇為所有警報、所有作業或所有運算符生成腳本。
◆您可以將作業、警報和運算符從SQL Server 7.0移到SQL Server 2000，也可以在運行SQL Server 7.0和運行SQL Server 2000計算機之間移動。
◆如果在源服務器上為運算符設置了SQLMail通知，則目標服務器上也必須設置SQLMail，才能具有相同的功能。
第5步：如何移動DTS包
第5步是可選操作。如果DTS包在源服務器上存儲在SQL Server中或存儲庫中，您可以在需要時移動這些包。要在服務器之間移動DTS包，請使用下列方法之一。
方法1
1.在源服務器上將DTS包保存到一個文件中，然后在目標服務器上打開DTS包文件。
2.將目標服務器上的包保存到SQL Server或存儲庫中。
注意：您必須用單獨的文件逐個地移動這些包。
方法2
1.在DTS設計器中打開每個DTS包。
2.在包菜單上，單擊另存為。
3.指定目標SQL Server。
注意：在新服務器上，包可能無法正常運行。您可能必須對包進行更改，更改包中任何對舊的源服務器上的連接、文件、數據源、配置文件和其他信息的引用，以便引用新的目標服務器。您必須根據每個包的設計逐個包進行這些更改。
本文中介紹的步驟不移動數據庫關系圖以及備份與還原歷史記錄。如果您必須移動這些信息，請移動msdb系統數據庫。如果您移動msdb數據庫，則不必執行“第4步：如何移動作業、警報和運算符”或“第5步：如何移動DTS包”。
注意：支持將數據從
SQL Server 2000遷移到Microsoft SQL Server 2000（64位）。您可以將一個32位
數據庫附加到一個64位數據庫上，方法是：使用sp_attach_db系統存儲過程或sp_attach_single_file_db系統存儲過程，或者使用32位企業管理器中的備份和還原功能。您可以在SQL Server的32位和64位兩種版本之間來回
移動數據庫。您還可以使用同樣的方法從SQL Server 7.0遷移數據。但是，不支持將數據從SQL Server 2000（64位）降級到SQL Server 7.0。下面分別介紹這幾種方法。
如果您使用的是SQL Server 2005
您可以使用相同的方法從SQL Server 7.0或SQL Server 2000遷移數據。但是，Microsoft SQL Server 2005中的管理工具與SQL Server 7.0或SQL Server 2000中的管理工具有所不同。您應該使用SQL Server Management Studio（而不是SQL Server企業管理器）以及SQL Server導入和導出向導(DTSWizard.exe)（而不是數據轉換服務導入和導出數據向導）。
備份和還原
在源服務器上備份用戶數據庫，然后將用戶數據庫還原到目標服務器上。在備份過程中時可能有人使用數據庫。如果用戶在備份完成后對數據庫執行INSERT、UPDATE或DELETE語句，則備份中不會包含這些更改。如果您必須傳輸所有更改，那么，假如您既執行事務日志備份又執行完整數據庫備份，您可以以盡可能短的停止時間來傳輸這些更改。
1.在目標服務器上還原完整數據庫備份，并指定WITH NORECOVERY選項。
注意：為防止對數據庫做進一步的修改，請指導用戶在源服務器上退出數據庫活動。
2.執行事務日志備份，然后使用WITH RECOVERY選項將事務日志備份還原到目標服務器上。停止時間僅限于事務日志備份和恢復的時間。
◆目標服務器上的數據庫將與源服務器上的數據庫大小相同。要減小數據庫的大小，您必須在執行備份前壓縮源數據庫的大小，或者在完成還原后壓縮目標數據庫的大小。
◆如果您將數據庫還原到的文件位置不同于源數據庫的文件位置，則必須指定WITH MOVE選項。例如，在源服務器上，數據庫位于D:/Mssql/Data文件夾中。目標服務器沒有D驅動器，因而您需要將數據庫還原到C:/Mssql/Data文件夾。有關如何將數據庫還原到其他位置的更多信息，請查看相關資料。
◆如果您想覆蓋目標服務器上的一個現有數據庫，則必須指定WITH REPLACE選項。
◆源服務器和目標服務器上的字符集、排序順序和Unicode整序可能必須相同，具體取決于您要還原到SQL Server的哪種版本。有關更多信息，請參閱本文中的“關于排序規則的說明”一節。
Sp_detach_db和Sp_attach_db存儲過程
要使用sp_detach_db和sp_attach_db這兩個存儲過程，請按下列步驟操作：
1.使用sp_detach_db存儲過程分離源服務器上的數據庫。您必須將與數據庫關聯的.mdf、.ndf和.ldf這三個文件復制到目標服務器上。參見下表中對文件類型的描述：
文件擴展名
說明
.mdf
主要數據文件
.ndf
輔助數據文件
.ldf
事務日志文件
2.使用sp_attach_db存儲過程將數據庫附加到目標服務器上，并指向您在上一步驟中復制到目標服務器的文件。
◆分離數據庫后將無法訪問該數據庫，并且復制文件時也無法使用該數據庫。在進行分離的那一時刻數據庫中包含的所有數據都被移動。
◆在您使用附加或分離方法時，兩個服務器上的字符集、排序順序和Unicode整序都必須相同。有關更多信息，請參閱本文中的“關于排序規則的說明”一節。
1.克服慣性
將大塊任務細分為微任務。
2.關注大牛
你想學的或許是一門新的編程語言、應用框架或者是新的工具，一旦你確定了想要的是什么，就立刻去收集相應的優秀群體所做的一些優質的
工作成果。這些可以從YouTube、Vimeo、HackerNews、各種博客，甚至是你的微博好友那里獲取。關注別人做了些什么可以給你強大的信心，讓你覺得 “You can do it, too!”
3.建立知識網
當你對自己要
學習的東西建立了信心之后，接下來要做的就是做一塊海綿，然后開始瘋狂地吸收知識。從
Google搜索關鍵詞“beginner tutorials”開始吧，搜索一些跟你要學習的知識相關的入門教程。如你所知，Nettuts+上面有成千上百的各種教程供你選擇，StackOverflow上面也有很多學習資源。此外，Quora也是一些不錯的選擇。通過瀏覽這些網上的資源之后，如果想要集中精力學習某一方面，這時就需要閱讀一些相關的書籍了，個人推薦在Amazon上面尋找一些評分較高的專業書籍來提高自己。
4. 多聽多看
隨著你對技術的深入挖掘，你可能會想利用更多其他形式的學習資料，比如podcasts，screencasts等等。我的建議是多用 iTunesU，這上面有很多很專業的知識可以讓你對于特定的領域進行深入的探索。
目前，有很多的網站都有提供在線教育服務，你可以在下面幾個網站上找到自己需要的教程：
· Udemy
· CodeCademy
· CodeSchool
此外，你也可以看一些免費的會議視頻材料，比如YouTube上面的Google IO，以及Confreaks！
5. 行動起來
用你所掌握的技術做一個個人的小項目，設計一些簡單的功能并且實現他們。毫無疑問，你會遇到很多的絆腳石，當遇到它們的時候，在StackOverflow或者Google上面搜索之，解決之。你已經踏上一條成為某一領域專家的旅程，遇到的困難挫折越多，你會變得越睿智。有句老話說得好，“專家是犯錯最多的人”，這意味著他們嘗試了很多瘋狂的事情來探索這門技術的極限，最后，對于這門技術是如何運作的就可以知根知底。擁有這種洞察力之后，他們便可以隨心所欲的運用這項技術去按照自己的意愿完成想做的事情（當然，是做好的事情）。
6. 寫博客
如果你想走的更遠（比如想像Nettuts+上面的職業作者一樣），你也可以制作屬于自己的screencasts。總的來說，寫博客能夠提升你的個人溝通能力，這與你學到的技術同樣重要。
7. 感受技術的脈搏
社交網絡已經廣泛應用于人們的日常交流以及發現新鮮事物。Twitter和Facebook是信息的主要來源，與此同時，有很多的網站提供更專注的資訊，如前面提到過的Quora網站，這上面有很多涉及面很廣的一些話題供人們評論。在這上面可以找到很多知名大牛的建議以及觀點。
8. 參加聚會以及會議
盡管社交網絡很棒，但是沒有任何事物可以取代面對面的交流。在你住的附近參加一些小組聚會，在這里你可以找到志同道合的伙伴。你可以知道他人在做的一些有趣的項目，同時也可以在他人的幫助下解決一些自己遇到的難題！同樣的，技術會議對于分享經驗以及增長技術大有幫助！
9. 擁抱GitHub
GitHub是全世界開源項目的標志性“建筑物”。它是知識以及優質代碼的寶庫。當你對某項技術自我感覺良好的時候，下一步便是在GitHub中瀏覽尋找有趣的項目。閱讀開源代碼，盡可能多的閱讀。這樣做的話，你能夠學到很多東西，比如說：
· 如何管理規模較大的項目
· 項目中應用的有趣的庫
· 代碼規范以及代碼全局設計
· 文檔風格
· 測試規范
· 解決詭異問題的方法，以及發現項目中有問題的地方
所有的這些知識都在等待著你去挖掘。有趣的是，這些知識的通過一個簡單的標簽就可以得到，那就是“好奇心”。
10. 專注學習
如果你擔心上述的學習過程太遲緩，那么你也可以嘗試一下快速學習模式。你或許聽說過“24小時學會某某某”，但是這種方式不是我所推薦的。我認為更合理的是用幾周的時間去學習。你可以嘗試一下類似“七周學會七種語言”或者是“七周學會七種數據庫”等學習方法。盡管這些講的是語言以及數據庫方面的學習，但是你在學習其他技術的時候也可以運用這種思維。
有一個不太相同的學習風格是“困難學習模式”，這種觀點的前提是沒有人可以真正掌握一門技術，除非每天都練習。所以，想要成為專家，你就需要不停地進行練習。異曲同工的是你可以查看Katas 和 Koans，他鼓勵的使用你學的知識來解決問題。這些可以讓你更好地入門以及接受那些陌生的概念，勇敢走出自己的舒適區，開始學習新知識！
學習一門交叉的技能
編程是一項左腦的運動，它利用的是大腦的分析能力，一步一步地尋找解決問題的方法。為了發揮右腦的功能，你可以嘗試從事一些創造性的活動，比如說畫畫、3D建模、折紙、樂器甚至是制作家庭相冊等。事實上，編程同樣需要大量的創造力。或許你曾經遇到過類似的事情，你在睡夢中找到了問題的解決方案。這是因為你的右腦處理問題的方式很不同，它可以從各種地方獲得信息。敏捷開發權威人士Andy Hunt就這個話題寫了一本書《程序員的思維修煉》。如果你想點燃你的每一個神經元，建議你開始學習一門交叉的技能。
總結
掌握一門新技術振奮人心，這是一項影響你思維的新的體驗。但是首先，你必須克服你的慣性，一旦你做到了，你便開啟了從web的每個角落學習知識的旅程。我希望上面講的十點能夠給你的學習旅程帶來一些幫助或啟發。