先讲在前面，我对于“乘龙消失”这个命题保持疑虑，所以可能会有偏见..
也先撇开原文的生怪模式探讨，如果是交给半桶水乌鸦来处理的话会是这样：
[丢骰子服务器]
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
然而 ( 在于没有变动的前提下 ) 是没有过一个点一个小时没有准时生怪
出来的前例的。可以观察自己家/学校/办公室圈得到的地点，会生出来的
点就肯定是每个小时的同一个分秒那段区间会出现一只怪。