开发者谈利用业余时间开发游戏的5个经验教训

原作者：Scott Beca 译者：Vivian Xue

Considerable Content是一个两人工作室，成员Edward Blanch和Scott Beca在过去的三年里利用傍晚和周末的时间制作了传统3D平台游戏Rogue Singularity。由于他们在行业内都有自己的本职工作，因此对于这个私人项目他们一直尽力保持创作的动力。这篇文章中，Edward和Scott谈论了他们在制作这个游戏的过程中获得的最宝贵的经验。想要了解他们的进展，你可以去Steam上抢先体验一下这个游戏，完整版将于2018年在任天堂Switch上独占发行，并在Steam上同步发行。

多年以前，我们俩开始制作一款十分奇怪的动作冒险游戏Postman’s Odyssey。这个游戏与它最终演化而成的版本几乎完全对立：节奏缓慢、充满情调并且内容完全由手工制作。

经过努力我们制作出了游戏的雏形并邀请人们来体验它从而获得一些反馈。我们从中得到了很重要的两点经验：玩家们真正享受的只是大型游戏中的某一小部分内容，还有（如果我们继续下去）我们正在把年复一年的工作耗费在一款吸引力有限的游戏上。

万幸的是人们对这个游戏中的某一部分感兴趣。尽管大部分内容是手动制作的，游戏中玩家需要攀爬的塔是由程序自动生成的，这些塔的结构复杂并且充满了死胡同和移动机关。鉴于玩家们觉得在奇形怪状的程序生成空间中跳跃很有趣，我们决定把其它的元素统统舍弃，制作一款以此为核心循环的游戏。

Rogue Singularity就是由此诞生的游戏，一个受到《超级马里奥 64》启发的3D平台游戏，玩家们操控一个勇敢的小机器人穿越被一个黑洞撕裂的太阳系。为了模拟宇宙毁灭后的动荡和混乱，所有的游戏关卡都是由程序随机生成的，正如我们今年初在Gamasutra网站的文章中描述的那样。

简单，当时的我们想。我们一年左右就可以搞定这个项目！

结果并没有那么容易。三年后Rogue Singularity才接近制作完成，而我们已是更加有经验的游戏开发者了。以下是我们在这个副项目中获得的五个最大的经验教训。

确立一个明确而适当的范围（并且允许它发生偏离）

如果我们再次用业余时间制作游戏——并且如今这主意一点也不吸引人——我们会考虑自身可利用的时间，确立一个双方认为可实现的开发范围。我们最有可能的选择是制作Rogue的续作，因为这样我们就可以在之前工作的基础上继续创作而不用从零开始。

由于Rogue是从早期项目中自然诞生的，我们刚开始并没有明确的设计方案。缺乏范围不可避免地造成了特征蔓延（Feature creep）。我们绝不会重蹈覆辙：任何未来的项目都会提前做好计划。

这并不是说特征蔓延不会发生或者它不应该发生。你自己做出来的游戏可能会让你吃惊：一些你认为平平无奇的功能结果可能是最有趣的，这促使你重新分配资源进一步开发它们。然而，你每次做这些决定前应该谨慎考虑，权衡它们为游戏带来的提升以及它们所需的工作量。

Rogue和我们最初设想的游戏很不一样。大致的框架还在，但是细节却发生了巨大的变化。最关键的变化是游戏的速度。由于受到马里奥游戏的启发，我们设定了两种奔跑速度：一种慢一些的常规速度和另一种通过按下按钮达到的冲刺速度。事实上，我们发现所有的测试玩家全程都按着冲刺按钮，因为缓慢移动在游戏过程中毫无用处。

得知这一点后，我们放弃了两种速度的设定，直接把人物的常规速度改成了冲刺速度。随着人物持续地冲刺，整个游戏的节奏也加快了，接着我们决定把游戏镜头拉近一些，把人物的尺寸扩大一倍，然后把平台做的更大，这使得游戏的速度更快。突然间我们的游戏，原本要求玩家们在障碍物中谨慎地选择道路，变成了一个更加狂热的、追求又快又安全地通关的游戏。这使我们想到了计时制玩法，接着又让我们联想到了排行榜、player ghosts和Rogue的整个在线功能。

