终于,在前天把地图做出来了。
它是一个无限大的可自动扩充的地图。理论上它可以管理的区域为2^63 * 2^63 格。格这个单位可以是像素,格子,或者其他。
实现原理是树,使用树形结构从根一路扩展到树叶,自动搜索,自动添加节点。
每个地图区域的获得需要17个节点的搜索,效率上看似乎有些地方浪费了,不过可以从缓存方向解决这个不足。
地图的存储使用nosql数据库,所以它支撑这种存储方式。
终于,在前天把地图做出来了。
它是一个无限大的可自动扩充的地图。理论上它可以管理的区域为2^63 * 2^63 格。格这个单位可以是像素,格子,或者其他。
实现原理是树,使用树形结构从根一路扩展到树叶,自动搜索,自动添加节点。
每个地图区域的获得需要17个节点的搜索,效率上看似乎有些地方浪费了,不过可以从缓存方向解决这个不足。
地图的存储使用nosql数据库,所以它支撑这种存储方式。
如果抛弃玩家的操作接口,星海传奇就是一个自然发展的世界,当然需要给里面每一个功能单位添加AI。
世界的主体是星系,星系内有各种对象,主要的对象是移动要塞,次要的是NPC,再其次的是星系物体。
模拟要素一,地图:
星系很大,需要保存的东西虽然不多,但为了可能存在的无限扩展地图,需要定义一种高可扩展的地图。我在之前的博客有介绍过。
模拟要素二,时间:
既然是一个世界,那么我们需要处理世界中的大大小小的对象行为,时间控制以任务的形式,由任务调度来执行。
模拟要素三,事件:
世界中对象的状态改变由监听器来交互,感兴趣则监听状态否则不管。
模拟要素四,对象:
世界基本对象构成,星海传奇中,数据存储以对象为基本单位,基本处理单位也是对象。
互联网服务的特点就是面向海量级的用户,面向海量级的用户如何提供稳定的服务呢?这里,对这几年的一些经验积累和平时接触的一些理念做一个总结。
一、原则
1.Web服务的CAP原理
CAP是指的是三个要素:一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)。CAP原理指的是这三个要素最多只能同时实现两点,不可能三者兼顾,对于海量级服务,一般这是一条常记心中的基准准则。
如下是《Web服务的CAP 》关于CAP的定义:
Ctrl+1 快速修复
Ctrl+D: 删除当前行
Alt+↓ 当前行和下面一行交互位置
Alt+↑ 当前行和上面一行交互位置
Alt+← 前一个编辑的页面
Alt+→ 下一个编辑的页面 阅读这个条目剩下部分 »
忽然发现,我对项目的要求太宽太泛了,好像不一次开发出承载100W同时在线就不能活似的,搞到现在,结果就是阻碍重重却无法看到产品。
我该检讨,该改变做事方法,由小到大,积少成多。
星海传奇在我的脑海中是个奇大的世界,可是它需要解决的技术问题不是几天就能解决的。好吧,我会做个规划,将可替换的东西使用简单的实现或者开源项目来解决。到了该为星海传奇添加roadmap的时候了。
1、Hypertable:它是搜索引擎公司Zvents根据Google的9位研究人员在2006年发表的一篇论文《Bigtable:结构化数据的分布存储系统》开发的一款开源分布式数据储存系统。Hypertable是按照1000节点比例设计,以 C++撰写,可架在 HDFS 和 KFS 上。尽管还在初期阶段,但已有不错的效能:写入 28M 列的资料,各节点写入速率可达7MB/s,读取速率可达 1M cells/s。Hypertable目前一直没有太多高负载和大存储的应用实例,但是最近,Hypertable项目得到了百度的赞助支持,相信其会有更好的发展,地址:http://www.bt285.cn 下载。 阅读这个条目剩下部分 »
见鬼,我居然买了一本厚黑学,并且还看了几章。
一直觉得自己老实巴交,和熊猫合计了一下买了本厚黑学,然后就和那边易经一样搁置在案头,忽然有天无聊拿起厚黑学看了两篇。 阅读这个条目剩下部分 »
一个web游戏的产业链中有两条重要的链:
利益链、信息链。
利益链:
游戏除了休闲,还有一个重要的作用是为现实生活中不得志的人提供心理补偿的地方。这是利益链的一个重要驱动,游戏为玩家提供物品道具来弥补玩家在现实中办不到的事。
信息链:
游戏要维持利益链的持续,需要不断的给游戏添加内容,有个很好的办法就是为玩家提供参与游戏的机会。
游戏社会: 阅读这个条目剩下部分 »
不知是不是快过年了,总感觉到有些累。在公司越来越没有什么存在感了,可能和公司现在的工作方式有关吧,我不知道在公司还能做多久。每个人都有自己的价值,群居动物需要向其他个体证明自己的存在,当他体会不到自己的存在的时候,不知他会做何打算。
准备请个年假,带着熊猫回家过年,呵呵,希望能获准。不然老子不干了。