游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

Brad Meyer分享网页及手机游戏声音制作经验

发布时间:2011-06-13 09:33:00 Tags:,,

游戏邦注:本文原作者是Brad Meyer,他曾经是一名掌机游戏声音总监,现在负责手机和网页游戏的声音监制工作。他将以其丰富的专业经验为各位解读手机和网页游戏声音设计所面临的挑战,并解答如何利用工具、团队规模和文件大小来攻克难题,制作出上乘的游戏声音。

过去数年,小型免费游戏呈现爆炸式增长,特别是网页和手机平台。游戏家族现在的欣欣向荣不禁让人回想起早些年的艰苦卓绝:小型新游戏可怜到只能由不过数人组成的小团队来完成制作。

当一些手机和网页游戏推动游戏机制的创新性和独特性进入一个新纪元时,游戏声音制作却跟不上这个亚工业的发展步伐。原因是显而易见的:小预算甚至没预算的小团队,怎可能“奢侈”地供起一个全职声音设计师?更别说作曲家和声音程序员了。另外,网页和手机游戏设计还迫使我们反思如何应对有限的硬盘空间和严格的硬件限制的挑战。

本文旨在阐明这些难题,并提出解决方案,以便升新兴网页及手机游戏的整体声音质量。

music_note_art(from vixstar1314.wordpress.com)

music_note_art(from vixstar1314.wordpress.com)

挑战1:团队规模

团队规模,大概是手机和网页游戏这片领域的新开拓者们普遍面临的挑战。这个领域的游戏制作正在进入转型期(主要是因为预算极小)。100人以上规模的团队正在被十几个人组成的虔诚小开发团队所取代。

结果是,大多数团队摒弃昂贵的专属游戏(和声音)引擎,转向Unity、 Flash,、Unreal、Torque和ShiVa等第三方引擎。

借助这些现成的开发引擎,游戏团队抓住了有利的开端,因为他们没必要白费力气做重复的工作了,单靠为平台量身打造的成套工具就已经能着手制作整个游戏。因为这些小团队,我们看到了更简单的游戏,但也看到了开发过程中的专门化不足、普遍化有余的缺陷。

作为声音开发者,你必须首先成为一把声音制作的“瑞士军刀”——多才多艺。要是让我说一名热忱的声音制作人对小团队的重要性,洋洋洒洒几千字不在话下。不过我还是克制一下这种冲动,言归正传。

大多制作手机和网页游戏的小团队都认为团队无所谓有没有专门的声音制作人,大不了就是外包游戏声音,然后由程序员或者设计师添加到游戏中就好了。如果是制作动画、艺术品或者编写代码,我姑且赞同这种想法。但前提是制作游戏声音,这种结论就不成立了。即使是在最小的制作团队,每个学科也至少需配有一名精通者,以便把好质量关,保证各项工作看起来、做起来、听起来都像那么一回事。

一款游戏若想跻身尖端行列,它在各方面的素质都必须出类拔萃,游戏声音当然也不例外。要想让手机和网页游戏声音与掌机游戏声音在水准上并驾齐驱,必须有人对制作卓越的声音充满热情,并且百分之百投入精力(就如艺术总监要确保图像质量到达预期要求)。

小团队中往往需要一个堪称各个学科的“万事通”存在。整个团队都会因为“万事通”而受益无穷。但要是没有一个专注于声音制作的人,没人有那份心思管理声音制作的工作。

更进一步讲,声音制作人之所以必不可少,是因为有这样的人在,其他部门才有可能专注于各自的任务。动画师可以好好做动画,而声音设计师就把声音添加进去;关卡设计师可以集中精力设计关卡,而声音设计师就把布景音乐穿插进去。多一个专注的声音设计人就等于扩大了团队规模,但同时也提升了整个项目的质量,使其他人能做好各自学科的工作,还能多个人监“听”游戏。

因为团队规模小,声音设计师不可能指望让声音程序员或者声音执行员把他们的声音放进游戏里去,然后就“听起来真棒”。大多数游戏引擎都提供一个控制游戏回放和参数管理的脚本语言。如果你没采用独立声音中间件的解决方案(就算你用了),这些脚本语言也能变成开启天籁之音的钥匙。

