posted by wap, platform: MAC OS X
还是gdc演讲还是哪次演讲提到的，任天堂先构建了一个世界，物理元素以及多大范围内可以允许与之互动的逻辑关系。

这个东西底层定了再开始往上加。

这个做法是开创性兼趣味性兼一定程度的合理性，各种元素的可交互程度相乘就是一个很有意思的“化学反应“。

posted by wap, platform: VIVO
开放世界主要体现在自由度上，自由度可以体现在很多方面，比如剧情走向，npc互动，你不能说上古卷轴这种以剧情为主就不是开放世界了吧，而且乐趣也不一定就比荒吹差。

美末2拿psv打fc游戏钓起两条鱼，233

引用:

原帖由 雨中芭蕾 于 2022-3-10 03:19 发表


老头环里很多怪死了就是化作一团烟凭空消失= =

老头环也不是写实风格啊，魔幻风格

你们搞错了 我不是说塞尔达不好 是不同意一些人说的：“塞尔达教业界怎么做开放世界”这句话 因为塞尔达并没有教r星做开放世界的实力

其实就是为了减少脚本制作，直接做了一套规则，整个gameplay都运行在这套规则上，相应的减少了很大的开发工作量。不然这些特殊的交互靠脚本写，估计要写死程序员了。坏处就是好多特例无法实现，按照游戏设计的本意，视频里肯定是要打死怪才能解谜题，但因为底层规则的存在，所以只要球碰到机关神庙就解锁了

posted by wap, platform: Chrome

引用:

原帖由 @jiejieup  于 2022-3-11 02:15 发表
其实就是为了减少脚本制作，直接做了一套规则，整个gameplay都运行在这套规则上，相应的减少了很大的开发工作量。不然这些特殊的交互靠脚本写，估计要写死程序员了。坏处就是好多特例无法实现，按照游戏设计的本意，视频里肯定是要打死怪才能解谜题，但因为底层规则的存在，所以只要球碰到机关神庙就解锁了

恰恰相反，这套规则会因为其复杂和不可控，平添出相当多的debug工作量。

而把交互逻辑写死才是最省力的办法。

比如：Link杀掉独眼怪→球掉落（插入动画以防止物体掉落出现问题）→Link拿起球→嵌入洞中（插入动画以防止出现摆放错误）

一般游戏都会按照这个逻辑去制作，因为简单，出错率低，后期debug也简单。

posted by wap, platform: Android

引用:

原帖由 @BeastMa  于 2022-3-11 03:18 发表
恰恰相反，这套规则会因为其复杂和不可控，平添出相当多的debug工作量。

而把交互逻辑写死才是最省力的办法。

比如：Link杀掉独眼怪→球掉落（插入动画以防止物体掉落出现问题）→Link拿起球→嵌入洞中（插入动画以防止出现摆放错误）

一般游戏都会按照这个逻辑去制作，因为简单，出错率低，后期debug也简单。

如果你把杀怪后使用定义成正常，那这种确实是bug ，如果定义只要是合适大小的球都可以，那么用物理引擎做通用规则就是简单的做法
所以我没觉得这个视频体现了什么很强的设计，只是说明开发者给这个附件球设定了实际的体积属性罢了

[ 本帖最后由 yfl2 于 2022-3-11 07:41 编辑 ]

posted by wap, platform: VIVO
难的是交互的物理引擎，有了引擎，设计规则解密并不比常规谜题复杂多少，把谜题的交互物理特性定好，按照正常流程设计解法，做下常规的边界检测避免出现明显漏洞，加上本身有重置机制不会卡死就行了。因为多出来的解法实际没啥影响，就像战斗时有很多利用环境交互来打的，这些打法测试不一定都需要测到，只要符合规则引擎交互逻辑的都不会存在啥大问题。

本帖最后由 LTFYH 于 2022-3-11 09:30 通过手机版编辑

当年看见御树飞行就惊为天人了

桃白白啊

和不可思议机器、围攻类似
谜题存在一个最终条件，但是实现的中间过程就是一堆限制极少的演算。
表面来看，比起脚本，尤其是有分支的多线脚本，游戏的事件配置更简单了，因为跟脚本不同，引擎是一次制作全局有效的。
但是这对于游戏带来两个问题
1是，游戏对规律的模拟并不完美，比如我前面提到的Havok，穿模，抖动，飞射而出都是常见的事情。
2是，现实世界里错了无法挽回了，那就是这是事实请接受它，但是游戏是不应该出现死档的。
因此，debug压力是非常大的，尤其是引擎演算相比脚本，是更难以复现问题的。

posted by wap, platform: Android

引用:

原帖由 @卖哥  于 2022-3-11 10:18 发表
和不可思议机器、围攻类似
谜题存在一个最终条件，但是实现的中间过程就是一堆限制极少的演算。
表面来看，比起脚本，尤其是有分支的多线脚本，游戏的事件配置更简单了，因为跟脚本不同，引擎是一次制作全局有效的。
但是这对于游戏带来两个问题
1是，游戏对规律的模拟并不完美，比如我前面提到的Havok，穿模，抖动，飞射而出都是常见的事情。
2是，现实世界里错了无法挽回了，那就是这是事实请接受它，但是游戏是不应该出现死档的。
因此，debug压力是非常大的，尤其是引擎演算相比脚本，是更难以复现问题的。

单纯说视频这个谜题来说没那么复杂

posted by wap, platform: iPhone

引用:

原帖由 @yfl2  于 2022-3-11 07:38 发表
如果你把杀怪后使用定义成正常，那这种确实是bug ，如果定义只要是合适大小的球都可以，那么用物理引擎做通用规则就是简单的做法
所以我没觉得这个视频体现了什么很强的设计，只是说明开发者给这个附件球设定了实际的体积属性罢了

对牛弹琴

posted by wap, platform: Android

引用:

原帖由 @BeastMa  于 2022-3-11 13:18 发表
对牛弹琴

你也没弹，也没说这么做有啥困难的，你应该知道这套引擎是现成的吧

原版Havok你可以拿他搞一些视觉效果，反正闹出离谱效果也不影响游戏的可完成性。