6 寒雪落花静云月 12小时前 232次点击
哈哈,我又成了幸运儿,每次豆包内测的时候都知道带上我。
废话不多说,直接上新功能。
这个功能具体是这样的。
支持下面这些平台的链接。
抖音、B站、小红书、西瓜视频、微博、芒果TV。
不支持微信视频号。
具体是会像深入研究那样的一个东西弹出来,但是呢它是视频解析。意思是控件都在下面。
支持使用普通的模型和深入思考对你解析的视频进行分析,但是呢你要在使用之前调试好,如果你要普通模型分析视频,就不需要点深度思考。
然后,将视频链接输入到那个编辑框里。
发出去它会有一段时间的解析。然后就是一般模型回答的过程会将你提供的视频内容总结出来。可以让我们看懂视频大概讲了些什么,对盲人朋友特别方便。
看看效果。
我尝试的链接如下。可以复制到抖音去看一下原视频。
3.35 复制打开抖音,看看【Voidmatrix的作品】A*算法?高效环境感知?通用寻路算法全解析! # ... https://v.douyin.com/Wi1tLLwt1zE/ 09/09 vfb:/ X@Z.ZM
非思考版本的回答是下面这样的。
这是一则聚焦游戏开发中寻路算法的科普视频,核心是讲解不同场景下游戏角色(如怪物、AI单位)如何规划移动路径,从基础逻辑到进阶技术展开解析,还结合经典游戏(《吃豆人》《环世界》等)和现代引擎工具(NavMesh、Recast Navigation)讲解实践应用,以下是关键内容拆解:
一、基础寻路逻辑(简单场景)
无障碍物场景:通过“坐标差值计算速度方向 + 持续更新位置”,让怪物追踪玩家(如两个小球示例,蓝球玩家、红球怪物,靠坐标差让红球追蓝球)。
简单障碍物场景:给怪物加“物理碰撞逻辑”,让其“蹭墙绕路”靠近玩家(虽视觉上速度变慢,但能保持追击)。
二、经典游戏的“取巧”寻路(以《吃豆人》为例)
受限于早年硬件性能,《吃豆人》幽灵的寻路被简化为“局部最优决策”:
仅关注“路口”决策点,不计算全局路径;
追击时,以路口为中心建坐标系,把玩家位置投影到坐标轴,选“与玩家距离最短方向”;
若多方向距离相同,按预设优先级(如上→左→下→右)选路。
这种“短视型”逻辑,靠4种幽灵+模式切换,也能给玩家沉浸感。
三、现代游戏的“全局寻路”算法(从Dijkstra到A*)
硬件性能提升后,需全局视角规划从起点到终点的完整路径,核心算法是A*,它基于Dijkstra并加入“启发式引导”:
1. Dijkstra算法:解决“带成本的路径选择”
思路像“洪水扩散”,从起点向外逐步计算每个节点到起点的移动代价(如地形、障碍、减速区都算“代价”);
把待遍历节点放队列,每次选“代价最小的节点”继续探索;
优势:能在复杂地图(如《环世界》基地、大世界山脉)选“代价最低”路径(而非直线距离最短)。
2. 启发式引导:给算法“方向感”
Dijkstra会无差别探索,浪费性能。“启发函数”通过曼哈顿距离/欧几里得距离,让算法优先探索“更靠近终点”的方向:
曼哈顿距离:适合网格地图(如《吃豆人》四向移动),公式 d(A,B)=|x1 - x2| + |y1 - y2| ;
欧几里得距离:适合自由移动场景,公式 d(A,B)=√[(x1 - x2)² + (y1 - y2)²] 。
3. A*算法:Dijkstra + 启发函数
节点“优先级” = 「到起点代价」 + 「到终点的启发式距离」,既保证路径“成本最优”,又减少无效探索,是通用性最强的寻路算法。
四、海量单位的高效寻路(如RTS游戏)
像《星际争霸》满屏单位,若每个单位独立寻路,计算成本爆炸。解决方案是**“流场寻路”(洋流图)**:
提前计算/共享路径,运行时“查表”得到移动方向;
生成流场:用广度优先算法遍历网格,记录各节点到目标的“行动代价”,再从每个节点邻居中选“代价最小”方向作为“流场指向”;
单位移动时,只需持续查询脚下节点的“流场指向”,就能高效到达终点。
五、3D场景与动态地形的寻路(NavMesh导航网格)
非网格3D场景(如斜坡、梯子)或动态修改地形(如《死亡搁浅》建桥),需用NavMesh(导航网格):
生成步骤:体素化(把3D场景拆成体素)→ 剔除不可走区域 → 多边形覆盖可行走区 → 分割为三角形,方便运行时检索;
动态优化:场景分块,只更新“被修改区域”的导航网格,同时保证块间顶点对齐,避免AI卡墙。
六、总结:寻路算法的“取舍”
没有绝对完美的算法,需结合游戏类型、性能预算、场景复杂度选择:
小体量/复古游戏:用《吃豆人》式“局部决策”省性能;
3A大作/开放世界:靠A* + NavMesh平衡精度与效率;
RTS/海量单位:优先“流场寻路”降低计算压力。
核心目的是让算法服务于游戏体验,而非追求理论最优。
思考了的是这样的。
思考过程。
用户现在需要总结这个关于游戏寻路算法的视频内容。首先,得理清视频的结构:从基础场景的寻路讲起,到经典游戏《吃豆人》的简化策略,再到现代算法如A*、Dijkstra,还有流场寻路、NavMesh等,最后讲实践优化。
首先,视频开头用小球示例解释简单场景的寻路逻辑,比如空旷场景下通过坐标差移动,有简单障碍时用物理效果蹭墙移动。但复杂场景(障碍多、地图大、单位多、有地形代价)需要更复杂算法。
然后讲《吃豆人》的简化寻路:幽灵在路口选局部最优方向,红色幽灵追踪玩家,路口用坐标系投射选最短路径,同距离按优先级(如上→左→下→右),这种短视策略靠多幽灵和模式切换营造沉浸感。
接着引入现代全局寻路需求,介绍A算法。先讲Dijkstra算法:基于广度优先,计算移动代价,优先遍历代价最小节点,处理复杂地图的“移动代价”(如《环世界》选速快路径而非直线跨山)。但Dijkstra有性能浪费,因为反向探索目标方向优先级低,所以引入启发函数(曼哈顿距离、欧几里得距离)引导探索方向,A结合Dijkstra和启发函数,代价=起点代价+终点启发式代价,高效找全局路径。
再讲海量单位的寻路优化,如RTS游戏用流场寻路:提前计算网格节点到目标的代价,生成向量场(流场),单位查表移动,避免重复计算。以塔防项目《村庄保卫战》为例演示,还提到流场生成需插值平滑。
然后是3D场景的NavMesh(导航网格):现代引擎生成工具,步骤为体素化→剔除不可行区域→多边形覆盖→分割为三角形。动态场景(如《死亡搁浅》建桥)需局部更新网格,避免断裂,推荐开源库Recast Navigation。
最后总结:寻路算法无绝对最优,需结合项目需求,让理论服务实践。
现在要把这些内容组织成清晰的结构,分点讲解,突出关键算法和应用场景,语言简洁。
正式回答。
这是一则讲解游戏寻路算法的技术向视频,从基础逻辑到复杂场景优化,系统解析了不同游戏开发场景下的寻路策略,核心内容总结如下:
一、基础场景的寻路逻辑
视频以“小球追逐”示例切入,展示不同场景下的基础寻路思路:
空旷场景:通过“坐标差值计算速度方向”,让怪物持续追踪玩家。
简单障碍场景:为怪物添加物理效果,利用“非障碍物法线方向的路径”,让怪物“蹭墙”逼近玩家(速度视觉上变慢)。
二、经典游戏的简化寻路(以《吃豆人》为例)
受早期硬件性能限制,《吃豆人》幽灵的寻路策略被局部简化,核心逻辑是:
幽灵仅关注“路口决策点”,不计算全局路径;
追击时,以路口为中心建坐标系,将玩家位置投射到坐标轴,选择“与玩家距离最短的方向”;
若多方向距离相同,按优先级规则(如上→左→下→右)选择。
这种“短视式”寻路,通过多幽灵搭配和模式切换,仍能营造沉浸感。
三、现代游戏的全局寻路算法
现代硬件性能提升后,需在全局视角规划“从起点到终点的完整路径”,核心算法包括:
1. Dijkstra算法
思路:基于广度优先,像“墨水扩散”一样遍历节点,同时计算“移动代价”(如地形、障碍的通行成本);
优化:优先遍历“代价最小的节点”,能在复杂地图中(如《环世界》跨地形、绕建筑)选择“综合成本最优”的路径。
缺陷:对“目标方向的反向探索”存在性能浪费。
2. A*算法(Dijkstra + 启发函数)
核心:在Dijkstra基础上,加入启发函数引导探索方向,减少无效计算。
启发函数:常用曼哈顿距离(网格地图,适合四向移动,如《吃豆人》)或欧几里得距离(空间自由移动,适合3D场景),让算法优先探索“更接近终点”的方向。
公式:节点代价 = 「起点到该节点的移动代价」 + 「该节点到终点的启发式距离」,实现“全局最优”与“效率”的平衡。
四、海量单位的寻路优化(以RTS游戏为例)
面对《星际争霸》等满屏单位的场景,逐单位计算路径成本过高,需批量优化策略:
流场寻路:提前计算“网格节点到目标的移动代价”,生成“向量场(流场)”;单位移动时仅需“查表”获取方向,避免重复计算。
案例:塔防项目《村庄保卫战》演示“查表式寻路”,流场生成需通过“广度优先遍历节点→计算向量场→插值平滑”实现连贯移动。
五、3D场景的动态寻路(NavMesh导航网格)
应对3D场景(如斜坡、梯子、动态建筑),现代引擎用**NavMesh(导航网格)**技术:
生成步骤:体素化场景→剔除不可行区域→多边形覆盖可行区域→分割为三角形网格,供运行时检索。
动态优化:如《死亡搁浅》中玩家建桥/梯子后,仅局部更新受影响区域的网格,避免全场景重算;需保证网格顶点对齐,防止AI“卡墙”。
工具推荐:开源库Recast Navigation(Unity、Unreal等引擎均采用其技术)。
六、总结:寻路算法的工程实践
无“绝对最优”算法,需结合游戏类型(如RTS、塔防、3D开放世界)和场景需求(静态/动态地形、单位数量)选择策略;
核心目标:让算法理论服务于“玩家体验”和“性能优化”,而非追求数学上的绝对最优。
视频最终强调:游戏开发中,寻路算法的价值在于平衡“逻辑合理性”与“运行效率”,助力打造沉浸感与性能兼顾的体验。
具体效果你们看着说,评论区要给大家。
我也用了,感觉很不错。
看来,你们拿到视频总结的时间还挺晚的。我记得在我这边,视频总结前几个版本就已经有了。
最开始没有视频总结这个东西的时候,他确实能解析并总结抖音的一些视频内容的。但看这个的话,感觉比视频描述效果还是差了很多的。其实我希望楼主能够测试一下是那种无声的纯背景音乐或无音乐的,只有画面的那种视频,没有任何的字幕或者是解说。
看到了不少,感觉都是像在玩文字游戏。如果不能描述出画面,那也只能说明大概率他看不了视频。当然楼主别误会,我不想攻击你或者嘲讽阴阳,因为我实在是看的太多这种搞表面文字游戏的,烦透了,是真的烦透了好吧。我只能说某些开发者的思路,我能理解,毕竟咱都是发疯界的,抬头不见低头见对吧。但有没有一种可能,即使是发疯界的同行,也不想在这一块被耍。唉。真搞不懂。一说起这个我就想吐槽一下,天工我之前也使用过音视频,我以为他能真正看视频。我传上去了好多个音频视频他好像是只会听并且只会听人的声音就是人的说话声只会转文字。甚至还有更绝的,我上传一个音频,他就给我回答一些视觉描述,说的倒挺像模像样,还有什么什么画面。
我觉得我还是做好回归网页端或者其他接口端的准备吧。不是说安卓应用端完全不好,只是有些场景有些不好的地方,让我实在是完全受不了。
其实我现在最期盼的就是它能够也有视频描述。最好能够调用系统的文件管理选择就是系统的文件app,而不是相册选择那个页面。
但不过怎么说,我还是挺希望我也能拿到视频总结这个东西的哈哈哈。