现在有一张大的地图，人物行走会解锁周边x*x的迷雾。有什么算法可以以最小的数据量存储已探索的地方呢，存储的数据越小越好。
主要是存在服务端，常规的保存方法数据量有点大
大佬们都在哪
bitarray 存储就可以了。0或1表示是否探索过。
这个方法数组最后还是会很大
你不会记录所有坐标点吧，这种迷雾解锁都是一块一块的，固定打几个点就行了
是一块一块，地图分成了很多块，每次解锁都把每块数据存起来，解锁到后面，就存储很多了
之前有个优化方案是，连续的格子会合起来记。看有没更好的
方块迷雾必然是一个起点开始向外扩张
记录 上 下 左 右 各开启了多少迷雾区域
比如起点 100,100 上 20格 下 30格 左 50格 右 100个
服务器只需要存储这些数据就可以
多大的地图可以用
1赞
这不是指单格，这是嵌套位置 这样不需要每格都存储，数据越多效率越高
很多是多少，一张图一个int可以标记32个区域，都是flag 能占用多少空间，一百张场景也就400字节，一K都没有
单独存储是没什么。每个用户现在的数据是按字符串存储在mysql，基于这个来做数据量优化。
斜方向的格子没法记吧，地图上是否解锁需要全部显示的
这种数据的特征是连续性比较强，可以考虑把每行拼接成一个01长串，然后用0n1m…的方式压缩。
0n表示接下来有n个0，1m表示接下来有m个1。
行拼接和列拼接两种做比较，那种压缩后数据小用那种。
结果和01串的zip压缩再做比较，用小的那个。
1赞
2维数组那有斜方向了，默认未解锁，有数据就是解锁的。你这个过分了
斜着走也不影响存储的，本质不变
把所有能走的结果都算了存起来，服务器只存已走结果对应的地图ID。用空间换时间
长>宽 用行拼接，在去掉未解锁的，100*100 已解锁的大概就是 1,100 | 510,550 | 1000,1500 | … 看还有没优化空间
用0、1切换的步长代替区间，因为尾端的数字大，串就长。但是步长相对较小。
你的这组数据改写后就是 100,410,40,450,500。
然后数字转成26进制/52进制字母表存储，更短。如果你直接存字节流的话那就不用转。
有点难理解，是这意思吗
起始点 = x + （y-1）*width
起始点，步长 | 起始点，步长