先講在前面，我對於「乘龍消失」這個命題保持疑慮，所以可能會有偏見..
也先撇開原文的生怪模式探討，如果是交給半桶水烏鴉來處理的話會是這樣：
[丟骰子伺服器]
table: work_list
hive_id hive_type
94879487 water_a
94879488 mountain_c
94879489 urban_a
94879490 event_a
94879491 event_b
* hive_type 是根據 open street map 的資料來算的，
hive 的經緯度座標則是參考 NIA 前前作 ingress 人口活動量去算的
可能是每小時的 30 分開始工作, 照這這個表格逐個丟骰子
94879487 丟一次骰子得到 31 點，查 water_a 的權重表格：
1 = 呆河馬
2~12 = 呆呆獸
13~40 = 可達鴨
41~99 = 鯉魚王
所以下一個小時 hive_id = 94879487 會在一分二十七秒的時候生出可達鴨；
然後繼續丟骰子得到三項 iv 以及兩項技能跟身高體重以及一個等級的參數。
... 然後製造類似下面的東西吧：
table: next_hour_result
hive_id poke_id atk def hp move_a move_b h w lv_factor
94879487 54 15 15 15 10 29 0.87 19.87 20
94879488 143 0 0 15 16 132 1.87 487.0 15
94879489 19 10 10 10 222 132 0.33 3.33 7
94879490 124 6 6 6 223 86 1.00 41.60 15
94879491 13 0 0 0 99 134 0.33 3.21 0
* 上述的 table 以及丟骰子權重表都只是為了呈現方便，不一定要真的在資料庫
裡面蓋這些表格，只是一堆存活在變數裡面的東西或者硬碟上的一份 json/xml
都可以。
[小智查詢怪物用伺服器]
這傢伙就可以開一到數台，端看供應資料的需求有多大。
這台的運作方式是每個小時的 45 分或者一開機 ( 供應資料需求上升時候加開 )
就去跟丟骰子伺服器討一份 next_hour_result，用來充實自己這邊的資料：
table: hive_base_info
hive_id lat lng min sec appear_type
94879487 25.000612 121.551309 01 27 15min
94879488 25.029999 121.569714 31 01 15min-15min
94879489 25.025468 121.501704 01 39 15min
94879490 24.978100 121.520370 11 28 15min
94879491 25.002141 121.513357 40 00 15min
( 當然，這邊的經緯度舉例不好，一台應該只負責一小塊區域 )
所以小智的手機就是跟這台問說：
「嘿！我在 (25.000612, 121.551309) 附近有什麼 *****ing？」
然後就看看手表，照經緯度跟種類丟東西回去砸小智..
「畫個草叢，前面放隻鴨，沒了 A_A 」
上述這樣子的規劃可以確保再多的小智擠到南寮也能正確給予
該出什麼東西的資料。 ( 大概吧？ BUG 總是上線後才來報到 A_A )
無論是更動巢穴或者萬聖節活動都只需要去更改 hive_type 對應出來的
權重清單就可以了，這是在數量相對很少的機器 [丟骰子伺服器] 上的事情
( 以這樣子欠缺考慮的時間規劃，大概就是一台能在十分鐘內能丟幾次九個
骰子吧？然後看遊戲開始之前用 open street map 算出了多少組 hive_id
除一除就知道這個「相對少數」是多少.. 我是覺得這應該是個可以接受改變
的數量啦 )
****
接著是前述架構的猜測理由，無論輕重，依照順序來講。
* 使用 open street map 來算生怪點 ( 前述 hive_type )
> 萬盛溪這條看不到的地下河的路徑完美的呈現了迷你龍重生的地點
http://i.imgur.com/DkKA7Ma.png
圖中箭頭是我所熟知的重生點，無論巢穴怎麼搬家都不影響
「扣除掉旁邊的河流，附近的迷你龍完全不會在這條路徑外出現」
* 使用 NIA 前前作 ingress 的經驗來決定生怪點地方數量與密度
> 鄉下沒人權，又山頂幹嘛一堆雜魚在密謀開會..
擺明跟前前作邪惡的 XM 產生方式一樣是 NIA 的邪惡結晶
* 使用的是 water_a event_b 然後去不同分類查扔骰子的權重表
> 地區性的東西不會搬家，好比說前面提到的萬盛溪迷你龍
> 每次搬家的那些 event_a event_b event_c 都是 四號公園 陽光公園
新莊運動公園 bla bla 那些地方，甚至 連座標點都一樣的直接代換
> 先運算過並且固定下來的生怪點 可以依照這種模式確保
「在不違背神奇寶貝生態習性 以及 人口流動正比於生怪量 的前提
下生怪決定不會造成過多的運算負擔」
( 達成了利用 open street map 的資料細緻的塑造生怪點差異
又可以規避掉教會程式一堆不規則區塊識別的複雜運算；亦即
把面的概念切割成許多獨立的點 )
* 每一個生怪的點在每個小時生怪的時間是一樣的，好比說一分二十七秒
> 這算是借用了不法所得而知道的資訊；在那些雷達還活著的時候就可以
觀測到 同一個點 ( 經緯度座標精準到小數點下六位，大約兩公尺吧 )
在於每個小時生怪的時間分秒上是完全一致的
> #050 20161006 18:45:30 #Diglett
#050 20161006 18:15:30 #Diglett
#027 20161006 17:45:30 #Sandshrew
#027 20161006 17:15:30 #Sandshrew
...
#023 20161006 14:45:30 #Ekans
#149 20161006 13:45:30 #Dragonite
- 14/ 8/ 5 (60%)
- #Dragon_Breath #Hyper_Beam
#149 20161006 13:15:30 #Dragonite
- 14/ 8/ 5 (60%)
- #Dragon_Breath #Hyper_Beam
節錄部分的不法所得 /o,o\
這段展示出了：
- 出現 15min 消失 15min 出現一模一樣 15min 的生怪點
- 邪惡的雷達會漏東西 14:15:30 應該也要有一隻阿伯蛇的紀錄才對
- ( 這個點 ) 都是每小時的十五分鐘三十秒生怪
- 只要是生怪點，每小時必定生一隻怪
****
hmm.. 寫了又臭又長，好像只是零碎的提出了一個新的做法，
也沒有真的贊成或駁斥到什麼東西；看起來也不夠「程式」...
好吧，文末補一下覺得原文中可以商議的項目：
* 更換巢穴沒有想像中複雜與耗能，以我的架構例子只需要派送 event_a
event_b 權重清單這些資料給 [丟骰子伺服器] 的伺服器變更資料就可以了
可以是一直開著的 socket 也可以是一次的 curl，扔應該不會超過 50MB
的資料吧？ ( 要定義那麼複雜的權重應該也很燒腦子.. )
* 教會程式 南寮 台北市中心 這樣子的概念可大可小，越細緻的呈現
應當對於運算的複雜程度越高；一隻迷你龍的程式丟出了要出現在萬盛溪
骰子，然後萬盛溪的不規則形狀是這一百個節點，挑裡面的一個座標..
是做得到啦，只是每次都要選擇一個點這件事情也是一道工啦，比起先選好
點然後每個點都使用來說真的是多費一點力氣。
* 根據不當得利的遺產所得.. 每一個點每一個小時就是會生一隻怪，
原文在極端的狀況下..
- 波波.. 南寮！(2%)
- 波波.. 南寮！(2%)
- 波波.. 南寮！(2%)
- 波波.. 南寮！(2%)
... ( X！全世界的波波都給南寮就好了呀 )
這種狀況下會讓某個生怪點一個小時沒辦法正確的生出一隻怪 0.0
然而 ( 在於沒有變動的前提下 ) 是沒有過一個點一個小時沒有準時生怪
出來的前例的。可以觀察自己家/學校/辦公室圈得到的地點，會生出來的
點就肯定是每個小時的同一個分秒那段區間會出現一隻怪。