總覺得如果一個內容被深刻地理解了，那麽當在他口中說出來的時候，應該是很簡單才對。

　　所以一直覺得，編程裏那些不容易理解的，需要記住很多內容的東西都是有缺陷的。自己又比較自我認可強，看不到別人的角度，表現上有些自我。自己想的只是，事情還有很多解決方法，為什麽要被那一種很難學的方式占了路子，而且找不到理解透徹的，有點為這種狀況氣憤，覺得肯定是沒有好好做的原因，或者是一些人太安於現狀的原因，或者是一些找不到出路就說沒出路的人，自己沒吃透卻站在高處誤導別人，阻礙大部分人的進一步思考。

　　即使這樣，自己該做的事情還是要繼續做，去探索可以用來解決問題的架構。首先3D建模還是比較擅長的，玩了那麽久的遊戲，對場景想象比較容易。於是一個平面問題，可以用一個立體方式來解決，這樣就多角度一些，把事情變得容易。

　　說是這樣說，具體做的時候，到具體項目的時候還是暫時沒有想出來。知道以前自己所提出的面向對象的架構是一種不是很確切的說法，需要更合適的描述。這樣，沒有成熟理論的話也不好去找工作，沒有底氣。

　　遊戲的事情也一直徘徊著弄著，最近又來了一股隱藏的熱情，不知道是否需要把這份繼續。對有些人來說還是有幫助的，真可以實現的話，對自己也有很多幫助。

　　主要是不想總是碰電腦。不想總是盯著屏幕，生活中有一些很漂亮的景色，我的眼睛漸漸適應了屏幕光和它的刷新、它的尺寸範圍。當看開闊的東西時候，眼睛有些睜不開。用手把光線來源遮擋到像屏幕那麽大的時候，就可以正常看得很遠。總覺得用電腦，和這些電打交道不是那麽合適，高豐富的內容在周圍環繞，不一定非要通過電腦，可以是一些比較傳統的方式，畫畫之類，到電影院看電影。

　　至少現在可以做的事都和計算機有關。如果思想足夠好的話，可以從中抽象出來，用到別的領域去解決 問題。別的領域...不知道可以做什麽，現在這邊還對軟件架構比較有熱情，不管是不是一時，是自己會經過的地方吧。

　　覺得電腦，還有相似的工具，與其它東西最大的區別是可以玩video game。獨立出來一個獨特的空間來體驗劇情，不需要小說裏看到一些事物的描繪還要去想到底是什麽樣子，這樣都可以直接看到、聽到。比起video game來，電腦對企業服務的應用就像是小兒科了，也就是說，按道理來說如果用運轉好遊戲的邏輯去處理一些企業軟件編輯，應該很容易做到。不是“按道理”，就是某種感覺。因為遊戲邏輯要比軟件邏輯在電腦裏走的深。體驗遊戲的過程，是踏實了一個電腦裏邊的世界，有種從內部開始向周圍思考邏輯的感覺。

　　每個企業軟件也應該有一個核心，從核心裏看問題，每個固定服務都是個NPC，每個使用這個軟件的人都是一個玩家。這樣新的需求分三部分：給玩家的角色增加這份智能；從服務器世界多設置一個相關的NPC；給玩家設定一個對話這個NPC的路線。這樣一邊面向客戶，一邊面向服務，一邊面向業務邏輯。

　　面向客戶這邊是前端和主語言實現；面向服務這邊是主語言和數據庫實現；面向業務邏輯這邊是全部交給主語言處理。對應的分別有些像view，model，controller。這樣V部分做的是把視圖用主語言包起來，M部分是把數據庫用主語言包起來，C部分就直接用主語言引領包好的兩部分、牽引玩家到各個NPC所在點對話。還有一個就是真正的controller，之前那個C只是用來領路的，不如改成map好了，真正的C是可以更改玩家角色技能，可以建立新的路線，可以增加新的NPC的那個遊戲控制室。

