以一个费时费力的项目谈先做玩法再做美术和编程的必要性

原文作者： Jason Knight 译者：Megan Shieh

你好，我叫Jason，是Noodlecake工作室的一名开发人员。在过去的四年里，我一直在发行团队工作，帮助其他人将游戏概念变为现实。在这个过程中，我也一直在忙自己的副业。近期，我终于成功发布了自己的副业项目之一，一款名为《4 Way Stop》的免费手游。

我花了很长的时间才把这款游戏做好，在开发这个简单游戏的过程中，我学到了一些有趣的东西。

2014年6月，我成为了Noodlecake发行团队的开发人员之一。从那时起，我参与了50多款游戏的发布，这些游戏分别分布在苹果、谷歌和亚马逊的应用商店中。

同时，我也一直在钻研自己的副业项目。

2014年的某个下雪天，正在开车的我停在了萨斯卡通市的一个四向停车路口（4 way-stop）。我观察着排在前面的3辆车，心理数着什么时候才会轮到我。

（游戏邦注：4-way Stop是一种交通路口控制系统，主要用于美国、加拿大和南非；车辆会从十字路口的各个方向驶入，到达十字路口时，所有车辆必须完全停下，然后根据到达的顺序逐一通过交通路口。）

当时我想：“可以把这做成一款游戏！”

“估计一个周末就能把它给做出来。”

3年后，这款游戏终于做好了。

你可能会想：“怎么这么久？说好了一个周末呢？！”

Grand Theft Auto V(from pastemagazine)

首先，编码很难。实际花费的时间永远比你想象的要长，传统的软件工程思维方式是，将最初估计的时间乘以三。我估计一个周末就能做完，结果花了三年的时间…显然是有什么在作祟。

让我们先来聊聊游戏开发中的生产力哲学：

一名“优秀的开发人员”应该首先将核心玩法做出来，然后将它进行抛光、迭代，接着把游戏变好看，然后大功告成，准备上架!

在制作《4 Way Stop》的时候，我是从核心玩法开始做起——先简单地做了几个立方体，把它们当作车辆，让这些车辆开到十字路口停下来，然后你点击这些车辆让它们逐一前进。

当时的游戏界面看起来巨丑无比，不过那是因为我还没有加入任何美术成分。

这个时候游戏已经具有功能性了，“车辆”必须先完全停下，然后你才能点击它们。如果你能按照车辆到达的顺序去点击它们，就能得一分；点错你就输了。

制作这个原型花了我一个周末的时间。好了，玩法有了！但是它看起来实在是太丑了，一点都不有趣。那我现在该怎么办？

嗯…暂时想不出其他玩法了，那就先弄美术吧！

于是我用了两个月的时间和几百个“Unity立方体”做出了一个挺好看的界面。

然而在这两个月里我就只做了美术方面的工作，丝毫没有调整过玩法。美术方面的工作总是很有趣，因为你可以马上看到结果，而且比起给玩法编码，“花时间->马上看到结果”的反馈回路也比较线性。尤其是当你脑袋空空，没有任何清晰的玩法创意时，拼命编码能给你带来的就只有一系列失败，相比起来美术工作有趣得多。

但是，这篇文章的重点是：

先做玩法！

因为3个月后，我有了一款“界面很好看的烂游戏”。

UI看起来很棒，但游戏本身一点也不好玩。

从最初的原型开始，游戏玩法丝毫没有被修改过。玩家仍得等到这些车辆完全停止，然后才能点击它们，因此他们很快就会感到沮丧并退出游戏。但至少UI挺好看的…

我和我的家人、朋友一直在对这款游戏进行“用户测试”，所有人都玩不到一分钟就不想玩了，很明显，游戏不好玩，因此我不得不退回去修改核心玩法。

我把“核心玩法”放在首位是因为一切都依赖于它，当你修改它的时候，其他的一切都会破碎。它就像是床垫上的床单，如果不把整理好的被子弄乱，就没办法换掉铺在被子下的那张床单。

当你退回去修改玩法的时候，很多美术工作都必须得重做，尤其是UI。

在开发《4 Way Stop》的最后一年里，我大约尝试了5种不同的方案，每一次尝试都需要一个新的UI，致使之前做好的UI变得毫无价值。

经过大量的用户测试，我得出了一个结论——发生“车祸”的场景可以令玩家感到兴奋，于是我就围绕着这点定下了核心玩法：

- 多部车辆往四向停车路口开

- 车辆在停车线前停下来

- 玩家按照车辆到达（或将要到达）的顺序点击车辆

- 点击正确得分

- 点击错误会致使“点击错误的车辆”和“正确的车辆”同时行驶

- 如果两车相撞，你就输了！

本文的主要目的是提醒你不要过早抛光：如果睡觉前还得换床单的话，整理床铺只是在浪费时间。

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

Hey there, I’m Jason a developer at Noodlecake. For the past 4 years I’ve been working on the publishing team, helping make other people’s games a reality. I’ve also been working on some side projects of my own. I’ve finally released one of them under our Noodlecake Labs brand, check it out on the Play Store andiTunes! It’s free!

It took a very long time to make this happen, and I learned some interesting things about game development while developing this simple game. I want to share some of those lessons with you, so let me take you back to where it all began. In June, 2014 I was hired as a developer on the publishing team at Noodlecake Studios.

Since then, I’ve been a part of 50+ game releases across the Apple, Google and Amazon app stores.

I’ve also been delving into side projects (known as R&D within Noodlecake).

Sometime in 2014, I pulled up to a 4 way stop in snowy Saskatoon. I observed 3 cars ahead of me, mentally noted my place in line and awaited my turn.

“This could be a game!”, I thought.

“Probably could make it in a weekend.”

3 years later, that game is coming out.

What took so long? Well, a couple of things.

First, coding is hard. It always takes longer than you expect. The conventional software engineering mindset is to triple your initial estimate. I estimated a weekend. It took 3 years.

Clearly something more sinister was at play.

Let’s diverge for a second and talk about a philosophy of productivity in game development. Here’s a pictogram demonstrating my thoughts on the subject:

A “good developer” would start at the center of the circle, and work outwards. First you make the core gameplay, then you polish it, then you make it beautiful, then you finish the product and SHIP IT!

The next image is to be read from bottom to top. Each line represents a batch of changes to the project and I’ve categorized them into the 4 color categories outlined above.

You can see that I started with the core gameplay. I made cube-based cars drive up to the intersection and stop, and you’d tap them to make them go.

Here’s what it looked like around that time:

EWW! It looks horrid! Get that away from me! That’s cause there hasn’t been any blue (art) commits yet!

The game is functional here. The “cars” have to come to full stop before you can tap them. If you tap them in the order they arrive, you get a point. Tap them out of order and it’s instant game over!

WOW! It’s a game! This white box prototype took me a weekend. But it looks terrible and it’s not fun. So what do we do now?

Well, I ran out of gameplay ideas, so I turned to art. Using only the “unity cube”, different diffuse materials and tons of scaling, I came up with this:

2 months and hundreds of cubes later.

This work is all “blue” – art work. No tweaks to the gameplay. It’s seductively fun working on aesthetics. You get immediate results and it’s a more linear “time->results” feedback loop than working on coding gameplay – especially when you don’t have any clear gameplay ideas and have to go through a long series of failures.

BUT, AND HERE’S THE POINT OF THIS ARTICLE:

Do your gameplay first.

Cause 3 month’s later I had this polished turd of a game:

This iteration looks great, but it’s not fun.

The gameplay hasn’t changed at all since the initial prototype. The cars still have to come to a complete stop before you can tap them, and users were quickly frustrated and quit playing. But hey at least it looks nice…

I’d been “user testing” this game with friends and family, and no one played this thing for longer than 1 minute. Failure was upon me. I had to return to core gameplay.

I put “core gameplay” at the center of the diagram above because everything else relies on it. And when you change it, everything else breaks. It’s like the fitted sheet around the mattress on a bed. There’s no way to change that sheet without screwing up the rest of the “well made” bed.

When you go back to change the gameplay, a lot of the art has to be redone. Especially the UI.

In the last year of 4 way stop, I tried about 5 different implementations of failure conditions. I tried a “red bar” that would build up over time to a game over state, and the only way to stop it was to tap the correct car. I tried a lives system. Then I moved the red bar around. Then I built the red bar into the road. Each of these attempts required a new UI and rendered the old UI worthless. Ugh.

After tons of user testing I came to an obvious conclusion: car crashes are exciting. Fake ones anyways. I leaned into that and settled on these rules:

- Cars pull up to a 4 way stop
- They stop at the stop
- Tap the cars in the order they arrive (or will arrive – if you tap early)
- Correct taps score a point and increment your combo
- Incorrect taps cause both the tapped car and the correct car to go simultaneously
- If they crash you lose!

Here’s what the released game looks like. It still isnt perfect but that is what Noodlecake Labs is for. A place to bring ideas and concepts to life like this.

This article is meant to teach you something about game development. Specifically about polishing too early. I’m gonna close this out with an analogy:

There’s no point making the bed if you still have to change the sheets.

Check out the game on iOS and Android and thanks for reading! （Source：gamasutra.com ）