一方面，制作这些社交内容让我们的发行日期推迟了至少一年，但是另一方面，它确实提升了这个游戏。在我们抢先体验计划中，排行榜是那些参与度最高的玩家的主要动力。这值得吗？这个嘛…

学会接受你的决定

作为游戏开发者，我们常常沉浸在科幻作品和幻想的世界中，但是现实世界没有时空穿越，也没办法让你跨入交替的现实中。我们会被迫接受我们的决定，而我们所能做的只有充分利用他们。

An early version of Rogue(from gamasutra.com)

直到Rogue的开发末期，我们才意识到游戏的主题是错误的。游戏的速度主导型的玩法和排行榜元素使得我们意识到极限运动主题会更适合这个游戏。想象下在一个电视直播的运动比赛中，机器人选手们尝试在极限障碍路程中获得最佳的成绩，而取代Rogue邪恶重型角色的是一个不断鼓舞玩家们的教练。

我们意识到了两点：这个设定更加适合游戏当前的玩法和主题，以及我们无法改变什么。做出这个变动意味着几年的工作将付之一炬，我们的开发工作几乎要从头开始并且进一步推迟我们的发行时间。即使我们确定它可以成为一个更好的游戏，但我们意识到在这个阶段一切都太迟了。

我们只能选择接受它，以及众多我们曾经坚持但日后却发现是错误的选择。Rogue Singularity是一个令我们骄傲的优秀的游戏，但是我们自然会去好奇它本可以是什么样子。然而最终，你只能接受你的选择并继续前进。

当然，也许某一个平行世界里，Edward和Scott正大喊着“为什么我们不坚持黑洞？这个运动主题根本行不通！”

没有人购买你的游戏并不意味着你所花费的时间毫无价值

很多年轻的独立开发者都会犯这个错误。当你利用业余时间制作你喜爱的项目、没有了老板的指挥可以随心所欲地做决定时，你很容易将“无收入”等同于“无价值”。这是一种很危险的态度，年轻的开发者们可能会因此放弃。

你时常会在游戏媒体上看到这样的文章，一个团队声称他们正在制作“零预算”的“免费”游戏。这样的团队一般躲在大学里并且睡在桌子下面，一旦他们被抓到了，他们会搬到一个单人间里然后24小时地开发游戏。这种开发过程固然有趣，但是它绝对不是没有成本的。

成本并不只关于金钱。你的时间也同样宝贵，你花在个人项目上的每一个小时都本可以用在别的地方。比如开发者们在一个合租屋里开发所谓的“免费”游戏，但你想想如果游戏失败了会怎么样呢？如果它吸引不到玩家并且赚不到钱（游戏邦注实话实说，即使很棒的游戏也有可能因为一些开发者不可控的因素而收入惨淡）结果开发者们白白浪费了多年的时间。两三年后他们仍没有任何经济保障、没有商业人脉、没有稳定的收入。

更糟的是，即使游戏成功了，由于缺乏专业工作室的工作经验，当他们继续做下一部作品时，他们根本不知道如何写设计简稿、评估预算、安排工作任务，这很大程度上是因为他们从来没有觉得自己的个人时间是有价值的。

利用傍晚和周末的时间开发游戏是有很有挑战性的事，并且它一直都挺不容易的。刚开始这个项目的时候，我们俩都已经签了数小时的兼职合约，而如今我们都是不同的专业工作室的全职员工。即使如此，我们的本职工作使我们获得了经验并成为了更好的开发者，Rogue的提升就是一大成果。

我们的效率更高、工作方法也更明智，并且如果不是在日常工作中遇到了一些东西，我们永远不会想到把它们放到Rogue里。简单的说，你得多付出才能成为更好的开发者。

寻找保持动力的方法

事实上，这个项目中最大的挑战是如何在时间和精力有限的条件下保持创作，但是我们通过一些不可思议的方式中获得了动力。

最强大的动力源泉之一是金钱，讽刺的是我们并不是因为缺钱，而是因为手头上有钱。我们获得了Film Victoria的一笔赞助，这使得我们能够做更多的事情，包括聘用Trevor Powell为我们做镜头控制。Trevor是游戏镜头系统的世界级专家，尤其擅长3D动作平台游戏的镜头运用，并且他将14年的经验都应用在我们的小项目中。

