游戏邦注：本文原作者是Vector Unit开发者Matt Small，主要讲述XBLA游戏《Hydro Thunder Hurricane》化身《激流快艇》成功移植到Android平台的相关经验。

2010年六月，Vector Unit开发团队度过了一段既惊又喜的时光。我们刚刚结束第一款游戏《Hydro Thunder Hurricane》的开发工作，时间和预算上都做好准备了，就等着在XBLA梦寐以求的游戏夏季展（Summer of Arcade ）华丽亮相了。早期的评论不错，销售预测表明，不到年底，我们就能收回版税了。

通过发布《Hydro Thunder Hurricane》的DLC（可下载内容），我们仍然有一点收入——这足够我和一个合约美工维持一整个夏天的工作了。因为接下来的工作不太需要程序方面的配合，所以我的合伙人Ralf Knoesel和首席程序师都去接EA Visceral的《Dead Space 2》的单子了，与此同时，我们继续向微软和其他发行商推广其他新项目。

我们有些非常了不起的新游戏概念，我们认为有朝一日必定会有伯乐相中，虽然我们的想法相当天真，但从来没有失败。一方面，在发行商的观念里，我们是就是搞“竞速游戏的工作室”，但最近的竞速类游戏已是多不可胜数，这类新游戏的市场需求并不大。

《Hydro Thunder Hurricane》发布于七月份，获得评论一面倒的好评，并大受玩家欢迎。按一般的XBLA标准来衡量，销售成绩相当喜人，虽然没有像我们期望的那么好。看来，短期内自己凑齐下一款游戏所需的资金还不太可能，或者至少没那么快。十月份，我完成了《Tempest Pack》的工作，Ralf和EA的合约还没完，而我们眼下也没有明确的新项目计划，我们的下一步要走向何方成了一个紧迫的问题。

十一月初，我们接到来自NVIDIA的一个令人惊喜的电话。这家芯片制造商打算携带其双核Tegra 2处理器进军Android手机和平板电脑市场，而现在它正在物色能够展现其新硬件能力的游戏。NVIDIA公司里的人玩过我们的《Hydro Thunder Hurricane》后，想知道我们能否做出和那款游戏差不多水准的手机游戏。

这个项目确实出乎我们的意料，难度真大。我们双方都没涉足过手机游戏。我们也不清楚Tegra 2是不是真有能力，或者说，它有没有可能实现360平台上的水上运动效果。此外，预算很紧张——我们不得不在开发费用上四处筹资，补缺补漏；日程安排也是颇有挑战性——二月份要上初版，五月就出成品。

比较令人欣喜的一面是，我们已经打算将自己的引擎移植到Android平台，这正是一个我们开发首款针对高端平板电脑和手机游戏的大好机会。挑战虽大，但意义不凡。总之，工作就是工作。

所以整个十二月我们都用来敲定项目条款。在NVIDIA的帮助之下，我们成功地凑足资金。对工作已经胸有成竹了，我们就给自己放了一点假。20011年二月出头，我们一头扎进工作室的第二个游戏项目——未来派摩托艇竞速游戏《激游快艇》。

成功经验

1、立足于《Hurricane》的基础

如果没有《Hurricane》，我们断然不可能按时交付《激流快艇》。

Vector Unit拥有所有用于开发《Vector Unit》的技术，所以二月初我们着手制作《激流快艇》时，借助现成的全功能、跨平台的引擎，我们可以直接进行在PC上开发内容，同时，Ralf就把低级部分移值到Android的NDK上。

当我开始制作第一个垂直切片的原型时，Ralf很快就发现，Tegra 2的CPU完全胜任与《Hurricane》中相当的流体动力模拟。他可以把为360平台编写的所有水、波和子弹的物理代码移植过去，只需要小小调整或完全不必调整。这不是说，代码方面我们就没有什么困难了（游戏邦注：详见下文的“失败教训”这一环节）。但总的来说，我们在《Hurricane》跨平台基础上的付出有所回报了，移植Android平台的过程相当顺利。

两年的水上竞速游戏设计经验和教训使我们受益匪浅。我们知道，打一开始，我就会遇到许多能做和不能做的东西，还有些我们想改变的东西。

例如，我们从未自满于《Hurricane》的水体模拟技术——它确实太逼真了。当你看到高速的海上竞速，快艇却不会陷进水中——在100英里/时的速度下，水面就像沥青铺成的路一样硬实。但在游戏里，玩家希望体验到的是那种柔软的感觉。

在《Hurricane》中，我们一开始使用的是现实水体模拟，再用逆向工程技术软化水体，这样快艇就会稍微陷进水中。至于《激流快艇》，Ralf 深入模拟水基，调整了下面的浮力和阻力运算，这样，水体的感觉就会更舒适、更柔和，同时仍然保有真实水体运动的特点。

如果我们从头开始，不足五个月的开发周期根本不容许我们搞研究和反复测试。我们选取了《Hurricane》中的精华，剔除了不适用的部分，水上竞速游戏的玩家将在《激流快艇》中获得《Hurricane》所具有的完美体验。

2.严格的设计规范

我们带着四个相当明确的根本目标着手《激流快艇》的开发工作。

