游戏大厅 从基础开始（1）
——最简单的关系，用户与房间。
做游戏 就好像写一篇简单的记叙文
作为小学语文大纲要求 记叙文需要完整地叙述：
时间，地点，人物，事件
也就是 WHEN ， WHERE， WHO， WHAT HAPPENED
猜猜哪个最重要？
我选WHO
WHO
没有WHO，没有了某个意识的主观活动影响客观环境，故事就是静止的。那就不叫故事，叫速写。
在一个网络游戏服务模型中，最基础的概念就是 WHO
有了WHO游戏才不是电影电视剧那样的直接灌输。
有了WHO电脑屏幕前的个体才能与别的个体有所区分
有了个体的区分 网络游戏才可以"互动"。
最最基础的用户的存在，至少要有一个唯一的数据库ID，一个登陆用的用户名，一个友好的名字
- 唯一的ID 让数据库认识你是WHO
- 唯一的登录名 让服务程序认识你是WHO
- 友好的名字 让别的WHO认识你是WHO
其次是
WHERE
WHERE的本质用途是 隔离WHO和资源。
试想有一座学校 ，没有分别的教室而只有一间大会堂，三十多名老师和校工 四百多个学生一起办公与学习，一边在唱着童年的歌谣，一边在笑人齿缺曰狗窦大开。
把学校换成服务器 把学生换成用户 这样的烂摊子你能收拾得了么？
我们需要教室！
- ID 表示房间是 504
- Name 表示班级是三年二班
-
Users是全体在教室的同学
我们可以更换房间的名字变成五年三班 但是我们改变不了这是五楼的第四间房
这就是ID和Name的区别
最基本的User和Area的关系需求：
-
用户和区域都能标识自己
-
用户和区域都具有友好名
-
区域间可以建立联系,产生空间结构
-
区域可以被用户进入
-
用户可以在区域间移动
-
用户可以登出
这里我们要着重分析一下房间与房间的关系
- 一维关系
典型的例子：棋牌房间，劲x团，百战天虫，疯狂坦克，浩方，QQ聊天室
这种树形房间结构只有两种关系：父，子。实际上是在一个简单维度上的两个方向。一个房间有多个子房间，一般看成同一纬度上的若干不同的点。用户最基础的移动操作就是 上一层 下一层。
- 二维关系
典型的例子：文字MUD
常常听说十字链表这个词语，我最早就是从文字mud的开发文档中接触的。
作为一个模拟真实的地图，大家把区域模拟成类似国际象棋那样的棋盘,彼此保留着邻居的结构，或者类的引用
interface IArea
property name as string ..
...
..
property Warea as Area
property Earea as Area
property Sarea as Area
property Narea as Area
end class
用这种链表 用户的身处环境就可以平滑有序的移动。
- 三维关系 一般网络游戏(传奇、RO）
后来更复杂些的MUD和网络游戏 又增加了 UP和DOWN两个方向 比如xx地下城1层 2层，天空挑战赛1层2层
有些是真的实现了立体链表 有些使用更抽象的方式 在某个没有邻居的方向用二维十字链表模拟
- 多维关系和混合关系 （wow等等副本游戏 立体地图的部分游戏如孢子)
- 同目标多入口
比如ro 两个地区间可能有2-3道门 每一条都可以进入目标区域相应的位置。 所以相邻的两个地区间 仅仅维护一个彼此的引用是远远不够的
- 单程票
有的区域进得去出不来
有的区域要满足xx条件才能出来
有的区域要找另外一条道路才能出来
- 例外通路
回到最上层 回城
参考以上可能性 我建立了目前的 IPathWay 接口
IArea之间不再用链表而是使用IPathWay互相连接。IPathWay是单程的 是可以附加属性的(坐标，范围,条件)
IArea本身可以通过添加或者减少IPathWay来保证与其他Area的连接
Iuser可以选择直接移动 还是按照已经准备好的IPathWay 规则来移动。
每个IPathWay 都有自己的方向
对于父子树来说 之需要一个水平方向的x轴， 深层是正方向
对于二维十字地图链表 我们把地图映射到坐标系 东为x的正方向 北为Y轴正方向
对于三维 上为正
对于更多。。。。
对于完全没有道理但是一定会存在的那种特殊路径 在6维空间以下的坐标系 我们可以直接放在C轴
这就是最简单的房间与用户的交互
房间组织 -〉 用户进入 ——〉 用户移动
参考代码：