我在几个月前在Windows Phone上开发了一款实时快节奏的射击游戏,然后我将游戏移植到了Windows上。
现在我正在考虑让游戏具有多人游戏功能,但我之前从未做过一些问题:
考虑到它的射手所以有很多子弹,所有类型的游戏对象,玩家/小怪的动作等......:
提前多多感谢! :)
答案 0 :(得分:3)
一般情况下,射击游戏使用UDP来发送带有镜头的数据包,并且由于数据包数量很多而没有多少考虑提供数据包,所以如果少数数据丢失在电缆中也无关紧要。但是,如果出现问题,为什么不首先尝试TCP并稍后切换到UDP?
答案 1 :(得分:1)
一般建议是发送通常倾向于用户输入而非世界状态的最低限度的信息。
e.g。在游戏的142秒处,用户A点击了开火按钮。在145秒时,用户B开始向左走。
(从用户输入开始,每个客户端都可以重新创建世界状态...通常。如果你有随机元素,那么这是在你的设计中捕捉并重新考虑它们的好方法。)
至于协议选择,我建议从HTTP开始并从中“向下”工作。这提供了最强大的“内置”功能(例如NAT遍历和代理),并有望提前强调您可能遇到的任何网络逻辑问题(例如您是否预测算法与玩家的游戏风格相当接近,以便在重新同步时'确实发生在客户端,“回弹”并不烦人)。
当/如果您确定HTTP太重/太慢,那么您可以将其换成UDP之类的东西,并了解需要实现的内容。
答案 2 :(得分:1)
我会乞求,借用,并窃取其他游戏的好主意。 id Software's Quake 3 has its network source open and many folks have dissected it。今天大多数FPS游戏都使用UDP以确保及时传送时间敏感数据。丢弃的旧数据不需要新数据包。
Quake 3使用一种策略,其中最后已知的良好快照ID与来自客户端的每个数据包一起发送,服务器在内部发送每个快照的ID。此时,当客户端丢弃数据时,它会继续发送最后一个已知的正常ID,并且服务器会从其快照缓冲区发送差异。
如果您使用TCP,则必须等待每个客户端确认旧数据,这将增加人为延迟,这对于第一人称射手来说是无法容忍的。
答案 3 :(得分:0)
混合:对于身份验证,登录或更改服务器/客户端信息使用TCP但是当电缆上的大多数数据通过UDP使用时。由于面向连接的操作,TCP将产生更高的延迟。