Trevor的加入影响了我们的很多工作方式，但是最大的影响是激发了我们的工作动力。即使我们尝试告诉自己我们的个人时间很宝贵，我们还是很容易认为我们的时间是“免费的”。然而Trevor是有收入的，并且我们是付工资的那方。一想到有他为我们工作却因为我们没有准备好而耽误了他的工作，我们就感到恐慌。避免浪费了我们少而宝贵的预算是一个原因，但是更多的是因为我们对Trevor的崇拜。因为我们没做好工作而让一个行业传奇人物闲着没事干，简直让人难以忍受，因此我们会尽力逼迫自己去完成。

坚持参加活动也是另一个保持动力的有效方法。我们带着Rogue参加了好几次澳大利亚的PAX游戏展。每次展会前的几个月总是让我们极度紧张。（我们在Gamasutra上为首次去PAX参展商写过一篇指导）不断地优化现有的作品从而能够带些新鲜的东西去展会是很困难的，但也很有必要。准备一个展位所花费的精力和资金是一种投资——有一年我们甚至制作了专业的胸针——如果你没有一个可行的游戏，这种投资就会被浪费。

回望过去，这些PAX展前紧张的准备阶段反倒是我们最有成效的时期。它几乎要把我们逼疯了，但是同时也促使我们把项目进行下去。

抢先体验不一定是个好主意

在Steam上发行抢先体验版对我们来说喜忧参半。它自然有它的好处，但是我们强烈建议所有小型独立开发者们在这么做前一定要考虑清楚利弊。积极的一面非常明显，当然，并且我们无可否认能够让真正的玩家接触到我们的游戏并且给与我们反馈确实对进一步提高游戏有帮助。

尽管如此，抢先体验相当于一种成承诺，一种你和玩家之间就如何提高游戏体验而达成的一项协议，最好还是定期生效的。一旦没能履行合约你将面临失去玩家的风险。我有个业内的朋友，发行了抢先体验版并定期发布更新——像我们一样两周一更或者每周一更——几个月里他们为了保持更新频率而筋疲力尽，结果不知道是因为发现了一个大bug还是得了流感错过了一次更新。可就因为这一次错过更新他们的玩家数量显著下降。

另外你还得时刻把营销考虑在内。当你最终准备正式发行游戏时，你需要让人们在同一时间玩游戏，因为这样他们才能彼此分享和谈论你的游戏并传播它。这能够让你的曝光程度最大化，增加你的游戏成为社交媒体焦点的机会，从而得到足够的关注并最终为你带来大销量。

把几个月的时间耗在抢先发行上将会消磨你的动力。太多的开发者在他们发行抢先体验版本时获得了很大的关注度，但是随着时间的流逝，当他们准备正式发行时，他们已经失去了当初的兴奋，玩家们同样地也会逐渐丧失兴趣。即使我们的游戏拥有理论上无限的程序生成关卡，也只能吸引玩家一段时间而已，即使是铁杆粉丝也会最终丧失他们的热情。

因此我们故意降低了抢先体验版本的标准，因为你只有一次机会来给人们留下好的第一印象。当你参加游戏发布会接受人们的鉴定时，如果他们已经充分地了解了你的抢先体验版本，他们将有充分的理由问你“这次发行的版本有什么特别之处吗？”这次是真正的发行、百分百的官方1.0版本，这样的回答会让他们感到不屑然后无视你，除非你的正式版本中有亮点。

因此，你应该想清楚你想通过抢先发行版本达到什么样的效果。无论它带来什么好处，你必须记住它肯定也有一定的负面影响，只有你能决定这么做是否值得。

那么，到底应不应该在业余时间开发游戏呢？

人们倾向于否定的答复，但这答案有点过于简单化。你必须是真的很想做这件事，事实上，这类工作有时候真的很残忍。你不得不妥协，放弃那些不可行的游戏功能。

然而，如果你能够确定一个适当的并且可行的范围、坚持你所做的决定、牢记你的宝贵时间、思考一些让项目持续运作下去的策略并且做出明智的发行决策，你有可能成功。

