阶段总结3



游戏对象的存储
游戏对象包括在游戏场景中所有的怪物，npc，物品等，游戏对象有一下几点要求：
1 全局唯一索引，根据对象获取索引和根据索引获取对象，这个全局索引作为服务器内部以及服务器和客户端之间
  对同一个对象的标示。
2 类型体系结构，索引和对象之间可以互相转换，根据对象实例，获取对象的继承体系
3 各种池技术
第一点解决方案有两种，第一种在老项目中使用的，简单粗暴，直接将对象的内存地址作为对象的索引
第二种方案成为自动列表，事先生成一个对象池，理解成为一个对象数组，new对象的时候去查找一个可用
的位置存储该对象，于是数组下标就成为对象的索引，这种方式添加了一层间接性，不直接操纵指针，
在函数传递过程中传递的都是数组的下标，理论上来说更加安全。
第二个需求的解决方案在于手动实现一个对象继承体系。每个对象在创建时指定一个类型编码，以及父类对象
，存储在一个数组中。初始化数组时先把父对象以及父对象的父对象的code直接填入数组中，然后在数组的下一个
位置填上自己编码，每个类保存自己的继承层次：即自己的编码在数组中存储的下标。于是判断两个对象是否是
同一种类型就变成了比较自己下标的code是否相等。判断一个对象是否继承与另一个对象只需要遍历数组0-下标-1的
位置与另一对象的编码比较，即自己的继承体系中是否有一个编码等于待比较对象的编码。
3 第三个，内存池对象池就很多了。

场景管理
职责：
1 地图，地形 ：网格，地图划分多少行多少列，每个网格大小，是否允许站位，xstar寻路
2 移动，视野  ： 寻路，移动+服务器验证，广播，视野的大小，九宫格
服务器的性能瓶颈主要在网络IO，网络IO占用最多的就是广播，移动，战斗等。有的服务器支持单服多少人，有的
支持多少人同屏，这其实在不同游戏里是没有可比性的。网络中间层各大公司都差不多，网络总的吞吐量都差不多，
这样影响在线人数的是哪些因素呢
1>网格大小：同一个地图，网格大一些和小一些广播包的数量会有很大差距，网格的大小又会影响到用户体验，所以
  综合来讲是在用户体验和我们预估的服务器承载人数的一个平衡。（所有移动都是服务器验证跨网格否）
2>视野的大小：视野大小影响的广播包的数量，同屏玩家的数量，npc，野怪，掉落的数量，所以视野越大，广播包越多。
3>这个就跟本模块无关了，协议的定义，哪些消息服务器验证和广播，哪些客户端存储。影响包的数量和大小
4>服务器单区支持的人数和此无关，和服务器架构相关，例如我们的游戏服务器采用8个逻辑服务器，社会关系服务器共享，
  网关与逻辑服1:2，单gs至少支持1000+，大概在1500左右，这样单区支持12000人。去掉一定的冗余，通过gs限制登录在
  8000-10000，然后限制单张地图的角色数量，超出了就开支线.但是同屏就不一样。同屏的限制主要在网络报的广播量。
3 游戏对象管理 ：npc，野怪，掉落，资源，角色
这一块主要相关的就是服务器的cpu资源主要占有者之一，野怪的ai逻辑，这个在后续日志详细，
这里只是提一下。野怪ai是服务器cpu资源的主要占有者之一。
4 刷新系统 ： 怪物刷新，资源刷新，活动刷新

欢迎指正