Game Audio Programmer Roundtable
一、声学现象与声音传播 · Acoustic Phenomena & Sound Propagation
[主持人 / Moderator]
So, acoustic phenomena — the ones we're talking about here — is how sound gets from point A to point B, respecting the geometry. If you're in the next room, you should not be hearing me, because the doors are closed. If someone opens that door, you will probably hear phantom sounds of me over there, because the sound made it through. That's propagation and occlusion.
声学现象，我们这里讨论的，是声音如何在尊重几何结构的前提下从A点传播到B点。如果你在隔壁房间，因为门是关着的，你应该听不到我的声音。但如果有人打开那扇门，你可能就会听到从那边传来的幽灵般的声音，因为声音穿透过来了。这就是声音传播与遮挡。
I want to say there's a lot of new technologies coming out, a lot of talk about GPU. Obviously, because of that, I'd say for now the main balance that a lot of these things are trying to find is authoring versus doing everything at runtime. And I think that's where a lot of it is going to need to find a space.
我想说，现在有很多新技术涌现出来，很多都在谈论GPU。显然，正因如此，我认为目前很多系统都在努力寻找的核心平衡点是：手工预制（authoring）与运行时实时计算（runtime）之间的权衡。我认为这是整个行业需要找到定位的地方。
Because on one side you have things like rooms, portals, Wwise Rooms and Portals, or Volumes in Unreal, which are very hand-authored — which is cool because you can choose exactly how you want things to sound — but it requires a lot of manual labor. On the other hand, you have Project Acoustics, GPU ray tracing, things that are coming up, which are cool because they do everything from math and physics. But it also means that if math and physics don't deliver the drama you want to bring into the game, then suddenly you're stuck. So right now, these are the arrays of tools and you have to choose from there.
一方面，你有像Wwise Rooms and Portals、Unreal中的Volumes这样的系统，它们都是高度手工预制的——这很好，因为你可以精确控制声音的表现——但这需要大量的手工劳动。另一方面，你有Project Acoustics、GPU光线追踪这类新兴技术，它们很酷，因为一切都基于数学和物理自动完成。但这也意味着，如果数学和物理无法呈现你想在游戏中营造的戏剧性效果，你就会陷入僵局。所以目前，这些就是可供选择的工具矩阵。
Colin:
Hi, I'm Colin. On the open world physics simulation front — I was sold by the talk last year by Lucasoft on GPU ray tracing for audio, to the point where we're going in that direction. With the help of Jian, we made the switch. I'm really convinced that the performance cost is negligible — it's really not affecting things in a very noticeable way on the GPU. It's really hard for me to imagine a case where it wouldn't be smart enough to cast tens of thousands of rays for practically nothing on the GPU. So I was sold and committed to this direction.
大家好，我是Colin。在开放世界物理模拟方面——去年Lucasoft关于GPU音频光线追踪的演讲彻底说服了我，以至于我们决定朝这个方向发展。在Jian的帮助下，我们完成了切换。我真的相信性能开销可以忽略不计，它对GPU的影响并不明显。我很难想象会有这样一种情况：它无法足够智能地在GPU上以近乎零成本投射数以万计的光线。所以我被彻底说服了，并坚定地走这条路。
Jaycee (Jay):
Hi, I'm Jaycee, audio director at [studio]. My answer is pretty definitively: it's great for audio. I've done a story — when we first started asking graphics designers about how many degrees per sound source on the GPU, the graphics designers said: "64 max? Yeah, no problem, that's fine. 4,000? Actually no problem." So that sounds great, and with that information you can obviously do a lot more than the traditional approach to get closer to the continuous acoustic picture you want. You still have to deal with frame latency, but most of the acoustic phenomena you're trying to represent are captured well enough.
大家好，我是Jaycee，担任[工作室]的音频总监。我的答案非常明确：这对音频来说非常好。我讲个亲身经历——当我们最初去问图形设计师，GPU上每个声源能分配多少度数（光线方向）的时候，图形设计师说："最多64个？没问题。4000个？其实也没问题。"这听起来很棒，有了这些信息，你显然能做到比传统方式更接近你所想要的连续声学画面。你仍然需要处理帧延迟，但大多数你试图模拟的声学现象都能被足够准确地呈现。
Alish (Valve):
Hi, I'm Alish. I work for Valve. We are hiring sound designers and audio programmers all the time, so if you're interested — I worked on something called Sea of Stars... Any of these publications can consistently give you data that you can use to reduce manual work. Another direction some people are looking at is: is there a way to say, "this is the content, this is what I want propagation to sound like" — but could you reverse-engineer whatever simulation would match it? I don't know if there's anything out there that truly marries authored content with more physics-based simulation, but that's one thing which seems to be missing, at least from what we've seen.
大家好，我是Alish，在Valve工作。我们一直在招募音频设计师和音频程序员，如果感兴趣欢迎了解。我曾参与一个叫Sea of Stars的项目……这类出版物和研究可以一直提供数据，帮助你减少手动工作量。另一个有些人正在探索的方向是：有没有办法说"这是内容，这是我想要传播听起来的效果"——然后反向推导出能匹配它的模拟方式？我不知道目前是否有什么工具真正做到了将预制内容与物理模拟相结合，但这确实是一个感觉缺失的东西。
[参与者 / Participant]:
Just a quick addition: my last project was cancelled. But we had run half a million ray traces for audio only, and generated impulse responses. So you can do this. And I would add — it's a really interesting topic.
补充一点：我的上一个项目被取消了。但我们曾为纯音频目的跑了五十万条光线追踪，并生成了脉冲响应。所以这是完全可行的，而且这是个非常有趣的研究方向。
二、回调函数的应用 · Callbacks in Audio Middleware
Sam (Moody Game Audio):
Hi, my name is Sam from Moody Game Audio. This is a bit noisy, but I'm curious — I know callbacks can be used for music integration, save state playback, things like that. What other use cases have you guys encountered for callbacks in Wwise or other middleware, and how would you use that from a creative purpose?
大家好，我叫Sam，来自Moody Game Audio。我想问一下——我知道回调函数可以用于音乐整合、存档状态回放之类的事情。你们还遇到过哪些回调函数的使用场景，特别是从创意角度出发的？
Kyle:
Hi, my name is Kyle. I work at [company] as a sound designer. We're not on Wwise, we're on FMOD. One thing we do with callbacks for a creative purpose is that a lot of our songs are very directional in a musical sense. We do a system where you can put markers on a track that define a key signature, and that gets read by the game engine to set a parameter — so we can then drive the pitch of sound packs to change the key in real time. Similarly for music, there's a music dynamics bar where we put markers on the music track marking how loud the music is from 0 to 5, and we use that as a callback parameter on the engine side. We can then use that to make, for example, the wind louder if the music is louder, so the mix stays relatively balanced even when there are large music dynamic swells. So in terms of creative uses, we're keeping the music system in sync and allowing us to more seamlessly match the key of sonic effects to the background music.
大家好，我叫Kyle，在[公司]担任音效设计师。我们用的是FMOD而不是Wwise。我们从创意角度使用回调函数的一个方式是：我们很多音乐在音乐方向上都非常具有调性。我们有一套系统，可以在音轨上放置标记来定义调号，游戏引擎读取后设置参数，从而实时驱动音效包的音高来改变调性。类似地，对于音乐，我们有一个音乐动态条，在音乐轨道上标记音量大小（0到5级），并将其作为引擎端的回调参数。然后我们可以用它来让风声在音乐较响时也变响，从而使整体混音保持相对平衡，即使音乐有大的动态起伏。从创意角度来说，这保证了音乐系统的同步，并让我们能更无缝地将音效的调性与背景音乐相匹配。
[参与者 / Participant]:
One thing about callbacks I want to amplify: we often think of callbacks as instantaneous triggers — that's how they're supposed to be used. But then we realized that animators have no use for instantaneous triggers, because animations are fluid. If you were playing drums, you don't go instantaneously from here to here — it's the whole movement, you're anticipating the beat. So we realized the best use of callbacks isn't the trigger itself, but being able to create ramps out of them. Once they had that, animators felt more comfortable hooking up to the audio system because suddenly they could anticipate movements rather than just reacting to "oh, something happened."
我想强调关于回调函数的一点：我们通常把回调视为瞬时触发器——这是它们设计上的用途。但我们意识到动画师根本用不上瞬时触发器，因为动画是流动的。如果你在打鼓，你不会从这里瞬移到那里——整个动作过程都在，你是在预判节拍。所以我们意识到回调函数最好的用法不是触发本身，而是从中构建渐变曲线（ramps）。有了这个，动画师就更愿意接入音频系统了，因为他们终于可以预判动作，而不是只能被动响应"哦，发生了什么"。
[参与者 / Participant]:
We also echo that — animators use the breathing system a lot, taking feedback from how long a sound has been selected, so you can get procedural breathing generation that knows how long to scale. That's a really good use of callbacks in practice.
我们也有类似的体会——动画师大量使用了呼吸系统，从声音已被选中多长时间来获取反馈，从而生成程序化的呼吸，并知道如何调整时长比例。这是回调函数在实际应用中非常好的用法。
[参与者 / Participant]:
I think if you step back, there are actually two different types of callbacks. One type tells you something just happened — the sound ended, a key changed, the beat of the music hit — these are all tightly coupled to what's actually happening aurally. The other type is more mechanical, specifically around thread synchronization: it tells you something has just been processed. In Wwise, there's one specific callback you can listen to where, if you then ask for RTPC values, they are guaranteed to be free of locking conflicts. So there are functional callbacks that help you optimize, and informational callbacks that tell you what happened in the audio world. I'd separate those two types clearly.
我认为如果退一步看，回调函数实际上有两种截然不同的类型。一种是告知你某事刚刚发生——声音结束了、调号改变了、音乐打到了节拍——这些都与实际发生的音频事件紧密耦合。另一种更像是机械性的，特别是在线程同步方面：它告知你某些东西刚刚被处理完。在Wwise中，有一个特定的回调，如果你在那个时机请求RTPC值，它们是无锁保证的。所以有优化用途的功能性回调，也有告知音频世界发生了什么的信息性回调，我会明确区分这两类。
[参与者 / Participant]:
I'll go further than that — I run my entire audio engine loop off callbacks. There are also callbacks for rotating sounds around the listener, and there are callbacks you can use because if something has been processing for a certain amount of time, you can start to project into the future and make assumptions about what's coming.
我要说得更进一步——我的整个音频引擎循环都是由回调驱动的。另外还有用于在听者周围旋转声音的回调，以及可以利用的一类回调：因为如果某件事情已经处理了一段时间，你可以开始向未来投影，对即将发生的事情做出预判。
Colin:
Quick plug — in Game Audio Programming Volume 5, there's a chapter on using Wwise callbacks to blend meters or modify meters, and another chapter by my colleague Fiona McDonald who inverted that control entirely so that the game drives the music rather than the music driving the game.
顺便打个广告——在《游戏音频编程 第五卷》中，有一章讲如何使用Wwise回调来混合或修改声量表，另一章由我的同事Fiona McDonald撰写，她完全反转了控制关系，让游戏来驱动音乐，而不是音乐驱动游戏。
三、音频程序员与技术音效设计师的角色边界 · Audio Programmer vs. Technical Sound Designer
Sean (Johns Hopkins):
Hi, I'm Sean. I'm a senior in Computer Science at Johns Hopkins. I was the audio programming intern at [studio] last year. I ask this because when people mention "audio programmer," it can sometimes feel like it's more low-level DSP programming, but it could also be something higher-level. When I was going into my internship, I thought it was supposed to be deep low-level stuff, but I also did things some people would call "tech sound design." So I'm just wondering what you guys think about where that line is.
大家好，我是Sean，约翰霍普金斯大学计算机科学系大四学生，去年在[工作室]担任音频编程实习生。我问这个问题是因为当人们提到"音频程序员"时，感觉有时像是偏底层的DSP编程，但有时又像是更高层次的工作。我去实习时以为会做很多底层的东西，但我也做了一些人们称之为"技术音效设计"的事情。所以我想听听大家对这条界线的看法。
[参与者 / Participant]:
I wrote a whole chapter about what I call the different "flavors" of audio programming. As you pointed out, there's more low-level, there's more high-level, there's the tooling — and these are specialties where people can move between. If we take gameplay audio programming at the high level and compare it to tech sound designers: in theory, there's no difference. The more the tools are advancing — if you can build with Blueprints and visual scripting — in theory a tech sound designer can go as far as the tools let them. And if they know a bit of scripting, even more. A gameplay audio programmer can be as "tech sound designer" as they want if they know enough. Like if they suddenly have to program a random container — that's pretty much tech sound design. So there's no clear-cut limit in the end. I've had a role of tech sound designer where I was essentially programming, and the other way around. It's kind of how you want to see it, and each company will define it their own way.
我写了整整一章来讨论我所称的音频编程的不同"口味"。就像你指出的，有更偏底层的、更偏高层的，还有工具开发方向——这些都是可以相互流动的专业方向。如果我们把高层次的游戏音频编程和技术音效设计师放在一起比较：理论上两者没有区别。随着工具的进步——如果你能用蓝图和可视化脚本构建系统——理论上技术音效设计师可以走多远都行，只要工具允许。如果他们懂一点脚本，能做的就更多了。游戏音频程序员如果懂得足够多，也可以扮演技术音效设计师的角色。比如突然要编写一个随机容器，这本质上就是技术音效设计。所以根本没有明确的界线。我曾经担任过技术音效设计师但实质上在编程，反过来的情况也有。这更多取决于你怎么定义自己的角色，每家公司都会有自己的界定方式。
Jake (2-man indie studio):
Hi, I'm Jake from [studio], a 2-man indie studio. Before getting into games I made music as my main job. For someone at our studio who does everything — from C++ plugin programming to micromanaging compositions — I personally find I need the discipline to spend deep enough time in each mode. My brain thinks about things in entirely different ways depending on whether I'm looking at the sound in an IDE versus in my DAW. I try to fully separate those things: either I'm in music mode working on music in my analog state, or I am purely focused on implementing that sound in the game.
大家好，我是Jake，来自一个两人独立游戏工作室。在进入游戏行业之前，我以音乐创作为主业。对于我们工作室这种什么都要做的情况——从C++插件编程到管理作曲家的创作——我个人发现需要足够的自律，让自己在每种模式下都能深入其中。我的思维方式在IDE里看声音和在DAW里看声音是完全不同的。我尽量完全把这两件事分开：要么我处于音乐模式，在模拟状态下创作音乐；要么我就是纯粹地在把声音实现进游戏里。
[参与者 / Participant]:
The general thing is that technical sound designers are the ones who both author content and potentially write code, while audio programmers generally don't author content — but that's fuzzy, because sometimes audio programmers just put some sounds in, and technical sound designers can go weeks without authoring any sounds. The audio programmer usually works at a lower level, more sophisticated code — potentially C++ — while the typical sound designer is using a scripting language, maybe visual scripting. And I always saw my job as making myself irrelevant over time: I did a great job if I eventually had no more tasks. That's the difference with a tech sound designer, because the tech sound designer always has a job — always produces more content.
总体来说，技术音效设计师是那些既创作内容又可能编写代码的人，而音频程序员通常不直接创作内容——但这条线也是模糊的，因为有时音频程序员也会放几个声音进去，而技术音效设计师也可能好几周不创作任何声音。音频程序员通常在更低的层次上工作，写更复杂的代码，可能是C++，而典型的声音设计师使用脚本语言，可能是可视化脚本。我一直把自己的工作看作是让自己变得多余——如果最终我没有任务了，那说明我做得很好。这与技术音效设计师的区别在于：技术音效设计师永远有活干，永远在产出内容。
[参与者 / Participant]:
I think this is interesting, especially right now with AI. In these times it can empower people — even those with less coding experience — to actually create tools and pipelines and break those rules.
我认为这个话题很有意思，尤其是现在有了AI。这个时代它可以赋能更多人——即使是编程经验较少的人——实际去创建工具和流水线，打破以前的界限。
四、构建自己的音频引擎 · Building Your Own Audio Engine
[参与者 / Participant]:
As someone interested in building their own audio engine, I wanted to get a sense of advice on how much to dig into DSP, and what the first steps would be.
作为一个有兴趣构建自己音频引擎的人，我想听听大家的建议——需要在DSP上深挖到什么程度，以及第一步应该怎么做。
Rachel (UC student):
Hi, my name is Rachel. I'm a university student at UC. Not employed at the moment, but looking. In terms of building your own audio engine, I did just hear something about cloning existing engines as a viable option — but then again, it depends on how many different options you want. If you're talking about a total low-level approach and having all of it, I'm a little in the dark on how much work goes into that.
大家好，我是Rachel，加州大学在校生，目前还没有就业。关于构建自己的音频引擎，我刚听到有人提到克隆现有引擎是一个可行的选项——但这取决于你想要多少不同的选项。如果你在谈论完全底层的方式并且想要所有功能，我对这需要投入多少工作量还不是很清楚。
Jay:
I think a good way of doing it is: there's one way of doing things at the lowest level, and as you go up the levels and get closer to the game level, you make things more open for people to put their own versions in.
我认为一个好的方式是：在最底层有一种统一的做法，但随着你往上走、越来越接近游戏层，你让架构越来越开放，让人们可以插入自己的实现。
Dylan (independent audio engineer, Washington):
Hi, my name is Dylan. I'm an independent audio engineer based out of Washington. Some of the indie projects I've worked on — I've taken existing code and adapted it. One of the best things to do to start is look at what other people have done. There are videos on YouTube, there are open-source repositories. Maybe you're copying stuff at first — that's fine, it gives you a good idea of the framework. Especially if you're coming from a production background rather than a software engineering background, it's easy to look at code structure and start to break it down. Then you play around with it and see how it works in games, and then you start to add your own flavor into it.
大家好，我是Dylan，华盛顿的独立音频工程师。在我参与的一些独立项目中，我借用了现有代码并进行了改编。最好的起步方式之一是看看别人做了什么。YouTube上有教程，也有开源代码仓库。也许你一开始在复制别人的代码——没关系，这能给你一个很好的框架感。尤其是如果你来自制作背景而非软件工程背景，看代码结构然后开始拆解它是很自然的。然后你开始尝试它、看它在游戏中如何运作，接下来就可以加入自己的风格了。
[参与者 / Participant]:
That reminds me of the first time I dove into the Source Engine source code — it was open source at the time. That was the first time I experienced "oh, how is this supposed to work?" That was quite a struggle. So I really think it's good to tinker with something that's already there before you start from scratch.
这让我想起我第一次深入研究Source引擎源代码的经历——那时候它是开源的。那是我第一次体验到"这到底应该怎么工作"的感觉。真的很挣扎。所以我非常赞成在从头开始之前先在已有的东西上摸索。
Toby (PhD student):
Hi, I'm Toby. I'm a PhD student doing work on sound and audio. For a small project, especially building on top of existing hardware APIs, a good option is to start with what you have — for instance, starting with what's in OpenAL, which has two different APIs: a higher-level and a lower-level one. Pick the level of detail you want to work at, and add the functionality you want on top of that to flesh out your audio engine. It's a bit more approachable than going completely from scratch.
大家好，我是Toby，研究声音和音频方向的博士生。对于小型项目，特别是在现有硬件API基础上构建的情况，一个好的选择是从现有的东西出发——比如从OpenAL开始，它有两个不同的API：一个更高层，一个更低层。选择你想要工作的细节层次，然后在此基础上添加你想要的功能来充实你的音频引擎。这比完全从零开始要更容易上手一些。
Martin (graphics programmer):
Hi, my name is Martin. I'm a graphics guy who wanted to do audio programming, so I started in that direction. I found that a useful library is miniaudio — a small library that hides OS-specific details so you can run on Windows and other platforms without worrying about it. I did some granular sound synthesis with it, made my own mixing layer on top. The low-level native APIs are a bit annoying — I'm happy that a library did that for me and then I could go to the next level. And for the very hardcore, there's also a place to work at that level on GitHub. I found it very rewarding to make your own thing, just to learn how audio works from the inside.
大家好，我叫Martin，是一个图形程序员，想转行做音频编程。我发现一个很有用的库是miniaudio——一个小型库，它隐藏了操作系统特定的细节，让你可以在Windows和其他平台上无缝运行。我用它做了一些粒子声音合成，在上面构建了自己的混音层。底层原生API确实有点烦人，我很庆幸有个库帮我处理了这些，让我能专注于更上层的工作。对于真正的硬核玩家，GitHub上也有地方可以在那个层次工作。我觉得自己做这件事非常有收获，单纯是为了从内部理解音频是如何工作的。
[参与者 / Participant]:
There's the question of: what layer are you at? My advice would be: start with the middle layer and work outward from there.
这涉及一个问题：你在哪一层？我的建议是：从中间层开始，然后向两端延伸。
五、工具开发与音效设计师的工作效率 · Tools & Helping Sound Designers Work Better
[参与者 / Participant]:
My interest — and I know Jay shares it — is in building tools that make sound designers' and tech sound designers' lives easier. Things like having reverb applied automatically, or footstep setups generated for you, so you don't have to manually tag all of these little things. We spend so much time building these tools that we probably don't spend as much time using them to actually work on games. So my curiosity to game audio programmers is: what is the thing taking the most time right now that's really bothering you — the tedious work you don't want to be doing anymore — which game audio programmers might be able to help automate?
我的兴趣——我知道Jay也有同感——是构建让音效设计师和技术音效设计师的生活更轻松的工具。比如自动应用混响，或者自动为你生成脚步声设置，这样你就不用手动给所有这些小东西打标签了。我们花了那么多时间构建这些工具，以至于可能没有足够的时间真正用它们来做游戏。所以我对游戏音频程序员的问题是：目前最耗时间、最让你烦恼的事情是什么——那些你不想再做的重复性工作——也许游戏音频程序员可以帮助自动化？
[参与者 / Participant]:
As a technical sound designer, I constantly remind people: write your request down and say "we need this to do that." But what I've found really helpful is: don't bring me solutions, bring me problems. When sound designers come saying "I need this specific thing," I adapted to asking "what problem are you trying to solve?" That turns the conversation into "oh well I'm trying to do X" — and what they asked for was only a very narrow version of that. If you take a step back, you can implement a broader feature that actually addresses what they really want.
作为技术音效设计师，我一直在提醒大家：把你的需求写下来，说"我们需要这个做到那个"。但我发现真正有帮助的是：不要给我解决方案，给我问题。当音效设计师来说"我需要这个特定的功能"时，我改成问"你想解决的是什么问题？"这就把对话变成了"哦，我其实是想做X"——而他们最初要求的只是那个X的一个非常狭窄的子集。退一步看，你可以实现一个更宽泛的功能，真正解决他们内心真正想要的东西。
Alan:
Hi, I'm Alan. I just want to echo the conversation. At the end of the day, it's not just "this is what I want to do, give me that capability and that's it." It's a conversation about what tools are needed to get from A to B. And more importantly, it's a discussion of: how much am I actually going to use that tool? If it's a one-time thing, I should be able to find a solution with the tools I already have. But if it's something I'm doing for the entire project — implementing something in a card game for every single card played — then it's something that follows me around for the whole project and warrants a proper investment of engineering time.
大家好，我是Alan。我只想呼应这段对话。最终，这不只是"我想做什么，给我那个能力就行了"。这是一个对话：需要什么工具才能从A走到B？更重要的是：我实际上会用这个工具多少次？如果是一次性的事情，我应该能用现有工具找到解决方案。但如果是整个项目中每次打牌都要触发的东西，那它就会伴随我整个项目，值得进行适当的工程投入。
David:
Hi, I'm David. We're hiring. One thing I found very helpful is: every couple of weeks or couple of months, get the entire audio department together and have an open conversation about what the pain points are. That way you don't have to create tickets for everything — it's all out in the open. Then you can follow up on what everyone is actually trying to do, and make it a regular thing.
大家好，我是David，我们在招人。我发现一件非常有帮助的事是：每隔几周或几个月，把整个音频部门聚在一起，公开讨论痛点是什么。这样你就不必为每件事都创建工单——一切都摆在桌面上。然后你可以跟进大家真正在做什么，并把这变成一个常规活动。
[参与者 / Participant]:
Another way of looking at "bring me problems not solutions" is just: collect stories. The perspective of "I'm clicking here and I need to do this and then this" — you're not even getting into the mindset of proposing something, you're just narrating your workflow. This is tricky because sound designers and tech sound designers are very good at finding shortcuts — that's the craft. So it takes a little discipline to step out of the "how can I solve this with a queue and a filter and a hack" mode, and instead just describe the journey.
另一种理解"给我问题而不是解决方案"的方式是：收集故事。那种"我在这里点击，然后我需要做这个再做那个"的叙述视角——你甚至不是在提出方案，你只是在描述你的工作流程。这有点难，因为音效设计师和技术音效设计师非常擅长找捷径——这是他们的技艺所在。所以需要一点自律，让自己跳出"我怎么用队列、滤波器或hack来解决这个"的思维模式，转而只是描述整个过程。
六、互动音乐与游戏参数驱动 · Interactive Music & Game-Driven Parameters
James (Digipen, senior):
Hi, I'm James. I go to Digipen, I'm a senior there. We kind of covered the callback direction earlier. I want to go the other route — what kinds of game parameters are actually affecting the music in your technical sound or programming work?
大家好，我是James，Digipen大四学生。我们之前讨论了回调的方向，我想换个角度——在你们的技术音效或编程工作中，实际上是哪些游戏参数在影响音乐？
[参与者 / Participant]:
Let's go the other direction entirely: what can we drive in the game from the music? What things can be synchronized to the music? In an action RPG, you want to know what the player is doing — maybe you can detect something about their playstyle, whether the enemy is going in full force or retreating. Music can also be giving information back to the player about something that might not be immediately obvious on screen. What kind of emotion do you want to convey in this narrative scene? You drive music accordingly. And from a structural point of view: can we think about the dynamic controls of the music — its structure — and how that can inform the game to create a more cinematic or emotional experience? Timing animations and synchronizing them to hit specific strong points in the music, specific bars, specific phrasing — this is what imparts the emotion from the music into the actual gameplay.
让我们完全反过来想：我们能从音乐驱动游戏里的什么？哪些东西可以与音乐同步？在动作RPG中，你想知道玩家在做什么——也许你能检测到他们的游戏风格，敌人是在全力进攻还是撤退。音乐也可以向玩家传递那些屏幕上不立即显现的信息。你想在这个叙事场景中传递什么样的情感？据此驱动音乐。从结构角度来说：我们能否思考音乐的动态控制及其结构，以及这如何能告知游戏，从而创造更具电影感或情感的体验？将动画的时间点与音乐中特定的强拍、特定的小节、特定的乐句同步——这就是将情感从音乐注入实际游戏的方式。
[参与者 / Participant]:
One quick anecdote: when I joined [studio], we were looking at firecrackers — designing the final encounter. You'd go into an area, shoot everyone, and when the last enemy died, the music would play a little success stinger. It all comes back to design: you need to ask yourself, "why?" — "what is the purpose, and does it advance the game?" For our game, we set that as a team discussion: do we want this or not? For us, we made the opposite decision. When you shoot the last person, the music actually stays on, because we do not want to reveal that that was the last enemy. So we slowly fade it out over 20-30 seconds. I ended up designing a state graph that knew more about the state of the game and the AI than the game itself did, just from the music's perspective. It all comes down to: we have all these tools that talk to the game designer — but you need to ask "why is the music the way it is in a given moment?" In a multiplayer game, music is very informational. In a single-player game, it's mostly emotional. Start from that angle. And one tip: have someone just record the gameplay and score music over it linearly in a DAW, then reverse-engineer it — "why did what came out in that video work?" — and that gives you a blueprint.
分享一个亲身故事：我加入[工作室]时，我们在设计烟火筒的最终遭遇战。你进入一个区域，射击所有人，当最后一个敌人死亡时，音乐会响起一个小小的胜利片段。一切都回归到设计本身：你需要问自己"为什么"——"目的是什么，这是否推进了游戏？"对于我们的游戏，我们作为团队讨论后做出了相反的决定。当你射杀最后一个人时，音乐实际上继续播放，因为我们不想让玩家知道那是最后一个敌人。所以我们在20-30秒内慢慢淡出。我最终设计了一个状态图，从音乐视角来看，它比游戏本身更了解游戏和AI的状态。一切都归结于：我们有所有这些与游戏设计师沟通的工具——但你需要问"为什么音乐在特定时刻是这样的？"在多人游戏中，音乐非常具有信息性。在单人游戏中，它主要是情感性的。从这个角度出发。一个技巧是：让人录制游戏画面，然后在DAW里线性配乐，再反向工程——"为什么那段视频里的配乐效果这么好？"——这给你一个蓝图。
[参与者 / Participant]:
There's a question that came up: in Triple-A, how often are you given no visual references at all for what you're trying to create sound for, because nothing exists yet? As programmers, we're not always doing visuals. This is a real challenge in the industry.
有一个问题浮现出来：在3A游戏开发中，有多少时候你根本没有任何视觉参考来创作声音，因为画面还不存在？作为程序员，我们并不总是在做有画面的东西。这是行业中真实存在的挑战。
七、如何开始学习音频编程 · Getting Started with Audio Programming
Sam (aspiring audio programmer):
Hi, I'm Sam. I'm a designer/programmer who has yet to figure out how to make those two things fully work together. What's a good way to start learning audio programming?
大家好，我是Sam，一个还没搞清楚如何让设计和编程完美协作的设计/程序员。有什么好的方法可以开始学习音频编程？
[参与者 / Participant]:
The thing I always tell people who ask this question is: game audio programming is just audio programming, and audio programming is just programming. So you learn to program. That said, my books are available. More broadly: learn how to solve problems with code. We're problem solvers first. So learn how to write and solve problems with code, and then bring your own problems as a sound person — "how would I solve this with code?" That's how you learn programming through the lens of audio.
我总是告诉问这个问题的人：游戏音频编程就是音频编程，音频编程就是编程。所以你先学编程。当然，我的书也是可以参考的。更广泛地说：学习如何用代码解决问题。我们首先是问题解决者。所以学习如何用代码写出并解决问题，然后作为音频人带入你自己的问题——"我怎么用代码解决这个？"——这就是通过音频视角学习编程的方法。
[参与者 / Participant]:
My advice: find one little thing that you can box into a condition — "when I reach this point, I can either move on or I've found something interesting." Whether it's a feature, a little demo, or hacking something into an existing game mod — just find something that would be fun, then pick the next one, and the next one, and the next one. The moment you're in a state of approaching a problem, defining it, solving it, and getting it out of the way — that's how you get into a technical mindset. Just do it, even if it's not perfect.
我的建议是：找一件你能把它框定在一个条件里的小事——"当我到达这个点时，我要么可以继续前进，要么发现了有趣的东西。"不管是一个功能、一个小演示，还是往现有游戏Mod里插入一些东西——就找一件有趣的事，然后找下一件，再下一件。一旦你进入了"接近问题、定义它、解决它、然后把它放下"的状态，这就是你进入技术思维的方式。就去做，即使不完美也没关系。
[参与者 / Participant]:
One more thing: since audio programming touches pretty much every game system — physics, effects, and more — the more you can understand how those systems are built from the ground up, the better you can understand how to connect to them and get the parameters you need to drive sound.
还有一点：由于音频编程几乎会触及所有游戏系统——物理、特效等等——你对这些系统从底层如何构建理解得越深，就越能理解如何与它们对接，获取驱动声音所需的参数。
[参与者 / Participant]:
One historical observation: over the decades there have been a number of transformative moments in audio technology. First, having libraries that just play sounds for you was transformative compared to doing everything by hand. Then there came a moment when Wwise appeared and the level of abstraction went up — that was also transformative. And now we're in the GPU era, where the fact that we have access to it is clear, but what we can really do with it — figuring out the right and best ways to use it — that's still being worked out. What you think is possible is still evolving. And on that note, we're out of time.
一个历史性的观察：在过去几十年里，音频技术经历了多个变革性时刻。首先，有一个能帮你播放声音的库就已经是变革，对比之前所有东西都要手工完成。然后出现了一个时刻——Wwise出现了，抽象层级提升了——那也是一次变革。现在我们在GPU时代，我们能访问GPU这件事已经很清楚了，但我们真正能用它做什么——摸清正确的、最佳的使用方式——这仍在探索中。你以为可能的事情仍在不断进化。说到这里，我们的时间到了。