Heim >Backend-Entwicklung >PHP-Tutorial >大家探讨下制作网页游戏私聊器,喊话器的思路

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

WBOY
WBOYOriginal
2016-06-23 14:39:141275Durchsuche

本帖最后由 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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Vorheriger Artikel:PHP的curl请求jsonNächster Artikel:php 链接数据库错误