17:01 2013-2-17
採用JSON指令碼組織通訊
20:33 2013-2-18
字串編碼(數字型別)，傳送時再把字串轉成相應的數值型別傳送（省傳送長度）
10:27 2013-2-19
as3中delete 其實就相當於把 obj = null
17:16 2013-2-19
用json時報一大堆錯， 把C/C++的程式碼生成的執行時庫調成的型別是供用雙方一致即可。
17:07 2013-2-25
回撥， 好組織面板， 但是不好擴充套件。
訊息， 好擴充套件， 但是不好組織面板。
17:13 2013-2-25
介面的東西，不適宜用訊息， 而宜回撥， 因為介面是可見的， 可見的東西一般是固定的，需強管理弱擴充套件。
框架的東西，不宜用回撥，而宜用訊息， 因為框架是抽象的，靈活多變的，需弱管理強擴充套件。
 
20:13 2013-2-25
每個實體，除了程式執行給他生成的ID外， 還應有一個指令碼ID屬性（這個ID可以是指令碼配的，也可以是玩家註冊時資料庫配的）
 
22:54 2013-3-15
今天見到一同事寫的頁遊程式碼， 它在create功能裡實現了單例模組， 在get功能獲得物件。 初看下，感覺怪怪的。 因為C++裡，一般是get裡面實現單例的， 而不是在create裡。 後來一想， 還是C++準確些：因為當用戶get時，他是不關心你這東西是那來的， 所以裡面你實現單例是充許的。 但是當用戶create時，他是會關心要建立問題的，有時他甚至會有建立多個的需要的。 這樣把create給封成單例了， 就等於把建立多個的需求的封死了， 那還不如不要提供create這個功能呢。
 
15:21 2013-4-21
施法者提出一個施法公式，施法公式以公式單元的方式存在於伺服器列表。公式表的每次重新整理，都會引起客戶端的效果更新。
 
提煉出施法公式，有利於數值策劃在更抽象的層次上獨立的思考遊戲世界的各種公式和數值組合，從而建立更合理和有趣的遊戲體系。
 
每個施法者只是施法公式的釋出中介。
 
伺服器是不管客戶端顯示的。一切有關顯示的問題客戶端自已去解決。
 




施法公式的傳參問題，可以考慮通過直接傳參加框架API間接取值的方式相結合。
 




15:24 2013-4-21
DB_ID, SPR_ID, U_ID,
 
17:12 2013-4-24
color = frame.data.getPixel(localX , localY);
if (color != 0x00000000)
{
  return true;
}
通過犧牲一個色彩值，達到點與面的畫素級的檢測碰撞。
 
17:55 2013-4-24
上帝說， 要有一個點選類，於是便有了一個點選類。提煉出“點選類”，可以讓點選事件可控， 從而減少開銷。
點選類功能點： 
1，使某實體可觸碰。
2，提供點選型別。
3，滑鼠的觸發型別。
 
14:10 2013-4-26
裝飾類其實類似是C++類的友元，有時侯你想給類增加一些功能， 但這些功能點是附帶的，會隨需求增長變化的，如果整合或固化到類裡，又感覺成本太高而且不靈活（附帶功能的變動會引起整個類的變動）。舉個例子， 任務NPC在有任務時頭頂相應圖示。如果直接伺服器任務類發訊號過來，則加重任務模組和UI的關聯性了，這樣的繫結弱化了任務模組的靈活性。 更好的做法則是類似客戶端在處理服務任務資料時，增加一個友元（或者裝飾的東西），處理NPC的頭頂圖示。
 
16:48 2013-4-26
突然覺得如果擊殺BOSS的頭上可以有個游標就更好了。就像接受任務時，NPC頭上會頂上卷軸。
如果打副本時，擊殺BOSS的頭上有“集火”，“擊殺”的標誌， 就更明確了。甚至如果可以， 當角色成為幫主，或者啥啥啥的， 可以送套限時的面板，例如角色的裝備變成黃金聖衣那樣， 就更叼了。
 
 
10:31 2013-4-27
伺服器其實做的就是把相關的部件資料重新整理到客戶端的所有相關部件裡。 
某個時間段的單個部件SC行為(注意:是&&行為集):
 = SC行為(S_part_k -> Cx_part_k)
  = {  
     SC行為(S_part_k -> Cx_part_k_1)
  && SC行為(S_part_k -> Cx_part_k_2)
  && SC行為(S_part_k -> Cx_part_k_3)
  ...
  && SC行為(S_part_k -> Cx_part_k_N)
   }
某個時間段的單個部件CS行為(注意:是||行為集):
 = CS行為(Cx_part_k -> S_part_k)
  = {  
     CS行為(Cx_part_k_1 -> S_part_k)
  || CS行為(Cx_part_k_2 -> S_part_k)
  || CS行為(Cx_part_k_3 -> S_part_k)
  ...
  || CS行為(Cx_part_k_4 -> S_part_k)
   } 
 
15:02 2013-4-28
客戶端的場景實體重新整理演算法是隻重新整理當前可見的實體，針對這樣的情況，可以搞一個只針對當前需求單例的計時器， 每次呼叫只重新整理該計時器的計時量即可。 這樣玩家狂奔時， 到了最後終點時，才進行重新整理。 不會每跑一步刷一次， 從而提高了效率。
 




14:03 2013-5-4
呼叫或回撥一般用於內部模組， 因為生命週期是可控的，完全資訊博弈。 訊息一般用於多個模組， 因為彼此是不完全資訊博弈， 用訊息省去很多生命週期不同的處理。
 
22:51 2013-5-4
頁遊的客戶端有時會因為多個重新整理事件呀卡在一起導致驟發性卡， 可以以定時器為基礎實現一個時間槽佇列類， 每個函式的呼叫指令會分配到一個以時間槽為單位的佇列。
-- ------------------------------------
-- 時序放大器(放大函式呼叫的時間差)
-- ------------------------------------
G_timer_num = 0
function Lua_Run_Fun_Time_Order_Amplifier( _fun, _time_dt )
 local function run_fun()
  if G_timer_num > 0 then
   G_timer_num = G_timer_num - 1
  end
  _fun()
 end
 G_timer_num = G_timer_num + 1
 _time_dt = _time_dt or 30
 Lua_SimplenessTimer(run_fun, G_timer_num*_time_dt, 0)
end
 
15:26 2013-5-5
凡是要進行伺服器操作的， 定義為打斷行為。
 
14:08 2013-5-7




偶然發現QQ的設定視窗設計得挺好， 左邊是標籤欄， 右邊是拖拉條。這樣的話， 想區域性瀏覽或者全域性瀏覽都兼職到了, 挺方便的。




 
14:26 2013-5-7
地圖的流程估計是這樣的， 每走一次， 就寫入人物座標資料， 然後廣播罷了。  （尋路演算法的API可以放在這裡提供（或者放在怪物AI裡實現我認為也行）。）
優化1， 全域性廣播開銷太大， 只需廣播附近的。所以伺服器引入了九宮格的概念。
優化2， 每次都搜出九宮格還是有開銷，所以引了判斷是不是有交換九宮格的行為。
 




23:16 2013-5-7
移動演算法：
方案1： 決定移動一段距離， 客戶每走一個單位，就和伺服器同步資訊一下（進行可否到達和下一步的指令）。
方案2： 決定移動一段距離， 伺服器直接開一個定時器每個單位寫一個內部資料，客戶端進行介面顯示，伺服器和客戶端不進行互動，兩者分頭進行應用需求。 除非伺服器進行中斷情況或客戶端進行中斷情況才中止止。
好處，減少了互動量，就算被做弊了，也頂多就是介面顯示問題，伺服器資料正常的。 
LOL應該就是採用了方案2，因為玩LOL會發現掉線了，人還能一直走。
 
10:24 2013-5-9
像有一些耦合操作，例如地圖儲存人物的資訊， 人物又有儲存著地圖的資訊， 那麼可以通過第三方的友元函式API實現統一的寫操作。
 
21:50 2013-5-9
三十二個專案，一天重寫一個.
 
0:22 2013-5-7
由於配置檔案一般屬於資原始檔，每次構造相應物件時都要從配置檔案裡讀取引數將會相當耗時。一個好的方法預先構造出各種型別的物件儲存為“火種”，然後當需求真正需要用到時，將“火種”克隆一份輸出。這樣就減去與外部資源打交道的開銷。
 
0:27 2013-5-7
頻繁傳送資料包問題的處理，可以在應用層提供批指令操作， 也可以在底層實現“粘包處理”。
 
1:27 2013-5-7
有時侯，你會發現伺服器的程式碼有些奇怪，它不是用delete去釋放，而是呼叫模組自身的release(){delete this;}去釋放。 其實這並不奇怪，這樣做的原因是dll和com技術本身有一些侷限，如果外界detete，可能會造成記憶體漏露，所以才採用由模組自已去釋放的原因。 但是話說回來， 更好的做法，如果你決定某模組非要release，那最好把它的解構函式給私有了。
 
21:43 2013-5-10
責任人其實並不是真的在說責任相關的人， 而是在說真正在做的人。 一旦有問題，真正在做的那人才麻煩了， 其它人不過在旁壓陣罷了。 所以讓沒有做事的責任人在非原則性問題上對設計可以強制性的橫插一刀是不合理的。 事實上， 真有問題， 都是壓在做事人身上， 責任人幫不上任何忙的。




11:10 2013-5-12
有時需要遍歷裡提供回撥操作（這會更靈活）， 但是回撥操作又可能打砸遍歷次序以致程式崩潰。
解決方法1：對遍歷佇列進行復制以避開刪除後的野指標問題。這樣在做刪除時， 只刪除資料來源的項，
遍歷佇列的項因為是備份的，所以沒被刪到，仍可正常進行，操作時要判斷資料來源的項是否存在。
解決方法2：回撥物件定義一個死亡狀態，外部沒有刪除功能，只有致死的許可權，這樣就確認了遍歷次序
不會因刪除行為而異常，然後在遍歷過程中發現死亡狀態的再進行刪除。
方法1要時間（拷貝的開銷），方法2要空間（死亡的狀態）。 
伺服器計時器的實現應該是採用方法2， 因為算時間的數值剛好可以用來折現成空間的開銷。
 
16:48 2013-5-12
據說， 現在的效果多是拼“底圖+特效”來實現最終效果的。
我覺得這樣會有問題的。  因為特效的資料來源（那些錨點資訊什麼的）是來自配置表XML，而底圖是沒有這些的。 也就是說底圖的資料來源要在程式上寫死。 這樣到時一換皮，又要改配置表又要改程式，就不好了。
還有另一個更深層的問題， 設計上的： 其實需求是隻需一個特效即可的，但是因為容量原因， 不得不把特效拆分，以便壓縮空間佔有量。 這其實是一個壓縮環節， 既然有一個壓縮環節， 就應有一個反壓縮環節， 再到程式使用。
即 美術(源頭) -> 美術(壓縮) -> 程式( 反壓縮 ) -> 程式(應用層使用)
而不是 美術(源頭) -> 美術(壓縮)  -> 程式(應用層使用)
去掉反壓縮環節，會讓程式應用層又要管應用邏輯，又要管特效的拼湊方法等細節，分工不清，在需求改變時， 這段程式就會廢掉的（  原先那種，需求改變時， 只是反壓窮縮的環節變下罷了。）
 




0:39 2013-5-14
在VS2010的除錯時， 通過觀察堆疊資訊， 就可以看到函式的來龍去脈。
 
0:49 2013-5-14
場景服start時，開啟自身管理的監聽模組，中心服的監聽模組，前置機的監聽模組, 開啟完畢後。就開始載入場景服自身的模組(各個模組如有監聽需求， 向相關監聽模組(自身通訊線,中心服,前置機)註冊監聽事件即可)。
 
11:33 2013-5-14
要是菜鳥，不知不覺， 做了就做了。 尼瑪，別人都看出這設計就是一坨屎了，那爛得都引蚊了， 還讓人家吃屎，惡不噁心？
 11:59 2013-5-14
定時器會自已封裝一個設制和取消的介面， 以便應用層在做定時邏輯時，可以純應用邏輯，脫離與具體的應用平臺的關聯。
 
19:55 2013-5-14
雖然目前的定位有其歷史認識， 但是把LUA來做配置檔案的誘惑還是很大的，因為有時侯會需要一些的確有了會非常好的功能： 例如，一個數據域對另一個數據域的引用，或者繼承； 甚至還需要一些簡單的運算，例如想把某個圖片縮放到當前解析度的幾分之幾這樣；又例如想依據客戶端的配置情況動態計算出當前特效每幀的持續時間； 又例如要配置大規模重複的資料。。。 如果用ini或者xml，這些需求就得改動到程式了， 而LUA可以只侷限於在配置檔案裡改。
所以， 如果LUA能實現永久儲存的話。。。嘿嘿。。。
 
19:55 2013-5-14
雖然目前的定位有其歷史認識， 但是把LUA來做配置檔案的誘惑還是很大的，因為有時侯會需要一些的確
有了會非常好的功能： 例如，一個數據域對另一個數據域的引用，或者繼承； 甚至還需要一些簡單的運
算，例如想把某個圖片縮放到當前解析度的幾分之幾這樣；又例如想依據客戶端的配置情況動態計算出當
前特效每幀的持續時間； 又例如要配置大規模重複的資料。。。 如果用ini或者xml，這些需求就得改動
到程式了， 而LUA可以只侷限於在配置檔案裡改。
所以， 如果LUA能實現永久儲存的話。。。嘿嘿。。。




17:43 2013-5-17
人物有自身的屬性值， 而特效有時也有一些需要臨時儲存的屬性值。 把特效的屬性值和人物屬性值摻和
在一起很奇怪的， 特效的屬性值顯然應該是透明的, 是特效內部的事。




22:17 2013-5-17
TweenLite是個好類， 能實現flash裡的"補間動畫效果"。
靜動態資料的合成常用方法:
void getData(int _ID, int _dynamic_par1, int _dynamic_par2)
{
 print( DB_STR[ID], _dynamic_par1, _dynamic_par2 )
}
 
14:06 2013-5-19
遊戲可以在擴充套件功能的過程增加各種補償，通過補償變相打折和表達人文關懷。
10:08 2013-5-22
任務項的更新如果每個任務配一個版本號， 工作量相當麻煩，而且而且也不必要（因為直接更改玩家的任務項是不合適的）， 所以任務的更新機制是：
1， 已接取任務的玩家任務內容保持不變。
2， 新接取任務的玩家任務內容為新的。
相當於新賣的東西會不一樣， 已經賣出的就不管了。
10:10 2013-5-22
如果真的就是修改馬上直接修改玩家的任務項怎麼辦呢？
一個更合適的解決方法依然不是每個任務配一個版本號。而是應該把玩家接的任務ID做廢，同時新增一個有效的任務ID。當玩家上線時， 發現相關任務ID是做廢的，依據相應的補丁邏輯把任務刪掉並新接一條指定的有效ID即可。
 
