|
工具开发者:@nsmTech @张嘿嘿_@吉了个吉个了
前言
我们曾经有过这样的经历:
搭建好了新版本的wwise工程,现在要进boss战测试实机效果;
然而,
进了游戏发现,已有的GM指令并不是十分易用;
账号只有一级,进不去特定关卡的特定boss战啊?行,从第一关开始打过去;
开了挂打boss这么快,两下就没了,boss技能都还没放完啊?行,找策划调数值;
最后的大招怎么也搓不出来...门槛太高了...
(让程序更新一下GM指令需要排期,实在等不了...)
最终,只能用三分钟的战斗记忆,调整工程里各种各样的问题。
还有另外一些令人头大的情况:
• 开大型测试,服务器只能允许测一次
• 测多人战斗,人手只够测一两次
• 等等...
可不可以像电影一样,把游戏流程录制成wwise声音胶片存起来,以后可以无限次回放呢?
当然可以,我们尝试开发了URW(unity-reaper-wwise)回放工具链,只需将一次流程录制下来,就可以生成一个reaper工程,在reaper中触发wwise event,满足之后无限次的联调与测试。
生成的reaper工程就是独属于你的wwise声音胶片,在reaper这个放录机上,你可以自由回看自己的胶片,这样,Wwise就成为了Reaper的混音台,允许声音设计师反复打磨声音表现。
此外,将游戏流程录制成声音胶片(reaper工程)还意味着,设计师可以在工程中随意调整播放进度,定位到游戏流程的某个特定时间点,针对某一帧或某一小段游戏流程反复打磨。
工具流展示Unity录制音频信息
既然是回放wwise的声音,那么这部分需要回放的声音数据数据,1、形式是什么?2、声音数据该怎么抓取?
关于数据形式
因为是1.0版的工具流,所以当前的数据形式还比较简单。一句话来说,只是知道在什么时间?播放了哪些声音事件即可了。如下图。
声音时间时间点的抓取前期思考过两种抓取方式:
1、unity runtime 阶段嵌入抓取逻辑。
这种方式我们构想的理想实现方法是:项目中所有的播放声音行为有一个统一的入口。然后在这个入口处嵌入抓取逻辑,来一个声音,便抓取一个声音,存储一个声音。但考虑到不同的项目有不同的逻辑,或许就有项目不会有这样的统一的播放入口。我们给这套工作流的首要要求就是通用性,即做到任何项目都可拿来即用。因此如果后续存在在不同的项目去改造逻辑适配这套工作流的情况,这是不可接受的。另外,我们要求可以在Editor模式下也可使用。最后,在实现层面还有一个尚未验证的担忧,考虑到游戏跑起来之后的时间稳定性,或许会导致本该是同一时间触发的声音,最后数据记录下来的时间数据有所差异。所以,综上我们采用了以下第二种抓取方式。
2、Waapi
Waapi中有一个订阅接口:
这个订阅函数会在新的日志条目添加到wwise中时,执行你定义的回调函数。我的处理是在这个时候存储新的条目的信息,然后在录制结束之后,通过另外一个函数将条目信息列表生计算出所需的可供播放的数据。
需要注意的是
1.wwise条目时间单位是毫秒,且存在同一时间触发多个event的情况。因此,不管是在存储还是在播放都应该针对这个做出相应的应对操作。
2.wwise条目时间是声音引擎初始化开始所经过的时间,因此有可能录制的第一个数据触发时间量级很大。(或许你在声音引擎初始化了1小时之后才开始录制,那么第一个声音数据的时间就要>=60*60*1000)。所以,不管是为了录制完成之后及时回放,还是为了把录制的数据能在后续生成的reaper工程中能顶头播放,都应该把所有的数据时间等比例前移,我的做法是把所有的时间最后都从0秒或0.5秒出开始。
其他便是播放的时间控制逻辑、用户界面的逻辑以及保存加载逻辑编写了,不多说。
第二步:Json To Rpp
在生成rpp(即reaper工程)这一环,我选择了用Node.js来编写脚本。因为对于技术音频来说,我认为基于Node.js的JavaScript语言是一种相对来说比较轻量级的选择,可以快速地达到“写工具”的目的,从而将更多的时间用在“设计”上。
首先,Node.js有npm包管理工具,可以将脚本所需的依赖包粘合在一起,使脚本开发过程变得相对流畅。比如FFmpeg是一个非常强大的音视频处理工具,支持多种音视频格式,提供了丰富的功能和参数选项。而在Node.js中使用它也相对便携,只需使用npm命令进行安装:
安装完成后,就可以在Node.js代码中引入fluent-ffmpeg模块,然后使用其提供的API进行音视频处理了。在我之前给音频部写的打metaData标签的工具中,也是调用了FFmpeg中相关的API:
npm中的FFmpeg Metadata API示例相比于其他编程语言,Node.js在处理IO密集型任务上表现更为优异,这意味着Node.js脚本能够更快地读取和写入大量的音频数据,而不会因阻塞而导致程序运行缓慢。另外,Node.js还提供了异步编程模型,可以使脚本在进行IO操作时不会阻塞主线程,从而保持应用的高响应性。
更加令人惊喜的是:JavaScript有相关的Waapi接口,你可以在网页中、桌面应用程序中和Wwise做相关的交互。这也为技术音频在设计工作流的过程中提供了很多的思路。通过Waapi接口,可以方便地使用JavaScript与Wwise进行通信和交互,实现对音频资源的实时控制、管理和自动化处理。例如,可以通过Waapi接口实现动态更改音频事件、创建和管理游戏中的声音对象等操作,从而为游戏音频设计提供更多的可能性。
官方用JavaScript写的“Hello Wwise”Waapi示例在当前这个回放器工具中,我就是通过Waapi来获取实践中音频样本的最大长度,从而将其转换为rpp中item的长度的。我使用的uri是ak.wwise.core.object.get,options为'maxDurationSource',以WAQL的形式向Wwise发送http请求,从而获取信息。
使用Waapi的查询事件信息函数至此,结合Unity中录制的Json、mp4和从Wwise获得的信息,我已经能完完全全地生成一个rpp的文本文件作为这个工作流中的reaper工程了。
工作流中生成的reaper工程ReaWwise Caster界面-概述
在reaper端实现重放的初衷,是为音频设计师提供一个能够在DAW中配合视频调试wwise工程的环境;更加贴合DAW使用者的操作习惯,播放方式能够与制作视频贴片时的播放方式相同。
我把脚本设计成小UI的形式,相当于是个小遥控器——开关开启,遥控器丢在一边就不用管了(当然报错了还是要管一下0 0)
为了实现这个设计目标,工具需要实现这些功能:
1.基于播放光标位置捕捉item的event触发器
2.连接Waapi并调用API的通道
3.播放视频的同时低延迟post event
4.操作者自由开启或关闭capture功能, 无感化Wwise通信
-前置扩展
ReaWwise:
ReaWwise是Wwise中的一个插件,它允许用户将Reaper中的音频和音乐资源集成到Wwise中,以便在游戏中使用。因此,ReaWwise插件提供了一些API,用于在Reaper和Wwise之间进行交互,开发人员可以将Reaper中的音频资源快速有效地转换为Wwise项目,并在游戏中使用它们。
前置扩展1UI界面:
UI前置扩展-reaper端Waapi调用的实现
今年一月份AK官方扩展了ReaWwise的功能,提供了在ReaScript调用Waapi的API:
官方使用ReaScript编写的示例脚本相关API:
使用ReaScript相关API,可收集reaper中item、track所包含的相关信息,最终通过reaper.AK_AkJson_Map_Set转化为调用"ak.soundengine.postEvent"所需要的格式。
-基于播放光标位置捕捉item的event触发器
由于ReaScript API中没有提供捕捉item的trigger功能,所以只能自己写啦。基本思路是收集各轨道item起始位置数据,实时刷新播放光标位置坐标,当判定与起始位置重合时,post event;
然而在实际码代码时遇到两个问题:
1.刷新函数时间间隔(用while do秒崩)
2.判定点精确度
在献祭头发后,问题解决:
1.ReaScript中提供每帧刷新函数
运行流畅没烦恼。
2.由于播放的声音是给人听的,所以将起始位置数据精确到1ms,兼顾延迟与判定准确度。
后续功能展望
打通reaper-Waapi通道意味着,reaper中更多的参数可转化为wwise相关参数,实现reaper控制wwise播放行为的目标。我们希望最终可以实现的是Wwise可以作为Reaper的拓展辅助调音台。
功能展望:
1.轨道包络控制rtpc
2.item控制switch、state切换
3.为轨道分配GO,根据Unity回放器记录数据,实时更新GO坐标信息
4.结合ReaWwise原生功能实现reaper item、wwise audio clip无感化自由替换,实现在reaper中还原wwise中听感并直接挂插件调整素材,一键导回wwise工程
来源:http://www.yidianzixun.com/article/0ptK1I8T
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
x
|