不管怎样,我给小公司的声音设计师们的第一个建议是:学习编写脚本语言。一款拥有出色声音的游戏核心就在于绝佳的音效。制作声音的另一个大难题就是如何在游戏引擎中处理声音,答案就是编写脚本语言。

所以,你正在使用的引擎的脚本语言就是最重要的内容。编写脚本语言一个比较好的地方在于,通常大多数编程语言,只要你明白了其中一种流程和语法,其他的也就不在话下了,可谓达到“举一反三”的效果。不幸的是,常用的引擎之间兼容性不足:Unreal使用的是基于UnrealScript的专用Java语言;Flash的JavaScript与ActionScript相关;Unity支持 JavaScript、C#和Boo (Python的衍生物);Torque引擎使用基于TorqueScript的C++语言;ShiVa使用的是Lua语言等等。

所谓万事开头难,学习编写脚本语言也是一样的。我的编写学习之路是一个多阶段的过程:我一开始运气就很好,之前任职的工作室Shaba Games的技术总监Robert Morgan和编程团队给我们上了几堂编写原则的入门课。我还因此知道了C++速成学习的网站,虽然有些不入流,但大约也是最实用最直接的编码和编程基础原理的学习指导吧。

从那时起,我开始阅读参考资料、做演练、看别人编写的脚本语言。我从程序员那里得到了一个非常实用的小窍门,就是修改别人的脚本语言为己用,这与其说是剽窃,倒不如说这就是生存之道。我们稍后要讨论的论坛和在线社区,也是指导和帮助你尝试脚本语言编写的好资源。

编写脚本语言未必人人适用。毕竟让自己的头脑塞满编写的基本概念和特殊功能、语法和特征,也是件费神费时的事。然而,有付出才有收获。你为了控制声音表现而投入到编写脚本语言学习的时间、精力最后都会一一在你的职业生涯中得到回报。掌机游戏中已普遍存在遮蔽音、动态布景音和互动音乐,我们必须有能力做出复杂度与之相当的声音系统,这样才能把网页和手机游戏的档次提升到与掌机游戏相当的水平。而这些复杂的声音系统,大多可以通过在现代游戏引擎中编写脚本语言而实现。

大多数引擎必须编写脚本语言,有些引擎确实提供了用于调整某些参数的图形用户界面的组件。无论这是不是构成声音的工作,处理衰减曲线、甚至编写复杂的视觉脚本语言,这些对声音设计师来说,都是有益的附件,有时还能代替脚本语言。

正如我介绍的那样,让一个声音设计师学会编写脚本语言,然后摇身一变成了一个声音程序师,这显然不可能。对小工室来说,要把声音系统制作到与掌机游戏相当的程度,是天大的挑战,也是个极端的难题。

在信息时代,社交和理念传播的最好最平和的方式就是:社区论坛。大多数引擎供应商都有一个论坛和邮箱列表,可用于协助用户解决共同的难题。我加入了Unity和Unreal的论坛,我不止一次看到互为竞争对手公司的人如何互相排忧解难和共享技术。结果是通过友好的互相帮助和互相竞争,大家的游戏品质都得到提升了。

就声音而言,总是存在这么些人,能帮助你更深入地理解程序和工具的装配。虽然你不能指望这些论坛上有人会帮你编写好一整套系统或代码,但论坛上的人能帮你发现不足和你忽略掉的问题,这还是比较实用的。不过这还关系到你能不能做到不耻下问、耐心求教、主动学习。

无论项目的规模大小,要求一个人要同时管理所有音效、音乐和声音编程,绝对是苛求,这也是承包商存在的原因。一个专注的声音设计师存在,未必意味着你可以指望他完成所有与声音有关的任务。

与其他学科类似,为了保证游戏品质和进度,游戏中的某些部分采用外包通常是必要的。就项目规模来说,外包一部分内容(游戏邦注:如武器的声音、音乐、对话编辑、定位等等)是把好声音质量关的同时保证合理预算的一个有效方法。同时,如果有团队内部本身有个声音设计师,那么制作团队就相当于多了一个人来协调与承包商的关系、提供指导、和容纳、剔除及整合资产。

挑战2:文件大小

网页和手机游戏声音面临的更大的挑战是文件大小。所有数据都要放入一个大小非常有限的空间中,而这个空间容量与蓝光光碟或者DVD相比,简直是小到不能再小了,这就是我们要解决的难题。那么,为了让我们的游戏大热,怎样才能把各种高品质的声音资产塞进这么小的空间里?

