关于魂系列的判定范围

mes

w30of 发表于 2020-3-5 09:57
横版平台的话，我刚好有些经验，有一个拙作叫超级幻影猫，它的碰撞底层就是纯自己造轮子出来的
恰好实现 ...

要实现应该不是不能，但如果在制作那边了，那就还有这样做“好不好看”，还有既然都要扔掉物理了，那等能做出这种程度再继续。
info.sonicretro.org/SPG:Solid_Tiles


仿制是没关系的，只要有自己的东西，以前的游戏不也一堆类似，当然那时就算说像也差很远。

所以说我没技术力，必须具体到能做出整个范例，抛去物理首先要面对的问题就是地图怎么办，u ity的逻辑是现实和碰撞是分开的，就是说默认只是它从图块生成了碰撞形状，如果不用它的物理引擎，那怎么另外弄个地图数据已经是问题。

mes

题外话，为什么说物理引擎不适合做“像素”游戏？我试过的其实只有平台游戏，原理上，比较简单来说就是如果两个碰撞判定从分开到碰在一起，会知道碰的那一点上对方表面的角度和陷入的距离，那就能比如按那个表面的垂直线移动那个距离而分开到刚好接触，但是如果已经陷入了呢？没有办法，因为已经没有表面，要么掉下去，要么飞上天你们自己选。如果用来做单方向平台，就是说只有向下能站的平台

单做这么一个是不难的，但是

这种情况，就是刚好进入另一个平台的区域，就会失去“表面”，就会直接掉下去。

其他还用多说吗？做游戏多么快乐

汪达

mes 发表于 2020-3-4 20:08
说真的我想过了，and怀疑很多回帖的没想过，你知道看那些教程会遇到什么吗？明白3D旋转是怎么回事吗？想 ...

你考证这个如果是为了应用，有人告诉你老游戏是出于省性能省事其实是相当负责的说法。因为把受创判定做到空气上都是绝对绝对不会符合玩家心理预期的设计，不是因为省事，那图什么？
你要是硬解释，那也可以考虑几种可能。
可能性1：判定框太窄可能游戏里某些快速的子 弹会跃过判定框，做这么宽这些子 弹就不用优化判定了。
可能性2：洛克人来自垂直方向的攻击较少，且很多垂直方向的攻击是炸 弹，所以哪怕头部的判定已经明显偏离视觉判断，但根据脚制作受创判定会更符合设计者的预期效果。
等等等等。
但游戏里有没有这么快的子 弹，或者有没有其他什么原因，还是需要花费很多时间来理解、计算、印证的，而且最后可能发现并没有，您笑话别人缺乏坚持，那还是劳您大架，自己琢磨吧。再说归根结底，完全可以用更复杂的方式实现更好的效果。理由还是那句话，把受创判定做到空气上都是绝对绝对不会符合玩家心理预期的设计，不是因为省事，那图什么？
如果你觉得游戏公司这么做不是冲着省性能省事，而是有什么精妙的哲思与构想，你倒是说出个理由来，难不成你的意思是格斗游戏那么费心做判定，所以射击游戏肯定也是在判定上下了苦功夫的？那格斗游戏也没把头的判定做那么大吧。
别人好心告诉你，老游戏其实没那么讲究，人家更在意开发效率吧，你觉得不可能。让你自己去试试吧，估算下开发效率差距会有多大，换你你会不会那么讲究，你又说自己试“效率”不高，连试都懒得试。觉得效率不是问题的是你，觉得效率是大问题的也是你。别人好心建议重视效率，结果你一个连自己试试都懒得试的，反倒笑话别人不懂“坚持”，这我是没想到的。我是不知道你发这个帖子究竟是冲着什么来的，可能假期真的太长了。

GloryXie

虎纹鲨鱼鱼鱼 发表于 2020-3-4 17:53
算了,感觉回了这么多帖子的我脑子简直有问题

我爬楼下来也为你觉得不值。不过你还有那位哥们讲的都挺好的。

mes

汪达 发表于 2020-3-5 11:19
你考证这个如果是为了应用，有人告诉你老游戏是出于省性能省事其实是相当负责的说法。因为把受创判定做到 ...

要说可能性就太多了，要说游戏公司怎样还是等开过游戏公司再说吧。现在的玩家想不想要更复杂的方式也是个疑问，我觉得他们只想一直点触屏吧。与其说老游戏不讲究，不如说有讲究的地方也不知还有没人看得出来，那还有必要讲究吗？所以说可能流传不下来了。

