menu
版本
2017.1.9.6501
2024.1.3.8749
2023.1.11.8682
2022.1.18.8567
2021.1.14.8108
2019.2.15.7667
2019.1.11.7296
2018.1.11.6987
2017.2.10.6745
2017.1.9.6501
2016.2.6.6153
2015.1.9.5624
2024.1.3.8749
2023.1.11.8682
2022.1.18.8567
2021.1.14.8108
2019.2.15.7667
2019.1.11.7296
2018.1.11.6987
2017.2.10.6745
2017.1.9.6501
2016.2.6.6153
2015.1.9.5624
为了做到尽可能灵活,并且满足几乎任何类型游戏的需求,Wwise已经引入了一种新方式来管理游戏中的SoundBank。这种新方式并不是要证明原有方式(将在本节后面部分解释)是无效的,而只是简单地给用户更多的控制和灵活度,让用户能够更好地管理游戏的需求。
这种新方式针对现有的传统方法提供了三种主要的改进:
用户不仅可以在SoundBank中安放事件,而且也可以安放结构化内容(声音、容器、角色混音器等)、工作单元和文件夹。
用户可以决定何种类型的信息将被包含在该库中。这意味着用户可以安置一个仅包含媒体、结构化数据、事件内容、或这三者的任意组合的SoundBank。例如,可以创建一个仅包含与某一具体事件相关联的媒体的库。
用户可以把多个具体的项目包含到一个SoundBank中,也可以把它们从SoundBank中排除。
这种新方法的主要优势在于允许把媒体内容分割成多个内存库。例如,假设用于整个游戏的音乐最开始使用的是一个单一事件。若使用传统方法,则需要把该事件添加到库中,这将自动添加所有对应的在内存中的声音和预抓取媒体,包括对仅在游戏结束时才会播放的乐曲的预抓取。为整个游戏而把所有媒体保存在内存中看起来是非常低效的。不过,使用新方法就能够更好地管理内存,它会把音乐媒体分割成多个库,因此只会在这些声音可能会被播放时把它们加载到内存中。
通过把媒体分割成多个库,用户还能为将要被加载的媒体设置优先级。例如,在内存数量有限的环境中,用户将只想加载最重要的媒体。非关键媒体可以被存储在一个单独的库中,这个库仅在有足够内存时才会被加载。在过去,关键媒体文件和非关键媒体文件是被包含在同一个库中的。如果这个库过大,无法被加载到内存中,则任何声音都无法播放,包括那些关键声音。
Wwise SDK库管理示例描述了能够用于生成并整合游戏中各个SoundBank的不同方法。在一个单一游戏中,可以使用一种方法或各种不同方法的组合。由于每个游戏都是不同的,因此需要根据游戏的具体需求选取一种或多种方法。请记住,所有解决方案都行得通,但你选择的策略应该把游戏中的内存使用量、I/O存取、以及整合的容易程度考虑进来。每种方法都有其优缺点,因此在大多数情况下,这是一个在内存用量与整合便利度之间的平衡问题。
有关SoundBank整合的附加细节: