当然做点改变
你想都不想就直接说这个是管显存的。。。难道就只用在显存管理上？

cosin提到的这个算法可以用来延缓大地图读入客户端，并且修改好了，可以实现近乎平滑的滚动效果。我用过类似的算法。不过本帖的意图在于讨论生成算法来取代存储和传输，而且不影响客户端和服务器端的一致性。
至于地图的分片处理技术，应该都算是处理显存吧，可能IE或其他浏览器也会把图像渲染在内存中，甚至渲染在虚拟内存中，但区别并不大。也就是说，如果客户端不能一下子装入10000个元素，那我们就分片，让他在同一时刻只装100个，这样就平滑了，流畅了，其余的等快要“看见”时再装。但装的方法基本是一致的，就是“读”。而本贴的目的就是要达到“不读胜全读”，即，服务器端生成的地图可以通过几个种子的传输在客户端完全再现，那样就不需要传输小片的地图了。

不知道说明白没有。

每个数字代表一屏幕
01 02 03 04
05 06 07 08
09 10 11 12
13 14 15 16
Player 在第6区，Client Browser 保存 9 个区的地图数据(01,02,03,05,06,07,09,10,11)
如果移动到11区，则丢弃 01,02,03,05,09  区的数据，并根据服务器来的种子生成08,12,16,14,15区的数据
假设Player又跑回06区，那么丢弃 08,12,16,14,15区的数据，并根据服务器来的种子生成01,02,03,05,09区的数据
Client Browser 上始终只要保持 9个区的数据，以 32*32 Tile 大小，屏幕为 1024 * 768 来计算
数据量 = (1024 * 768) / (32 * 32) * 9 * 100（假设每个Tile用 100 Byte 描述各种属性）= 675 KB

如果用稀疏矩阵存储，应该可以小很多，如果 Tile 的数据设计合理点，可以更小

[ 本帖最后由 cosin 于 2007-8-20 14:38 编辑 ]

嗯，基本说到点子上了。关键是“根据服务器来的种子生成01,02,03,05,09区的数据”这句。现在要讨论的就是怎样生成。

稀疏矩阵和纹理压缩是很高深的技术，不过在这里应该留给客户端的程序员去解决，相信cosin也是老家伙了，应该讨论一些构架上的安排。只要地图生成工作能顺利完成，把地图显示出来并保证平滑，甚至实现3D之类的都不是难事。

。。。生成很难么？好象只是麻烦而已

1 将地形按 2 种进行分类：可通过/不可通过
2 生成 0/1 格式的纯连同性描述地图
3 按 0 = 不可通过, 1= 可通过 原则进行替换地形代码
4 进行地形视觉连贯性修正不可通过地形（按需要可以将部分的可通过地形修改为不可通过地形）
5 进行地形视觉连贯性修正可通过地形（替换的地形只能是可通过地形）

就行了。。。只是视觉连贯性修正比较难，这个就是判断比较多

嗯，又说到点子上了。“视觉连贯性修正比较难，这个就是判断比较多”这句！
修正和判断是并存的，而且在生成一个"块"的时候很难保证客户端有其他"块"的相关知识。所以修正起来显得不是很从容。另外，如果全图都需要修正的话，局部的修正可能是与全局或其他局部的修正结果矛盾的。
如果生成结果不需要修正，那就好得没话说了。(但是很难找到)
如果生成结果可以作局部修正，并且理论上保证只要分块足够大，就不会有修正矛盾，这样的算法也是非常可取的。

既然是在探索新方法，我想也不一定局限于连贯性修正的方法。(其他的偶也不知道，所以才发帖啊)

[ 本帖最后由 necrocoder 于 2007-8-20 14:54 编辑 ]

每个块生成时，最多只有2个块的边缘与之相连，另外2边是不需要的地图，因此直接无视之
需要修正的也只有相连的边缘附近的那些块，其他块其实很自由，想怎么改就怎么改

另外块的修正和Tile的设计有关，设计的合理，就很容易修，否则就很麻烦。。。

01 02 03
04 05 06
07 08 09

比如这样的块，修正01时假设只考虑02 04，这没问题，但是修正02时，可能会用到一些01修正的结果(在交界的地方)，而这些改变即使很轻微，也不能保证对03的修正不会产生影响。除非，确保02分块和01分块的交界部分绝对不变。但这样一来，如果推广下去，则会有4个边都不能改变了。这样的地图是否能确保联通？