要说游戏制作的话如果觉得假期长你也可以试试啊，我也懂得不多，更多技术上感兴趣，要是你能做出来的话可以再回来看看自己的回复。

w30of

mes 发表于 2020-3-5 10:31
要实现应该不是不能，但如果在制作那边了，那就还有这样做“好不好看”，还有既然都要扔掉物理了，那等能 ...

地图数据怎么设计这个数据结构都可以
英文论坛很早就有用文本文件写地图的
用0表示空白 1表示地面 C表示金币 B表示砖块
碰撞就是Tile based基本9宫格碰撞法

我不太理解你说的现实和碰撞分开的是什么意思，Unity里OnCollision事件的触发时机确实不如人意

地图的话，目前独立游戏用的比较多的就是Tiled了，这个软件实在太出名
https://www.mapeditor.org/Tiled导入unity并渲染的包又非常多，还免费

另外这里有一个用Tiled实现整个洛克人的教程，绝对的干货
你可以看下它的静态地图是如何生成的

跟老游戏里可完全不一样了，但仍然能用
虽然我也不是很喜欢他这种，我自做还是用老式的9宫格碰撞
https://seanba.com/megadadadventures.html
顺带他也讲了下斜坡上脚悬空的其中一个处理方式

汪达

mes 发表于 2020-3-5 12:01
要说可能性就太多了，要说游戏公司怎样还是等开过游戏公司再说吧。现在的玩家想不想要更复杂的方式也是个 ...

所以您虽然谦虚地说自己不知道，但实际上给自己预设的形象是什么都知道。隔着网线连我试没试过游戏制作都知道了。那就多谢您的建议了。

mes

w30of 发表于 2020-3-5 12:04
地图数据怎么设计这个数据结构都可以
英文论坛很早就有用文本文件写地图的
用0表示空白 1表示地面 C表示 ...

因为麻烦，本来我就没技术力，还是希望有RPG MAKER的易用程度。

是显示和碰撞分开，工作流程大概是，用内置画图块工具画图块，好像还会为图块自动生成碰撞形状，但可以调整，到游戏运行的时候，它会把整大片图块生成1个碰撞形状，就是说其实是在碰整个地图而不是分开一个个图块，这也就出现了82L的情况。

mes

那我也不回了，只是如果有人问“为什么月亮和星星不会撞一起呢”就已经包含了太多信息，让我们都下台阶，要么说说真技术，要么发发判定框图OK?

w30of

mes 发表于 2020-3-5 10:57
题外话，为什么说物理引擎不适合做“像素”游戏？我试过的其实只有平台游戏，原理上，比较简单来说就是如果 ...

对于横版游戏，物理引擎最大的作用是角色行动，还有重叠判断+推挤
物理引擎不适合做像素游戏，是哪里不适合呢？

我可否理解你说的是，“通用物理引擎”不适合做像素横版动作游戏？
这个我也同意，通常游戏不是那么符合物理定律的，但没必要这样硬说出来
而且通用物理引擎合不合适，也得看使用的人会不会调校，不能一口断定

如果不用物理引擎，你还是得自己实现一套角色运动+碰撞物理
我也是这么做的，这一套东西，就是你自己游戏的“物理引擎”
既然你如此热爱这方面，也不必太担心技术力的问题，资料这么多，研究这么多，水到渠成

顺带说一下你第一张图，横版游戏做运动物体判断有一个很重要的辅助参数是last position
就是上一帧的位置，有了这个，在判断两物体重叠的时候，你就可以判定它是从哪个方向飞入的
然后你有推挤权重，谁推谁，推多少距离这些问题都变得非常好解决

第二张图，为什么会直接掉下去呢？
在物理中，角色每帧都会计算重力加速度，角色每帧都会下降，也就是说它每帧都会被左边的方块向上推挤
然后右边的方块还会把角色往左边推挤
实际的结果就是角色通过四叉树还是什么的数据结构，获取周围的对象，一个一个计算自己被推挤的坐标再相加
得到最终的位置

所以任何物理引擎，还是你自己制作的物理系统，玩家都会被这两个障碍物挡住，而不会掉下去
另一个可能是被挤上去，这个还是要看你的需求

至于更加细节的东西
https://www.metanetsoftware.com/technique/tutorialA.html
中 SECTION 5: Fast-Moving Objects 里有讲几种方法去处理你第一张图的情况
但这也不是什么困难的问题