如果你想尝试无预算的兼职游戏开发，我建议你参加一个game jam项目，比如Global Game Jam。一个Jam项目能够将整个开发过程压缩到一周，甚至有时候更短，逼迫参与者们快速做出艰难的抉择并且放弃不可行的想法。如果你发现你在这种高压环境下能够更有效地工作，也许业余时间游戏开发对你来说是合适的。

我们很幸运Rogue Singularity能够获得任天堂的青睐，并且他们会在2017年澳大利亚PAX 的展位上展示这个游戏。通过这次活动和其它的一些往来，我们与任天堂建立了良好的关系，有了他们的支持，毫无疑问游戏开发的最后阶段会更加轻松。然而被任天堂公司展出是千载难逢的机会，有点像中了彩票，你无法预料到。你所能做的就是尽力优化你的游戏并期待着它能获得某个发行商的赏识。

本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao

Considerable Content is a studio of two, Edward Blanch and Scott Beca, who have spent evenings and weekends over the past three years making the old-school 3D platformer Rogue Singularity. Both have day-jobs in the games industry, so they have struggled to maintain momentum on their personal project. In this article, Edward and Scott talk about the most valuable lessons they have learned trying to get their game finished. To check out their progress for yourself, Rogue Singularity is currently available through Steam Early Access. The full release will debut on Nintendo Switch as a console exclusive in 2018, alongside the full release on Steam.

Many years ago, the two of us started making a very strange action adventure game called Postman’s Odyssey. It was almost the perfect opposite of the game it would one day mutate into: slow-paced, atmospheric, and almost entirely hand-crafted.

After quite a lot of work, we had a working prototype and were getting people to try it out and give us their feedback. We learned two important things: players were really only enjoying one small part of a much larger game, and (if we continued) we were looking down the barrel of year and year of work on a game with limited appeal.

The silver lining was the one part of the game that people really got into. Despite being mostly made by hand, it featured procedurally-generated towers that players needed to climb, which were complex and full of dead ends and tricky traversal. We decided that since jumping around on weird procedural shapes was fun, we would discard everything else and make a game based just around that gameplay loop.

The result was Rogue Singularity, a Mario 64 inspired 3D platformer which put players in control of a plucky little robot that was traversing a solar system being torn apart by a black hole. To simulate the random, chaotic nature of this cosmic destruction, all of the levels would be procedurally generated, as we described in this Gamasutra article from earlier this year.

Simple, we thought. We can knock this over in a year or so!

Well, not quite. Three years later, Rogue Singularity is close to being done, and we are much more experienced game developers. Here are five of the biggest lessons we’ve learned since beginning work on this little side project of ours.

Set a clear and modest scope (but accept that it will slip)

If we ever do another game in our spare time—and right now that is not an appealing idea at all—we will insist on a strictly limited scope that we both agree is achievable in the time we have available to us. The most likely option if we do a follow-up will be a Rogue sequel, since that will allow us to build on everything we already have instead of starting from scratch.

Because Rogue kind of started organically, emerging from that earlier project, we got into it without a clear design in place. Feature creep was inevitable because we began without a real sense of scope. This is not a mistake we will repeat: any project we work on in future will be carefully planned in advance.

This is not to say that feature creep won’t happen, or even that it shouldn’t. Your own games can surprise you: features you never gave any real consideration to may turn out to be the most fun, prompting you to reallocate resources to develop them further. However, you need to make these kinds of decisions very carefully, weighing up how much they will improve the game against how much extra work they will require.

Rogue is a very different game now from the one we originally envisioned. The broad strokes are there, but the fine details have evolved dramatically. Speed is one of the key changes. Since we were so inspired by Mario games, we automatically included two running speeds: a slower default and a sprint that was enabled by holding down a button. In practice, we found that all our test players were playing the entire game with the sprint button held down, because there was no advantage to moving slowly.

With this new knowledge, we got rid of the idea of two running speeds entirely and instead changed the character’s default speed to the original sprinting speed. With the character always sprinting, the gameplay began to speed up as well, and then we decided to bring the camera in much closer, double that character’s size on-screen, and make the platforms larger, which made it faster again. Suddenly our game, which had been about carefully picking a path through obstacles, was much more frenetic, focused on not just getting through the level safely but also quickly. From that was born the idea of timed runs, which gave rise to leaderboards, player ghosts, and Rogue’s entire online functionality.