首先，作为Tegra 2的展品，无论是技术还是画面，必须让人印象深刻。第二，它针对的是手机平台，所以它必须具备易用、易运转的游戏机制和简短的（2到3分钟）的体验时间等特点。

第三，我们希望游戏俱有足够的重玩价值来支撑其“物有所值”的价格——这并非因为我们有对付免费模式或99美分低价竞争的法宝，而是因为我们认为，市场上使用这种高端新设备的用户还不够多。

最后当然就是，我们必须能够以二人之力、四个月半的时间完成游戏……主要是因为我们希望自己的作品能成为新平台游戏中的一员。我们的第二个目标——简单、简洁——与紧张的日程安排配合得天衣无缝。但要保证画面达到掌机游戏的水平，同时控制开发时间，这确实是个挑战。为了制作足够的内容，特别是场景，我们得模块化所有工作，尽可能地引用和重复利用图形和材质。

这种重复利用使我们的程序包大大“瘦身”；最终我们成品大小没有超出谷歌的50MB上限，并且不需要下载额外的数据，游戏的下载速度非常快，所以连下载进度条都省掉了。

在我们最初的设计说明和创意开发阶段，我们狠下心抛弃了所有可能偏离核心目标的元素。有许多元素其实还是很不错的——在线多人模式、自定义角色和工具等全都被弃置一旁。

关注核心游戏玩法，加快了我们的开发进度。大约二个月以后，游戏完成了，操作上非常过瘾，但整体体验仍然略显单薄，所以我们决定重新引入之前剪掉的机制。通过空中组合特技这种新功能，可以让玩法获得更理想的效果。

特技给游戏增加了额外的乐趣。动作特技乐趣十足，同时增加了这款游戏原来缺失的冒险感。

3、上手快

《激流快艇》是我们从事了数年的掌机游戏开发后，第一次设计和制作的手机游戏。我们不想把游戏做成休闲派，但我们觉得这款游戏在难度和控制机制上应该更适合休闲玩家。

掌机上的竞技游戏，甚至是如《Hydro Thunder Hurricane》这样的街机竞技游戏，往往在技术上颇有挑战性。大多乐趣和奖励都来自对工具的熟练操作、物理的精通、速度的谨慎控制以及在不同的拐角和轨距之中挑选理想的赛道。另一方面，手机竞速游戏的普遍问题是，加速器启动和自动加速确实不能达到严苛的完美状态。

我们没有这些不足上挣扎，而是坦然的接受现实。我们的交通工具和轨道布局设计都满足全速驾驶，只有玩家跑错拐角了才会刹车。我们希望让玩家感受到游戏的快速和流畅，另外，我们留心地设计了Wipeout系列的赛道布局——基本没有不规则或死角来“陷害”玩家——撞墙后，玩家会减速，但还是可以继续前进。

结果，《激流快艇》当然非常容易上手和操作。玩家在大部分赛道上都可以让游戏自己运行下去——虽然只能得最后一名，但毕竟是完成比赛啦。深度和挑战来自学习在拐角的加速、水波的阻力、其他选手的追尾和掌握特技表演的时机。

起先，我很担心游戏太过简单。但我们把游戏拿给周围的朋友做三个难度级别的测试，我们发现， 这款游戏既适合休闲玩家，也不排斥硬核玩家，总之，休闲玩家不感到受挫，硬核玩家也不觉得无趣。

4、专注

跳上Tegra 2这班列车对我们来说是一个绝好的机会。从产品的角度来看，这意味着我们更容易管理项目。在iOS平台，你必须保证硬件和软件更新的一致性，而硬件和操作系统的分裂性对Android开发者来说确实是一个严峻的考验。

出于对Tegra的“情有独钟”，我们始终保持表现和技术标准的一致性。因为大多数社备是新的，所以我们只需担心一些Android操作系统的不同版本。一致性大大简化了我们适应性测试要求……太好了，因为我们本来就没有多少时间搞这些。

另外，因为我们专注于这个平台，得到了NVIDIA的鼎力相助。这家公司给我们提供了开发硬件和即将发布的设备作测试。它的技术小组帮我们评估程序，然后给出关键的优化反馈。它的营销小组将我们引见给许多分销商和生产新设备的制造商，它们当然也在寻找能够丰富产品的新游戏。他们的支持给我们制造了许多必要的曝光机会。

5、收益分成

好吧，我们都知道这个，但我还是要说：传统的游戏赢利模式，即由发行商垫上扣了版税的款，真的不是很妙！

制作《激流快艇》时，我们得到的最大的好处就是，绕过传统模式，成功地为游戏集资——我们自己的资金加上第三方投资。正如我在介绍中提到的那样，NVIDIA帮了我们一把。这家公司把我们介绍给Flashman融资公司，这是一家位于旧金山，帮助小工作室集资开发的公司。Flashman同意垫付一笔我们需要的资金，并以分享收益作交换；我们自己拉到其他投资金，补差补漏。

这笔生意让我们收获了两大好处。一是我们保住了自己的原创所有权，这意味着，经过短暂的Tegra“专属期”后，我们可以把游戏放到任何我们想放的平台。