数字声音在过去的20年中,最革命性的突破就是高压缩技术和优质编解码器的发明。把PCM文件压缩为原大小的十分之一甚至十五分之一,且没有明显的痕迹和频率响应,这就是高品质游戏声音可以在小平台上实现的原因(甚至掌机游戏声音品质高也是因为这个原因)。

虽然压缩可以把更多、更大的声音文件塞进游戏里,可谓游戏业的奇迹,但大小与品质的取舍问题仍然存在。大部分支持网页和手机平台的游戏引擎使用的压缩格式都是ogg或mp3。

这两种编解码的特点都是,码率越低,品质越差,文件越小。在位深度和文件大小的距阵中,最佳位置点在哪里,这就是声音设计师要计算的问题。

无论如何,浏览器、手机和笔记本可不是我们所说的音乐发烧友5.1系统,所以在没有过度牺牲声音品质的情况下,宁可降低码率还是比较容易的。

如,使用Unity时,我把大部分ogg格式的声音以56千位每秒的采样率转换为14:1的压缩版。这样无论是使用什么扬声器,从丹拿(丹麦举世闻名的扬声器制造品牌)、笔记本到耳机,转换后的声音品质我都尚能接受。

另一个建议是,就ogg和mp3压缩文件的大小来说,立体声特效其实是“不受约束”的。有许多不同压缩声音的方法可以处理立体声道文件,而且这些方法都可以保持文件大小接近或者与单声道文件一样的声长。

在这些压缩格式中,品质最高的立体声文件是联合立体声,它能选择性地压缩,不会产生多余的数据,最大限度地保持立体音效。我喜欢把用户界面的音效设置为立体声道,这样菜单的声音会比较有特点,而且我也不用怕影响到整体的声音轨迹。

有关压缩的另一个重点是,始终保持源文件的最合理采样率。编解码器会自动处理降低采样,所以把一个12kHz的WAV文件压缩到某个码率的,其大小和48Hz的压缩文件没有区别,但只有原文件四分之一的声音数据。压缩前的除低采样会使游戏声音变模糊,所以无论如何都要避免。凭着经验法则,我设计的声音都是48kHz,输入引擎时也是48kHz,让我在引擎中设置的压缩参数来决定声音获得的空间大小。

要在小内存的小平台上做出卓越的声音,另一个重要因素是优化。在整个开发过程中都熟知声音的大小,有助于正确判断优化。像剪掉WAV文件的多余尾声、限制变种或者对低率声音降低码率/品质这类简单的工作,听起来都很普通,但到最后产生的作用可能是“滴水穿石”。

处理手机平台上的循环mp3声音时,还要对压缩和优化做最终的记录。做这种记录可能是大多数声音设计师无尽的挫折感来源,因为你的引擎必须能够补足把声音压缩成mp3格式时产生的采样填料,所以记录量是相当惊人的。

当一个未压缩文件转换成mp3格式时,压缩算法在声音文件中增加采样,才有可能实现无缝循环。许多引擎对此拥有自己的绕行方法(Flash、 Unreal 和Unity 3.2都有,后来所有声音制作编辑软件都有了)。然而,如果你没有意识到你的引擎不支持无缝循环,那么这种逃避的技术可能会很令人沮丧。(游戏邦注:详情请阅读《设计师分享iPhone游戏音效设计准则》)。

流媒体

与掌机游戏类似,如果我们想要在小游戏中加入更长的声音,如音乐、对话或者长背景音,我们需要运用流媒体技术。流媒体技术曾经与掌机、电脑(硬驱、CD-ROM/DVD/光盘等)的实体媒体相分离。而现在,除了我们的常用流媒体来源是实质媒体(游戏邦注:电脑硬驱和SD卡或者其他可移动存储设备)和网络,我们仍然沿用旧的研究方法。

说到什么声音适合流媒体技术时,有几个因素要考虑到。最重要的可能是,我们从哪里“流”?从实质媒体上“流”,就时间而言,比从网络更快(如果算上网络延迟的话),就流量而言,也比网络更稳定(因为网络交通比设备与存储介质之间的交通更容易被中断)。在线游戏可能还要与网络和媒体流争带宽。如果网络突然暂停,媒体流就会被中止,或者不能及时缓冲。

