关于魂系列的判定范围
- mes哈哈哈哈，就当是
吧，不是的话老师就太惨了。
那认真说吧，退一步不用标准物理公式，那也肯定是更简单的式子而不是什么“移动的二次函数”。 - w30of这个就是一个编辑器，逐帧查看或者按事件查看动画
并能让设计师在指定帧上配置hitbox、hurtbox、硬直等信息然后按特定的格式保存
然后程序运行时读取这个数据文件，在动画播放到指定位置的时候进行判定检测
步骤无非是：读动画，定格动画到指定帧/时间，画判定，填数据，序列化保存
要制作的话理解原理其实是比较简单的，就是个填表软件
要难一点的话也就是要让游戏好玩合理，你需要经常更改判定的配置，所以需要反复测试非常多次
那么这一套框架最好做的能快速在运行时/编辑器状态切换来验证你的配置
编辑器中需要配置哪些东西，这里有一篇应该会提供帮助：
A Glossary of Fighting Game Terminology
https://tiltingatpixels.com/post/Terms-to-know-during-EVO/
至于你说为什么圆形判定用方的，我的理解是判定框对玩家不可见，只要合理，有说服力即可用
大乱斗的判定区域是圆形，什么你躯干长条凳，他判定都是圆形，这也并不影响游戏好玩
你要是非想让判定符合图像，也有办法，就像楼里朋友图里说的骷髅女孩
用常用的计算图片填充率的方法生成一下动画中对应帧的多边形数据，然后点选哪些多边形是Hitbox、哪些是hurtbox就好了
用圆形还是用什么奇怪的形状，都可以的，但判定区域只是工具，你做精确是完全可以，但没必要，开发量的处理也是个人开发游戏的重中之重
至于手感，攻方受方多少硬直才合适取决于你自己的决定，这是另一门学问了
我自己是在用Spine库做一套这种框架，也乐于见得跟老哥们讨论的呀 - 虎纹鲨鱼鱼鱼大乱斗是3D游戏直接骨骼绑胶囊体了,这样其实最省事也最符合实际观感,但是也会有2D3D视角错觉导致的一些额外问题
- 洗刷刷从物理来说当然是起跳速度和重力系数决定最大高度，但是从游戏设计来说没人会这么搞的，都是先确定角色能跳的最高高度，然后选择合适的重力系数控制下落速度和滞空时间（影响游戏体验），倒推回应该给与的初始起跳速度。懂吗？
这你要还是看不懂我一定会扣你鹅 - mes怎么做简单也是一种技术，用方形做出斜射弹的好像还真见过，在不能完全框住怎么框也是一种技术，还有是只能用一个框的话怎么画动作也是一种技术，格斗比较起来就太自由了点。
- mes没有人会用绿色的跳法谢谢，你应该从脚开始画，是不是就很明显了？以前墙又不会给个摩擦力，就算碰到墙一样可以跳过。
总之就是，哎，为什么搞这么复杂，脚开始，最高碰到平台，最高点在墙或者右边就是过去了，还是得……好好学习，我的意思是如果确定了最高点的话……哎，算了看看有没别人能看懂我列的式子吧。 - 虎纹鲨鱼鱼鱼如果你按照你的想法做一下你就知道你做出来的这个平台跳跃根本没法玩...
说真的,自己弄个UE4鼓捣鼓捣就能明白很多东西,很多游戏类型都有模板可以直接研究各项参数细节以及具体实现
比起在论坛上打嘴炮,你还是太缺很多实践的东西了,你说出来的很多东西明显是没做过才会这么想当然的 - mes那种圆形恐怕已经不一样，直接物理引擎，完全另一回事，以前大概是这种算法
(x2-x1)^2+(y2-y1)^2与半径（a+b）^2比较
格斗暂时没打算深入了，但还是谢谢材料。 - mes所以说你们不在乎，这么新用物理引擎的游戏引擎是不适合做“像素”游戏的，反正不懂就不懂，我只弄懂我想弄懂的，别人懂不懂，我觉得没闲心管。
- 虎纹鲨鱼鱼鱼算了,感觉回了这么多帖子的我脑子简直有问题
- w30of其实用两点间距离 小于 两圆半径和这样算更快
想再快还可以不开方判断
不过判定这部分不会是性能瓶颈的
不过就像楼上所说的 两个坐标轴绑定骨骼 加上用半径缩放来配合角色动作以改变判定区域
这个会降低设计师的编辑工作量
尤其是hurtbox的编辑不会像老游戏那样累人
但大乱斗这个判定的设计比较异类 或者说有灵性
相比格斗游戏 大乱斗应该更适合或近似你的需求 - w30of怎么点了回复却还是丢引用呢
- cjcjason你看到老游戏的这些判定框都是不断测试迭代调出来的，你的角色实际大小跟洛克人马里奥又不一样。
参考意义在研究手感，跟自己的效果做对比，哪里该停顿，哪里该加帧，不是去纠结为啥他是方的圆的。
跳跃的话也是一样的，网上character controller的例子那么多，拿来改改看看代码怎么写的自己也会实现了，但是参数还是要自己调的，你想轻飘飘还是沉甸甸都看你自己的想法。 - 电风扇为什么你什么都要问别人？为什么你自己不思考？
是你自己要做游戏还是要网友手把手教你做游戏？
我现在用全是问句的方式和你对话，你难受不难受？你有没有考虑过别人难受不难受？
回到正题上来，你可能有一个误区：你认为旧游戏的每一个判定框这么设计都有它的道理，
你有没有考虑过其实没想太多的可能性，其实只是节约机能/只要不太离谱就行
就拿圆弧斩实际是方形判定框来讲，我们都知道圆弧斩肯定是圆弧形的碰撞判定才准确，方的不准确
那仔细想想，方形判定框在哪些场合劣于弧形判定框，又在哪些场合可以近似替代弧形判定框？
这个不难想明白，当你用攻击判定的前端去撩别的物体（格斗游戏中常见的情形），方形和弧形是一样的
只有当你要用斜上/斜下判定去攻击的时候，方形框会看到刀光覆盖了被击物体却打不中，而弧形框可以打中
那么问题来了，具体到某个游戏，这种斜向攻击判定的情形多不多，决定了有没有必要采用更耗费机能的弧形框
以及，上面是问题1，接下来还有问题2
我们知道不管是骨裂勾脚还是zero的光剑劈砍，其攻击判定本质是一个长条物体快速转动，拉出的弧光其实是对视觉暂留现象的模拟（以及美术上的考虑）
换句话说其实你要追求真实的话，沿着攻击轨迹快速变换位置的长方形框反而是准确的，弧光有没有攻击判定反而是次要的
那么问题来了：弧光盖到了敌人却没有算你攻击到，这会让玩家不爽。那么我在设计判定框的时候，应该向真实严谨的方向靠拢，还是向夸张豪迈的方向靠拢？
这个问题没有标准答案，取决于游戏中需要什么样的体验（比如鬼泣4尼禄可以刀光残留判定长的一逼，街霸中的骨裂就必须收敛），以及你想呈现给玩家什么样的体验 - 蕾丝控
- weiweiEX模拟器里可以直接弄到这些帧数之类的数据吧
- mes说真的我想过了，and怀疑很多回帖的没想过，你知道看那些教程会遇到什么吗？明白3D旋转是怎么回事吗？想过2d俯视游戏物体是怎么分层的吗？我问了这些了吗？
我也明白这种框普通又看不见，要不是真的喜欢的游戏里大概不会知道，那不知道就完了，干嘛还要我反问？
正题就是，如果要还原这种节约机能该如何，最好能做到什么程度。
还有就是前面也说了，这些是算出来的，弄个弧形框怎么算和别的形状有没有重叠呢？就算能算，算得再漂亮也不符合当年的“机能”吧。
还有这些正是不懂的表现，如果至少想过“这要算出来”就不会说出弧形框了，也不会问这判定要在图像前还是后。当然我也不懂，不然问啥？
还有一点让人很不爽的是你们觉得这就“性能问题”就完了，要是当年的制作人员都这样那我们就只有一大堆sh t game了，看到一些FTG判定框图也能感到某种坚持，看来这种坚持真的传不下去了吧。 - mes可能可以吧，speedrun的人也应该熟得不得了，但我需要大量比较容易看的形式，就像格斗游戏那些判定框和帧数图。
聊胜于无了 - yyman1980这就是一感觉！
- w30of难得有同好呀
看你第一帖问“如何制作这部分”，我还以为你问如何制作判定编辑器，原来是想找前人怎么放置判定框比较合理的资料……
横板游戏判定框确实有一些可研究的地方
但你的敌人美术形象是什么样的，判定框在哪里舒服，你想让玩家哪招打中哪种敌人，得根据你的游戏来
还要在运行时来回砍中击中测试才能感觉出来怎么回事
分析完这些老游戏，也没法一笔就画出契合你的游戏的完美的判定框，至少也不会减少多少测试次数，你还是得测
除非你直接扣他的图用，然后照着它的判定框抄
等你测完了，你会发现你做这么个东西也能总结出看那些老游戏所总结出的东西
它的学问要是真这么深，各大开发社区不会少讨论的，你去看看大家在讨论什么，健壮的2D平台跳跃碰撞，格斗游戏的碰撞盒，是这些
更何况现在的横板游戏开发有更加新的知识，内容也比老横板游戏复杂
有这时间自己写个玩具测测都值呀：
另外那个射击游戏，对于同一个部位，不同方向射入的**，判定框可以是不同的，目的是为了让**打在敌人“内部” - 凉宫绿豆沙这个小人太熟悉了，spine自带工程之一，demo也会出场的角色。
- 屑猫猫
- vhk908感谢各路大神分享经验...
- zag弹幕游戏有优化算法的，比如sweep and prune，然后结合空间分割，这块感兴趣可以读《the nature of code》
- mes反正很闲，就当你认真的吧，不过再说一遍我可不是老师，是的话早气死了。就说一般数学解题思路，就是化简，以前人们以为地球是中心，结果星星运行轨道乱成一团，所以这个从身体开始画线我真的不懂是想干什么。
另外我没见过蓝色跳不过去的旧游戏，要是能攀墙，那就不会这么设计，因为很明显会出现这种难受的情况。为什么能跳过是因为移动逻辑是水平和垂直分开，虽然水平被挡，但垂直还是会移动到最顶。只是如果你也做游戏，那我知道为什么，因为你把人物物理斜着“拖”到墙上，就完全被挡住了 ，但这当然能解决，而且完全不符合游戏的逻辑，不管是做游戏还是玩游戏都不该有这种想法。 - zzy516232108
- w30of是的就是spine自带的
基础动作齐全 还有个攻击 测试经常用 - Errey
- mes要实现应该不是不能，但如果在制作那边了，那就还有这样做“好不好看”，还有既然都要扔掉物理了，那等能做出这种程度再继续。
info.sonicretro.org/SPG:Solid_Tiles
仿制是没关系的，只要有自己的东西，以前的游戏不也一堆类似，当然那时就算说像也差很远。
所以说我没技术力，必须具体到能做出整个范例，抛去物理首先要面对的问题就是地图怎么办，u ity的逻辑是现实和碰撞是分开的，就是说默认只是它从图块生成了碰撞形状，如果不用它的物理引擎，那怎么另外弄个地图数据已经是问题。 - mes题外话，为什么说物理引擎不适合做“像素”游戏？我试过的其实只有平台游戏，原理上，比较简单来说就是如果两个碰撞判定从分开到碰在一起，会知道碰的那一点上对方表面的角度和陷入的距离，那就能比如按那个表面的垂直线移动那个距离而分开到刚好接触，但是如果已经陷入了呢？没有办法，因为已经没有表面，要么掉下去，要么飞上天你们自己选。如果用来做单方向平台，就是说只有向下能站的平台
单做这么一个是不难的，但是
这种情况，就是刚好进入另一个平台的区域，就会失去“表面”，就会直接掉下去。
其他还用多说吗？做游戏多么快乐
- 汪达你考证这个如果是为了应用，有人告诉你老游戏是出于省性能省事其实是相当负责的说法。因为把受创判定做到空气上都是绝对绝对不会符合玩家心理预期的设计，不是因为省事，那图什么？
你要是硬解释，那也可以考虑几种可能。
可能性1：判定框太窄可能游戏里某些快速的子 弹会跃过判定框，做这么宽这些子 弹就不用优化判定了。
可能性2：洛克人来自垂直方向的攻击较少，且很多垂直方向的攻击是炸 弹，所以哪怕头部的判定已经明显偏离视觉判断，但根据脚制作受创判定会更符合设计者的预期效果。
等等等等。
但游戏里有没有这么快的子 弹，或者有没有其他什么原因，还是需要花费很多时间来理解、计算、印证的，而且最后可能发现并没有，您笑话别人缺乏坚持，那还是劳您大架，自己琢磨吧。再说归根结底，完全可以用更复杂的方式实现更好的效果。理由还是那句话，把受创判定做到空气上都是绝对绝对不会符合玩家心理预期的设计，不是因为省事，那图什么？
如果你觉得游戏公司这么做不是冲着省性能省事，而是有什么精妙的哲思与构想，你倒是说出个理由来，难不成你的意思是格斗游戏那么费心做判定，所以射击游戏肯定也是在判定上下了苦功夫的？那格斗游戏也没把头的判定做那么大吧。
别人好心告诉你，老游戏其实没那么讲究，人家更在意开发效率吧，你觉得不可能。让你自己去试试吧，估算下开发效率差距会有多大，换你你会不会那么讲究，你又说自己试“效率”不高，连试都懒得试。觉得效率不是问题的是你，觉得效率是大问题的也是你。别人好心建议重视效率，结果你一个连自己试试都懒得试的，反倒笑话别人不懂“坚持”，这我是没想到的。我是不知道你发这个帖子究竟是冲着什么来的，可能假期真的太长了。 - GloryXie我爬楼下来也为你觉得不值。不过你还有那位哥们讲的都挺好的。
- mes要说可能性就太多了，要说游戏公司怎样还是等开过游戏公司再说吧。现在的玩家想不想要更复杂的方式也是个疑问，我觉得他们只想一直点触屏吧。与其说老游戏不讲究，不如说有讲究的地方也不知还有没人看得出来，那还有必要讲究吗？所以说可能流传不下来了。
要说游戏制作的话如果觉得假期长你也可以试试啊，我也懂得不多，更多技术上感兴趣，要是你能做出来的话可以再回来看看自己的回复。 - w30of地图数据怎么设计这个数据结构都可以
英文论坛很早就有用文本文件写地图的
用0表示空白 1表示地面 C表示金币 B表示砖块
碰撞就是Tile based基本9宫格碰撞法
我不太理解你说的现实和碰撞分开的是什么意思，Unity里OnCollision事件的触发时机确实不如人意
地图的话，目前独立游戏用的比较多的就是Tiled了，这个软件实在太出名
https://www.mapeditor.org/Tiled导入unity并渲染的包又非常多，还免费
另外这里有一个用Tiled实现整个洛克人的教程，绝对的干货
你可以看下它的静态地图是如何生成的
跟老游戏里可完全不一样了，但仍然能用
虽然我也不是很喜欢他这种，我自做还是用老式的9宫格碰撞
https://seanba.com/megadadadventures.html
顺带他也讲了下斜坡上脚悬空的其中一个处理方式 - 汪达所以您虽然谦虚地说自己不知道，但实际上给自己预设的形象是什么都知道。隔着网线连我试没试过游戏制作都知道了。那就多谢您的建议了。
- mes因为麻烦，本来我就没技术力，还是希望有RPG MAKER的易用程度。
是显示和碰撞分开，工作流程大概是，用内置画图块工具画图块，好像还会为图块自动生成碰撞形状，但可以调整，到游戏运行的时候，它会把整大片图块生成1个碰撞形状，就是说其实是在碰整个地图而不是分开一个个图块，这也就出现了82L的情况。 - mes那我也不回了，只是如果有人问“为什么月亮和星星不会撞一起呢”就已经包含了太多信息，让我们都下台阶，要么说说真技术，要么发发判定框图OK?
- w30of对于横版游戏，物理引擎最大的作用是角色行动，还有重叠判断+推挤
物理引擎不适合做像素游戏，是哪里不适合呢？
我可否理解你说的是，“通用物理引擎”不适合做像素横版动作游戏？
这个我也同意，通常游戏不是那么符合物理定律的，但没必要这样硬说出来
而且通用物理引擎合不合适，也得看使用的人会不会调校，不能一口断定
如果不用物理引擎，你还是得自己实现一套角色运动+碰撞物理
我也是这么做的，这一套东西，就是你自己游戏的“物理引擎”
既然你如此热爱这方面，也不必太担心技术力的问题，资料这么多，研究这么多，水到渠成
顺带说一下你第一张图，横版游戏做运动物体判断有一个很重要的辅助参数是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哦哦 那我86楼的回复里 那个洛克人实现的教程就有一个工具
自动生成多边形地图碰撞区，这种方法也可以自己写一个，拿到顶点生成多边形算法网上也有很多
技术力我觉得真不是什么问题，毕竟做横版游戏难的不在这
而且个人开发，这些作为常用工具的技术是大家都无法绕过的坎呀，没有什么捷径可走 - mes因为这是一个只对向下有反应的平台，首先最基本，不能用默认物理，所以是角色当成k字头的那种用脚本驱动的碰撞形状，陷入多少就拉出来，而这个平台则在这个基础上，只对角色有向下方向时才有反应，但是如果碰到另一个这种平台的左边或右边的话那就已经等于陷入了，因为它们是连在一起的，那物理系统再也不觉得是站在某个表面上，因为已经陷入，自然掉下去了。
- w30of你是Rigibody设置成Kinematic
然后想在OnCollision事件里处理角色推挤对吧
这样角色会先陷入碰撞体再弹出来，最后的表现形式是角色在上面抖动
更复杂的碰撞情况还会有更多不可预知的结果
这个你要看一下他这个事件在Unity里发送的时机
我一开始也是这么想的，但我测试后认为这个时机适合用来处理碰撞重叠事件而不是推挤
所以我自己写了套流程，就在一个Update里，这样这些事件的时机就完全可控了
但意味着性能要你自己优化
如果你的游戏是画面比较高级，元素比较复杂的，还是推荐用通用的物理组件，有许多干出
至少他的碰撞计算并发处理比你自己写的效率高多了 - w30of另外只对向下有反应的平台
你是说单向平台对吧
这个我实现的时候是记录上一帧坐标
用两帧做线段碰撞检测防止穿越的
毕竟单向平台是可以抽象成线的，而不是矩形
另外这个你要是在OnCollision里做的话也是会有抖动的 - mes平台游戏很多教程和范例，会抖可能就是默认物理引擎，k那个完全不会抖，因为它纯脚本控制，只是它想去哪就去哪，没有东西可以挡着它，所以也用脚本，当它陷进图块时候就拉出来，当然无法保证它就永远不会陷入，因为这其实还是物理引擎，但我觉得这就是基础了，控制怎么动肯定是脚本，而不是当成默认物理块给它速度或其他（其实也是脚本）。
至于线不知道如何实现，如果自己另外写一套那已经可以不用这种物理。
另一个问题
learn.unity.com/project/survival-shooter-tutorial/
以前还有项目下载，现在好像没了，这个的问题是，我觉得鼠标瞄准的地方不是我想射的地方。
那么一般这种视角鼠标瞄准的到底是什么呢？怎么实现呢？ - mes回帖顶顶，还有其实不太记得，而且搁置了目前并不想翻出来，好像是直接给个“到顶”的距离，而不用自己用减法求，但本质还是一样的，没有人说明这物理系统再具体一点的情况，它想陷就会陷。
- mes怎么回这里，但主题的问题仍然有效。
1太夸张了，这种情况直接送回边缘是不是更自然？
2我还是想问，是不是按住跳就一直原地跳？
3总之就是按着跳得话下落过程（到哪里为止不明）重力减半？
码了码了，这帖子干货量很高，谢谢各位坛友