第二个更棒的地方是，我们和其他投资者共享游戏的收益。传统的发行商模式，扣除开发商的版税后的初期投资收回本前，开发者别指望捞回自己的那一份子。等到有收益时，发行商获的利润比他们的最初投资还要高几倍。而在收益分享的模式下，所有投资者——包括我们，都可以根据我们各自的投资水平，从第一天起就一直共享收益。

失败教训

1、移植引擎的失误

二月的头几周，也就是我们把Vector引擎移植到Tegra 2开发硬件上的时候，遇到了点小麻烦。

我们已经签约要给 NVIDIA交付一份内部演示样片，且那份演示样片将在二月初的MWC上展出。在真实预演方面，我们不知道能对硬件能抱什么期望，但我们确实抱了很大的希望。我们没有完成的就是纸质说明和NVIDIA及之前采用过Tegra 2的开发者称其能在手机上实现“掌机游戏品质”的豪言壮语。

好吧，尽管新硬件的宣言确实是真的，但事实有点儿复杂。正如之前我所说的，把我们的360/PC跨平台引擎移植到Android NDK上很顺利。直到第二周底， Ralf升级了我的粗糙原型，并且放到Tegra 2开发工具箱上运行，从某些方面讲， Tegra 2硬件的表现超过了我们的期望。

CPU太强大了——它不但能容纳我们的水体模拟器和液体计算器，我们的Bullet Physics，还有我的高聚模型，甚至还余下大量可用空间。

但GPU却是另一回事。 我们被填充率害死了，几乎半个屏幕都让透明的水体大网格霸占了，真是很棘手的问题。我们很快意识到复杂的像素着色器只“衷情”于360，根本不许我们使用高速竞速游戏所需的帧率。

我们改进了着色器，把所有”per-pixel“换成”per-vertex“（游戏邦注：着色程序中的一种优化方式） 、然后在所有可能的地方转换低精度的运算器。我们把水平上的正常映射波纹丢掉，增加了网格的密度以保持我们需要的打破反射时的复杂度。我抛开自己的老式美术技术，把光打到顶点色上，在扩散材质上绘制光的细节，严格管理纹理和网格参数以保证GPU管道尽可能呈开启状态。

NVIDIA在整个过程中都在表现分析方面给予大力支持。最后，我们总算把第一个游戏MWC演示样品交付出去了，至于画面的质量，从不太专业的角度看，确实能和现代PC或掌机游戏相媲美了。手机平台的技术发展速度相当惊人，我认为数年之后，即使内行玩家也很难辨别某张截图是出自高端掌机还是手机游戏。

2、创意的再利用

一开始， 我们知道内容创意是开发《激流快艇》的重要路子。不像代码，我们已经大胆地照搬，但我们不能重复利用《Hurricane》中的任何内容了（游戏邦注：例如模式、纹理库等等），所以我们只能从头开始。

当我第一次分解我那4.5个月的美术日程表时，它看起来相当吓人。大约4周制作摩托艇、角色和动画，10周制作场景，5周处理其他东西，如UI、微粒特效、润色和优化及所有不可预测的东西。场景制作的日程安排是最紧张的。平均算来，我有大约6到7天的时间来完成六个主要赛道中的一条，还要分配另外一两天来制作各个相反的变体，因为我想每条赛道在独一无二的光照和水纹条件下，至少得有一点点不同吧。

唯一可行的解决办法就是，老老实实重复利用和实例化，一定程度上，我做到了——赛道是根据实例片段制作的，我找尽一切机会在赛道上重复利用和循环利用纹理和几何图案。但我忍不住要把每条赛道都做得独一无二，所以我并没有把现成的东西全部重复利用。

最终，我还是按老方法完成了，尽管着实下了一番苦功，费了老长的时间。但我不太在意——这是一份有创意的工作，我前面说过了，我们就是要尽心尽力地做高质量的游戏。在《激流快艇》发布的前一天晚上，我还在润色和调整游戏的细节。当我们最终按下发布键时，我这才长长地舒了一口气。

3、小团队的挑战

我们不打算两个人完成制作《激流快艇》的重任。我曾想过我可能会在一两个月内结束美工外包合约，然后我们就有了些预算均给声音设计和音效制作。

但因为我们是自己掏腰包出了部分制作《激流快艇》的费用，所以我们控制低成本方面的欲望非常强大。也因为我们的日程安排太紧凑，我们觉得我们也没办法均时间给外包工作。

所以我们全速前进。我的日程表从头到尾塞满了美工任务。但结果是， 自完成图形引擎的优化后，Ralf的编程日程表开始松动了。所以他接手了大量混杂的内容任务，包括声音设计和音乐策划（我们在资源网站如Audiomicro上外包了大部分音乐任务）、画面流程脚本，甚至部分微粒特效。

小团队总是会遇到各种麻烦。如，我们这个非常小、非常小的团队，其实连测试参数的房间都没有。在项目的一开始，我们冲刺般地工作了3周，然后是2周，最后的1周，最后的最后，我们彻底抛弃了一头猛冲的工作方式，只是跟着优先任务列表走，尽可能地挤时间。虽然困难，但这是一项有创意、有收获的工作，我们不知怎么地就按时完成了。但整个过程并不总是那么精彩。

4、盗版问题

盗版在手机平台是个没人喜欢谈的问题。对于平台持有者来说，这有点令人难堪，我认为大多数开发商最喜欢的就是曝光这个问题。但盗版是个很实在的问题，特别是对于像《激流快艇》这种基本上是通过付费销售而不是靠IAP赢利的游戏。