修正只修正新生成的那快，原来已经生成的完全不动。。。有什么理由要去改原来已经生成的呢？

生成顺序：
1 => 01
2 => 01 02
3 => 01 02
        03
4 => 01 02 04
        03
5 => 01 02 04
        03 05
6 => 01 02 04
        03 05
        06
7 => 01 02 04
        03 05 07
        06
8 => 01 02 04
        03 05 07
        06 08
9 => 01 02 04
        03 05 07
        06 08 09

哪一块是4条边都不能变的？最多只有2条边。。。
话说回来，就算4条边都不能变，里面还有那么多Tile呢。内部调节应该也搞的定的

并不是想要改变已经生成的地图，而是生成的地图超大，所以不能全部存储。这样一来，以前生成的地图就迟早面临被"丢弃"，和那个分片的技术是一个道理。丢弃后的地图也不一定就没人用了，也许又用到了，于是要重新生成。不过，虽然存储系统把原来的地图丢了，但玩家可能还记得清清楚楚，所以，重新生成的地图要和丢掉的基本完全一样，至少在联通上是一样的。

都用固定种子了，难道不能生成一样的图么
计算机里的随机数都是伪随机数。。。

但是修正会不一样：
1  => 01
2  => 01 02
3  => 01 02
         03

如果不是从01开始，就完全不同了
1  => 0A
2  => 0A 01
3  => 0A 01
         0B
4  => 0A 01 02
         0B
5  => 0A 01 02
         0B 03
……

后面就不写了

[ 本帖最后由 necrocoder 于 2007-8-20 15:37 编辑 ]

地图采用随机数生成背景地图

背景地图每100*100的区域采用一个数值为Key（随机种子）进行生成，这样可以保证每次生成的100*100的地图都是一样的。

假设地图是10w*10w的总宽度，那么，需要保存的key就有100w个。以前做过一个测试，在MSSQLServer里对以数值ID为索引100w条记录的查询，其响应时间可以在100ms内，理论上可以忽略查找时间。

其实当用户首次打开地图时，根据用户当前所在的位置，找到对应区域的Key，并根据该Key生成100*100的地图后，把地图保存在用户Session里，后面的访问，只要不跨过该地图区域，则不用再重新生成。
假设，每个地图用2个byte来表示（65535种情况应该够用了），100*100的地图需要20k的内存，按照目前web游戏2K人在线计算，保存背景地图需要40M内存，在服务器以G计算的内存里，这点占用应该是可以接受的。

至于地图上的道路，村庄，城市等点，可以采用疏矩阵的方式保存在数据库里，如果嫌道路占用空间多，还可以针对道路，只保存道路的起点坐标和终点坐标，在首次加载地图时，再生成对应的坐标，这个应该不难。这些信息连通背景地图信息一起保存在Session里，应该占用不了多少资源。

最后，玩家在游戏的时候，喜欢扎堆，那么在很大程度上，部分玩家会在同一个地图区域内活动。针对这些在同一区域内活动的玩家，在服务器端，采用同一份背景地图，那么又可以减少部分内存空间。

用种子保存和传输自然效率是很高的，也具有很强的可行性。关键是怎么生成？算法是什么样的？

具体算法就不是我能写的了，具体情况要你自己来，我只能提供给您一个应用的架构。具体的代码，仍然可以采用随机数来。
在不考虑地图的情况下，完全可以进行全随机数生成，或者根据一定的模板地图来进行。

假设目前有100个模板，事先自己设计，符合一定的规则，模板只规定了一些山的坐标。
对山附近5*5的地方随机生成一些森林，
在随机生成森林的地方再随机生成一些灌木丛
剩下就就以草地或者沙漠来填充。

模板是个好思路！

难题主要在与如何处理地图上生成设施建筑的连贯和自然性
把一些块于块相连的地方单独建立处理规则，
比如
物体1可以放在背景2和3上，物体1只能和物体2搭配或者单独存在，那么就要建立一些这样的规则在地图生成的时候根据这些规则去判断生成，规则设置的越细微，生成的地图效果越好，来回经过的时候误差越小