JNGame 简单的物理同步实现 欢迎优化谢谢

本人热爱做游戏 但是职业是Web开发 所以很多游戏开发技术并不了解
我在游戏开发领域比较了解的技术就是网络同步联机 这次给大家带来我自己制作的简单物理同步实现 希望大家可以帮我优化

物理同步我认为是应该比较难的问题 我找了很多教程都是简单同步 如果涉及物理 则需要解决一系列难题 我以前接触UE4时候游戏引擎有同步解决方案 可以自动生成 服务端 通过服务端的物理模拟进行每个客户端的同步 达到物理同步.

在我使用cocos的时候发现同步这一块需要自己写 我的一个cocos同步的项目就是贪吃蛇 在自己写的途中遇到很多问题慢慢的都解决 做完之后 我在想如果物理需要同步cocos要怎么解决 我去很多论坛找了很多 但是我都实现不了(技术不允许) 比如服务端运行物理进行同步 可是我不会啊 。。。 所以有自己写的打算 JNGame就是我的物理同步的作品 JNGame并不是可以商用的框架 只是一个思路 大家如果需要商用肯定要进行大幅度调整 。

上面是我的出发点 我简单讲讲我的思路 首先物理难同步 我认为两个难点 网络延迟导致物理的出发点每个客户端不一致 设备的物理计算结果不一致 如何解决 我这里总结就是多物理导致的 每个物理都在计算自己的 在加上延迟一系列导致不同步 所以我想如果一个物体只有一个控制者控制这个物体的物理不就解决了吗 UE4的控制者通常计算服务端 也就是服务端控制世界 但是门槛太高了(/(ㄒoㄒ)/~~) 我不会 所以我JNGame用的思路是物理继承 由物理的触发者拿到这个物体的物理权限 其他服务端则同步他的物理结果

简单的假设一个足球游戏这个游戏很多人操作这个足球的物理 那谁控制呢 就是最后对它踢的那个控制…这样就可以解决了哈哈哈哈

JNGame我还没做完 这是我为了实现这个想法做的项目 看看是否可行 在我一系列调整 感觉已经可以接受了 不过还是有小问题 这些我没法解决 所以大家有解决的方案请告诉我

bug:
1.物理交接的时候丢失一部分物理效果
2.使用两个碰撞体 (为什么使用两个 因为 两个物理属性为Static触碰不会触发碰撞事件 所以用了两个)

吞吐量比较大 如果你们要用一定要把DTO对象改成protobuf生成 我这里为了方便所以除了自己实现的RPC 代码 在业务中的DTO我都是JSON序列化。

环境:
后台: Java 【框架 Spring Boot 下的 WebSokect】 没有使用Netty是因为我只是测试 我会一点Web服务器开发使用比较会Spring 大佬们需要用可以自己改
客户端:cocos creator

git:JNGame: NGame 是一个Java游戏服务器框架 实现基础功能 可以让使用者更方便的编写业务
效果视频:文件分享

我是cocos新人 希望大佬可以加我QQ:2858626794 WX:jisol_kun

本人目前做Web前端 打算过年后转游戏开发 如果可以内推我的大佬可以加我~~~~

1赞

效果:文件分享

我这个注释很少 :no_mouth: 将就吧

公司电脑并不是很好再加上开了很多工程和录制所以效果视频中的帧数浮动大了 正常运行应该不会的

mark~~早上还看到大佬在群里问,下午就完工了 :+1:

你是那个? 哈哈哈

也就是服务器只转发特定客户端的物理模拟状态?那此客户端是可以作弊的?

那些中立障碍物的运动如何同步和判定呢

大佬,带弟,我看见你在群里问了static的刚体问题,带带我!我也想物理同步!

(我并不是这个行业 但是有自己的理解 不敢百分百正确)

在同一刻 或者 帧 只有一个客户端拥有这个物体的物理状态.
作弊这个其实我认为 是另外一个层次才需考虑的 市面上大部分游戏都是可作弊的 能百分百不作弊的只能服务端去控制世界和玩家但是 绝大部分不会这样选择 因为实现起来代价是最大的维护也是.
但是通常解决方案都是验证行为数据 和 进行数据的加密 来达到反作弊 我这个实现方式是可以进行这种验证的…

所以为什么有游戏会误封就是因为触发了 行为不对的缘故 很多都是网络导致的误封.

如果是定时生成某个物体可以服务器去生成 如果 这个生成的物体具有物理效果可以随便找个玩家获得它的物理哈哈哈随便想的 不过肯定是没问题的.

如果这个人掉线了 就将他的物理控制权交给另外一个玩家 不过肯定是有物理损失的 所以交接的时候需要特殊处理 只是我不会 比如航迹推算??? 反正我不会 我这里看过一个文章写的很好:浅谈物理引擎的网络同步方案!_状态 不过很多都不会

你带我呀 :grinning:

能自己思考并花时间精力做出点东西,已经很不错了。
据我所知,有一些单机游戏的联网功能,物理同步跟你的做法有点像。不过这种肯定是不能用于普通网游的,早期韩国的那一批网游是可以在客户端改数据,现在基本上都是在服务器上跑了。
不知道你有没有考虑网络比较差,有延迟的情况下怎么处理,例如A玩家网络差,在他的世界里他碰到了物体O,B玩家网络好,在他的世界里,他也碰到了O但他看到A还在远处。

另外目前物理同步的主流方案应该是用“快照同步”,之前我看过Respown工作室的一个GDC演讲,他就是推荐快照同步的。不过我没有实践过。
他们做做过很多联机游戏,也做的非常好。例如泰坦天降,APEX等

了解了 我去了解了一下快照同步 其实和我之前 UE4 联机一样UE4 它支持生成服务端 它就好像你说的快照同步

就是服务器进行游戏模拟 UE4中你需要一个物体进行同步 则服务器里面就会存在需要同步的Actor 服务器每隔一段时间发送游戏世界的所有实体的 快照 给所有玩家 玩家则发送控制指令
以前不知道这个叫什么…应该就是你所说的快照同步 也就我说很难实现的 服务器去计算 逻辑… cocos 好像也不支持

网络差这个 我认为也是属于需要 数据验证的 比如这个玩家攻击到了 一个人 其实 他网络很差 目标其实已经不再哪里 则发送数据 是 攻击的目标 和 攻击的目标状态(比如位置) 在和 被攻击的状态对比 如果不对 则攻击失效 目前想的是这个不知道对不对