https://www.gameres.com/863889.html
1.省沟通成本和程序用代码实现的时间成本
2.动态化效果，类似daw效果器集成，相似与编曲里面的自动化。比如改变pitch，改变混响发送量，做eq高低切，声像。具体效果想象你玩CS，枪声、手榴弹爆炸的方位，不同大小房间的混响效果。这让程序实现怎么可能就几行代码的事
试着体验一下任何一个3d网游，除了音乐之外所有的声音效果都是音效师、声音设计要和程序配合完成的。试着数数个数，是不是想象那么简单。
低成本的游戏不会用这玩意
基本上是北上广深成都的规模化游戏公司会用，追求效果和产出效率
讲究点的游戏音效怎么可能就一个两个
这玩意你全要程序员去编要累死他
本帖最后由 次奥啊 于 21-7-20 16:39 编辑
1.省沟通成本和程序用代码实现的时间成本
2.动态化效果，类似daw效果器集成，相似与编曲里面的自动化。比如改变pitch，改变混响发送量，做eq高低切，声像。具体效果想象你玩CS，枪声、手榴弹爆炸的方位，不同大小房间的混响效果。这让程序实现怎么可能就几行代码的事
试着体验一下任何一个3d网游，除了音乐之外所有的声音效果都是音效师、声音设计要和程序配合完成的。试着数数个数，是不是想象那么简单。
低成本的游戏不会用这玩意
基本上是北上广深成都的规模化游戏公司会用，追求效果和产出效率
讲究点的游戏音效怎么可能就一个两个
这玩意你全要程序员去编要累死他
本帖最后由 次奥啊 于 21-7-20 16:39 编辑
观众反应
我司之前试水做游戏的时候，刚开始就是直接调用mp3文件，后来发现当要调用多个mp3文件时，性能下降明显，甚至音频间不连贯、卡顿，然后我们就集成了Fmod音频引擎。
观众反应
直接调用资源文件是相当可行的 但是也是很原始的手法
中间件的目的不是给你添麻烦 而是帮助音频和程序方便对接、方便资源管理、以及对资源二次创作和整合
同时还能实现互动音频的目的
比如你做个BGM 调用资源的方式是 根据场景提供不同的音乐文件 如何切换是程序来设定
但是 程序不一定懂音频 就算懂 可能也不如你懂 就算比你懂 但你是音乐的创作者 你更清楚逻辑 更何况 如果有这么牛逼的程序 请告诉我 我去他家门口跪拜
所以 你如果自己用中间件解决的话 自由度就高了 你可以把你做的音乐横向拆分成不同的段落 也可以纵向拆分成不同的轨道和轨道组合 然后把这些拆分去中间件里重新组合 而程序只需要执行跟你统一的事件就可以了
音效同理
比如一个角色的脚步 需要作出草地 沙地 石板路 要不要调用混响等多种声音 调用样本的话 你自己算你的脚步需要多少个样本 而且每个样本间没有软过渡 只有硬切
如果是中间件的话 你只需要把所有材质的样本作出2个以上就够了（当然样本越多随机性越自然） 混响可以在中间件里做 最后还有软过渡
以上这些东西 不是程序不能实现 而是 程序不一定能实现 或者说难于实现 或者说实现出来也不如中间件的效果好 就算比中间件还牛逼 那程序光开发你这些实现的功能要耗费的时间就多少？既然这些东西中间件已经可以做到了 为什么不直接用？
我给你举的例子只是中间件功能的很普通和基本的东西 还有很多可操作和可实现的东西 就不多表述了
本帖最后由 研究员 于 21-7-20 19:00 编辑
中间件的目的不是给你添麻烦 而是帮助音频和程序方便对接、方便资源管理、以及对资源二次创作和整合
同时还能实现互动音频的目的
比如你做个BGM 调用资源的方式是 根据场景提供不同的音乐文件 如何切换是程序来设定
但是 程序不一定懂音频 就算懂 可能也不如你懂 就算比你懂 但你是音乐的创作者 你更清楚逻辑 更何况 如果有这么牛逼的程序 请告诉我 我去他家门口跪拜
所以 你如果自己用中间件解决的话 自由度就高了 你可以把你做的音乐横向拆分成不同的段落 也可以纵向拆分成不同的轨道和轨道组合 然后把这些拆分去中间件里重新组合 而程序只需要执行跟你统一的事件就可以了
音效同理
比如一个角色的脚步 需要作出草地 沙地 石板路 要不要调用混响等多种声音 调用样本的话 你自己算你的脚步需要多少个样本 而且每个样本间没有软过渡 只有硬切
如果是中间件的话 你只需要把所有材质的样本作出2个以上就够了（当然样本越多随机性越自然） 混响可以在中间件里做 最后还有软过渡
以上这些东西 不是程序不能实现 而是 程序不一定能实现 或者说难于实现 或者说实现出来也不如中间件的效果好 就算比中间件还牛逼 那程序光开发你这些实现的功能要耗费的时间就多少？既然这些东西中间件已经可以做到了 为什么不直接用？
我给你举的例子只是中间件功能的很普通和基本的东西 还有很多可操作和可实现的东西 就不多表述了
本帖最后由 研究员 于 21-7-20 19:00 编辑
观众反应
我只接触过 CRIWare。
如果你知道「面向对象的编程」这个概念是怎样的话，那么 CRIWare 封包就是把死板的音频变成可以交互的对象。
比如说你把不同雨量的下雨声音进行采样、且对各自对应的室内外雨声做分别的采样，然后将这些采样封装成一个下雨的对象、且确保其有「雨量」与「室内外」这两个属性（每个采样之间用动态 Crossfade 来调配比例）。这样就可以封装成一个下雨声的采样来丢给程式师，然后程式师就可以将这些细微的参数调整与玩家的实时动作位置进行绑定。
如果你知道「面向对象的编程」这个概念是怎样的话，那么 CRIWare 封包就是把死板的音频变成可以交互的对象。
比如说你把不同雨量的下雨声音进行采样、且对各自对应的室内外雨声做分别的采样，然后将这些采样封装成一个下雨的对象、且确保其有「雨量」与「室内外」这两个属性（每个采样之间用动态 Crossfade 来调配比例）。这样就可以封装成一个下雨声的采样来丢给程式师，然后程式师就可以将这些细微的参数调整与玩家的实时动作位置进行绑定。
观众反应
他的实际原理就是让你调用这个mp3啊。只不过为了实现更加复杂的功能。
举几个例子：
我想要bgm循环播放，但是第一小节之前有个引子。再重复播放的时候不需要引子。
wwise里实现的话很容易，程序员做也很容易。但是你要给程序员讲明白可能要讲半天。
而且你要知道游戏公司的音频部门地位不一定高。人家程序不一定愿意搭理你帮你实现这种你觉得有用的功能。
再比如你要做一个射速特别快的技能，如果频繁重复就会让声音机械，如果让声音不重复就得做一堆采样（让游戏安装包变大，还得让程序做随机化）。但是wwise里就能随机化每一次攻击的音调和音量，让声音机械重复的感觉感下降。
你想做一个进入水里的声音，水面上所有的声音(技能、背景音效)都变成了高切效果、但是语音、背景音乐、UI音效啥的不能高切。没有wwise的话你还要去给程序讲什么叫高切，哪些音频需要做高切。
好了，光解释这三个问题你已经浪费了人家程序半天时间了。而Wwise就能让你节省这些沟通成本。
============
至于什么"低成本的游戏不用wwise"，低成本的游戏公司可能连音频部门都没有23333。
该外包的外包，还有直接去网上搜索闪吧音效之类的对付上就行了。
本帖最后由 qwetvj 于 21-7-20 21:16 编辑
举几个例子：
我想要bgm循环播放，但是第一小节之前有个引子。再重复播放的时候不需要引子。
wwise里实现的话很容易，程序员做也很容易。但是你要给程序员讲明白可能要讲半天。
而且你要知道游戏公司的音频部门地位不一定高。人家程序不一定愿意搭理你帮你实现这种你觉得有用的功能。
再比如你要做一个射速特别快的技能，如果频繁重复就会让声音机械，如果让声音不重复就得做一堆采样（让游戏安装包变大，还得让程序做随机化）。但是wwise里就能随机化每一次攻击的音调和音量，让声音机械重复的感觉感下降。
你想做一个进入水里的声音，水面上所有的声音(技能、背景音效)都变成了高切效果、但是语音、背景音乐、UI音效啥的不能高切。没有wwise的话你还要去给程序讲什么叫高切，哪些音频需要做高切。
好了，光解释这三个问题你已经浪费了人家程序半天时间了。而Wwise就能让你节省这些沟通成本。
============
至于什么"低成本的游戏不用wwise"，低成本的游戏公司可能连音频部门都没有23333。
该外包的外包，还有直接去网上搜索闪吧音效之类的对付上就行了。
本帖最后由 qwetvj 于 21-7-20 21:16 编辑