我们采纳了谷歌的建议，安装了他们的Android市场授权审核程序。Ralf努力掩盖证书的代码，想法子至少克服自动木马的问题（自动木马会将证书御到新的可执行文件上，然后自动发布到盗版网站上）。要知道如果黑客团体确实想盗我们的游戏，他们就要找个变通方案了，不过我们这样做，至少够他们死点脑细胞。

好吧，其实他们不必那么努力。游戏第一次发布时，我们正得意洋洋，然后就在盗版论坛上发现了一个通告——自动授权证书根本不管用。但24小时以内，一个可以玩的破解版《激流快艇》就出现了。

根据我们的分析，盗版和正版的比率大约是9：1。我们的假设是大多数盗版者可能无论如何都不会购买游戏，所以这些数字不能精确地解读成销售损失。

但让人恼火的是，对于购买了游戏的玩家，谷歌证书审核严格过头了，特别是，当用户的手机网络连接质量不一时。我们没有得到太多关于技术支持的电邮——我可以很负责地说，游戏本身是很稳定的——但我们收到的大多数电邮都是关于失败的证书审核。这个问题只要一个字母就能解决了，但太费时间了，也太让人讨厌了，我们几乎怀疑值不值得安装证书审核程序了。

5、项目推广

除了XBLA的《Hydro Thunder Hurricane》，我们认为自己已经想出所有推销的办法了：放出一些带屏幕截图的新闻稿，预览视频，评论代码，然后实时监控。当然《Hydro Thunder Hurricane》着实”提携“了它的“小弟”一把，但就我们所知，相同的策略多多少少也适用于掌机上的原创独立游戏。

但这一招在手机游戏领域却未必管用——Android游戏要获得媒体报道并不容易，更别说是Tegra专属游戏了。在主流游戏网站中，少有提供专业的手机游戏报道，就算有，提供的也多为iPhone/iPad平台的大型游戏。我写这篇文章时，你在Metacritic上找不到任何一个Android游戏。除了主流的游戏媒体，主流科技网站，如CNet和Wired关注的也多为硬件和非游戏软件。

我们和Flashman的营销团队合作，竭尽所能地给《激流快艇》造势。在新闻发布会和贸易展销会上（如MWC，GDC和E3），我们和NVIDIA和传输商/硬件合作商一起推广游戏。我们向所有主流游戏和技术网站放出新闻稿、 预告片、截图等。

尽管如此，我们向世界宣传《激流快艇》的努力，收到的也不都是鲜花和掌声，好吧，那不太公平。Joystiq报道了我们，许多小型或者中等规模的Android手机游戏网站和博客发布了对我们的鼓励和赞扬。但主流游戏和技术网站对我们仍没有多大兴趣。

对于那些没有报道我们的网站， 我们的问题来自一些基础设施。 Android Market没有任何预览代码机制，所以要把你的游戏发送给媒体预先体验实非易事。一个额外的挑战是，很少网站拥有能够运行游戏的Tegra硬件。结果我们只好自己用一大堆预安装了该游戏的手机和平板电脑，向新闻界放出预览视频。

我明白缺少主流网站的关注，部分原因是由于平台市场的占有率。但我相信这也是因为部分主流媒体的偏见。手机游戏的威信还不足，用完即丢的体验，确实不能和开发给PC和掌机的“真正的游戏”相提并论。但高端手机市场正在成长，并且比游戏机市场的成长更迅速，新一代手机游戏横空出世，带来的游戏体验绝对不输传统游戏平台。用户已经看到这点了。但问题是，游戏媒体什么时候才能跟上脚步？

结语

《激流快艇》于5月20日投放Android Market。销售成绩喜人，至少相对于其他Tegra专属的游戏而言是如此。用户的评论更是振奋人心——这款游戏的保持了平均4.8（总分是5）的用户评分。我们正制作一款iOS版本，也在考虑其他平台。另外，不排除推出可下载内容和其他衍生产品的可能。

最重要的是，这次经历让我们尝到了新市场的甜头。我们总是希望保持团队的小规模，这种规模最终有可能把我们的关注焦点从掌机转向手机，但这种改变可能还需要几年。

这不是说我们已经放弃了开发掌机游戏，而是说我们会将两者结合起来。掌机游戏在技术上仍然领先，扩大范围和增加资金投入会带来更稳定的发展。另外，掌机玩家仍然需要并支持我们去探索比目前的手机更丰富的游戏机制深度和难度。

在手机游戏市场，我们仍然有机会尝试小规模项目，即把集中多笔小资金搞项目，而不是拉拢几笔大资金。游戏开发的工作很有趣，还能武装大脑。我们确实可能自己出资，然后从工作中连本带利地收回来。

我不敢说我们已经把小工作室的问题解决了。但至少在可预见的未来，我们有足够的工作保持工作室的稳定运转。眼下，稳定的感觉真好。

项目资料：

名称：《激流快艇》

发行时间：2011年5月20日

平台： Android/Tegra2

类型：竞速

引擎：Vector Engine

开发团队人员：2名

开发时间：11个月

预算：10万美元

