【日常吐槽 · 第四期】咱也搞搞服务器 by EOS.
在公司搞rpg游戏，然后只有一个后端，导致前端很闲。因为大部分逻辑都在服务器的，
前端只是根据后台数据来做画面展示，所以呢，我也就看了一下服务器。
好久没吐槽，让我来个不吐不快吧=、=
先说java吧
我们的服务器是用的java的，=、= 迷之认知：这才是java
以前也是做安卓打包的时候才用一下，才接触一点java代码，然而那一点也不java。
当我第一眼看到服务器代码的时候，我是崩溃的：可以，这个很java
不经历一番展开~根本看不到java文件。。。
然后稍微询问了一番，终于摸清了路径，然后服务器程序顺手赠送一张图
顺便吐槽一下eclipse，电脑4G内存完全不够用=、=
一点调试，各种未响应，搞的我也是醉醉的，然后服务器程序又顺手给我推荐了一本书。
书？没错，我电脑卡，他竟然给我推荐书 = =、
但是看了书名，我恍然大悟：《java 从入门到加内存》，2333333
然后说说逻辑
其实 前后端，结合起来看跟写单机游戏也差不太多。
但是设计到数据库，数据库的存储和我之前所想还是有点差距的，
然后服务器还要考虑N个玩家的管理，服务器压力、场景的压力之类的。
(PS：我也才看了几天，如果有说的不对的地方….我改还不行么0_0)
服务器好比是上帝视角、而客户端更像是第一人称视角。
服务器的各个系统肯定都是要挂到人物身上的，比如某一player的任务、成就等，
每一个player都有一个uuid也就是唯一的，他们之间的任务、成就不可能有任何关联的。
而客户端各个模块却相对独立了，因为客户端同一时间，也不可能出现2个主角，
而且因为各个模块数据服务器都处理好了，几乎不用考虑和人物的联系。
再说场景，玩家的切换场景对于服务器是把玩家数据挂到了新的场景上。
而客户端则是不会管上一个场景的数据的，基本上直接干掉了。
但是在服务器上，所有的场景都是还在跑的，来存储各个玩家、npc、怪物等数据，
当切换场景的时候，新场景的数据统统丢给客户端就ok了。
从这两点也不难看出，客户端是把服务器的N个玩家中的一个具象化。
场景中的玩家虽然有显示，但却只是一个模型数据而已。
而其他数据都是单独去请求的（比如查看装备），这也看出的非主角的地位。
顺便，再拿查看装备来说一下，服务器的简单的处理流程。
玩家连接socket的时候会，会根据这个socket的实例类来做网络事件的监听，
也就是说通过这个socket连接发过来的指令，这个实例内的Listenner中寻找，
然后也就确定到某一用户了，当玩家登录后会有一个identity（身份证一样的东西），
然后选择角色的时候会有player的uuid，然后uuid通知给identity。
接收到指令的时候根据identity，获取到player的uuid，然后从playerManager中，
以uuid为key取出，player实例（一般是以指令号为key注册回调，注册时把Listenner中设置player，
回调的时候就能直接取到player了），再接下来就是处理逻辑。
从player中装备信息，指定一下格式发送一下就好了（或者判断一下是否在同一场景）。
再说说数据存储
更上边所说的具象化有关，客户端的数据其实是经过服务器加工的，
所以基本就可以认准了，背包里的东西是面向主角的，所以存储起来自认是
玩家背包list:【物品1、物品2、物品3……】、玩家装备list:【物品1、物品2、物品3……】
玩家仓库list:【物品1、物品2、物品3……】
这种思维应该是没什么问题的，甚至也认为这是理所当然的，
但是当考虑数据库存储的时候，一类东西一张表，玩家放玩家表、角色放角色表，
物品肯定是要存放物品表的，然后在从一个仓库表？背包表？装备表？
显然这么做没为什么意义，而且这张表中可有有数千玩家的数据，这样很冗余。
其实一个position就可以搞定了（是在玩家的身上、背包或者仓库）
key | 物品refId | 所属playerId | 所在位置 | 索引 | 数量 | 其他属性 |
uuid | item_909(读表用) | player_uuid | 仓库 | 0 | 1 | < fumo:30,40,50>< qianghua 55> |
总结
码字码了不少了，吐槽篇中都开始讲知识了，真是沉迷学习无法自拔。
虽然是浅薄的知识，但是希望给没接触够服务器的朋友带来一点灵感。
to be continue！
See Again~
之前
