自推出《Flick Buddies》后，我们就开始根据下款作品的构思创建游戏模型。最佳模型我们已在早前的GDC同发行商分享。今天我主要谈论8条有关建模的建议。

Flick Buddies from hiapp.org

1. 设定目标

确定建模目的及预期目标非常重要。这些目标告知你建模过程如何分配时间。就我们而言，就是测试玩法机制，检验游戏核心理念。第二目标就是创建可玩模型，让发行商迅速把握游戏风格。

没有这些目标，我们就很难知晓如何合理分配时间。这关乎在某平台测试机制，还是检验某玩法是否有趣？游戏最初采用素描模型是否更好？（游戏邦注：这些问题值得你在确定资源最佳用途前花时间思考）。

2. 时间期限

我总是明确限定我可以在模型花费的最长时间。开始建模后我经常忘乎所以，浪费许多不必要的时间。时间表迫使我侧重模型中最重要的元素，因为我无法覆盖所有内容。

实际分配的时限取决于具体情况。我通常给每个模型分配20个工时，这刚好是我两天的工作时间。我觉得两天是缩短时间完成所有核心要素的合理期限，这样我就能够有所侧重。

3. 摒弃模型

这对某些人来说很难，但我通常建议着手抛弃模型。下面是主要优点：

* 实用——这阻止我预先进行大量设计，迫使我仅局限于完成任务，令我持不同心态开发游戏，因为我只是希望尽快完成任务。

* 经验教训——当你开始着手真正的游戏时，安装相同功能和解决相同游戏问题就有前车之鉴。这能够帮你完善游戏设计（游戏邦注：不论是软件层面，还是玩法层面）。关于某些极其复杂的问题，我们需首先要试着解决，方能全面理解问题，找到最佳解决方案。

* 较少约束条件—–若你摆脱模型，建模时就会受到较少限制。你可以选择最适合建模的技术，而非最适合创建完整游戏的技术。若你的开发工作无需遵循任何公司方针，这就不成问题，因为活动完全属于单独行动。

你不是创建游戏基础元素，而是研究最佳创建途径，这样待到创建基础元素时，你就处于更有利地位。

4. 仅关注核心玩法

我只关注当前游戏的不同之处。若制作的是克隆内容，那建模有何意义？我挑选令游戏脱颖而出的玩法元素，进行相关测试，确保内容能够运作，做出相应调整。我们其中一个模型就是重新调整某平台游戏题材。我在游戏元素中投入较少时间，主要侧重“调整”。

另一着眼此内容的方式就是测试游戏最高风险元素。促成或破坏游戏的玩法最好尽早测试。通常我会发现某些无法运作的元素（游戏邦注：这最好在开发头几天就发现）。

5. 进行调整

我尽可能向设计师和测试者呈现内容，以便他们调整玩法。游戏将以粗糙形式呈现，因此快速调整核心玩法能够确保游戏朝正确方面发展。

我们的另一模型是异步策略游戏。我呈现开头和获胜情形以及所有元件数据。稍微调整这些内容就会完全改变游戏体验方式。这非常适合模型，因为所有人都能接触测试值，提出原型调整建议。这将模型试验、平衡和调整任务转移到其他游戏体验者身上。

6. 划分游戏

若我面对的是款大型作品，我会把不同元素划分到独立模型中。例如，在《全面战争》系列中，我把策略和战斗地图归纳到完全不同的模型中。这里有若干突出优点：

* 必要时，独立团队能够应对单个模型

* 若有所帮助，可以采用不同技术和工具

* 可以单独评判某游戏要件。也许某些部分不够有趣？你可以把每个部分当作单独游戏，轻松判断优劣。

7. 瞄准目标平台

我发现要完全呈现某个模型的用户体验，最好瞄准某个目标平台。这是玩法体验的核心，某些平台还会完全改变模型所得到的反馈。

只有当其打乱时间安排时，我才会放弃此策略，或者出现其他限制条件促使此策略无法实现（游戏邦注：例如平台所有者的限制）。在这种情况下，我竭尽所能模仿平台运作方式，尽量让用户体验接近实际平台。

8. 外部资源

有些内容最好在模型外完成，以便节省时间。我通常会制作游戏指南和附有系列说明的游戏辅助截屏。通过Photoshop操作要比在模型中落实快很多。虽然使用截屏充当游戏指南算不上优质用户体验，但它省下安装其他模型功能的时间。

另一节约时间的方式是亲自指导用户体验模型，而非借助指南。我喜欢看到大家尽可能地体验模型，向他们解释游戏玩法是开展模型讨论的最佳方式。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Prototyping Tips

