開發者談在規定時間內如何儘可能地按照要求完成製作任務

原文作者:Ryan Krause 譯者:Megan Shieh

製作遊戲時,最重要的就是要搞清楚規模。如果你生活自由,而且能夠在沒有截止日期的情況下工作,那太好了!但是絕大多數的開發者一般都會有個截止日期。無論是週末的game jam、私人的小項目、還是較大的團隊項目,作爲開發者,你都應該問自己這麼一個問題“這個遊戲要做多大?”

這個問題並沒有準確的答案。比如說,給你48小時來做一款遊戲,那麼經驗不同的開發者,做出來的遊戲大小也會不一樣。能夠幫你計算出答案的公式根本不存在,許多人因此只能盲目地朝着腦子裏的一個抽象目標而努力。

Ridiculous Fishing(from gamesindustry.biz)

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  )