|
发表于 2020-4-10
|
|阅读模式
关于游戏动态音乐设计的思考(1)设计分类学; U' }2 D% a: m& R {
3 f. j0 E6 Z, s) i \' V- x; oPart1-设计分类学 % }8 B' O0 ]# W( d
引子
9 r$ i6 e, _; u o大概是在2015年,我得到了自己第一份在游戏公司的工作,然后偶然接触到了Wwise(当时居然是通过一位美术总监同事的介绍……)。在那之前我的职业目标还是为游戏谱写音乐,尽管对互动音乐、音乐生成与算法作曲已有兴趣,但从未想到过这些东西就存在于从小便热爱的视频游戏中……然而在我读完Wwise互动音乐相关文档后,便意识到自己可能在从事世界上最棒的工作!但由于当时国内还不存在音乐设计师这样的职位(可能现在也没多少),并且还没有多少游戏公司充分意识到互动音乐的价值(也许现在已经好多了),我只能利用业余或者自主加班的时间进行有关游戏互动音乐的“地下研究”。5 l$ ~8 q* B# s* C, o
出于对游戏互动音乐设计方法的更多可能性的好奇,我便开始了刷Google和Youtube的学习之旅……最初Youtube频道Music By Kejero给了我非常多的启发,他的系列视频中对Vertical Techniques、Horizontal Techniques、Stingers、Transition Segments、Hybrid Techniques设计方法进行了系统地介绍,其中关于不同技术在叙事中作用的讲解也使我开始思考技术与表达的关系。再之后的几年中,我刷掉了能在Youtube上找到的讨论游戏互动音乐的所有视频、读掉了Audiokinetic Blog、DesigningMusicNow、Melodrive Blog这些网站上绝大多数与游戏互动音乐相关的文章……这个过程让我回顾了游戏音乐的发展史——从蜂鸣器/Chiptune到自适应管弦乐,从硬件FM音源到算法生成打击乐(Intelligent Music Systems);让我了解到91年就存在的运用了Hybrid Techniques + Procedural Audio的天才引擎(Lucas Arts - iMuse)、了解到存在着开创性地将音频与MIDI技术混合使用的疯狂而巧妙的音乐设计(Get Even!) @( [) |$ }0 h% i7 e
现存学习材料存在的问题
. \4 W$ q5 i! R0 ^9 i$ @- V学习的确是快乐的,然而在试图将所学转化为实践的过程中我意识到几个问题:
+ i! w6 Z0 W0 X7 v2 V6 b7 f: Y! o许多介绍游戏互动音乐的材料,侧重点都是受游戏引擎驱动的音乐设计,在音频引擎不受游戏引擎驱动情况下的设计很少被提到;; M; O6 _" s, i, o; z, W1 V! |
游戏中对于不同技术的使用总是“你中有我我中有你”,这也是为什么会出现Hybrid这种称呼(而Hybrid对Kejero与Olivier Deriviere来说可能指的又是极其不同的东西);- o4 i7 P; e! Q' {
处理方法的称呼方式不固定——Vertical Techniques也被称为Vertical Remixing、Layering、在某些地方甚至直接以Multitrack作为“Jargon”来代表这类技术;
" q+ I7 n d* R通过混音技术实现的互动音乐创作手法没有得到足够的关注,而这恰恰是Olivier Deriviere的Hybrid(Audio+MIDI)方法中的复杂性所在,也是更加复杂的音乐设计可能性得以存在的基础。% T' P0 E0 T2 H0 Y9 |$ o
对策. w' q+ Q3 u6 |) H
Michael Sweet曾说:
) G/ g+ x2 y: ~& J“…并不排除许多游戏同时利用多种自适应音乐技术这一事实。但是,如果作为作曲家的我们要更好地为游戏编写音乐,那么就应该为每种技术的使用组织一些通用准则。” # O) p8 L, ]$ e
尽管艺术创作的可能性是无穷无尽的,但就像我们在日常工作中需要Shortcuts与工程模板——归纳总结处理方法以消除迷惑也像优化工作流程一样,有助于我们降低试错成本、尽快制定出贴合游戏且可靠的音乐设计方案,并将更多的精力投入到精巧复杂的具体设计及实现当中,为此,我便尝试制定了一套处理方法的分类标准,最初目的是指导自己的音乐设计实践,在这里分享给大家。7 B, q2 u! t* E
User Driven方法与Game Driven方法 D# ^+ L0 Y6 P. }$ X- {; m
首先,参考Wwise中定位及辅助发送的概念,根据音乐表现是否受游戏引擎状态的影响,我将可能存在的音乐处理方法划分为两大类:User Driven方法与Game Driven方法。如此,独立于游戏引擎运转的动态音乐机制便不会丧失该有的关注,从而能更好的被注意到和开发。
4 f7 K& W' r) S# Z1 [/ DStatic方法与Dynamic方法
. R: `1 R2 m; J) o* O然后,根据设计实现后结果是否能够按预期执行,将音乐设计技术进一步区分为:Static方法与Dynamic方法。如此,便可对音乐设计问题中的线性与非线性进行更好的辨别,从而选择合适的处理手段。
6 f) g; Y! K ?, _# \注:由于绝大多数情况下我们无法预料玩家在游戏中的行为,所以采用Game Driven方法进行设计的游戏音乐都可以被描述为“动态的”(Dynamic);然而由于存在由实时过场动画驱动不同音乐片段进行线性播放的设计,因此即便音乐未被渲染成一段音频文件,这种Game Driven的设计也算是“静态的”(Static,所以Game Driven Static方法还是存在的)。然而因为这些都是游戏驱动的,区别只在于游戏驱动的过程是否是线性的,所以Game Driven方法的Static / Dynamic与否可不标明。1 Q. W2 y" u! a- I4 C
Mixing方法与Transition方法
9 d# D, |6 Y1 PMichael Sweet在他刊载于DesigningMusicNow的文章中将六种最常用的音乐设计方法分成了Vertical Remixing(Layering)与Horizontal Re-Sequencing两大类。这也是我们通常讨论游戏互动音乐时会想到的最流行的技术术语。
) f+ F* B- E, h9 E& {8 z就如Vertical Remixing(Layering)类方法的名称及其本质一样,无论具体使用的技术如何复杂,其实都可以被归结为某种“与混音相关”的问题。 9 r/ Y2 O6 j. D6 U5 Y* w
而Horizontal Re-Sequencing类方法实际上都是在处理音乐段落的切换与切换过程中的过渡的问题。因此,根据设计所处理的问题,我将处理方法进一步划分为Mixing方法与Transition方法两类。( w5 ~ H; U; K# p( }" {: V) q
小结
4 r! O7 Y( H' I p" i5 n( D8 W- P" j如此,根据上面提出的分类方法,我们将得到8种可能的音乐处理方法: - O& t7 t3 b5 r- I" P
User-Driven Static Transition——不受游戏状态影响的结果可预期的音乐段落处理方法; J O7 `; r. y8 \
User-Driven Static Remixing——不受游戏状态影响的结果可预期的音乐混音处理方法, D' P7 w1 m4 V9 s* ]9 |5 Z- J$ b
User-Driven Dynamic Transition——不受游戏状态影响的结果不可预期的音乐段落处理方法
: m; E! b) f8 U1 ^User-Driven Dynamic Remixing——不受游戏状态影响的结果不可预期的音乐混音处理方法4 I M+ H/ O' m1 }; N
Game-Driven (Static) Transition——受游戏状态影响的结果可预期的音乐段落处理方法
3 U1 ^- Q0 s6 a8 {, W4 R h. U% M4 h7 T" PGame-Driven (Static) Remixing——受游戏状态影响的结果可预期的音乐混音处理方法
7 W5 d2 o* F% L8 w$ B* DGame-Driven (Dynamic) Transition——受游戏状态影响的结果不可预期的音乐段落处理方法( Y: N6 L! b$ N; U) `5 W* y
Game-Driven (Dynamic) Remixing——受游戏状态影响的结果不可预期的音乐混音处理方法。# r% t6 x, N1 t+ a2 h* ~
注:因为这些都是游戏驱动的,区别只在于游戏驱动的过程是否是线性的,所以Game Driven方法的Static / Dynamic与否可不标明。
( W. k' c* z5 m1 f7 B% R解析Interactive Music Hierarchy各结构单元的功能定位
4 ]' e5 m3 K) ]" x& r在有了新的分类标准后,便需要将其用作理论来指导设计实践,而我们进行实践的工具便是Wwise。所以在实践之前我们也需要从新的角度对工具进行理解。
- F' [3 c! F* n接下来我将展示一张思维导图,以便分享我对Wwise互动音乐系统结构的认识。# Y7 t: L3 C9 C; _. H3 D. G
您可以在微云页面 ( 链接:https://share.weiyun.com/5XNv7gf ) 获取该导图的PNG文件。
8 E V$ h+ a, X' A3 I P- A1 `4 g
( }7 [4 _% p# n, A5 Z% R
在上图中,我使用了不同的颜色来标记各结构单元在音乐设计工作中所承担的责任。
; P6 c0 W* d. F8 c8 i图中红色方块代表”可用于User Driven类的处理方法“;蓝色代表”可用于Game Driven类的处理方法“;紫色代表” 可用于User Driven与Game Driven两类处理方法“。黄色代表Transition Manager(即Property-Transitions选项卡),由于其可被用于于各种类型的设计当中,与所采用的处理方法是User Driven还是Game Driven无关,故单独列出。而绿色则代表自2019.1.0引入的Music Event功能,由于其为音乐设计的可能性带来了极大的扩充,因此也单独列出,下文中会对其进行详述。& {' |' r' y. j) y3 L3 o
注:在进行标记前,我将要考虑使用的技术限制在各个结构单元的核心功能范围内,这样可以暂时避免引入过多的复杂性(通常这样的复杂性都是与混音相关的)。您可以看到图中存在一些包含Mixing字段的很小的紫色方块,它们都处于未展开的状态,代表的便是引入对非Interactive Music Hierarchy核心功能的技术(如State/RTPC/Positioning/HDR等)考量后可能引出的处理方法。
) y3 P/ P3 O6 A- Y宏观区域
, u# x$ x! ]0 t2 R3 _9 r0 j* k; \Music Switch Container
! o3 n& {, H# q4 c" n; D/ E5 Y
T1 g7 T. |, D: k( ?
首先,我们可以看到Music Switch Container的角色非常清晰:由于Music Switch Container Association Editor是Music Switch Container独有的编辑窗口,加上其作用便是将单独或组合的Game Sync——Switch / State与对应的音乐播放目标连接起来(而Transition Manager则可被用于为可能存在的过渡设置具体的表现方式),所以若要处理Game Driven Transition设计,首选结构单元便是Music Switch Container。
0 v# m' W q `- W* d9 s注:您可以看到, Music Switch Container可用的Game Sync——State与Switch尽管(在不考虑Scope问题的情况下)可用以实现相同的切换,但与State不同的是Switch的切换可由Game Parameter驱动(由此可引出不同的互动方式)。6 {7 b% p0 R, W; d- ]
Music Playlist Container2 J- [, P& P0 o9 M; ?
- u) c: c' X0 n7 k B
接下来来看Music Playlist Container,可以发现其角色也十分清晰:由于Music Playlist Container控制的是Playlist下Music Segment的播放次序,除了支持顺序播放也支持随机播放。所以我们可得出结论——Music Playlist Container的职责便是处理User Driven Static/Dynamic Transition的首选结构单元。 : W' l/ O0 _. Z" N, ^1 F0 {
注:Sequence Continuous/Step用于线性的User Driven Static Transition设计,Random Continuous/Step用于非线性的User Driven Dynamic Transition设计。% [# e% F0 c: a/ r7 V6 v
小结# D/ \& q3 E! R1 d# A
/ u9 q) X+ Y/ x" X i: ~
至此我们总结一下——可以说,Wwise互动音乐系统当中两个比较大的结构单元都与解决Transition问题有关。有效利用Music Switch Container与Music Playlist Container,我们便已可以运用好User Driven Static/Dynamic Transition类及Game Driven (Static / Dynamic) Transition类处理方法。然而由于他们是互动音乐系统中最大的单元,这意味着不存在更上层的结构单元(硬说有的话大概是Bus)来将他们用作Remixing类处理方法中的某一个Layer,因此某些时候可能我们将不得不利用同一事件来同时播放多个此类单元来实现我们的设计。在本系列博客第二部分当中我将介绍如何使用Wwise实现Terry Riley的 In C的音乐生成(其中便会用到这里提到的处理方法)。& @" w5 g0 H; e/ m; z
微观区域4 Z/ }, F2 d Q( G5 O. O0 z; I
6 _. c) P! j, }5 z$ ?/ c' Y接下来我们将注意力转向更微观的区域,您可以看到结构单元——Music Segment、Music Track与Clip都被标记成了紫色,代表他们可以被用于User driven与Game Driven两类处理方法;同时您可以看到,与Music Switch Container及Music Playlist Container不同,图中使用红色与蓝色方框标记出的处理方法都归属于Remixing类处理方法而不是Transition类处理方法。由此我们可以直观的看出,可能存在的音乐设计的复杂性不存在于上层结构单元而存在于细部,且都与混音问题相关。 |
|