15:09 2013-5-24
FB開發環境真心有太多的疑難雜症，犄角旮旯了。。。 除錯時改時間會引起以後的修改無效， 有時又會莫名其妙開發埠被佔用了而無效。
19:24 2013-5-27
有時侯行政管理和外交供需分成兩個模組會更清晰一些， 但是這兩者又有內在關聯。如何處理這問題的關係呢， 一個不錯的方法是對其中一模組提供一個“設定耳朵”的接受管理功能， 從而實現劃分成兩個模組，同時又處理了內在邏輯。
 
19:57 2013-5-28
關於狀態那塊（狀態其實就是效果集的控制器）， 客戶端實現狀態控制器也未嘗不可考慮， 就像尋路一樣， 開個頭後， 伺服器和客戶端就兩頭跑了， 減少了中間的通訊。但是--這個方案實現成本太高了。因為效果也不過就那麼幾個， 但是效果的組合是挺多的，每個組合可能就要實現一個控制器， 那這樣客戶端不是舉不勝舉了。。。 再加上單例，疊堆，增量等需求，開發量大很多， 而節省的通訊量不一定可觀。因為複雜狀態的不多見（就是狀態裡有流程控制的狀態）， 所以少掉的通訊也不見得可觀。




14:22 2013-5-29
伺服器的狀態其實是指控制邏輯， 施加效果， 前提條件， 後續行為的容器。它其實就相當於的一個處理外掛。




21:47 2013-5-30
map< pair<int, int>, int> test_map;
test_map[ make_pair(1,2) ] = 3;
cout<< test_map[ std::make_pair(12,33) ] <<endl;
std::map<std::pair<int, int>, int> res;
res.insert(  std::make_pair( std::make_pair(12,33), 33) );
 
17:51 2013-5-31
客戶端的狀態其實是很一個結構很簡單的東西， 沒有太複雜的處理的(有邏輯處理的東西伺服器都搞了)，所以客戶端的狀態元素： 狀態容器， 效果外掛， 表現外掛， 條件外掛。
當讀取配置檔案時，把相關外掛繫結到狀態容器裡監聽相關呼叫即可。 其實也就三個， 開始， 更新，結束。    （用外掛的方式， 是為了更靈活的組合，所以不是像上面那個屬性變數一樣寫死到程式碼裡）
另外，打算用Lua搞， 因為效果外掛， 表現外掛， 條件外掛的擴充套件量可能不少，這些如果用AS3搞，那麼還要去處理配置檔案怎麼把引數對映到外掛的處理。 而用LUA，直接讓策劃配外掛元素即可（相當於直接配簡單程式碼）。  萬一LUA速度不行，再在AS3裡做對映的工作好了。 而且用AS3，編譯時間真是太讓人想砸了它了。這小事還是先斬後奏好了，不然跟原負責人恐怕要討論半天。
 11:24 2013-6-1
用呼叫必須去寫程式碼，但是用訊息觸發，可以把一些簡單組合的訊息繫結配置交給策劃去配。
 




14:46 2013-6-2
關於各種特效和表現的實現方案。
1, 會有建立各種風格和特效小圖示的工具類。
2，應用邏輯依據需求選用需要建立工具建立小圖示。
3，應用邏輯依據需求將小圖示和容器繫結或解決繫結。
4, 應用邏輯會將解除繫結的小圖示刪除。
備註： 這裡真心不需要“容器或框架的好心，把圖示的顯示效果也給統一實現了”。因為如果實現了，那就靈活性和效能的後路堵死了， 事實上工具就是工具，沒必要帶上“應用邏輯的形容詞”，例如增益容器，減益容器。  這個增減是怎麼用的事，讓應用邏輯去做好了。同時也不必擔心開發速度的問題， 如果真有統一實現的需求也是由一個優化工具去自動生成，而不是框架來搞。
 
16:44 2013-6-2
程式設計中，經常面臨誰先誰後，而又要都到達時才成立的生命週期不同的問題。 一個不錯的解決方案是，對於各方面的到達訊息都進行監聽， 然後全為真時進行觸發。
例如加狀態圖示時， 應用邏輯監聽容器初始化訊息和自身初始化訊息（自身的可以省略為直接呼叫。當然， 如果更嚴謹一些， 也可以有一個第三方模組專門做處。或者用一個更好方法：初始化和開啟
分開，就像宣告和定義分開一樣）。 兩者都回調取控制代碼重新整理處理，這樣誰先誰後都會觸發，而只要兩者為真時，就進行刷圖。
例如：
-- ------------------------------------
-- 描述資訊
-- ------------------------------------
function DES_NameTips( _name, _tips)
 local function do_DES_NameTips()
  local public = {}
  function public.add( _t ) Lua_Trace( "增加描述資訊" ) end
  function public.remove( _t ) Lua_Trace( "減少描述資訊" )end
  function public.init(_t)
   --監聽開啟狀態視窗訊息,回撥add
   --監聽開啟狀態訊息,回撥add
   --監聽關閉狀態訊息,回撥remove
  end
  function public.uninit(_t)
   --去除監聽開啟狀態視窗訊息
   --去除監聽開啟狀態訊息
   --去除監聽關閉狀態訊息
  end
  return public
 end
 return do_DES_NameTips
end
 
17:16 2013-6-2
初始化和開啟最好是能分開， 因為有時會面臨一個宣告和定義的互相關聯的問題，初始和開啟分開能很好的解決這種問題。結束和反初始同理。
10:48 2013-6-5
這回的任務配得相當有長進，至少有些趣味性了，而且我猜不出劇情了。場景也相當有長進， 不像劍舞的新手村一樣， 好空曠的，一眼望盡東西。現在的場景好繞，而且山水相間，花香物語，沿途還佈滿小動物， 一個小地圖跑得我有種大地圖的錯覺了。








 
23:27 2013-6-5
有些公司的專案把名字當標誌用了。 個人感覺好二， 因為名字是介面顯示的， 如果把標誌和名字掛鉤， 就相當於把標誌和介面顯示掛鉤，而介面顯示的需求是多變的(例如說因為想設計故事背景或者配合相關電影什麼的要更改人名，地名等, 這在策劃配置時經常會出現的)，這就和標誌符的穩定性是衝突的。 所以更好的做法是標誌和抽象ID掛鉤。
1:41 2013-6-6
關於任務更新的。 首先排除的是針對每個任務都進行一個版本跟蹤，工作量太大，效能下降。二，憑任務內容ID更新到新的任務內容ID，這個也不適宜， 因為新的內容ID也可能是將來的被更新，配置時還要管“更新的更新”等遞迴問題的配置。哇X，太累了。 哥的絕殺是： 更新不是更改內容，而是刪掉舊資料，然後用GM功能直接接取到目前最新配置的任務。 也就是說， 憑舊任務“指令碼內容ID”換新任務，簡單易用，暴力紮實。
 
12:02 2013-6-7
用裝飾類的好處是使用時很方便（不用支考慮傳參等細節），但維護時會麻煩，因為他們要共同約定一些東西，從而造成兩個模組間的耦合性。 所以適用前提最好是約定的是一些必有的屬性。 例如world裡邊框的花紋可以用裝飾，因為視窗必有長寬這些屬性。否則還是弄成一個個小外掛比較好。
 




16:19 2013/6/3
一些通訊優化可以通過物件釋放自動解除， 不必一條條通訊解除。
 
19:41 2013/6/4
用全域性事件機的好處是通訊能力更強，雙方只要約定一個號碼，就是能進行通電話，但壞處是刪除是比較麻煩，　需指定刪除。　而用區域性事件機則通訊雖較為弱化（因為還有事件機與事件機之間的交流問題），但在增刪時更方便一些，　直接把相關的區域性事件機摧毀即可釋放資源。
 
21:43 2013/6/4
原先的副本機制是靈活了,也好擴充套件；　但是因為缺乏規範，在維護方面相當麻煩，除了作者，其它人接手時需理清訊息流通情況才能真正放心。所以進行改進。
　
10:32 2013/6/5
win7的net send指令沒了，　改為在CMD下執行：msg/server:192.168.0.118 * "你的IP佔用別人的了"
 
10:32 2013/6/5
雖然設計以面向需求為指導是不錯，　但過渡面向需求也會帶來維護的成本，因為會造成過渡的黑箱操作。事實上，　需求有時並不需要特別高的質量，甚至會需要一點點技術上的透明性，例如說需求有時會想了解程式此刻在做什麼。
 
20:31 2013/6/5
有時會面臨配引數的問題，　有些引數可能指向靜態(例如地圖座標)，也可能指向動態的(例如地圖的UID)。 我的建議是全都用動態參。但是動態參可能要等程式執行時才能確定，怎麼辦？　這個問題的解決可以交由另一層處理去解決，　例如GetShareMapUID(Map_IID), 例如GetPersonalMapUID(Map_IID), 例如GetTeamMapUID(Map_IID)。
 
22:05 2013/6/6
房間系統部件是由其相關地圖部件，人員部件，遊戲規則部件等構成的。其中地圖部件和人員部件是用於提供基礎資料，監聽系統事件並彙總轉發出相關的遊戲事件。
 
14:35 2013/6/7
原先的副本內部外掛是一種記憶體結構為鏈，邏輯結構為訊息的組織方式構成的。這在建立時是好弄，　但是在刪除時很糾結，不通用。　因為會面臨刪除時，　是依據邏輯結構進行刪除，還是依據記憶體結構進行刪除的問題。　




18:19 2013/6/7
副本的流程可以在程式上僅實現功能點，　然後把功能點的選擇，引數，　還能功能的組合次序（通過訊號量），完全提供給策劃配。
也就是說，除了以前的提供功能和引數配置外，　還可以提供功能的時序關係給策劃配。
19:30 2013/6/7
by design 設計如此
duplicate 重複的bug
external　外部因素
fixed 已解決
not repro 無法重現
postponed 待解
won't fix 不管
10:34 2013/6/8
用訊息雖好，但是有一個弱點是需要預先約定某些訊號。一個不錯的替代方案是用回撥函式做“觸發種子”，然後再建立訊號。
15:50 2013/6/10
一小朋友問一富翁說 叔叔你為什麼這麼有錢。富翁摸摸小朋友的頭說：小時候我爸給了我一個蘋果，我賣掉了它有了兩個蘋果，後來我又賺到了四個蘋果。小朋友若有所思的說 哦…叔叔，我好像懂了。
富翁說, “你懂你妹阿 後來我爸死了，我繼承了他的財產…
這笑話告訴我們：不要痴迷於從閱讀成功人士的傳記，從中尋找經驗，這些書大部分經過了精緻的包裝，很多重要的事實不會告訴你： 
1、蓋茨的的書不會告訴你他母親是IBM董事，是她給兒子促成了第一單大生意
2、巴菲特的書只會告訴你他8歲就知道去參觀紐交所，但不會告訴你他國會議員的父親帶他去的，是高盛的董事接待的。
3、王石的自傳不會告訴你，它的前老丈人是當年的廣東省副書記
4、華為的任正非不會告訴你其岳父曾任四川省副省長
5、馬化騰不會告訴你他的父親是鹽田港上市公司董事，騰訊的第一筆投資來自李澤楷，李與鹽田港母公司啥關係無需多言
6、任志強不會告訴你他的父親是曾經的商業部副部長
7、潘石歧不會告訴你他的發跡是和女富豪張欣結婚後開始的 
18:24 2013/6/10
個人專用資料可採用“下發+重新整理”的方式，　共享資料還是用“查詢”比較好。不然共享的一有更新，則所有人都要下發，效率下降。
21:40 2013/6/10
FB工程匯入，然後設定專案屬性http://127.0.0.1\Client\bin-debug\ArpgClient.html
 




17:15 2013/6/11
任務的獎勵如果和等級掛勾，可能會涉及要把接受時的等級儲存起來
12:34 2013/6/14
如果系統內部元素不需要對外公開，那麼可以用外掛的方式；否則，可以用註冊系統元件的方式提供出來。　這兩者都可實現靈活性。　注意，　需要註冊，不要直接用一個動態類把所有東西都搞上去，那樣會讓程式碼很亂的。
 
 4:15 2013-6-22
傳統的觀點是“管理階層主導”，即權力由上而下貫穿。 我覺得這對IT團隊這種以創新為主，以受過高等教育人群為主的員工來說，是不適宜的。 事實上，權力來自五個基礎： 合法權（組織認定），報酬權（回報值），強制權（開除等懲罰），專家權（在某領域具有高超而獨到的見解），典範權（人格魅力）。  在天下烏鴉一般黑的IT大環境下， 前三種權力基礎的影響因子其實並不高。專家權或還有一定影響力，但那也只對那些真正的程式設計師有效果。 影響因子最大的還是典範力。 當面臨令行不通的時侯， 其實做管理的人自問一句：你有自信和責任感嗎？ 你有道德和操守嗎？ 你有犧牲和奉獻嗎？ 如果這些都自問做得到位，其實底下的人自會心甘情願發揮出主動性。  人與人相處， 是做出多少分的人，心裡都自有一把尺。




遊戲團隊的管理應該是“員工參與”。在大師你身體狀況如此，臨危授命的情況下。 我的建議是，不宜去強化團隊裡每個員工的服從意識。 因為遊戲的服務是員工在做，遊戲產品是員工在生產，遊戲的BUG也是員工在解， 一個人包打天下的時代已經不在了。 公司只有關注員工，員工才會關注產品， 產品才會更好的帶來回報，而強化管理者的權威卻對此一無所得。 強化的結果可能是，一旦你離開，陽奉陰違的事就出現了， 再然後可能因為不懂管理技巧而矛盾激化了。  從“員工參與”這種實際公式出發， 我覺得遇到執行不力的問題， 不妨換個角度，不是從更高一層的權力出發去強化制度權，而是關起門來，對你的權力交接者說一句：“我在想我是不是升錯人”了。   或者反有效果。
 
3:16 2013-6-29
在怪死那裡截流傳送資訊會造成很多需求上靈活的矛盾的。一種適宜的解決方式是在接收處前，插入一個“訊息特定引數觸發器”，由該觸發器再產生需求相應的事件。
















3:20 2013-6-29
當提出“訊息特定引數觸發器”這個觀點時，我突然想一個經常面臨的問題。 有時需求只是需要監聽某個特徵的訊息，但因為“依賴倒轉原則”的限制， 傳送方不得不傳送一個巨集觀的訊息，然後接收方再在具體實現裡去挑出符合自已的訊息。  傳送方和接收方沒有一個合理的轉換空間層。 
例如登陸地圖訊息， 供應方系統會發出一個“登陸事件，引數是相關地圖和相關人”。 而需求方功能模組需要的是監聽“某人登陸某張地圖”。供需之間存在嚴重的代溝。








“訊息特定引數觸發器”似乎可以解決這個問題。 有“特定人物引數觸發器”，“特定地圖引數觸發器”， 然後這兩個“訊息特定引數觸發器”一組合，就可以在訊息上預先挑撿出特定的訊息，從而減輕實現層的壓力並提高整個流程的複用性。 而且“訊息特定引數觸發器”還可以複用“引數檢驗”的過程，從而提高伺服器效能。








通過“訊息特定引數觸發器”可以解決組合訊息的問題。需要監聽根訊息就監聽根訊息， 需要子訊息就監聽相關的“訊息特定引數觸發器”的組合。








我開始在猜想，這個細節上的提高是否可能改變整個伺服器的程式碼框架了。
 
10:40 2013/6/28
普通情況，　可以在監聽事件裡引入函式，　發現有特定要求的，則定義一個全域性唯一的“訊息特定引數”觸發器。
11:08 2013/6/28
最好不要用外掛式實現觸發器，這樣便讓大量複用檢索條件的功能失效。所以還是用關聯式實現觸發器。
11:37 2013/6/28
那是因為程式碼太老了，有一些以前的設計方案。現在是到了可以更完善的時間了。
我的原理是：　針對訊息，會有一些“特定訊息拾取轉發器”，然後這個轉發器構成一個訊息樹。
使用如下：
現在的方式：
G_Game_Server.action_map.addListener(   EVENT, public )
G_Game_Server.action_map.removeListener(  EVENT, public )
擴充套件後的方式
G_Game_Server.action_map.addListener(   MAKE_EVENT(EVENT, { KEY1=VAL1,KEY2=VAL2 }), public )
G_Game_Server.action_map.removeListener(  UNMAKE_EVENT(EVENT, { KEY1=VAL1,KEY2=VAL2 }), public )
然後每個"KEY=VAL"採用引用計數法進行建立和刪除“特定訊息拾取轉發器”。　因為這個"KEY=VAL"僅僅是“特定引數觸發器”，它不對資料做任何加工處理的，所以需求可以共享同一個“特定引數觸發器”。
MAKE_EVENT(EVENT, { {KEY, VAL} } 和　MAKE_EVENT(EVENT, { {KEY, VAL} }　實際是構造一顆特定引數訊息樹。




17:27 2013/6/28
"特定訊息拾取轉發器"　其實就是把引數的驗證過程從處理層提煉出來，放到訊息流的模組裡。　因為驗證功能是不會對資料做任何加工處理的，所以放到訊息流時可以用共享的方法供各方引用，從而提高了效能和減少空間消耗。　又因為檢證功能提煉複用了，所以處理層的實現壓力減少，程式碼簡潔化。　並且，當提煉出種元素後，還在可在訊息層實現訊息樹的動態組合檢驗以更大程度的複用程式碼。　正可謂“一石三鳥”。
22:33 2013/6/28
有時侯UID需要具有時間和空間都要唯一點的需求。有很多種方法解決，我的方案是通過通過可動態擴充套件UID所佔空間實現其理論上的無限範圍。




1, 發現一個需求的矛盾：系統殺死怪物和玩家殺死怪的問題一直沒有很好的解決。一開始是直接遮蔽掉系統殺死怪的訊號的，以便遊戲邏輯可以正常的進行。但後面一些需求發現這種方式很不好，例如說：按時殺死未死亡的怪，因為系統殺怪的訊號被遮蔽了，所以雖然殺了怪，但是怪物列表的資料沒有獲得同步更新。
2, 我突然想一個經常面臨的問題。 有時需求只是需要監聽某個特徵的訊息，但因為“依賴倒轉原則”的限制，接收方是沒有權決定傳送方的內容的。 所以傳送方不得不傳送一個巨集觀的訊息，然後接收方再在具體實現裡去挑出符合自已的訊息。  傳送方和接收方沒有一個合理的轉換空間層。
例如登陸地圖訊息， 供應方系統會發出一個“登陸事件，引數是相關地圖和相關人”。 而需求方功能模組需要的是監聽“某人登陸某張地圖”。供需之間存在嚴重的代溝。
於是我提出了“特參轉發器”這個觀點。
例如有“特定人物引數的轉發器”，“特定地圖引數的轉發器”，然後這兩個“特參轉發器”一組合，就可以在訊息上預先挑撿出特定的訊息發給接收方。通過“特參轉發器”可以解決組合訊息的問題。需要監聽根訊息就監聽根訊息， 需要子訊息就監聽相關的“特參轉發器”的組合。
優點：
１，　效能提高。　“特參轉發器”並不對資料做任何加工處理的，所以該觸發器可以共享，並可用計數法進行資源管理。　而又因為只有根和事件源是經常一樣的，所以原來的優化估計也就拿這兩個東西分兩層去實現共享機制，從而減少建立量。　　　但新的方式沒有兩層之分，它是隨意組合關鍵字的。　所以觸發器能共享使用的元素更多。從而更趨近於需求上的共享數而不侷限於（事件源）。從而提高效能減少開銷。
２，　靈活性。　新的方式沒有特定的層數構造，是由使用者決定的，所以更靈活。
３，　更簡單。　這裡沒有設定好的多層結構，　全是一層結構，只是用相關觸發器轉換特定引數罷了。
3，分配房間時需要UID,有時侯UID需要具有時間和空間都要唯一點的需求。有很多種方法解決，但今天我突然想到通過可動態擴充套件UID所佔空間實現其理論上的無限範圍。即是說UID會是一個不限字長的字串，當前面的所有字元可能都嘗試過後，會自動增加一個位計數。經驗證，效果挺好的，更接近理論空間。
17:18 2013/7/1
在怪物的建立，控制，刪除方面，一直是個老大難的問題。　一方面希望這個模組的實現是外掛式的，一方面又面臨著雜亂的需求功能（例如外部的控制可能有：系統擊殺，玩家擊殺，關閉房間引起，玩家怪物表的記錄重新整理，最近怪死地點的記錄）。　在以前這些問題是通過不斷測試，修修補補而達到完善的。　這種完善的後果就是功能可以達到，　但維護性很差。
這回重寫下定決心解決了這個問題。　在怪物模組裡借用了訪問者模式的方案和技巧：即內部關係上，訪問者會通過被訪問者的回撥引數的訪問回自已。　在這種方式下，　個體和群體之間的內在關係得以對外界透明。　從而使整個程式碼的維護變得簡單安全起來。　對外界來說，僅僅留下個體的操作，或者群體的操作，而不用關心兩者的同步。 從新效果來看，程式碼簡單幹淨很多。
實現了“特參轉發器”，將進行了監控和測試。監控和測試結果顯示，　“特參轉發器”的建立和刪除是安全的，　同時功能是有效和靈活的。
 1:08 2013-7-2
習近平指出，用一賢人則群賢畢至，見賢思齊就蔚然成風。選什麼人就是風向標，就有什麼樣的幹部作風，乃至就有什麼樣的黨風。




1:56 2013-7-6
由於在同步伺服器和客戶端的引數編碼和解析花的時間比較浪費。
於是我嘗試改進這個過程，即試圖在應用層把send和recv的語句這兩個總是對應的過程封裝打包起來，包括其概念消滅掉。而改用
 g_client.disptchevt(...)
 g_client.run_Lua_fun(...) 
 g_client.run_AS3_fun(...)
 g_server.disptchevt(...)
 g_server.run_Lua_fun(...) 
 g_server.run_C_fun(...) 
 這樣的方式。
 也就是說，會有一個通用的訊息層處理。 兩邊直接面嚮應用處理， 而不再考慮send和recv這些細節，更不再考慮這些傳送和接收後怎麼對映到函式的細節。
 
19:23 2013/7/13
在封裝send和recv的打包過程接口裡，　不應起名runXXX. 而應起名為startXXX。　因為用run表明要執行完的, 用start則沒有這種意思。
 
14:51 2013/7/9
實踐證明“特參轉發器”相當好用。　現在的不足是，　原系統之前是把一些參綁在訊息裡
的。　如果提到BUF參裡，　就更方便了。
10:45 2013/7/10
"特參轉發器"帶來了一個很方便的用途，　就是檢索時，再也不必一定是要有序的了，　例
如說，一定得先檢索第幾波的訊號，再找相應的怪ID, 而是想聽那個就選那個。　因為觸發
訊息的層次再也不繫結某個執行期的東西了。
13:45 2013/7/10
或許一個更好的名稱是“特徵觸發器”
 11:33 2013/7/24
解決FB還是執行老程式碼的方法：
方法1, 把Internet臨時檔案和歷史記錄設定設為檢查所存網頁的較新版本為每次訪問網頁時。
方法2, 把檢視檔案的目錄裡的東西全刪掉。




20:34 2013/7/25
對手的武器太過華麗了，你像孔雀一樣華麗地開屏一下，使用者就來，關屏了他們又走。而我們是一點點地幫你倒杯水，幫你沏杯茶，幫你點根菸，沒什麼牛逼，但是你慢慢會發現這樣留下使用者的比例非常高。
我們有一句話，任何領域未經優化前，都有百分之三十的效益上升空間，這是我們做產品的原則。比如說，做首頁大圖，如果我們認真地去想怎麼做，百分之三十的提升空間一定有。
人人都能看到的潮流，對於大部分人都是陷阱，因為這時候只有一個人能活。












14:34 2013/7/13
由於目前暫定分工是客戶只負責表現的功能，　伺服器和客戶端
的應用邏輯都是我在調。　這導致我要負責不少細節處理，其中在同步伺服器和客戶端
的引數編碼和解析花的時間比較浪費。
於是我嘗試改進這個過程，即試圖在應用層把send和recv的語句這兩個總是對應的過程封裝打包起來，包括其概念消滅掉。而改用
 g_client.disptchevt(...)
 g_client.run_Lua_fun(...) 
 g_client.run_AS3_fun(...)
 g_server.disptchevt(...)
 g_server.run_Lua_fun(...) 
 g_server.run_C_fun(...) 
 這樣的方式。
 








也就是說，會有一個通用的訊息層處理。 兩邊直接面嚮應用處理， 而不再考慮send和recv這些細節，更不再考慮這些傳送和接收後怎麼對映到函式的細節。








19:23 2013/7/13
在封裝send和recv的打包過程接口裡，　不應起名runXXX. 而應起名為startXXX。　因為用run表明要執行完的, 用start則沒有這種意思。








16:57 2013/7/17
有些需求如果拆成兩套設計會更安全和靈活些。　例如副本離線獎勵，　如果按這個字面需求做，就真的弄一個副本相關的離線獎勵，這意味著可能要三個步驟。　首先，要通過標誌１，通過一系列額外技巧，找到對應模組裡的固定獎勵集；　然後通過標誌２，找到那些是隨機生成的獎勵集；　再然後要把這兩者打包起來發出去。　這裡有三個步驟，光測試就估計要半天是花在驗證上了。








但是如果拆分開來，　副本獎勵歸副本獎勵，離線獎勵歸離線獎勵，則程式簡單健壯很多。因為實現步驟縮減為：當發現離線時，直接查離線獎勵表給固定獎勵即可。　至於和副本的相關性，只要把相關的獎項值配成一樣的即可。








不足：配置值要多配幾次。
優點：各個模組獨立，沒有相關性，維護和擴充套件更方便。








20:51 2013/7/17
很多人都跟我們一樣，這就是婚姻。如果兩個人老有激情，就累死了。兩個人這麼熟悉了，不小心摸到對方跟摸到自己似的，還能有激情？所以，我們的婚姻沒有問題，是人們對婚姻的認識有問題，不成熟。現在你遇見這個人，他給了你新鮮感，你就覺得他好，我們倆不好。錯！如果你跟他結婚過上幾年，就會發現我倆的今天就是你們的明天，而且還不如。因為我們倆從一開始就沒隔著心，有了兒子，一起買了房子置了家，你和我，掙來的每一分錢都給了咱們兒子、咱們的家。你和他呢？從一開始就是兩家人，他有閨女你有兒子，誰都想多吃多佔，永遠不均。有激情時，糊里糊塗地過，激情沒了，對方就成了外人，到那時候，你就後悔了！所以，你要是覺得跟他一起更好，你就去吧。”
 
老公一席話，她猶如星湖灌頂。不知為什麼，當時她一把抱住他，緊緊地抱著，眼淚譁一下流出來。從那以後，妻子再也沒說過離婚。婚姻其實本來就應該是平淡的，是一種合作關係，這種合作裡面更多的是責任和義務，別奢求有太多的浪漫，奢求太多了，人會變得挑剔，一挑剔起來，婚姻就不能長久。成熟的面對婚姻。解決問題！
 太多的人經不起平淡的生活，脫離了生活的軌道，忽略了本有的責任。我想這應該是大多數人生活中都會遇到的問題吧，讓我們學著珍惜眼前人吧。
 看 一輩子的愛人，不是一場轟轟烈烈的愛情，也不是什麼承諾和誓言。而是當所有人都離棄你的時候，只有他在默默陪伴著你。當所有人都在讚賞你的時候，只有他牽著你的手，嘴角上揚，彷彿驕傲的說，我早知道。不要因愛人的沉默和不解風情而鬱悶，因為時間會告訴你：越是平凡的陪伴 就越長久。 












14:23 2013/7/25
獎勵其實應有三個屬性，即型別，ID, 數量。








22:01 2013/7/25
感覺做得不錯的地方：
解決方案：
在處理獎勵時，會面臨前提條件各種可能。例如加錢加經驗的，是某屬性值判斷即可，而加物品的則要等全部加上並判斷空間是否足夠才能做出決定（因為用回滾的方式效果更差）。面對這種問題，最後選擇採用訪問者模式解決，　即在實現“緩衝揹包”裡的獎勵行為裡，遍歷所有獎勵項的各自否決判斷，並把揹包物件傳遞給其，　最後再判斷揹包自身的否決判斷，所有都通過後，再一次性把獎勵加上。
優點：
通過上述方案，在擴充套件新型獎勵時變得簡潔健壯很多。　例如增加寵物獎如下：
程式碼實現：
-- 寵物
function TIG_PET( _ID, _num )
local public = TIG_BASE()
function public.vote( _bag )
return false
end
function public.action( _bag )
for i=1, _num do
API_GivePet(_bag.getRole(), _ID)
end
end
return public
end
獎勵配置表
FIRST_PAY = { TIG_PET(1,10000) }
擴充套件如上的新功能完全不用改動框架層的程式碼。在外部新增一個新獎勵功能型別，然後就可以直接配進配置表了。
個人覺得，　這個設計方案在後期實現一些VIP的特殊獎勵時，將會很有用。








12:04 2013/7/27
要有一個專門的通用的通訊模組，不是指socket的，而是指有一個專門封裝各種打包資料的模組，或者說資料字典。　對，應該有一個共享的第三方：資料字典模組。








11:52 2013/7/30
for key, value in pairs(tbtest) do  
    XXX  
end 
 
for key, value in ipairs(tbtest) do  
    XXX  
end 
 
for i=1, #(tbtest) do  
    XXX  
end 
 
for i=1, table.maxn(tbtest) do  
    XXX  
end




23:07 2013/7/30
意外發現靈活易擴張的獎勵流程相當有用，因為獎勵經常是在一些關鍵環節時給矛的，而這和需求的關鍵點恰好重疊。　所以當獎勵流程靈活化好，像擴張一些達到關鍵點開啟某模組，完成任務飛到某地點之類的需求，都可以通過獎勵實現了。




18:04 2013/8/2
通過查詢來實現各模組的靈活組合還是可行的（這樣不用定義一個靜態類）,　如果有效能問題，可以把查詢到的物件記錄起來並封鎖其刪除功能，以便後用。　這樣成本僅僅在於第一次查詢時的開銷。　　




21:20 2013/8/7
不同模組之間的大量互動，宜採用訊息機。　因為這樣定義一個訊息後，　互動雙方就可分頭獨立實現功能，且是弱耦合的。　若是採用函式呼叫，　則不能獨立進行某個模組的開發（因為呼叫空函式編譯器是通不過的），且會導致模組之間強耦合的問題




21:44 2013/8/7
兩個原因造成我在指令功能的實現上採用訊息機的方案而不是函式呼叫的方案：1,我不希望新增一個功能點要先兩個模組的互動調通後才可進行功能點的實現；　2,我對指令功能的需求點不是特別明確，也就是說，我認為他的擴充套件可能很多，用函式的話掛載在那個實體都感覺不適合（除非是當作系統API來定義）。


22:34 2013/8/21
客觀的說， XX在工作上還是很認真負責的， 這點是沒有問題。 只是在他那個位置上， 人際關係沒有做好，這個是大問題滴。  好壞我都是客觀的分析的，我不是那種會因主觀問題去否決客觀事情的人滴。




而且坑,哥跳多啦~~~  不在乎這麼一兩個。




像上週六那個， 我還能怎麼說呢。 我根本就不知道那個walk裡面在做啥的， 從它的設計意圖上看（它封裝了好多操作在裡面，例如對話， 尋路， 打怪）， 所以它就是想做一箇中間者， 一個智慧的封裝。  按它的設計意圖，我應該是不用管他的細節的。 




再者我根本就不清楚裡面做什麼的。  但是…… 呃， 一上來就是我這邊做錯了…… 然後哥就被拖進坑裡， 被輪歐……  X。   YY說得還溝通得來，能說明為什麼那個設計意圖不行， 另一個則是完全在旁吹水， 都沒進入到框架層說問題，就是依據幾個細節反覆的折騰問題， 其實那些細節問題真要解，我不信沒有辦法解（只是那個說多了就是在硬扯了）……  不過對於有些討論不能跳出細節，在框架層談問題， 我覺得議論得有些沒有多大意義了，都不是同個層次水平的……




這就是我那天事後對那次討論的意義的真實想法， 我覺得有些人想問題， 還不夠抽象， 聊起來不是一個層次的。 
但這不是說我的水平高， 各有各的長處啦。




21:55 2013/8/26
區分元件， 外掛， 部件， 還是很有好處的， 特別是在生命週期不同的環境時。 例如一開服就有的服務， 多用元件實現。 副本開啟時才要確認的功能， 多用外掛。 與人相關的長期繫結的東西，為部件。




22:23 2013/8/27
加班加點拼著命去趕上面要求的進度， 結果在事情過看，回頭看來，這在上面看來不是功勞，而是苦勞， 而且是沒有意義的苦勞，在發展空間上也只有一票否決的考量，沒有優先考慮的考量。 沒意思。 或許不是做得最好的， 但確實是當時能做的人裡面最適合做也做得最好的的， 人們總是健忘的，要你趕工時很客氣， 趕完後就無所謂了。




1:39 2013-9-5
面對上司的判斷，認為你沒錯，你缺乏認識問題的能力；認為你錯了，你沒有解決問題的能力--接受錯誤的最好方式就是對錯誤避而不談。最後一條，不準和老闆談公正。不認， 覺悟不行；認了，能力不行。 避而不談最好。利益之爭如果面對面解決，它就變得無法解決；如果不面對面解決，它就不會被真正解決。一個最終原則是，利益之爭從來就不會被解決。學會不談判的技巧。必須學會擺譜。如果你很靠譜但不擺譜，大部分人都認為你不靠譜。如果你不靠譜但經常擺譜，所有人都認為你很靠譜。




21:10 2013/8/29
全域性變數也有全域性變數的好處， 那就是不用涉及太多的引數傳遞處理。 但任其橫插也不是辦法， 一個改進的方法是， 對於那種寫少讀多的情況， 可以有一個全域性管理器統一的管理全域性變數。




11:29 2013/8/30
聖火微章（簡單和好玩法） + 太閣立志偉（介面和劇情好)。
離線 + 線上 結合的遊戲機制。
四技能固定，但是可以通過轉職切換。




16:38 2013/8/31
這個功能在除錯時還是很需要的， 從執行到登陸大概要2分鐘， 一個小時光執行這樣的步驟也就只能跑30次……， 這還不算一些額外的開銷（例如用GM接指令什麼的），實際真正有效的除錯，一個小時也就跑了個12、13次，   開發成本就是這樣耗掉的……。所以動態的LUA除錯還是很重要的。




17:42 2013/9/4
XMLSpy2011是個好東西。




13:07 2013/9/6
問：你寫資料的時候用 WaitForSingleObject(wOverLaped.hEvent,INFINITE);
如果一直沒有寫成個那不是卡死了嗎
答：就是要這樣的效果。 因為問題要一步步來解決，當時如果那裡寫不進，後緒的需求都沒法實現，致於異常的問題可以在後續需求中處理，因為這並不是不可控的問題。 就如下圍棋時， 先在關鍵點搶攻佈局， 搭好框架，只要事態在可控範圍內，不必急於把有限的資源投入到鞏固階段。 否則效率就低了。 效率低就會落後， 落後就要捱打。




17:54 2013/9/8
資料處理流程：1， 處理程式靜態配置資料； 2， 處理需求靜態配置資料； 3， 處理資料庫動態資料；4， 處理程式執行的動態資料；5，儲存資料庫動態資料。


17:59 2013/9/10
有時侯你不希望把虛擬函式留給終端結點於處理， 而是希望不管提供出去後外部怎麼處理， 最後總是決定權會回到你手裡， 這時你就可以用“模組繼承”的方式把第三方處理再構造到你的內部函式裡以實現虛擬函式的最終決定。(配後的型別統一問題可以通過基類指標解決)。






19:59 2013/9/13
副本有一個嚴重的設計問題，就是當初弄的時侯， 沒把外掛做成一個生成物件獨佔資源的。 弄得現在老要處理公共函式和獨立函式的問題。




14:19 2013/9/17
其實我想在遊戲裡做一個酒吧女郎， 玩家通過送花，送鑽戒什麼的， 可以獲得女郎的好感度， 當好感度達到一定程度時， 女郎會給出一些提示資訊：例如到某地方探索可以獲得什麼武器， 或者給出一條開啟某隱藏副本的路線來。




20:48 2013/9/23
突然想到一個解決取參和處理的函式方法了，那就是配置表去配置“取參函式 + 處理函式”的組合函式。




17:17 2013/9/24
在自動生成配置表時， 用批克隆介面有時勝於寫批生成處理介面， 1, 簡單化， 因為批生成會有各種引數的處理， 而克隆可能只需處理那個克隆後需要修改的東西。2，耦合化，當生成引數介面修改時， 指介面也要跟著修改， 而指克隆則不需要。




17:10 2013/9/26
由於動態連結庫生成的物件全都受限於動態連結庫的資源生命週期。 所以一種最安全規範的做法是， 不是每次都去查詢地址以處理函式， 而是直接內定動態連結庫只對外提供唯一的工廠物件，且庫資源和其生命週期等同， 然後函式由工廠物件去擴充套件。  因為生命期一樣，數目一樣且唯一。這樣就把對dll資源處理問題轉化為統一的對工廠物件的處理問題。








20:05 2013/9/29
對於很耗時的操作，倒是可以通過“功能CD”來實現不讓玩家頻繁操作。








23:00 2013/10/1
特別小心： 當函式裡有代表物件的ID存在時，要特別小心。因為一旦涉及ID操作，就有可能是幹掉物件的外包操作， 從而導致原先代表物件的指標是一個野指標存在。








21:38 2013-10-5
馮小剛：常遇熱心人苦口婆心勸我治療臉上的白癜風且免費獻出祖傳祕方，在此一併叩謝。這病在下就惠存了。不是不識好歹，皆因諸事順遂，僅此小小報應、添堵遠比身患重疾要了小命強。這是平衡。也讓厭惡我的人有的放矢出口惡氣。再者即便治癒，我也變不成呂布、黃曉明，頂多就一不用打底色的杜月笙。


21:38 2013-10-6
http://www.hxen.com/englishlistening/




12:15 2013/10/8
我們有一個看上去根本不像經驗的經驗是：用上所有渠道，包括內部人推薦。某季度或半年推薦入職最多的同事，即使本職工作不算突出，也可謂功臣。人手不足、虛席以待的問題很突出，那就應該花一半以上的時間去搜尋或者研究如何招聘。




　　其次，切忌以快為綱，融合是大問題。因為經驗表明，觀念很難改變，不是不能溝通，而是對某個問題的認識基於不同的事實和邏輯。因此，人員招募不能能力合格就“上車”，要把認同和價值觀當作非常關鍵的標準，職位越高越是如此。如果業務發展形勢要求需要短平快的招聘，那就要確保管理一定要跟得上。




人多了，就要拆分為小團隊，需要明確各個小團隊的具體使命和責任。CTO要給各個團隊講清楚未來6個月、1年甚至2年的使命和目標，未來成長之路是什麼，團隊負責人自己怎麼發展，團隊成員怎麼發展，小團隊怎麼建設，績效怎麼考核，怎麼獎勵……總之，要確保擴張而不脫節。












12:56 2013/10/8
關於伺服器和客戶端的技能互動是這樣的：伺服器負責在客戶端的相關佇列裡安插關鍵幀， 然後客戶端負責把關鍵幀佇列還原成動畫。  例如技能，有些技能在釋放瞬間就計算好了並安插到客戶端幀佇列裡， 只是客戶端表現上還在播放漫長的關鍵幀佇列動畫罷了。




13:41 2013/10/8
伺服器：邏輯關鍵幀製造機。
客戶端：邏輯關鍵幀播放器。


16:20 2013/10/9
利用lua的充許同名頂替功能，可以實現lua的熱更新。 通過GM功能隨時隨地載入一個lua檔案，然後同名頂替實現了任意資料，任意功能函式的更新。




19:06 2013/10/9
氛圍比過程重要，他深信培養音樂家，需要在襁褓時聽曲子；培養運動員，需要在學步時開始蹦跳。




23:45 2013/10/11
在遍歷時不採用標記後續法刪除，而採用替換當前物件為空物件，可以速度更快。








19:23 2013/10/12
可以通過置空+雙緩衝的方式，把訊息遍歷過程中的非空結點拷到備用緩衝上去， 然後把備用緩衝的地址給拷到前臺緩衝的地址上，從而避免了遍歷後非空結點的遍歷刪除過程。




11:22 2013/10/15
從長期的時間來看， 副本比功能難搞。 因為功能一般是作為基礎操作， 不管是從設計角度還是從需求角色，它都不會長時間的擴充套件和變化， 所以很容易定型。  而副本做為一種玩法，則經常天天換，天天調整，天天再另搞一個玩法出來。 所以麻煩很多。












20:45 2013/10/15
在一些沒有debug和release版本區分的語言， 可以通過SVN的上傳檔案標誌來實現對debug和release版本的區分。








13:02 2013/10/16
塔攻搞成拉據戰還是沒有快感和太慢， 不適合手遊。 還是要保持搶攻快跑的節奏才好玩。




14:23 2013/10/18
可以通過lua的頂替功能實現lua程式的熱更新（即不重啟伺服器的情況下更新伺服器功能）。當然，這只是暫時的更新，關服後還是會還原的。 所以完整的更新步驟是整個lua資料夾都覆蓋掉，包括其中的熱更新包。這樣不管是臨時的，還是關服後的， 都實現了更新。




23:24 2013/10/23
VS2010的自動化測試還是挺強大的。 它的操作原理是，提供對支援測試型別，進行其所有相關的行為錄製，並可隨時中斷新增對當前現象的判斷邏輯。 每個錄製步驟和其對應的判斷邏輯就是一個測試用例。  使用自動化測試時，要注意初始條件要一致，否則會導致測試中斷。
它的生成測試用例步驟：
1， 錄製目標物件的測試操作，並通過中斷錄製及時生成相關程式碼。（測試工具會自動把目標物件有關的行為轉為“程式碼關鍵幀”）
2， 對當時的結果新增斷言程式碼進行判斷。


23:39 2013/10/23
VS2010的自動化測試的錄製過程一般會全部以程式碼的方式儲存在XXXMap檔案上，測試專案檔案的程式碼只是呼叫XXXMap檔案的方法罷了。




23:44 2013/10/23
VS2010的自動化測試的原理是：先用一行行操作程式碼把所有記錄起來。 然後把使用者擷取的“操作程式碼段”儲存成一個測試步驟。再針對某個測試步驟呼叫完後進行相關的使用者斷言程式碼的判斷。


14:16 2013/10/25
其實概率按千分比百分比之類的， 是不合適的。 這會讓經濟模式固化而不適應市場需求發展。 合理的概率，應該由經濟模組提供概率API，同時由經濟模組來定價所有東西。例如充錢越多的人，幸運值越高。


20:50 2013/10/25
其實有不少遊戲邏輯的東西可以放到客戶端做。 例如自動開始和自動結束。可以由客戶端發起，伺服器沒必要開個倒計時去算時間然後把玩家T出副本。 因為當副本打完後，如果外掛要搞得玩家在副本，那就讓他搞嘍， 沒什麼大問題的。 


16:15 2013/10/26
發現一個監控LUA記憶體漏露的好方法： 由於LUA的記憶體回收方式有一些自身的優化， 常導致不準確的資訊。 所以直接監控記憶體量是不可靠的。 但是好在LUA的全域性變數是有引用的， 所以通過窮舉和追蹤LUA全域性變數物件的數量， 可以達到監控LUA的建立和解放是否正常的效果。


13:56 2013/11/1
把客戶端的入口綁限在唯一入口處是有好處的。外掛是可以把一個遊戲，包括其運營平臺都搞崩。唯一入口有利於檢驗，在有些情況下，這甚至是唯一的救命稻草。


0:25 2013/11/2
客戶端發向伺服器的資料越少越好， 除了效能問題外， 最大的問題在於可以減少伺服器對客戶引數的依賴，以防外掛。這是原則性問題。


10:28 2013/10/25
可以把查詢洩漏的部分寫入到關機邏輯裡面，每次關機的時候自動查詢洩漏，然後出具報告。


15:28 2013/10/25
關服其實可以做一個彙總資料的功能


18:42 2013/10/25
隨著公司遊戲上線， 挺有意思的。假裝玩家和黑手交流， 看著他們的視訊攻擊自已的模組。 結果固是有些被攻破了， 但挺長見識的， 特別是窮舉引數法， 一旦應用邏輯不邏輯，或視野太過切近應用， 很容易被窮舉突破。


14:52 2013/11/4
Lua的記憶體漏露是有可能多數是空表問題引起來。 解決方法是建立一個空表回收機制。


14:54 2013/11/4
Lua的loadstring函式是一個極可怕