Since the release of Flick Buddies, I’ve been prototyping game ideas for our next game. The best of these prototypes we’re taking to GDC to show publishers. Today I’m sharing my list of tips for creating prototypes.

1. Set Your Goals

It’s important to decide exactly why you’re making the prototype, and what you hope to achieve. These goals show you where to focus your time while developing the prototype. For us it’s about testing gameplay mechanics and proving the core concept of the game. A secondary goal is having playable prototypes we can show potential publishers to quickly get across the feel of the game.

Without these goals, it’s difficult to know where your time is best spent. Is this about testing a mechanic on a particular platform or finding whether certain gameplay is fun? Could the game better be served by a pen and paper prototype first? It’s worth spending some time before you begin, deciding the best use of your resources.

2. Timeboxing

I always set a specific limit on how long I can afford to spend on the prototype. It’s easy to get carried away once I start and I can easily lose a lot more time than is necessary. Timeboxing forces me to focus on the most important elements of the prototype as I can’t do everything.

The actual length of time allocated depends entirely on your situation. I allocate 20 man hours per prototype which fits nicely into two work days for me. I find two days is the perfect length for completing the core elements while keeping time short so I am forced to focus.

3. Throw It Away

This is a tough one for some people, but I always recommend planning to throw the prototype away. This has a number of core benefits:

* Pragmatic – This stops me from doing any big design up front and forces me to do just enough to get the task done. It puts me in a completely different mindset while developing as I just want to get it done as quickly as possible.

* Lessons learned – When you begin work on the real game you will have previous experience in implementing the same features and solving the same problems. This will help improve the design of the game, both at a software and gameplay level. With some particularly complex problems (“wicked problems” according to McConnell) we must try solving the problem first, before we can fully understand it and find the optimal solution.

* Less Constraints – If you’re throwing away the prototype there’s less constraints on how you build the prototype. You can use whatever technology is best for prototyping, rather than the best for creating complete games. If you don’t follow company (or personal) guidelines during the development it’s less of an issue, as it’s a completely separate act.

Rather than laying the foundations for your game your doing the opposite, investigating the best way to build it so that when the time comes to lay the foundations you’re in a better position.

4. Key Gameplay Only

I only focus on what’s different about the current game. If I’m making a clone, then really, what’s the point in prototyping? I pick out the gameplay elements that make the game stand out and test those to make sure they work and tweak them. One of our prototypes is a new twist on the platformer genre. I spent as little time on the platformer elements and focussed on “the twist”.

Another way of looking at this is to test the highest risk elements of the game. Gameplay that will make or break the game is important to test as early as possible. Often I find some ideas simply don’t work, and it’s much better to find this out in the first few days of development.

5. Allow Tweaking

I expose as much as possible to my designers and even play testers so they can tweak the gameplay. The game will be in a very rough form and allowing rapid changes to core gameplay can help steer the game in the correct direction.

Another of our prototypes is an asynchronous strategy game. I’ve exposed the start and win conditions and all unit stats. Small changes to these completely change the way the game plays. This is perfect for a prototype as it lets anyone play with the values and suggest changes to the originals. This pushes the burden of experimenting, balancing and tweaking off the prototype team and onto anyone else that plays the game.

6. Divide The Game Up

If I’m working on a large game I’ll divide the different elements up into separate prototypes. For example in the “Total War” series I would make the strategic and battle maps completely different prototypes. This has a number of core benefits:

* Separate teams can work on each prototype if needed

* Different technology and tools can be used if helpful

* Each individual part of the game can be judged independently. Perhaps some areas are less fun than others? You can look at each part as its own game and easily see its strengths and weaknesses.

7. Run On Target Platform

I always find that to get the full user experience of a prototype it’s best to run on the target platform. This is core to the gameplay experience and for certain platforms will completely alter the reaction to the prototype.

The only time I don’t do this is when it will blow out the schedule to do so or if there are other constraints that make it impossible (e.g. platform owner restrictions). In this case I do my best to imitate the platform it will run on to get the user experience as close to the real platform as possible.

8. Have External Material

Some things are better completed outside of the prototype itself to save time. I often write tutorials and help screens as a series of screenshots of the game with instructions overlayed. This is far quicker to do in Photoshop than implementing within the prototype. While having screenshots as a tutorial isn’t as good a user experience it saves time that can be spent implementing other features of the prototype.

Another time saver is to walk people through the prototype personally, replacing the tutorial. I like to watch people playing the prototype as much as possible and explaining the game to them is the perfect way to open up a dialog about the prototype.

Conclusion

What are your tips for prototyping? How long do you like to spend and do you throw them away once finished? （Source：doolwind）