On the one hand, all of this social content blew out our release date by at least a year, but on the other, it definitely made it a better game. For many of the most engaged players in our Early Access program, competing on the leaderboards is the main thing that keeps them playing. Was it worth it? Well…

Learn to live with your decisions
As game developers, we are often immersed in worlds of science fiction and fantasy, but here in the real world there is no time travel, and no way to hop sideways into alternate realities. We’re stuck with the decisions we make, and all we can do is try to make the best of them.

It was very late in Rogue’s development that we realised the theme was all wrong. Because of the shift to speed-driven gameplay and competitive leaderboards, we realised that the gameplay would have worked much better as a kind of extreme sport. Imagine a televised sporting event with robot competitors trying to make the best times on extreme obstacle courses, and with Rogue’s evil overlord character replaced by a coach or trainer who tries to keep the player motivated.

We recognised two things: this would almost certainly be a much better fit for the gameplay that the theme and story that we had, and we absolutely could not do it. Making that change would have forced us to discard years of work, restarting much of our development from scratch and pushing our release back even further. Even though we were certain it would have made a better game, we realised it far too late in the development process.

We’ve had to simply live with this, and with a multitude of other decisions where we committed to doing things one way and then felt later on that we’d made arguably the wrong choice. Rogue Singularity is a great game that we’re both very proud of, but it’s natural to wonder what might have been. Ultimately, however, you need to accept the choices you’ve made and move on.

Of course, in some parallel universe, there may be some alternate Edward and Scott shouting, “Why didn’t we go with the black hole? This sporting theme just isn’t working at all!”

Just because nobody’s paying you doesn’t mean your time has no value
This might be the most common mistake that young indie developers make. When you’re working on a project you love in your spare time, deciding on your own priorities and with no boss telling you what to do, it is easy to equate “no pay” with “no value”. This is a dangerous attitude, and it can really set young developers back.

Every now and then you’ll see an article pop up in the gaming press about a team who claims they’re making a game “for free”, with “zero budget”. One such group that made headlines were hiding out in their university and sleeping under desks, and when they got caught they all moved into a single house and just made their game 24/7. This kind of process can certainly be interesting and fun, but it isn’t free.

Cost is about more than just money. Your time is also valuable: every hour spent on a personal project is an hour that could have been spent elsewhere. In the case of the share house of developers making their “free” game, what happens if the game flops? If it fails to connect with an audience and makes no money (and let’s be honest, even great games can be financial failures because of factors outside the developer’s control) then those people have lost years of their lives. They’re two or three years older, but without financial security, without the business contacts, and without a portfolio they might have built up working a salaried day job.

Worse still, even if the game succeeds they will have no experience of what it’s like to work in a professional studio. When they want to begin work on their next game, they will have no idea how to write a design brief, or manage a budget, or prioritise tasks, largely because they have never thought of their own time as being worth something.

Trying to complete a game by working during evenings and weekends has come with its own challenges, and it hasn’t gotten any easier. When we started, both of us were working part-time on contract with variable hours, and now we’re both full-time permanent staff at two different professional studios. Even so, the experience we get in our paid roles makes us better developers, and Rogue has improved as a result.

We work faster, we work smarter, and there’s stuff we’ve included in the game that we would have never discovered if we hadn’t encountered it in our day jobs. Put simply, you don’t become a better developer by doing it less.

Find ways to sustain your momentum
Actually keeping the project moving when time is short and energy is low is perhaps the greatest challenge the two of us face on this project, but we have found motivation in some unlikely places.

One of the strongest sources of motivation was money, and ironically it wasn’t money we lacked, but money we had in-hand. We received a grant from Film Victoria which allowed us to do many things, including hiring Trevor Powell to code our camera controls. Trevor is a world-class expert in video game camera systems, especially in 3D action platformers, and brought 14 years of experience onto our little project.

Trevor’s presence affected the way we worked in a lot of ways, but mostly it just motivated us to work. Even though we tried to remember that our own time had value, it was easy to think of the hours we put in as “free”. Trevor, however, was getting paid, and we were the ones paying him. The thought of having him waiting on us for work, twiddling his thumbs because we hadn’t finished the prerequisites for his tasks, was horrifying to us. The waste of our small but precious budget was one thing, but Trevor was also someone we greatly admired. Leave a legend of the industry hanging because we didn’t get our work done would have been intolerable, so we pushed ourselves to get it done.

