原文作者：Ryan Krause 译者：Megan Shieh

制作游戏时，最重要的就是要搞清楚规模。如果你生活自由，而且能够在没有截止日期的情况下工作，那太好了！但是绝大多数的开发者一般都会有个截止日期。无论是周末的game jam、私人的小项目、还是较大的团队项目，作为开发者，你都应该问自己这么一个问题“这个游戏要做多大？”

这个问题并没有准确的答案。比如说，给你48小时来做一款游戏，那么经验不同的开发者，做出来的游戏大小也会不一样。能够帮你计算出答案的公式根本不存在，许多人因此只能盲目地朝着脑子里的一个抽象目标而努力。

Ridiculous Fishing（from gamesindustry.biz）

99.9%的开发者，尤其是那些刚刚起步的，目标都高得要飞上天了。这些目标要么会被现实动摇，要么就是会让开发者为了完成它们而搞得焦头烂额。无论是哪种结果，都不是好事儿。

其实唯一的解决方案就是：尝试不同规模的游戏。不过这种做法的失败率较高，而且许多开发者也会因此搞得很不高兴。那么，开发者们到底应该如何避免过度工作，或时间不够的情况呢？

我最近刚完成了一款名叫《A Fish Named Dave》的游戏，用时一个月。这绝不是一款完美的游戏，但这是我用一个月就能完成的事情，而且我只有在工作日的晚间和周末才有空做这个游戏。在完成游戏的过程中，我几乎感觉不到任何压力,虽然删掉了一些功能/特性，但是游戏好像也没有因此而受到任何消极的影响。

以下是我在这个月里所学到的东西：

1. 想法越多越好

在为游戏出主意的同时，我也开始列出一些随机的东西。最终，我想出了‘喷火鱼’，剩下的部分就围绕着这个点慢慢展开了。此前我列了一张单子，单子里的内容包含所有与水有关的东西，鱼可能会尽量避免的事情，鱼会喜欢做的事情，等等。单子列好了以后，里面就有很多的内容供我挑选和选择。

2. 故事情节不要搞得太紧凑

《A Fish Named Dave》的最初草稿是：Dave试图从一只鲨鱼那里救出他的女朋友，然后与路上遇到的敌人搏斗。而在这过程中，一切皆有可能。我以前参与开发过的一些游戏很多都是环环相扣，第一关是游戏介绍，第二关谁干嘛了，第三关又发生什么事儿了，之类的。然后…我们没来得及完成第二关，所以现在第三关看起来就像在瞎扯…

别把故事情节逼得太紧，留些空间，给自己留有余地。

3. 建立可以独当一面的机制

如果你的机制自身不够完美，那就试着尽快改进它。因为它们最终可能会成为你游戏中唯一剩下的东西。你当然可以拥有一些相互作用的机制，但如果没了B机制，A机制就活不下去，那你就得仔细再想想，实在不行就直接把它去掉。

4. 尽快完成最低限度的游戏

每个游戏都需要一个菜单，介绍，结局和计分系统。其他的东西在必要情况下都可以去掉。所以从最小的游戏开始做，然后在还有时间的时候开始插入关卡。这样的话，你就不用在最后的几个小时里慌乱地制造出一个毫无新意的终极（通关）BOSS战。

5. 不要气馁

开发的过程中，肯定会出现一些意料之外的突发问题，而这些问题也会不可避免地缩短开发时间。就像我之前说到的，不试你是不可能知道的。从错误中吸取教训。在固定的一段时间里，你能做出多大的游戏？这些都要记录下来。没有人比你更了解你自己，而且你还可以通过练习来更好地了解自己的技能和开发速度。

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

The biggest issue with making a game, is knowing how big to make it. If you’re living free and are able to work without deadlines, great! But most cases, you’ve got a time limit. Whether it’s a weekend game jam, a small personal project, or a large team project, the question you need to ask yourself is “How big is this game going to be?”

The trouble is, there’s no good answer. Given a weekend (let’s say a 48 hour game jam), a veteran game developer could make a way bigger game than someone just starting out. Plus, even that is hard to quantify. There’s no formula for “If you’ve done X hours of game development in your life, you should be able to make a Y minute-long game in Z hours.” Which leads to a lot of people just blindly striving to an ideal goal in their head.

However, 99.9% of the time, especially for those starting out, the goal is wayyyyy too ambitious, and the either the game falters to the intended vision, or the developer drives themselves crazy trying to finish the game. Nether are good outcomes for anyone.

To add more fuel to the fire, the only way to learn what you or your team is capable of is to try different sizes of games. However, this usually leads to a lot of failures and a lot of unhappy developers. So what’s the best way to avoid overworking or having an unpolished mess of a game when time is up?

I just finished a game I made for the month of August called A Fish Named Dave. It’s in no way the perfect game, but it was something I was able to finish in a month, only working evenings and weekends on it. I felt little to no stress in getting the game finished, and I don’t think any part of the game really suffered from me cutting any features. Here’s what I learned this month:

1. Brainstorm a bunch of things

While coming up with the idea for my game, I just started listing random things. Eventually I got onto the idea of a fire-breathing fish, and the rest of the game just spiraled from there. A kept a list of things that could appear in the game if I wanted to put it in. All things water related, all things a fish would likely try to avoid, what a fish would likely like to do in life, etc. At the end of this brain dump, there was a lot of content to pick and choose from. Which leads us to…

2. Don’t come up with an involved storyline.

The very first draft of the game was just supposed to be Dave trying to rescue his girlfriend from a shark, and he fights enemies along the way. It was designed to be ambiguous, that anything could happen from start to finish. I’ve worked on games where we clearly defined level 1 to be introduction, level 2 this happens, level 3 that happens, and so on. Well guess what? We ran out of time for level 2, so now level 3 makes no sense. Keep your story loose and flexible with the rest of your game.

3. Make your mechanics solid enough to stand on their own.

If your mechanics aren’t amazing on their own, try to rework them as soon as you can. They eventually could end up being the only thing left in your game before time is up. Obviously you can still have mechanics that interact, but if mechanic A absolutely needs mechanic B to be fun, try rethinking it, or removing it completely.

4. Finish the bare minimum of your game as soon as you can.

Every game is going to need a menu, an introduction, some end, and of course, credits. Everything else can be removed if needed. So start from that smallest game possible, and start inserting levels while you still have time. That way, you aren’t scrambling to create an underwhelming final boss fight in the last 5 hours.

5. Don’t be discouraged.

Games are always going to have unseen issues pop up out of nowhere, and that will always cut into development time. Like I said earlier, these things are pretty much impossible to know before you try. Learn from your mistakes. Keep track of how big a game you can get done in a set time span. No one but you knows how long something will take to make, but with practice, you can get a better understanding of your skills.

So what are you waiting for? Go join a jam, make a game, and keep on being awesome game developers.（Source: gamecareerguide.com  ）