大伙探讨下制作网页游戏私聊器，喊话器的思路

大家探讨下制作网页游戏私聊器，喊话器的思路

本帖最后由 huoshi5151 于 2013-06-06 23:36:57 编辑  

输入网址： 填入需要进入的游戏地址。
喊话配置： 填入私密的内容。
私聊对象列表：列出所有的玩家，包括：编号、玩家ID、玩家昵称、来源（附近 or世界）、消息状态（发送完毕、等待发送）
私聊对象可以在角色附近地图上找寻到（来源为附近），还可以在世界频道喊话中抓取到（来源为世界）。
随机字符：私聊内容随机跟几个字符，防止被系统判断为多次重复发同一内容的消息。
添加屏蔽人：不向哪些玩家发私聊。
清空列表后可以再次抓取私聊对象。

大家探讨一下，要想实现这些功能，需要从哪些方面着手

网页游戏 游戏 对象 地图

分享到：
------解决方案--------------------
这是客户端软件.分析各个站点的各种数据 完后集成登录,再分析发送的数据包，因为是flash比较容易分析..按照格式发送一个数据到相应的位置去即可
------解决方案--------------------
思考问题基本上离不开五个W一个H，不要光想着H（how）
what：聊天（实质为连接并传输文字）
who：玩家ID（视乎做法还可能有服务器本身）
where：地图内或更大范围
why：动机不用说了吧
when：实时

what确认是个连接，when确认是个长连接，who确认连接的两端，where缩减who的范围
最后才是how，因为是连接，就要按连接的做法
下面只是说个人大概思路，实际操作细节问题很多，甚至有完全不同的思路和做法

从零开始做还是从已有构件开始
前者需要从基本通讯开始，了解通讯协议，如何构建socket通信
后者是基于前者的通讯构件已完成，则从构件的使用接口入手，掌握使用规则
至于对话的断句之类问题，基本了解了如何通讯就知道该怎么做了

游戏一般离不开“地图”，有地图就有坐标或类似定位数据（这个在同一时间内一般和玩家ID是一对一关系的）
用定位数据自然就可以判断谁跟谁了，假定A和B，A为聊天发起方

A从服务器取得整体数据（表现为游戏界面），定位B，发起聊天，向服务器提交请求，服务器有两个做法：
1)服务器介入聊天，那么就是服务器分别向A/B产生连接（其实这个进入游戏已经做了），然后向A和B确认两者同意进入“聊天”状态，后面就是服务器按特定顺序（当然就是对话/时间的顺序）向A/B依次发送信息
2)服务器不介入聊天，就向A返回B的ip和端口信息，并同时向B发送通知说A要向你请求聊天，然后A向B的ip和端口发送连接请求，B接受就进入不经过服务器的“聊天”状态

一般情况下，采用1)的方式，这样服务器可以保留相关信息（包括对话内容）、各种细节数据，虽然数据量多了，但从游戏展现或避免非游戏事端的发生都可以采取相应措施
2)的方式类似于P2P，服务器流量负荷大大减少，但对A/B连接产生的事无从介入，不可控制，这样会产生各种不可预料问题（线上或线下），甚至连他们什么时候结束了“聊天”都难以掌握，游戏界面极可能就是两个人物定在屏幕那里了

补充一下：方式1)也可以使用短连接实现，视乎游戏本身的做法

题外话：大家觉得腾讯有没有介入QQ连天呢？自己想象吧
------解决方案--------------------

引用:

 

输入网址： 填入需要进入的游戏地址。
喊话配置： 填入私密的内容。
私聊对象列表：列出所有的玩家，包括：编号、玩家ID、玩家昵称、来源（附近 or世界）、消息状态（发送完毕、等待发送）
私聊对象可以在角色附近地图上找寻到（来源为附近），还可以在世界频道喊话中抓取到（来源为世界）。
随机字符：私聊内容随机跟几个字符，防止被系统判断为多次重复发同一内容的消息。
添加屏蔽人：不向哪些玩家发私聊。
清空列表后可以再次抓取私聊对象。

大家探讨一下，要想实现这些功能，需要从哪些方面着手

怎么说呢，apache的本身而且，我觉得这个不是优势了。目前国内有些网游的数据传输，采用的是nodejs来做服务器。