Committing to events was also a great tool to keep us moving. We’ve shown Rogue at PAX Australia several times now, and each time the couple of months before the show has been incredibly stressful. (We’ve actually written a primer for first-time PAX exhibitors on Gamasutra previously.) Getting the current build polished up so that we have something to show the public was hard but necessary. The effort and expense that go into preparing a booth space are an investment—one year we even had official PAX pins made—and that investment will be wasted if you don’t have a functional game.

Looking back, those pre-PAX crunch periods were probably the most productive times in Rogue’s entire development. It damned near killed us, but it kept the project moving along.

Early Access is a mixed blessing
Committing to Early Access on Steam has been a very mixed experience for us. It certainly has its benefits, but we strongly urge all small indie devs to weigh up all of the pros and cons before committing to Early Access. The positive aspects are obvious, of course, and we would never deny that having real-world players enjoying our game and giving us feedback has helped to improve it.

That said, Early Access really is a commitment, an agreement between you and your players to keep updating the game, preferably on a regular schedule. Fail to hold up your end of the bargain and you risk alienating your players. I have friends in the industry who launched games in Early Access and committed to punishing update schedules—fortnightly like we did, or even weekly—and after exhausting themselves meeting that update schedule for months, they’ve found a major bug or caught the flu and ended up missing just one update. That single missed deadline nearly always resulted in a noticeable drop-off in the player count.

There are also marketing considerations to keep in mind. When you’re finally ready to do your official release, you need everybody playing it at around the same time because that’s when people are going to be sharing it, and talking about it, and streaming it. This will maximise your exposure, increase the likelihood that your game will trend of social media and reach a critical mass of media coverage that should result in strong sales.

Drawing your launch out over months of Early Access can rob you of that momentum. Too many developers get a lot of press attention when they first launch into Early Access, but by the time they are ready to release that interest has died down. Players, too, will lose interest given enough time in Early Access. Even our game, with its theoretically endless procedural levels, will only hold a player’s attention so so long, and even the most hardcore fan will eventually take all the enjoyment from your game that they can.

We deliberately downplayed our Early Access release, because you don’t get a second chance to make a good first impression. When you go to the games press and ask them to check out your game, if they already covered your Early Access launch they will ask you, with good reason, ‘what’s so special about this release?’. Telling them that this time it’s the real deal, the absolutely official version 1.0 release, will lead to many of them just shrugging and ignoring you unless you have something that makes a splash for the full release.

As such, you should ask yourself what you are hoping Early Access will achieve. Whatever benefits it provides, you need to remember that there will be drawbacks as well, and only you can decide if it’s worth it.

So, should you do you make a game in your spare time?

It’s tempting to answer “no”, but that’s a little simplistic. You need to be really real about it, doing this kind of work, and the reality is that it’s sometimes really brutal. You have to be willing to compromise, throw features overboard when they’re not working, and just generally be brutal to your beloved electronic baby.

However, if you keep your scope modest and achievable, commit to the decisions you make, remember that your time has value, come up with strategies to keep progress rolling, and make an informed decision about whether or not to do Early Access, it is possible.

To get a taste of what no-budget part time game development can be like, I recommend trying out a game jam event, such as Global Game Jam. A jam compresses the entire development process down to one weekend, or sometimes an even shorter time, forcing participants to make hard choices quickly and to ruthlessly cut ideas that aren’t working. If you find that you thrive in such a high pressure environment, maybe spare time game dev is for you.

We were lucky enough to have Nintendo show interest in Rogue Singularity and they exhibited Rogue at the Nintendo booth at PAX Australia 2017. Through this event and others, we have been building up and good relationship with Nintendo, and their support will definitely make the final stages of development easier. Being exhibited by Nintendo is rare and kind of like winning the indie game dev lottery, though, so you can’t plan for it. The best you can do is make the best game you can and hope that a publisher finds out about it and likes it.

Now, if you’ll excuse us, we have a game to finish.（source：Gamasutra ）