另外,从网上“流”允许游戏的初期(或短增量)下载,也允许通过下载声音文件和修补单个脚本文件,小整量和动态地升级、修改内容,而不需要添加整个声音压缩文件或者程序包文件。

有些引擎甚至允许运用多重流媒体技术。开放复杂的多重流媒体技术,动态对话、环绕布景音、互动/动态音乐等的同时进行就有了实现的可能。总而言之,网上流媒体更灵活,本地流媒体更稳定。

“流”可能是一个复杂的脚本事件,也可能是一个取决于你想怎么“流”、流什么的问题。如果你比较一下从光盘和从网络“流”,你会发现,方法往往是不同的,并且有些引擎只支持其中一种。

所以,从时间、渠道和内容上为流媒体技术做好准备吧。最明智的“流”方式和“流”内容的决定权在你手上。无论如何,流媒体技术可能是一个展现优秀长声音的绝佳方法,除此之外别无他法。

调制

充分利用手机或网页平台的声音的方式是,发挥创造力。此法显然非常重要,但就是因为太显而易见了,所以往往更容易被忽略。

早期的声音设计师已经制作了非常不可思议的音效阵列和音乐工具,虽然只是一些方波和噪音发生器。

多年以来,我们已经提炼出玩家的喜好和期望,并且现在有了更多的工具、更强的能力,但我们仍然必须发挥自己的聪明才智,想出使声音更有趣、更先进、更有效的方法。

处理手机和网页平台上的循环声音时,我们通常需要更加注意文件大小。调制则是保证允分利用小循环文件的万无一失的方法。必要的调制才能使这些文件的形成和不断改变不会失真和引起反感。

调制声音的方法各不相同,用什么方法取决于你所使用的引擎。有些引擎允许你通过工具组调制声音。如你可以在Unreal中创建带振荡模块的声音提示,这样就能一直修改音高、音量了。(图1)

图1

图1

在Unity中,你可以不断运用动画组件来调整音量、音高、低频滤波器和几乎所有的其他参数。(图2)

图2

图2

虽然威力巨大,但缺点也不是没有的——调制意味着统一,所以每次播放的结果都是一样的。如果你的引擎不提供调制声音的工具,或者你自己想要更好地控制声音调制,你可以自己编写调制的脚本语言。

我已经用C#语言写脚本语言,这样在Unity上就能调制音量、音高和低频过滤了。这些工作使我能够更好地控制调整装置和随机调制各个循环、各个播放,从而使声音不断生成。

虽然大部分引擎都支持一些形式或者通过编写脚本语言的方法来调制声音,但为了简明扼要,我就不再探讨其他引擎的支持的调制方法和效果了。事实上,一个颇有首创精神的仁兄已经在Flash上用ActionScript语言编写了一些过滤器和效果,还把这些资源代码放在网上共享。

还有一件重要的事要记住,当添加调制到声音上时,调制量务必小些。小量调制的作用已经很明显了,而大量调制只会把玩家的注意力吸引到声音的变化上,这是设计师在从小循环声音开始制作动态生成声音时要避免的。

在此有一个例子。Free Range Game即将发布的网页游戏《Freefall》中有一个核反应堆活性区的场景音,是在Unity上实时播放。在影像的第一小节,只有两个声音版本在游戏世界中以不同的音高播放。第二个版本和调制过音量和音高的设计完全一样。你可以发现,两个版本的差别是巨大的。此外,你可以在第一个版本中听到重复的部分,但第二个版本在循环以前继续演化了几分钟。

风格和审美

在保证文件大小不超标又能提升设计品质的最后一个方法是,风格设计。以团队开发的游戏类型、艺术风格或者预期的玩家体验为基础,声音设计师可以选择移除或增加某些电子游戏的修辞,这样可以提升游戏的美感和优化声音轨迹。运用技术来塑造合理、不唐突又有沉浸感的听觉氛围,是声音设计中的关键环节。

然而,想在小平台上创造高品质的声音,就要在淘态冗余的同时,创意地运用声音设计来放大情绪和游戏基调。这一点显得更为重要。