w30of

三连回帖一下

eggplant：有用的开源游戏链接，游戏这东西其实能读源码比看教程有用
https://bbs.saraba1st.com/2b/thread-1530367-1-1.html

帮那位不能回帖的发一下

顺便能否帮我扣个鹅，让我战斗力保持在5

w30of

mes 发表于 2020-3-5 12:19
因为麻烦，本来我就没技术力，还是希望有RPG MAKER的易用程度。

是显示和碰撞分开，工作流程大概是，用 ...

哦哦 那我86楼的回复里 那个洛克人实现的教程就有一个工具
自动生成多边形地图碰撞区，这种方法也可以自己写一个，拿到顶点生成多边形算法网上也有很多

技术力我觉得真不是什么问题，毕竟做横版游戏难的不在这
而且个人开发，这些作为常用工具的技术是大家都无法绕过的坎呀，没有什么捷径可走

mes

w30of 发表于 2020-3-5 12:25
对于横版游戏，物理引擎最大的作用是角色行动，还有重叠判断+推挤
物理引擎不适合做像素游戏，是哪里不适 ...

因为这是一个只对向下有反应的平台，首先最基本，不能用默认物理，所以是角色当成k字头的那种用脚本驱动的碰撞形状，陷入多少就拉出来，而这个平台则在这个基础上，只对角色有向下方向时才有反应，但是如果碰到另一个这种平台的左边或右边的话那就已经等于陷入了，因为它们是连在一起的，那物理系统再也不觉得是站在某个表面上，因为已经陷入，自然掉下去了。

w30of

你是Rigibody设置成Kinematic
然后想在OnCollision事件里处理角色推挤对吧
这样角色会先陷入碰撞体再弹出来，最后的表现形式是角色在上面抖动
更复杂的碰撞情况还会有更多不可预知的结果

这个你要看一下他这个事件在Unity里发送的时机
我一开始也是这么想的，但我测试后认为这个时机适合用来处理碰撞重叠事件而不是推挤
所以我自己写了套流程，就在一个Update里，这样这些事件的时机就完全可控了
但意味着性能要你自己优化

如果你的游戏是画面比较高级，元素比较复杂的，还是推荐用通用的物理组件，有许多干出
至少他的碰撞计算并发处理比你自己写的效率高多了

w30of

mes 发表于 2020-3-5 12:47
因为这是一个只对向下有反应的平台，首先最基本，不能用默认物理，所以是角色当成k字头的那种用脚本驱动 ...

另外只对向下有反应的平台
你是说单向平台对吧

这个我实现的时候是记录上一帧坐标
用两帧做线段碰撞检测防止穿越的
毕竟单向平台是可以抽象成线的，而不是矩形

另外这个你要是在OnCollision里做的话也是会有抖动的

mes

w30of 发表于 2020-3-5 13:01
另外只对向下有反应的平台
你是说单向平台对吧

平台游戏很多教程和范例，会抖可能就是默认物理引擎，k那个完全不会抖，因为它纯脚本控制，只是它想去哪就去哪，没有东西可以挡着它，所以也用脚本，当它陷进图块时候就拉出来，当然无法保证它就永远不会陷入，因为这其实还是物理引擎，但我觉得这就是基础了，控制怎么动肯定是脚本，而不是当成默认物理块给它速度或其他（其实也是脚本）。
至于线不知道如何实现，如果自己另外写一套那已经可以不用这种物理。


另一个问题
learn.unity.com/project/survival-shooter-tutorial/
以前还有项目下载，现在好像没了，这个的问题是，我觉得鼠标瞄准的地方不是我想射的地方。
那么一般这种视角鼠标瞄准的到底是什么呢？怎么实现呢？

mes

回帖顶顶，还有其实不太记得，而且搁置了目前并不想翻出来，好像是直接给个“到顶”的距离，而不用自己用减法求，但本质还是一样的，没有人说明这物理系统再具体一点的情况，它想陷就会陷。

rzy

https://weibo.com/3195876175/Iyy ... t#_rnd1584181739429

mes

rzy 发表于 2020-3-14 18:29
https://weibo.com/3195876175/IyygVzjRf?type=repost#_rnd1584181739429

怎么回这里，但主题的问题仍然有效。

1太夸张了，这种情况直接送回边缘是不是更自然？

2我还是想问，是不是按住跳就一直原地跳？

3总之就是按着跳得话下落过程（到哪里为止不明）重力减半？