[構思] 關於架構-2 [sumtec]

目前為止，我的思緒還是挺淩亂的，不象steeven那樣，已經考慮清楚了，說起來一條一條的。我所想象的架構非常的大，自己也不知道該用什麼順序說。如果我說得太亂了請見諒！

在這個架構裡面，我想首先著重提出兩個概念：1、場（Field）；2、環境（Environment）。以及因此牽扯到的一個很普通的概念：地圖（Map）

首先說說“場”。所謂的場是指類似“重力場”、“磁場”等等地球物理規則，當然，物理上所說的場一般都和“力”有關係，同時是看不見摸不著、遠距離產生影響的抽象環境。而我這裡所說的場，僅僅體現一個實體環境的概念，裡面可能包含一些（簡化的、抽象的）物理規則。比如說：

重力場——用於制約地圖上的對象位置，如果無法產生一個向上的力，就會最終掉下來。
海平面場——用於描述整個海平面高度的情況，必要的時候可以擷取在“地面”移動所必須消耗的能量。
可見光場——用於描述我們普通情況下所看到的圖形情況。
紅外場——用於描述地圖上面的熱量情況，所有物體都會散發或多或少的熱量。
化學場——用於描述地圖上面化學物質的分布情況，可以通過遺留化學氣味來釋放資訊，通過“聞”來獲得資訊。甚至化學場可以和“物質”結合起來。（這個在以後的Post進行描述）
聲場——用於描述聲音的情況。可以通過說話、吼叫來傳達資訊，同時移動也會泄露資訊。
等等

上面這麼多的場並不都是必須的，一個遊戲可能只會使用其中的一個或者兩個場，但是都用也是可能的，例如我所考慮要複現的Terrarium就需要所有的這些場。那麼這些場怎麼描述呢？肯定是一個簡化的形式，例如化學場，會用一個int來表示某一種化學物質，另一個int表示該化學物質的強度。同一個地點可以有多個物質，也可能是同一個地點只能有一個物質但是附近有別的物質，這兩種形式我還沒有考慮清楚，但是有一點是確定的，那就是應該讓“遊戲對象”認為“這裡”有好幾種“化學物質”。
再比如說聲音，一個int表示頻率，另外一個int表示強度。我想這個就足夠傳遞眾多的資訊了。

有人會說了，那個可見光場還有重力場，不應該是地圖做的事情嗎？對，很多時候都應該是地圖的事情，甚至化學場也是地圖的事情，比如星際上面的礦和油，不就可以算是化學場嗎？但是，我們要考慮的是一個通用的架構，所以必須要把這個概念從地圖上面剝離出來。不然的話這個Map對象就很難定義，或者定義出來的Map對象適應性非常的差！比如說我們考慮：1、星際；2、QuakeII。那麼星際也許需要化學場，不需要重力場，但是QuakeII沒有重力場肯定不行，但是化學場有什麼作用呢？

當然，我這個考慮也不是很成熟，因為這麼多的場，很可能會佔用非常多的資源，包括CPU使用率和記憶體佔用情況。但是這個概念我還是得提出來，至於具體怎麼個設計，使得佔用資源的情況可以接受，那就是另外一回事了。

第二個要提出來的是“環境”。所謂的環境就是指一些“世界”常量，相當於係數，這些係數影響著整個“遊戲世界”的物理規律，或者守恒情況。也許大家會說：係數那還不好辦嗎？隨便找一個地方定義一個public static的東西就行了，何必搞出一個概念出來進行開發呢？讓我描述下面這幾個問題：
1、首先，隨便找一個地方有一個很大的缺點，就是遊戲開發人員不知道到哪裡去設定和調整這些係數，或者需要到處去找。重力相關的要到重力那裡去找，化學相關的要到化學那裡去找……找著找著就煩了，找不到那就更煩了。
2、其次，有一個問題不知道大家考慮過沒有？有些係數可能會影響另外一些係數的情況，為了正確調整某個係數的值，開發人員不得不調整一系列的值，這個問題時不得不正視的問題。舉個例子：
標準海平面重力加速度數值：g
海平面重力加速度調整係數：gFix
地球半徑數值：rEarth
標準單位重量移動消耗能量數值：burn
單位重量移動消耗能量調整係數：burnFix

那麼某個品質是m的對象在某個海平面高度h移動所需要消耗的能量的計算公式也許如下：（肯定不對，只是示意一下）
needToBurn = m * (gFix * g * rEarth/h) * (burn * burnFix) = gFix * g * rEarth * burn * burnFix * m / h
大家可以看到最後等式裡面前面一大串的數值都應該屬於世界常量，為了加快這個公式的計算，就應該有一個“海平面單位重量移動消耗能量值 burnSeaLevel = gFix * g * rEarth * burn * burnFix”，如此一來計算needToBurn就可以減少四次乘法計算（畢竟修改世界常量的頻率肯定非常低）。那麼問題就出來了，如果提供一個控制台命令，修改gFix，那麼這個命令就很麻煩了，除了需要修改gFix之外，還需要修改burnSeaLevel，以及其他這裡沒有提到的blablabla。

如果有一個“環境”，我們只需要定義好一些常量，以及一些“偽常量”的計算公式。那麼當修改某個常量的時候，“環境”就會協助我們自動更新那些“偽常量”，開發人員只需要定義一次，修改一次（而不是多次）。是否很方便呢？

最後，我來說一下地圖。由於有一些概念從地圖裡面剝離出來了，所以有必要說一下地圖上面有什麼。地圖上麵包括這個地圖的大小的定義，以及傳統意義上的“地圖”。也就是是這個地圖上面有些什麼對象，這個對象包括人物啦，物品啦，建築啦，還有陷阱（機關）——用於觸發某些事件。

這次就說到這裡，下次繼續。下次可能會說到“規律”以及/或者其他的一些東西。