>백엔드 개발 >PHP 튜토리얼 >大家探讨下制作网页游戏私聊器,喊话器的思路

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

WBOY
WBOY원래의
2016-06-23 14:39:141282검색

本帖最后由 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来做服务器。

这是客户端软件.分析各个站点的各种数据 完后集成登录,再分析发送的数据包,因为是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连天呢?自己想象吧

真的是受益匪浅,非常感谢

哎 好麻烦 不懂

huoshi5151]  您好,有事情想要请教,方便的话+QQ:519173276

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
이전 기사:PHP的curl请求json다음 기사:php 链接数据库错误