第三方工具：FMOD Sound System, Bullet Physics

开发工具：Maya 2008、Photoshop CS4、Microsoft Visual Studio 2010、Subversion（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Postmortem: Vector Unit’s Riptide GP

by Matt Small

[What does it take to deliver a console-like experience on Android? Vector Unit moved from XBLA title Hydro Thunder Hurricane to Riptide GP and here shares the ups and downs of creating a high-powered water-based racing game for Google's mobile platform.]

In June of 2010, the team at Vector Unit was feeling cautiously optimistic. We’d just wrapped up development on our first game, Hydro Thunder Hurricane, on time and on budget, and were preparing to launch it in one of XBLA’s coveted Summer of Arcade slots. Early reviews were good, and sales projections indicated we’d be in royalties before the end of the year.

We still had a little income coming in via the Tempest Pack DLC for Hurricane; it was enough to keep me and one contract artist busy through the summer. Since it didn’t require a lot of engineering work, Ralf Knoesel, my co-founder and our lead programmer, took a contract at EA Visceral Studios to work on Dead Space 2 while we continued to pitch Microsoft and other publishers on new projects.

We had some great new concepts that we thought were sure to get picked up by somebody, given what we thought was a pretty solid freshman effort, but nothing had stuck. For one thing, publishers tended to think of us as a “racing game studio”, and with some recent high-profile flops in the racing genre, there wasn’t a huge appetite for new racing games.

Hurricane launched in July. Reviews were solid and it was well received by players, but sales — although good by general XBLA standards — weren’t as off-the-charts as we’d hoped. It soon became clear that self-funding a second title would not be an option, at least not any time soon. In October I wrapped up work on the Tempest Pack, Ralf was still contracting at EA, and we still had no clear second project on the horizon. The question of what to do next began to feel urgent.

Then in early November we got a surprise call… from NVIDIA. The chip maker was moving into the Android phone and tablet markets with its dual-core Tegra 2 processor, and it was looking for games to showcase the new hardware’s capabilities. Someone there had played Hurricane, and wanted to know if we could build something similar for them.

The deal wasn’t exactly what we’d been looking for, and the challenges sounded formidable. Neither of us had ever worked on a mobile game. We had no idea what the Tegra 2 hardware was really capable of, or if it would even be possible to pull off the kind of water physics and effects we’d developed for Hurricane on the 360. The budget was tight — we’d have to scrounge up investment for most of the development costs and cover the difference ourselves. And the schedule was aggressive — first playable by February, finished game by May.

An early shot from Alpha City, right after the MWC demo in March.

On the bright side, we’d planned on porting our engine to Android at some point, and this would be an opportunity to create one of the first games developed specifically for high-end tablets and phones. It would be hard work, but it sounded like fun. And hey — work is work.

So throughout December we hammered out deal terms, and with NVIDIA’s help we managed to cobble together funding (more on this later). Knowing what was coming, we allowed ourselves a little break for the holidays, and at the start of January 2011 we dove headfirst into our studio’s second game — a futuristic jet ski racer called Riptide GP.

What Went Right

1. Standing on the Shoulders of Hurricane

It simply would not have been possible to make Riptide GP in the time we had without Hydro Thunder Hurricane.

Vector Unit owns all the technology we developed for Hurricane, so when we began work on Riptide GP in early January, we were able to hit the ground running with a full-featured, cross-platform engine that allowed me to begin content development on the PC as Ralf worked on porting the low-level stuff over to Android’s NDK.

As I began prototyping our first vertical slice, Ralf quickly found that the Tegra 2′s CPU was fully up to the task of handling the calc-intensive fluid dynamics simulation he’d used on Hurricane. He was able to port over all of our water, wave, and Bullet physics code as written from the 360 with little or no modification. This isn’t to say there weren’t challenges on the code side (see “What Went Wrong”). But, generally speaking, the cross-platform groundwork laid on Hurricane paid off, and the port to Android went relatively smoothly.

Major environment components were built and assembled in Maya, and then exported and brought into the Vector Engine game editor. We then add in PFX, animated objects, AI pathing, and water surfaces (click for full size).

We also had the benefit of two years of water-racing design experience, and two years of learning from our mistakes. We knew from the start there were a number of things we could and couldn’t do, and a few we wanted to change.

For example, we had never been completely satisfied with the water sim in Hurricane; it was actually too realistic. When you watch high speed offshore racing, the boats don’t sink into the water — at 100mph, the water might as well be asphalt. But in a game, you want that feel of softness.

In Hurricane, we started with a realistic water sim, and sort of backwards-engineered the softness to get the boats to sink more into the water. For Riptide GP, Ralf went into the base simulation and modified the underlying buoyancy and resistance calculations to give the water a much more pleasant, soft feeling, while still maintaining realistic handling characteristics.

With less than five months to make the game, we never would have had the time for this type of discovery and iteration if we had been starting from scratch. We came off Hurricane with a pretty good feel for what worked, and what didn’t, in a water-based arcade racer, and were able to apply all of that experience to Riptide GP.

2.Ruthless Design Scoping

We started Riptide GP with four pretty straightforward underlying design goals.

First and foremost, as a showpiece for Tegra 2 it had to be technologically and visually impressive. Second, it was aimed at mobile platforms, so we wanted an accessible, easy-to-pick up game mechanics and short, two to three minute play sessions.

Third, we wanted the game to have enough replay value to justify a “premium” price point; not that we have anything against the Freemium or 99 cent app models, but we presumed that there wouldn’t be enough of these new devices on the market to support a high-volume revenue model.

And finally, of course, we had to be able to make the game with two people in just four and half short months… primarily because we wanted to be one of the first titles available on the emerging platform.

Our second set of goals — simplicity, brevity — dovetailed nicely with the tight schedule. But striving for console quality visuals and scope within that time was a challenge. To create sufficient content — particularly for environments — we built everything modularly, instancing and repurposing geometry and textures wherever possible.

This reuse had the added benefit of keeping our pack size small; in the end we came in under Google’s 50mb limit without requiring an additional data download, and our load times are quick enough that we didn’t need a loading bar.

In our initial design specs and throughout development, we were ruthless about stripping away any elements that might distract from our core goals. Many otherwise desirable features — online multiplayer, customizable characters and vehicles — were left on the cutting room floor.

This stripped-down focus on core gameplay allowed us to make fast progress. After about two months of development, the game was coming together and the controls felt great. But the overall experience still felt a bit shallow, and we decided to reintroduce a mechanic we’d cut early on. We added the ability for players to earn extra boost by performing stunts with different combos of thumb-swipes on the screen when in mid-air.

Stunting provided the extra kick (ahem) that the game needed. The gestural stunting was fun, and tying successful stunts to boost provided the risk-reward tension the game had been lacking.

3. Easy Does It

Riptide GP was our first experience designing and building a mobile game, after years working on console titles. We didn’t want the game to be casual per se, but we felt that the game should be more accommodating to casual play styles, both in terms of difficulty and control mechanics.

Racing games on console — even arcade racers like Hydro Thunder Hurricane — tend to be very technically challenging. Much of the fun and reward comes from mastering the vehicle controls and physics, carefully managing speed, and picking out the perfect racing line through a variety of corner angles and track widths. The conventions of mobile racing games, on the other hand, with accelerometer steering and pedal-to-the-metal auto-acceleration, don’t exactly lend themselves to nitpicky perfection.

Rather than struggle against this, we decided to embrace it. Our vehicle specs and track layouts were all designed to be driven at full speed, with braking only really necessary when the player takes a corner wrong. We wanted the game to feel fast and flowing, and we looked to the Wipeout series for inspiration on track layout. There are very few irregular or hard corners where players can catch edges or get stuck — when you hit a wall you slow down, but you keep moving forward.

As a result, Riptide GP is incredibly easy to pick up and play. On most tracks, you can almost let the game play itself — you’ll finish in last place, but you’ll finish. Depth and challenge come from learning how to keep your speed up in the corners, interacting with the waves and other riders’ wakes, and knowing when it’s safe to pull off a stunt for that precious extra bit of boost.

At first, I was concerned that the game might be too easy. But we playtested the hell out of it with friends and anyone else we could get our hands on, and by providing three different difficulty levels, we found we could accommodate both casual and hardcore play styles without overly frustrating the one or boring the other.

A previous concept rendered in the Hydro Thunder engine on the 360, before we ported to Android. We had to lose normal maps and fogging, but otherwise managed to come pretty close to our visual target.

4. First!

Jumping on board the Tegra 2 train just as it was pulling out of the station proved to be a big win for us.

From a production standpoint, it meant a manageable target. Unlike on iOS, where you have this sort of benign dictatorship mandating consistency in hardware and software updates, hardware and OS fragmentation is a serious challenge for Android developers.

By focusing on Tegra, we had a relatively consistent performance and tech standard to steer towards. And because most of these devices are new, we only had to worry about a few different versions of the Android OS. All of this vastly simplified our requirements for compatibility testing… which is good, because we didn’t really have any time in the schedule for it.

Additionally, because we were exclusively targeting its platform, NVIDIA was incredibly helpful. The company provided development hardware and soon-to-be-released devices to test on. Its tech team helped evaluate our builds and provided critical optimization feedback. And the marketing team introduced us to many of the carriers and manufacturers launching new devices, who of course were looking for new games to differentiate their products. Their support helped generate buzz and gave us much needed exposure.

5. Fairness

Okay, we all know this, but I need to say it: the traditional game financing model, with its publisher advances and royalty recoupment, sucks.

One of the best things about Riptide GP is that we managed to skirt the traditional system and fund the game with a mixture of our own cash and third-party investments. As I mentioned in the Introduction, NVIDIA helped us with this. The company introduced us to Flashman Capital, a company in San Francisco that helps small studios with development financing. Flashman agreed to pony up some of the cash we needed, in exchange for a revenue share; we scrounged up some other investment and covered the difference out of our own pockets.

There were two key benefits to the deal we managed to pull together. First, we got to keep the IP, which among other things means that, after a brief exclusivity period on Tegra, we can take the game onto whatever other platforms we want.

Even better, we and the other investors all share in the game’s revenue. With the traditional publisher model, the developer doesn’t see a penny until the publisher’s initial investment gets paid back out of the developer’s royalty share. By the time that happens, if it ever does, the publisher has made back several times their initial investment. In the revenue share model, all the investors — including us — share in the proceeds from day one, more or less according to respective investment levels.

As a result, Vector Unit is much more invested in the game’s success. We’re motivated to promote and nurture the game and its community, because we see a direct benefit from every additional sale. And just generally, we’re happier, because the whole thing feels strangely… fair.

What Went Wrong

1. Great Expectations

The first few weeks of January, when we were porting our Vector Engine over to run on the Tegra 2 dev hardware, were a bit of a nailbiter.

We had signed up to deliver an in-engine demo for NVIDIA to show at Mobile World Congress in early February. We didn’t know what to expect from the hardware in terms of real performance, but we had high hopes. All we had to go on were the paper specs and the expansive claims from NVIDIA and early-adopter developers that Tegra 2 could provide a “console quality” experience on mobile.

Well, as is generally true with performance claims for new hardware, the reality was a bit more complex.

As I mentioned earlier, porting our 360/PC cross platform engine over to the Android NDK went smoothly. By the end of the second week, Ralf had my rough prototype level up and running on the Tegra 2 dev kit, and in some respects the Tegra 2 hardware exceeded our expectations.

The CPU was amazing — it ate up our water sim and fluids calculations, munched happily on a straight implementation of Bullet Physics, chewed up my high-poly models, and asked us for more.

The GPU was another story. We were extremely fill-rate bound, which is particularly a challenge in a game where almost half of the screen space is covered by a giant translucent water mesh. We quickly realized that the complex pixel shaders we’d relied on so heavily on the 360 just wouldn’t allow us the framerates we needed for a fast-paced racing game.

We streamlined our shaders, moved every per-pixel process we could to the per-vertex level, and switched to low-precision calculations wherever possible. We stripped normal mapped ripples off the water and increased mesh density to maintain the complexity we needed to break up reflections. I dusted off my old skool artist toolkit, baking lighting into vertex colors, painting lighting detail into diffuse textures, and ruthlessly managing texture and mesh variation to keep the GPU pipe as open as possible.

NVIDIA provided a ton of helpful performance analysis throughout this process, and in the end, we were able to deliver that first in-game MWC demo with a level of visual quality that, at least to the untrained eye, really does look comparable to something you might see on a modern PC or console. The rate of technological advance on mobile platforms these days is staggering, and I expect that within a few years even savvy gamers will be hard pressed to tell you whether an in-game screenshot was rendered on a high-end console or on a phone.

Modeling, animation, and shader adjustment was all done in Maya 2008 (click for full size).

2. Creative Reuse, or the Lack Thereof

From the start we knew that content creation would be critical path in Riptide GP’s development. Unlike the code, which we owned outright, we weren’t able to reuse any content — models, texture libraries, anything — from Hurricane, so I had to start from scratch.

When I first broke down my 4.5 month art schedule, it looked pretty scary. I had about four weeks for the jet skis, characters and animations, 10 weeks for environments, and five weeks for everything else, including UI, particle effects, polish, optimization, and whatever unforeseen gotchas might lay in wait.

The environment schedule was the hardest. On average I had about six to seven days to finish each of our six main race tracks, with another day or two allocated for creating each reverse variant, which I wanted to be at least a little different, with unique lighting and water features.

The only way this would be possible was through conscientious reuse and instancing, and to some extent I was able to make this work — the tracks were built from instanced segments, and I looked for every opportunity to reuse and recycle textures and geometry from track to track. But I couldn’t quite let go of my desire to try and make each track feel different, and I didn’t reuse as many assets as I could have.

In the end, I got it all done the old fashioned way, through hard work and long hours. Overall I didn’t mind; it was creative work, and as I mentioned above, we were energized and heavily invested in delivering a quality game. I was still polishing and tweaking details the night before we released Riptide GP on the Android Market in May. But I will say I was pretty relieved when we finally hit that Publish button.

All game scripting is built up using visual scripting components.  This sequence controls the animated ramps in “Grindhouse” (click for full size).

3. Small Team Challenges

We didn’t start out intending make Riptide GP with just the two of us. I’d thought I might contract out a month or two of artwork, and we had some budget allocated for things like sound design and music.

But because we were partially funding Riptide GP out of our own pockets, we were powerfully motivated to keep costs down. And because our schedule was so tight, we felt we couldn’t afford the time it would take to manage outsourcing.

So we just went full steam ahead. My schedule was pretty much filled from start to finish with art tasks, but as it turned out, Ralf’s programming schedule started to open up once he got past the graphics engine optimizations. He ended up taking on a ton of miscellaneous content tasks, including sound design and music curating (we sourced most of it from online stock sites like Audiomicro), screens flow scripting, and even some particle effects.

The problem as always with a very small team — in our case, a very, very small team — is that there is virtually no wiggle room for unforeseen variables. We went from three week Scrum sprints at the start of the project, to two week sprints, to one week, and towards the very end we tossed Scrum completely and just went with prioritized task lists, squeezing as much as we could into the time we had. As hard as it was, it was creative, rewarding work, and somehow we managed to get it all done on time. But the process wasn’t always pretty.

4. Yarrr!

Piracy is a problem in mobile that nobody likes to talk about. It’s kind of embarrassing for the platform holders, and I think most developers feel it’s in their best interest give the issue as little publicity as possible. But it is a bona fide issue, particularly for a game like Riptide GP that monetizes strictly off base game sales and not through in-app purchases.

We took Google’s advice and implemented their Android Market license-checking. Ralf obscured the license code wherever possible, looking for ways to outmaneuver at least the automatic bots that strip licenses on new executables and post them automatically to warez sites. We knew that if the hacker community really wanted to they could find a workaround, but at least they’d have to work for it.

Well, they didn’t have to work that hard. When the game first launched, we were elated to see posts in the warez forums indicating that the automatic license stripping wasn’t working. But within 24 hours, a playable cracked version of Riptide GP showed up.

According to our analytics, as of this writing the ratio of pirated copies to legal copies out there in the world is about 9 to 1. Our assumption — our hope at least — is that the majority of pirates probably wouldn’t have bought the game anyway, so the numbers don’t precisely translate into lost sales.

The annoying thing, though, is that for the players who buy the game legally, Google’s license check can be a little persnickety, particularly if the user has a spotty mobile internet connection. We don’t get very many tech support emails — I’m happy to say the game itself is pretty stable — but the majority of emails we do get have to do with failed license checks.

They can be answered and resolved with a simple form letter, but it’s time consuming, and annoying, and it makes us wonder whether it was worth implementing the license check at all.

5. Where is the Love?

Coming off Hydro Thunder Hurricane on XBLA, we thought we had the whole press-promotion thing figured out: You send out some press releases with screen shots and video for preview coverage, send out review codes for reviews, and bam, you’re done! Of course we were hugely helped by the fact that Hydro Thunder was a known franchise, but from what we could see, the same strategy more or less worked for original indie games on console as well.

Not so with mobile games — it’s particularly hard to get coverage for Android games, and even more challenging for Tegra-exclusive games. Few of the major gaming sites even offer dedicated mobile coverage, and those that do mostly just cover the biggest iPhone/iPad titles. As of this writing, you won’t find a single Android game listed on Metacritic. And outside of the mainstream gaming press, the major tech outlets like CNet and Wired focus primarily on hardware and non-gaming apps.

For Riptide GP, we partnered with marketing group Flashman Agency to try and make the biggest splash we could. We worked with NVIDIA and carrier/hardware partners to showcase the game at press events and trade shows like MWC, GDC, and E3. We sent out press releases, trailers, screenshots and other assets to all the major gaming and tech outlets.

Despite this, most of our efforts announcing Riptide GP to the world were met with… crickets. Well, that’s not entirely fair. Joystiq covered us, and we got a decent amount of traction and praise from many smaller to mid-sized Android and mobile gaming sites and blogs. But the major gaming and tech sites were simply not interested.

For those sites that did cover us, our challenge became one of infrastructure. The Android Market doesn’t have any review code mechanism, so there is no easy way to send a copy of your game to the press to review. One additional challenge was that not a lot of sites even had Tegra hardware they could play the game on. We ended up getting a bunch of loaner phones and tablets that we preinstalled the game on and sent out to press ourselves.

I understand the lack of interest from major outlets is partly a question of platform market share. But I believe it’s also due to prejudice on the part of the mainstream gaming press — mobile games still have a reputation for being shallow, throw-away experiences, unlike “real games” developed for PC and console.

But the high-end mobile market is growing much faster than the console market, and there is a whole new generation of mobile games coming out which offer experiences every bit as compelling as what you can find on traditional gaming platforms. Consumers already know this. The question is: when will the gaming press catch up?

A shot from the final game. The new billboard foliage system allowed us to mix a few naturalistic tracks in with the gritty industrial ones.

Epilogue

Riptide GP launched in the Android Market on May 20. Sales have been pretty good, at least relative to other Tegra-exclusive games. Better still our user reviews and comments have been really encouraging — the game is holding an average user score of about 4.8/5. An iOS version is in the works, and we’re considering other platforms as well. In addition, there’s always the possibility of downloadable content and other offshoots.

Most importantly, this experience has given us a taste of success in a huge new market. We’ve always wanted to keep our team small, and assumed that eventually that would mean shifting our focus from console to mobile — we’d just thought that move might be a few years down the road.

This isn’t to say we’ve given up on console development. We see it as part of the mix. Consoles still deliver superior technical punch, and the increased scope and budgets for funded titles offer greater stability. Also, console gamers still demand — and allow us to explore — a little more depth and sophistication in game mechanics than we might currently do on mobile.

Still, the mobile gaming market offers us a chance to experiment with smaller-scale projects, to put many small bets on the table as opposed to a few big ones. The games are fun to work on and easy to wrap your head around. Best of all, we actually might be able to self-fund a few and potentially reap the full reward of our work.

I hesitate to say we’ve got this small-studio thing figured out. But at least for the foreseeable future we have enough work to remain stable. And right now stability feels really good.

Data Box

Title: Riptide GP

Released: May 20, 2011

Platform: Android/Tegra2

Genre: Racing

Engine: Vector Engine

Team size: 2

Development time: 11 man-months

Budget: $100k

3rd Party Tools: FMOD Sound System, Bullet Physics (for collisions and ragdoll)

Development Tools: Maya 2008, Photoshop CS4, Microsoft Visual Studio 2010, Subversion（source:gamasutra）