　　制造一個武器，先去買鐵，再去打造師打造。後來要求高了，自制武器樣式，要先去賣鐵，再去鑄模師，再拿著模子去打造。這個過程就是多了個鑄模NPC，多了個用模子打鐵的NPC，多了一個打鐵移動路線。這樣把問題立體化，還可以做很多事情，比如說各種NPC放在哪裏，路線怎樣設定，可是在不同的城市裏，可以在樓上樓下，可以站在一起。這樣變相解決高負載之類的問題。

　　和遊戲不同的是，這個map，玩家進來後所走的路線是程序員給定的，不同的需求直接給設定好不同的路線。而不需要玩家自己走。也就是編好表面，編好底層，然後程序員自己在中間玩，覺得玩得不順可以申請到上層控制臺改一改地圖，從新布置一下各個NPC的路線和場景地圖。

　　這樣一個軟件裏的部分有：角色，NPC，地圖，代玩程序，遊戲控制臺。這五個內容相互協作，共同完成變動的軟件需求。除了企業方增加軟件需求以外，軟件本身隨著新需求加入後，時間的推移也在內部變動著，這種變動是不被企業直接看到的，可以影響到軟件表現出來的效率。

　　於是一個新需求進來，首先是軟件吞掉這個新需求，然後隨著新需求的運行再慢慢消化開。對用戶來說是從“吞掉需求”的時候就可以用了。這樣內部不斷調整，當再來新需求的時候又可以先吞再消化到合適的狀態，這個軟件就可以持續健康增長。

　　角色，NPC，地圖，代玩程序，遊戲控制臺。這是一種新的建模方式，可以邏輯分成更形象的模塊，給編程劃分好更明確的職責區域。來新需求時各模塊自身可以從整個軟件中抽出來單獨修改。現行的軟件問題大概都可以通過模塊之間的交互協調得到解決。

　　稍微想到的是，這個建模方式之所以能解決很多問題，是因為把問題映射到更廣闊的解決空間。角色功能的“增加方式”，NPC的“選取雕琢”，地圖的“布景”，代玩程序的“遊戲路線”，遊戲控制臺的“調整”，都是可以用來鋪展軟件問題並加以解決，進一步把計算機問題映射到適合人腦思考的空間。

　　選取這種建模，架構起來職責分配就容易一些。在這裏，角色是以前的view，npc是以前的model，地圖和代玩程序協調組成以前的controller，遊戲控制臺像是原來軟件架構。也就是把原來的控制層少部分邏輯合理的分離出來分給view和model（數據庫連接/處理類），自身再裂變成map和代玩程序（director）兩個模塊，現行架構師站在遊戲建造控制臺對一些對軟件的初建和成長進行角色（player）、NPC、map、director的調整。以這個模型在分配任務的時候網頁設計手和程序員都比較容易理解自己的職責。分布式處理、高負載也很容易直觀理解，把量大的數據訪問分配給單獨的NPC，調整下NPC在map上的位置讓director容易跑。在建表的時候就以NPC角度考慮這個表/數據庫的結構。在設置NPC功能的時候以遊戲環境裏NPC將被訪問的量調整NPC的服務內容。即使都沒有預設好，也可以在發現問題後各部分配合著進行靈活調整。

　　在最外圍，有個外部架構師。負責這五個模塊的任務分配、邏輯抽象。這和controller部位的架構師任務有些不同，controller屬於內部架構師，考慮的是場景控制，NPC分合，玩家新功能增加，以及和director的協調、處理反饋，吞進新軟件需求。內部架構師直接涉及到了內部邏輯包括頁面、主語言、數據庫，它們的相互協調和工作分配。而外部架構師只是負責這個模型的完善，引導和教會整個團隊調整思維角度，負責初始架構。

　　每一個人都有自己考慮的範圍。

我的路子 - 發現遊戲為模型的軟件架構方式