dungeon crawler这类游戏中真的需要脚步声吗?有人听到背景音乐在循环吗?用点源来触发一次性事件会不会更好?如果轨道空间射击游戏真的全是关于以有趣的方式炸毁敌人,那你是不是应该关注声音而不是玩家的轮船引擎?从我们播放声音的方式和我们选择加入音效的游戏元素,就可以看出一款游戏声音的最终品质。

有了强悍的设计师、卓越的声音和可靠的工具组,在任何平台推出令人惊艳的声音游戏就不再是幻想。Unity正在开发适用于手机和网页游戏的工具;Flash的Molehill 3D API也即将问世;Unreal甚至也支持iOS和Android。

这无疑是为盼望制做出高品质网页和手机游戏声音的小型开发者带来巨大恩惠。通过编写脚本语言、发挥个人的独创性和强力平衡压缩量与声音品质之间的矛盾,总有一天,我们会为浏览器、笔记本或者手机扬声器中所发出的声音所震撼(并且其他人也不会再摁下静音键了)。(本文为游戏邦/gamerboom.com编译,如需转载请联系:游戏邦

AAA-Lite Audio: Design Challenges And Methodologies To Bring Console-Quality Audio To Browser And Mobile Games

by Brad Meyer

[In this feature, former console audio director turned mobile and browser director Brad Meyer explains what challenges are presented by these constrained platforms -- and how to get the best results with the tools, budget, and staff size that's required by them.]

The past couple of years have seen an explosion in small, free-to-play games, primarily on the web and mobile platforms. These games’ pedigree is reminiscent of the early years of video gaming: smaller, innovative titles made by very small teams, often no more than a few people.

While we have seen some of these titles push gameplay mechanics into new and unique realms, the audio in this burgeoning new sub-industry is not quite keeping up with the innovation. The reasons are understandable: small teams with little or no budget rarely have room for the “luxury” of a full-time sound designer, let alone a composer or audio programmer. Also, designing games for the web and mobile platforms brings us back to the challenges of dealing with very finite disk space and more severe hardware limitations.

This article aims to address these issues and present ways to overcome them in order to boost overall audio quality in the growing browser and mobile gaming markets.

Challenge 1: Team Size

Perhaps the most ubiquitous challenge facing new developers in the mobile and browser realm is team size. Gaming is entering into a cycle of rebirth in these fields (thanks mostly to minuscule budgets). 100+ size teams are being replaced with a couple dozen, or fewer, dedicated developers.

As a result, most teams forgo costly proprietary game (and audio) engines in favor of a third party engine such as Unity, Flash, Unreal, Torque, or ShiVa.

Relying on these existing engines gives teams a head start, in that they do not have to reinvent the wheel and can start building a game with a toolset already tailored for their platform(s) of choice. With smaller teams, we see simpler games, but also less specialization and greater generalization in tasks.

As an audio developer, you must therefore become the Swiss Army Knife of all things audio. While I could rant for several thousand words about the importance of a dedicated audio person on even the smallest team, let me be brief so I can get off the soapbox and back to making sounds.

Most small teams working on mobile and browser games believe that they do not need a dedicated audio person on the team. They can outsource some sound effects and have a programmer or designer put them in. I would agree if the same were done with animation, art, and code. However, in even the smallest teams, there is at least one person from each discipline in-house to ensure the quality bar is being met and things are looking/behaving/sounding as they should.

If a game wants to be of the highest quality, then it must shine in all areas, including audio. For audio quality to catch up to consoles, someone must be involved in the oversight of all aspects of audio for a project. This individual must be passionate about good audio and devote all his/her energy to it (just as an art director ensures the graphical quality of the game meets expectations).

A jack-of-all-trades in each discipline is often necessary on a small team, and while it requires a huge skill set, it helps the team tremendously. Without a dedicated sound person no one would have the appropriate bandwidth to keep an ear and eye on audio.

Furthermore, a sound person can make him or herself indispensable by allowing other departments to focus solely on their own tasks. Animators can focus on animating and the sound designer can place animation event sounds. Level designers can focus on building the level while the sound designer hooks up the ambience, level event sounds, etc. A dedicated audio person may expand team size, but s/he will also increase quality of the entire project, allow others to focus on their respective disciplines, and keep a necessary ear in production. Okay, sermon over. On to the sound!

Due to smaller team sizes, sound designers cannot necessarily rely on having an audio programmer or audio implementer putting their sounds into the game and getting everything sounding great. Most game engines provide a scripting language for control over in-game playback and parameter control. If you are not using a separate audio middleware solution (and often if you are), these languages will be one of the main keys to getting your game’s sound to shine.

So for better or worse, one of the first tips I have for a sound designer in a small company is to learn scripting. The most important part of a great sounding-game is creating great sound effects. The other big piece of that puzzle is how the sounds are handled within the game engine, and control over this is most often through scripting.

Naturally the scripting language of the engine you are using will be most important to you, but the beauty of scripting, and most programming languages in general, is once you understand the flow and syntax of one it’s relatively easy to pick up others. Unfortunately there is not a lot of commonality across popular engines: Unreal uses proprietary Java based UnrealScript. Flash has JavaScript related ActionScript. Unity supports JavaScript, C#, and Boo (an offshoot of Python). The Torque engine uses a C++ based language called TorqueScript. ShiVa uses Lua, etc., etc.

The hardest part about learning a scripting language is getting started. I learned scripting in a multi-stage process: I was fortunate enough at my previous studio, Shaba Games, to have our technical director, Robert Morgan, and the programming team give classes to designers to help them get familiar with basic scripting principles. He also pointed me to this website: Pinky and Brain learn C++, which, cheesiness aside, is probably the most helpful, straightforward guide to teaching basic scripting and programming fundamentals.

From there, it became a matter of reading reference materials, experimenting, and looking at other people’s code. A very helpful tidbit I learned from programmers early on is that using someone else’s code and tailoring it to your needs is not so much stealing as a way of life. Forums and online communities, which we will discuss later, are also a great resource for direction and help when getting your feet wet in the world of scripting.

Scripting is not for everyone. It takes dedication and time to wrap your head around the concepts of basic scripting and then the unique functions, syntax, and idiosyncrasies of whatever scripting language your game engine may use. However, the time and energy invested in learning how to control your sounds’ behavior will pay back dividends throughout the rest of your career. We need to be able to create complex audio systems such as occlusion, dynamic ambience, and interactive music that are common in consoles and can push online and mobile game audio to the same level. All of these systems can be created via script in most modern game engines.

While scripting is inherently necessary in most engines, some do offer GUI components for tweaking certain parameters. Whether it’s building sound behaviors, setting attenuation curves, or even doing complex visual scripting such as Kismet in Unreal, these are welcome additions to the sound designer and can occasionally replace the need for scripting.

As I briefly insinuated, it would be unfair to expect a sound designer to pick up scripting and suddenly be an audio programmer. This is a huge challenge for smaller studios, and a potentially tremendous difficulty in building an audio system with features one would expect on a console.

Enter one of the most beautiful, populist means of social interaction and idea dissemination in the information age: the community forum. Most engine providers support a forum or email list designed to help users solve problems collectively. Having been involved in both Unity and Unreal’s forums, I have repeatedly seen people from competing companies help each other solve problems and share techniques. The end result is that everyone’s game is improved through friendly cross-corporate cooperative spirit.

In regards to audio, there are people out there who can help provide insight into setting up scripts or tools to do what you need. You should never approach these forums expecting someone to write an entire system or script for you, but participants can be very helpful in pointing out issues you may have or problems you may have overlooked. It is usually just a matter of asking around, being patient, and learning from your colleagues.

One person being in charge of all sound effects, music, and audio programming is a tall order, no matter the scope of the project, which is why contractors were invented. Having a dedicated audio designer does not necessarily mean you can expect them to handle every task related to audio.

Just like other disciplines, it is often necessary to outsource certain elements of a game to maintain quality and make deadlines. In the scope of the project, outsourcing a component (be it weapons sounds, music, dialogue editing, localization, etc.) can be an efficient means of raising the sound quality bar while keeping costs reasonable. At the same time, having an internal audio designer gives the team someone to manage the relationship with the contractor(s), provide direction, and accept, reject and integrate assets.

Challenge 2: File Size

An even greater challenge for pushing the audio envelope of browser and mobile games is file size. In these titles we are dealing with a very finite amount of space in which all data must reside; an amount that is minuscule compared to a Blu-ray, or even a DVD. So how do we pile on the variations and high quality assets that will make our game pop and sound great given this limitation?

Perhaps the single most revolutionary breakthrough in digital audio in the past 20 years was the invention of high compression, high quality codecs. Being able to compress a PCM file to one tenth or one fifteenth its normal size without noticeable artifacting and acceptable frequency response is really what makes console quality audio possible on smaller platforms (and even consoles for that matter!)

While compression is a modern miracle for cramming sounds into your game, it is still a matter of weighing quantity versus quality. Most game engines with support for browser and mobile platforms use either ogg or mp3 as the compression format of choice.

In both of these codecs, the lower the bitrate, the lower the quality and the smaller the file. It is the sound designer’s job to figure out where that sweet spot is on the bit depth/file size matrix for their sounds.

For better or worse, when dealing with browsers, cell phones, and tablets we are not talking about audiophile 5.1 systems, so it is a bit easier to err on the side of lower bitrates without overly compromising sound quality.

For example, in Unity, I compress most of my sounds at 56kbps ogg (roughly quality 0) which translates to 14:1 compression and gives me acceptable quality on every set of speakers I’ve played through, from Dynaudios, to laptop speakers, to headphones.

Another tip to remember when dealing with ogg and mp3 compression is that from a file size perspective, stereo sfx are virtually “free.” There are a couple different ways compressed audio handles stereo files, all of which keep the file size very close if not identical to a mono file of the same length.

The best quality stereo files in these compressed formats are Joint Stereo, which is a means for the codec to selectively compress in a way that maximizes the stereo effects of the sound without reproducing extraneous data. I like to use stereo sounds for my UI sound effects to give menus a bit more audio character, and am able to do so without fear of weighing down the overall audio footprint.

Another important point in regards to compression is to always keep your source files at the highest possible sampling rate. These codecs handle downsampling themselves, so a 12kHz WAV file compressed to a specific bitrate will be the same size as a 48Hz file post-compression, but with one quarter of the sonic data.

Downsampling before compressing is a sure fire way to make your game sound muddy and should be avoided at all costs. As a rule of thumb, I design all sounds at 48kHz and import them into the engine at this rate, letting the compression parameters I set within the engine dictate how small my sounds will get.

Optimization is another very important factor when it comes to making great sounds for smaller platforms with smaller memory allotments. Being cognizant of file size throughout development can help you be judicious in your optimizations. Simple tasks like cutting unnecessary tails from your wave files, limiting variations, or reducing the bitrate/quality for lower frequency sounds all seem mundane, but can make a cumulative difference in the end.

A final note should be made in regards to compression and optimization when dealing with looping mp3 sounds on mobile platforms. This can be a source of endless frustration for most sound designers in that your engine MUST be capable of compensating for the sample padding generated as a result of compressing to mp3.

When an uncompressed file is converted to mp3, the compression algorithm adds samples to the sound file which make seamless loops impossible. Many engines offer their own way to circumvent this issue (Flash, Unreal and Unity 3.2 and later all do.) However, it can be a very frustrating technical hurdle to get around if you are not aware of it and your engine does not support gapless looping. For more information on this issue see PJ Belcher’s article on iOS Audio Design.

Streaming

Similar to consoles, if we want to get longer sounds, such as music, dialog or long ambiences playing in our smaller games, we need to stream them. Streaming has historically been off the physical media of a console or PC (hard drive, CD-ROM/DVD/console disc, etc.). We still use the same methodology, except now our common sources to stream from are either the physical media (a hard drive on PC and SD-cards or other removable memory sources on mobile devices) or from the internet.

When thinking about what sounds are appropriate to stream, there are several factors to consider. Perhaps most importantly is, where are we streaming from? Streaming from physical media is quicker as far as response time if latency is a concern, and also significantly more stable since network traffic can be disrupted much easier than the communication between a device and its storage medium. Online games can fight for bandwidth with both networking and streaming going on. Streams can drop if there’s a network hiccup, or not buffer in time to begin when they need to.

On the other hand, streaming from the internet allows for a smaller initial (or shorter incremental) download of your game. It also allows a smaller overall footprint and the potential ability to dynamically update or alter content by uploading audio files to the internet and patching a single script rather than needing to append whole compressed audio files or package files.

Some engines even allow for multiple streams to play simultaneously opening up the possibility of sophisticated multi-stream scenarios for dynamic dialogue, surround ambience, interactive/dynamic music or other creative uses. In short, you have much greater flexibility with online streams, but greater stability from local streams.

Streaming can be a complicated scripting affair or a matter of checking a box depending on how you want to stream and what options your engine offers. The methodology often differs if you will be streaming from disc versus from the internet, and some engines only offer one solution or the other.

There is a time and a place and special content ripe for streaming. It is up to you to decide the most prudent way to stream and what content should be streamed.

Regardless, streaming can be an excellent means to showcase long dramatic sounds in your game that would not otherwise be possible.

Modulation

A very important and so-obvious-it’s-easy-to-overlook way to get the most out of sound on a mobile or web platform is to be creative.

Early sound designers were making an unbelievable array of sound effects and musical instruments with nothing but square waves and noise generators.

While we have refined consumers’ tastes and expectations over the years and have more tools and capabilities now, we must still use our brains to figure out ways to make sounds interesting, evolving, and efficient.

When dealing with looping sounds on mobile and web platforms, we often need to err on the side of smaller file size. Modulation is a surefire way to get the most out of small looping files so that they evolve and change over time without getting stale or annoying.

There are a couple different methods used to modulate sounds depending on the engine you are using. Some engines give you means to modulate sounds via their toolset.

For example, in Unreal you can build a SoundCue with an oscillator module to change the pitch and/or volume over time (Figure 1).

In Unity, you can use an animation component to modulate volume, pitch, pan, low pass filter, or pretty much any other parameter over time (Figure 2).

While vastly powerful, the drawback of these methods is that the modulation is uniform; therefore it will always be the same every playback. If your engine does not provide a tool to modulate sound or you want more control over modulation, you can create modulation in script.

I have written scripts in C# for Unity to provide for modulation of volume, pitch, and a low pass filter. Doing so gives me far greater control over the modulation control and also allows me to randomize the modulation each cycle or each playback to keep the sound continually evolving.

For the sake of brevity, I have not discussed what other engines offer in terms of modulation and effects, although most can support modulation in some form or another via scripting. In fact, one enterprising developer has written some filters and effects in ActionScript for Flash and posted the source code online.

One thing that is crucial to remember when adding modulation to your sounds is to be subtle in the amount of modulation you add. A little goes a long way and adding too much will draw the player’s attention to the changes in sound, which is what you are trying to avoid when creating dynamic evolving sounds from small loops.

Here is an example of a Reactor Core ambience from Free Range Games’ forthcoming browser game Freefall, played back in realtime in Unity. The first clip in the movie is just two versions of the sound playing at different pitches in the game world. The second version is the exact same layout using modulation curves on both volume and pitch. As you can hear, the difference is drastic. Furthermore, while you can hear the repetition in the first example, the second example continues to evolve for several minutes before looping. You can watch this movie by clicking here.

Style and Aesthetic

A final means which can improve your design while keeping file size down is through stylistic design choices. Based on the type of game your team is developing, the art style or the intended user experience, the sound designer can choose to remove or augment certain video game tropes for the sake of the game’s aesthetic and for optimization of the sound footprint. It is essential in all sound design to use your skills to shape the aural atmosphere in a way that makes sense, is unobtrusive and immersive.

However, when trying to create consol-quality audio on a smaller platform it becomes even more important to use your sound design creatively to augment the mood and tone of the game while culling the fat of unnecessary sounds.

Are footsteps really necessary in your dungeon crawler? Will anyone hear that background ambient loop, or is it a better idea to use point source triggered one-shots?

If your on-rails space shooter is really all about fun ways to blow up enemies, maybe you should focus on those sounds rather than the player’s ship’s engines? The way we playback sound and the elements of the game we choose to sonify in the end will inform the final quality of the game’s audio.

With a great designer, great sounds, and a solid toolset, amazing sounding games can exist on any platform. Tools available for mobile and web games are exploding with Unity, Flash’s forthcoming Molehill 3D API, and even Unreal on iOS and Android.

This is a boon for smaller game developers looking to create console quality experiences in the browser or phone. Through the use of scripting, ingenuity, and aggressively balancing compression quality and sound needs, we can approach parity where one day soon the audio you hear coming out of your browser window or tablet or phone speakers will blow you away (and ideally keep people from pressing the mute button).(source:gamasutra


上一篇:

下一篇: