吃金幣的人是對基因算法的一個研究和實驗，主要是資料及算法上的研究和測試。後來使用good的繪圖能力把它圖形化，同時測試及擴展good的整合能力。現在再進一步把它和網路底層作結合，建立一個新的實驗平台，命名為nature online。
和good一樣建立no的目的是為了創造一個可以讓我平常利用空間時間來作研發和實驗的平台。no整合了所有到目前為止所作的小實驗和研究。主要的目標是研究分散式網路遊戲的架構及模擬生態系統。
目前具備的功能:
- 分散式的網路伺服器架構，後端使用mysql。
- 使用2張測試地圖，隨時可以任意切換至任意地圖任意位置。
- 地圖物件目前有二種:tree/bug。
- tree物件應用生命遊戲規則生成及更新。
- bug物件應用基因算法活動食物為tree物件。
- 自動同步client可見視野內的內容。
-使用good為client成象引擎。
下階段的目標是持續底層研發及增加更多種類的物件。
;=========================
以下二件事是需要特別記錄的。
A.
首先tree物件的更新決定以生命遊戲的規則來作更新及生成，規則沒什麼問題，問題是數量和速度。如果是像good內建的life範例，那相當於16x16的地圖格子大小，總數也才256格，每次更新時全訠256格都掃一次也沒什麼問題。不過當地圖變成像no那樣是500x500或更大時，問題就出來了。每次要掃那麼多的格子，速度就成為一個問題了，而且server每次更新不只是要更新tree物件而己，還有其它工作要作。
一個簡單的解決方法是只檢查需要檢查的格子。
1,記錄目前有那些存活的格子
2,根據存活的格子推算有那些格子在下一世代可能產生狀態變化,可能有狀態變化的格子也就是存活的格子的周圍8個空格子
3,下一世代只需計算(目前存活格子+可能產生狀態變化的格子),其它的格子都可以忽略不看
假設目前存活的格子是10000個，這10000個格子周圍總共30000個空格子，那麼下一世代只需計算40000個格子，而不是全部250000個格子。數量大大的減少了!
B.
bug物件是以基因算法為基礎來製作。和吃金幣的人一樣，假設基因的編碼是根據上下左右中5個格子(環境變數)共3種不同狀態，基因長度為243。現在的問題是，假設過了一段時間之後，要改變編碼需要檢查的格子數或狀態數，這樣一來原本之前花時間演化出來的基因就會無效。因為新舊編碼方法不同產生的基因長度是不同的，二者無法一一對應。雖然舊的編碼方式的基因可以作為新編碼方式基因的一個子集合被包含，但是存取的方法必須改變，否則無法相容。
一個簡單的解決方法是另外維護一個編碼對照表，這樣即使基因的長度擴充了，舊的基因的位置還是不變可以向下相容。
1,建立<狀態編碼,基因位置>對照表
2,分別處理二種不同的擴充基因的狀況
* 檢查格子數擴充
* 檢查狀態數擴充
討論檢查格子數擴充的狀況。
0 0 [0] 0 [0 0] idx0
1 0 [1] 0 [0 1] idx1
1 0 0 [1 0] idx2
1 1 0 [1 1] idx3
1 0 0 idx4
1 0 1 idx5
1 1 0 idx6
1 1 1 idx7
假設現在只看一個格子且狀態只有0和1二種，如最上表最左行所示，基因長度為2，基因的索引位置為0和1。現在新增一個格子，每個格子一樣有二種狀態，基因長度變為4(2^2)。請看上表中間的部份，列出4種可能的狀態編碼，中括號標出來的[0]和[1]為一個格子的狀況的可能編碼，這是需要在基因擴充時保持不變且向下相容的部份。同樣的再增加一個格子，總共可能的編碼變為3^2=8。如上表右側部份列出所有可能編碼，中括號標示出來的部份[00][01][10]及[11]是必須保持不變向下相容的。
討論檢查狀態數擴充的狀況。
0 0 [0 0] [0 0] idx0
0 1 [0 1] idx1
1 0 0 2 idx2
1 1 [1 0] idx3
[1 1] idx4
1 2 idx5
2 0 idx6
2 1 idx7
2 2 idx8
如上表所示，類似於討論檢查格子數擴充的狀況所說明的，每增加一個新的狀態時，需要保持不變且向下相容的編碼規則會有些不同。不像上面增加檢查格子時舊的部份維持在上半部，新增的部份在下部份。每增加一個新的狀態時，舊的編碼和新的編碼會互相交錯，但還是可以看出其中的規則。
依據以上二個不同狀況變更編碼擴充基因時變更維護的<狀態編碼,基因位置>對照表，這樣就可以繼續套用原來己花時間演化出來的基因而不必全部打掉重來。
和good一樣建立no的目的是為了創造一個可以讓我平常利用空間時間來作研發和實驗的平台。no整合了所有到目前為止所作的小實驗和研究。主要的目標是研究分散式網路遊戲的架構及模擬生態系統。
目前具備的功能:
- 分散式的網路伺服器架構，後端使用mysql。
- 使用2張測試地圖，隨時可以任意切換至任意地圖任意位置。
- 地圖物件目前有二種:tree/bug。
- tree物件應用生命遊戲規則生成及更新。
- bug物件應用基因算法活動食物為tree物件。
- 自動同步client可見視野內的內容。
-使用good為client成象引擎。
下階段的目標是持續底層研發及增加更多種類的物件。
;=========================
以下二件事是需要特別記錄的。
A.
首先tree物件的更新決定以生命遊戲的規則來作更新及生成，規則沒什麼問題，問題是數量和速度。如果是像good內建的life範例，那相當於16x16的地圖格子大小，總數也才256格，每次更新時全訠256格都掃一次也沒什麼問題。不過當地圖變成像no那樣是500x500或更大時，問題就出來了。每次要掃那麼多的格子，速度就成為一個問題了，而且server每次更新不只是要更新tree物件而己，還有其它工作要作。
一個簡單的解決方法是只檢查需要檢查的格子。
1,記錄目前有那些存活的格子
2,根據存活的格子推算有那些格子在下一世代可能產生狀態變化,可能有狀態變化的格子也就是存活的格子的周圍8個空格子
3,下一世代只需計算(目前存活格子+可能產生狀態變化的格子),其它的格子都可以忽略不看
假設目前存活的格子是10000個，這10000個格子周圍總共30000個空格子，那麼下一世代只需計算40000個格子，而不是全部250000個格子。數量大大的減少了!
B.
bug物件是以基因算法為基礎來製作。和吃金幣的人一樣，假設基因的編碼是根據上下左右中5個格子(環境變數)共3種不同狀態，基因長度為243。現在的問題是，假設過了一段時間之後，要改變編碼需要檢查的格子數或狀態數，這樣一來原本之前花時間演化出來的基因就會無效。因為新舊編碼方法不同產生的基因長度是不同的，二者無法一一對應。雖然舊的編碼方式的基因可以作為新編碼方式基因的一個子集合被包含，但是存取的方法必須改變，否則無法相容。
一個簡單的解決方法是另外維護一個編碼對照表，這樣即使基因的長度擴充了，舊的基因的位置還是不變可以向下相容。
1,建立<狀態編碼,基因位置>對照表
2,分別處理二種不同的擴充基因的狀況
* 檢查格子數擴充
* 檢查狀態數擴充
討論檢查格子數擴充的狀況。
0 0 [0] 0 [0 0] idx0
1 0 [1] 0 [0 1] idx1
1 0 0 [1 0] idx2
1 1 0 [1 1] idx3
1 0 0 idx4
1 0 1 idx5
1 1 0 idx6
1 1 1 idx7
假設現在只看一個格子且狀態只有0和1二種，如最上表最左行所示，基因長度為2，基因的索引位置為0和1。現在新增一個格子，每個格子一樣有二種狀態，基因長度變為4(2^2)。請看上表中間的部份，列出4種可能的狀態編碼，中括號標出來的[0]和[1]為一個格子的狀況的可能編碼，這是需要在基因擴充時保持不變且向下相容的部份。同樣的再增加一個格子，總共可能的編碼變為3^2=8。如上表右側部份列出所有可能編碼，中括號標示出來的部份[00][01][10]及[11]是必須保持不變向下相容的。
討論檢查狀態數擴充的狀況。
0 0 [0 0] [0 0] idx0
0 1 [0 1] idx1
1 0 0 2 idx2
1 1 [1 0] idx3
[1 1] idx4
1 2 idx5
2 0 idx6
2 1 idx7
2 2 idx8
如上表所示，類似於討論檢查格子數擴充的狀況所說明的，每增加一個新的狀態時，需要保持不變且向下相容的編碼規則會有些不同。不像上面增加檢查格子時舊的部份維持在上半部，新增的部份在下部份。每增加一個新的狀態時，舊的編碼和新的編碼會互相交錯，但還是可以看出其中的規則。
依據以上二個不同狀況變更編碼擴充基因時變更維護的<狀態編碼,基因位置>對照表，這樣就可以繼續套用原來己花時間演化出來的基因而不必全部打掉重來。
留言
張貼留言