作者：Jay Weston

如果你是美术人员或设计师，你可能会发现自己的编码能力与特长并不相称——我自己就是如此。我的专长在于设计游戏，但如果没有代码，你就无法制作游戏，不是吗？但有了Unity和Playmaker（Unity的可视化脚本系统），这就不是问题了。

利用业余时间与Binary Space程序员/首席技术官Saxon Druce联手制作了《Zombie Outbreak Simulator》和《Class 3 Outbreak》这两款游戏之后，我打算推出更多游戏以丰富自己的游戏设计履历，但同时我又希望这些游戏是小型且易于实现的项目。

我将《Zombie Outbreak Simulator》移植到iOS平台时玩了大量iOS游戏，并且对《Tiny Wings》尤为着迷。从游戏玩家的角度来看，我就是喜欢这种一个接一个完美跳跃的感觉。而从经济角度考虑，我很欣赏这款游戏实际上只有一个关卡并且玩法极为简单的设计，它的开发时间更为迅速。

掂量了一些游戏理念之后，我最终决定制作一款第一人称视角的3D版《Tiny Wings》。我只用Unity，尝试通过一些基本的物理代码让一颗球在地形引擎上滚动，经过一周左右的时间，取得了较为满意的结果。

但同时，作为一个最无助的编码员，这个过程极为缓慢且令人抓狂。我不但要费力地搞定3D物理和向量问题，还要想法摆平Unity引擎以及JavaScript！有些创意人员可以不费吹灰之力地完成一些脚本，遗憾的是我不属于这种人，并且掌握这项游戏开发本领可能需要我投入数年时间进行学习和实践，但已经到了32岁的我是绝对不愿意这样做的！

进入Playmaker

在查看Unity的Asset Store时，我找到了Playmaker。它是一个可视化脚本系统/状态机管理器，使用状态（游戏邦注：它包含动作，每个动作都是预先编写好的代码片段）和转变来开发游戏。举一个很简单的例子：你可以为一个有限状态机（以下简称FSM）分配一个“战斗”、“闲置”和“行走”等状态的字符。

在每个状态中，都可以包含动画动作、光线投射/射击动作和移动支作。每个状态之间的转变都要使用到事件，例如，在闲置状态中，你可以增加一个等待鼠标左击的动作。状态中每个动作实际上都是一个预先制定的代码片段，你可以对其进行调整，将其拼凑一起创建一个状态机，最终形成完整的游戏。

playmaker’s test lab(from gamasutra)

从上图中可知，对于非技术人员来说，这些可视化状态机真是太强大了。我每次看到代码模块时，就好想看到一堵天书墙，根本不懂这些代码的作用是什么，何时发生作用，以及在特定节点的用处。但使用Playmaker，我就可以只看将状态机立即领会发生了什么情况。

通过Playmaker，我完成了自己的首个作品《Unknown Orbit》，玩家可在一个类似彗星的超现实3D行星系中漂浮、跳跃和飞翔。我在闲暇时间开发这款游戏，耗时约为一年左右。如果是全职开发这款游戏，我想可能只需要半年。如果是现在，因为我已经更为娴熟地掌握了Unity和Playmaker用法，所以可能只需要几个月时间就能完成了。

unknown orbit(from gamasutra)

以下是《Unknown Orbit》的一个FSM例子，玩家在其中执行的动作是拣起雪球。左边是控制我们何时切换状态的状态和转变。中间面板显示的是“自我毁灭”动作里面的动作。在这个FSM中，当玩家飞向雪球并拾取后者时，就会传播一个名为“增加雪球”的事件。

分配给拾取雪球的状态机(from gamasutra)

彗星对象会通过“整体转变”接到这个信息，并输入一个增加彗星冰核半径的状态。

分配给冰/雪对象的状态机(from gamasutra)

权衡利弊

你可能会问，这其中有什么弊端吗？那就是，由于系统中存在额外未使用的容量，所以某些区域会出现一些小小的运行性能问题。要知道Playmaker并非针对特定类型游戏而优化的工具，Unity也不是。但今天的硬件设备很强大，所以除非你真的要做特别疯狂的项目，你应该是不会遇到太大的问题。

我遇到的另一个问题就是，由于游戏开发过程中的一些抽象层次，你有时候可能会觉得无力去修补问题。我可能会在发现一个漏洞后，花了好几天去修复它，但却未必解决根源上的问题。我想多数游戏通常都会遇到这类问题，在使用他人引擎/代码/API的时候尤其如此；但是，当你使用一个引擎所附带的插件时，情况会更为棘手。所幸Unity和Playmaker都有出色的技术支持，并且我是与一个使用Unity和Playmaker的高手直接合作，所以每次遇到自己不能解决的问题时，我都可以向对方求助。

另外（虽然我还没有遇上这个问题），你使用的Unity插件越多，就越可能遇上故障，或者得不到其开发者的技术支持。如果你选择搭配插件使用Unity，我建议你选择那些已经出现了一些时日，并且经常更新，其开发者在论坛中处于活跃状态的插件。就我自己的情况而言，Playmaker已经能够支持我所选择的界面插件，因为我选择的插件已经问世有一段时间了，使用起来也很顺手。

优势

从游戏设计来看，Unity和Playmaker几乎可让你完全专注于创建和测试理念。我个人更重视游戏设计，所以这一特点便于我快速验证自己的游戏理念是否可行，在短时间内快速练习和掌握经验。

如果你是一个常规大型工作室的游戏设计师，你可能会制作“第N个可靠无风险的续作”，虽然你可能有一些自由发挥的空间，但却很难真正施展手脚，尝试完全不同或独特的设计理念。假设，你是一名“卡”制作赛车游戏上的设计师，你可以用相对轻松的方式和较少的时间投入，先在其他题材的游戏中练练手。

我还认为，参与项目的人数越少，设计理念就越独特和奇异，从而制作出更具个性化的游戏。使用这些工具几乎可以让你置身于一个创建了图像/物理/动画等引擎的团队，让你随心所欲地实践自己的设计理念。

精简型团队

我也是一个奉行精简型团队理念的人，Eric Reis正是因这一理念而得名。不少公司试图验证产品或服务理念可行性时，都会采用精简型团队的运营模式，并快速研发一个最小可行性产品（游戏邦注：minimum viable product，即MVP），在此基础上迭代，并迅速获取用户反馈。这种方法不同于传统的游戏开发过程，即首先通过设计文件敲定项目，然后制作游戏，最后就只能祈求游戏热卖。

针对精简型团队战略，我认为结合使用Unity和Playmaker当然是值得希望快速制作MVP或原型理念的大型工作室，以及独立小型工作室考虑的方法，在你缺乏编码员或者就是想单干的情况下更是如此！通过大众融资平台Kickstarter，你就可以执行精简型团队的游戏开发策略，快速创建原型，推出Kickstarter项目提案，然后通过人们的支持意愿来判断这个项目是否值得一试。

那么，我又是如何执行这种精简型团队战略的呢？因为这是我第一个Unity项目，我通过精简型方法挑选了不同理念，决定从中筛选出一个可行的游戏理念。我观察了《Tiny Wings》、《Dino Run》、《Dolphin Olympics》以及其他类似的游戏；因为这些游戏已经获得了成功，所以我瞄准的实际上是拥有一定成功机率的游戏理念。如果你愿意，你还可以彻底一点，通过在谷歌或Facebook上创建条幅广告或文本广告，查看你所收获的点击率，由此判断你的理念是否有望获得成功。

随后我选择了一个自己熟悉的美术风格——-我拥有3D美术/纹理背景，在此无需动画技能，AI技术，我只需要凭直觉来调整一个极为简单的游戏机制。借助Unity的内置物理系统，我只用几天就完成了MVP，我向几个好友展示了作品，得到认可后开始进入制作成品阶段。

通过制作《Zombie Outbreak Simulator》的经验，我对freesound.org也颇为了解，我从中快速且免费找到了游戏中所需的声音。至于音乐，我的朋友Rhys Lindsay为我录制了一个很棒的曲子。因此我能够全心投入学习和调整游戏的过程。

我之所以遵循精简型团队模式，很大程度上是看中它能以最小资产需求、最小开支，快速且经常迭代地创造出MVP和最终产品的优势。老实说，我其实并不是很敢于向好友之外的其他人需求早期反馈信息，因为我真的担心自己还在摸索着怎么开发游戏的过程中，就已经有人抢先一步，窃取了我的创意。并且我也希望在有限的反馈条件下，制作一些富有自我风格的游戏。有趣的是，在接近项目尾声时，我发现与测试者合作并且获得他们的反馈，其实对我真的很有帮助，并且趣味无穷。

根据我独自使用Playmaker完成一款Unity游戏的经验，我建议具有类似情况的开发者采取以下做法：

1.瞄准你能够独立完成并且发挥自己优势的小型、简单游戏。我原先认为《Unknown Orbit》太容易了，我只要几个月就能完成。如果我克隆《Tiny Wings》，而不是采用困难的3D小行星/月亮设置，也许这真的有可能成真。但是，你还得考虑到有些事情会让你耗费大量时间——你如角色和动画。如果你自己没有美术经验，即使是简单的3D建模也会让你大费功夫。我最早的工作是3D建模师，但也还是花了好多时间重新了解Blender的情况。

2.要以可重用的资产制作简单的美术风格和玩法循环。含有大量内容，基于故事的游戏，带有20个独特关卡的游戏会耗费很多制作资产的时间，而像《Super Hexagon》这种游戏则是美术资产不多的完美典型。

3.使用Creative Commons资产，尤其是制作声音和音乐。Freesound.org最棒！要确定你已经阅读了CC资产的授权条款，了解它是否允许商业用途。我完整保留了文件名称，以免遭遇侵权问题。

4.最好借助一些使用指南。他们可以是Unity和Playmaker论坛的活跃成员，也可以是Unity对话渠道，或者各种Playmaker/Unity 3d教程。我极力推荐你查看WellPlayedGames教程以便学习Playmaker。如果没有这些帮助，我可能真的要花更长时间胡乱摸索。

5.你可能还是至少需要一些代码。不过我有Binary Space成员Saxon的帮助，所以能够顺利完成高分系统。随着Playmaker的发展，我们未来也许将使用更少的代码来制作游戏，但目前来看，我认为还是有许多游戏至少需要一些代码。

当然，有些游戏还是需要编码员，但证明你自己能够独立制作/发布一款完整的游戏，其实也是在向你自己、潜在合作伙伴、基金会、Kickstarter捐赠者等人证明，你具有完成任务的信念。

题外话，我还发现使用Playmaker巩固了我对面向对象设计，以及其他编程/设计概念的了解。所以我认为了解这些概念还是很有帮助的。

如果你是一个创意人员或者只是想以最快速度推出一个原型，我严重建议你试试Unity/Playmaker这个组合方法。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Suck at Coding, But Make Games Anyway

by Jay Weston

If you’re an artist or designer, you may find that your ability to code seems opposite to your main talents — I have certainly found this myself! My main passion is game design, but without code, you can’t make a game, right? With tools like Unity and Playmaker (a visual scripting system for Unity) this isn’t necessarily the case.

After working part time on a couple of games, Zombie Outbreak Simulator and Class 3 Outbreak for a few years with Binary Space’s programmer/CTO Saxon Druce, I was looking to add more titles to my game designer belt, but at the same time I wanted to keep things small-scale and achievable.

I had been playing a lot of iOS games while we ported Zombie Outbreak Simulator to iOS, and Tiny Wings in particular had me completely enthralled. From a gamer standpoint, I loved the feeling you got of being in the zone, getting perfect jump after perfect jump. From a business standpoint, I loved that it was essentially one level and extremely simple gameplay, hence quick development time.

After toying with a few ideas for games, I ultimately decided to try a version of Tiny Wings that was first person, in 3D. Using just Unity, I struggled through some basic physics code to get a ball rolling around on its terrain engine (I can hear you laughing) and after a week or so, I was quite happy with the result.

However, being the most hopeless coder of all time, progress was slow and infuriating. Not only was I trying to get my head around 3D physics and vectors, but also Unity itself, AND JavaScript! There are some creatives that can bash out some script without much problem, but I’m not one of them, and to learn this side of game development would set me back arguably years of study and practice, which at the ripe age of 32 I’m not willing to do!

Enter Playmaker

Somehow — I think while looking through Unity’s Asset Store — I found Playmaker. Playmaker is a visual scripting system / state machine manager, which uses states (which house actions, each a snippet of pre-written code) and transitions to develop a game. A highly simplified example: You can attach a finite state machine, or “FSM”, to a character with the states “fighting,” “idle,” and “walking.”

Within each of these states, you can include animation actions, raycasting/shooting actions and movement actions. You transition between each state using events, i.e. within the idle state, you would add an action that waits for a left mouse click. This left mouse click triggers a transition event to the shooting state. Each action in a state is essentially a pre-made piece of code that you can tweak and fit together to create a state machine, and eventually an entire game.

Playmaker’s Test Lab example scene, which controls simple opening/closing doors

You can see from the above image how, for the non-technical, these visual state machines are so powerful. When I look at a block of code, I see a wall of text, and try in vain to understand what it does, when it triggers, and what it’s doing at any given point. With Playmaker, I can glance at an FSM and see what it does in almost an instant.

I can also see not only what it is doing in real time in the visual editor, but also in the game view, where each object will display which state it is in. I can’t tell you how good this is for debugging and just general understanding of what your FSM and the game in general is doing. Add to this things like debug rays, break points, and more, and you get a very clear understanding of what’s happening.

Using Playmaker, I’ve just completed my first (mostly solo) creation, Unknown Orbit, where you can float, jump and fly around a surreal, 3D planetary system as a comet. Part-time, this game has taken me about a year. Full-time, I imagine it would have taken six months, and now that I’ve learned Unity and Playmaker to a greater level, I think the game could be recreated in a few months if not less.

Unknown Orbit

Here’s a quick example of an FSM for Unknown Orbit, where the player picks up snowballs. On the left are the states and transitions that control when we move between states. The middle pane is currently showing the actions inside the “destroy self” action. In this FSM, when the player flies into a snowball and picks it up, an event is broadcast called “Add snow”.

The state machine attached to a snowball pickup in Unknown Orbit (click for larger version)

The comet object hears this broadcast via a “global transition”, and enters a state that increases the radius of the comet’s ice core.

The Tradeoffs

So what are the tradeoffs, you may ask? Well, you will have some memory overhead loading everything in, and yes, there are some small performance hits in some areas because of all the extra unused capability in the system. Playmaker isn’t optimized for any particular type of game, and neither is Unity. But today’s hardware is so powerful that unless you are doing something pretty crazy, you probably won’t hit the wall any sooner than you would using other approaches.

Another trade-off that I encountered was that due to a couple of levels of abstraction in the game-making process, you can sometimes feel helpless to fix problems. I would find a bug and spend days trying to fix it, and be clueless to the source of the problem. I imagine this is common to some extent in most games, especially where you use someone else’s engine/code/API; however, when you are using an engine with a plugin to that engine, things can get tricky. Luckily both Unity and Playmaker have excellent support, and I further mitigated this by working directly with an expert in both Unity and Playmaker whenever I encountered problems I couldn’t solve.

Also, while I have yet to encounter this, the more plugins you use with Unity, the higher your chances of conflicts, or of the creator disappearing/no longer providing support. If you are selecting plugin(s) to use with Unity, I suggest choosing ones that have been around for a while, receive frequent updates, and whose creators are active in their own forums. In my case, Playmaker actually supports my chosen interface plugin, which has also been around for some time, which was very handy.

The Advantages

In terms of game design, Unity and Playmaker are great in allowing you to focus almost entirely on building and testing ideas as quickly as possible. I’m personally focused on game design, so this allows me to create ideas and prove/disprove them quickly, getting in as much practice and experience as possible in a short time span. I jumped out of games into a business and back again a few years ago, so I feel like I’m getting to make up some lost ground now!

If you’re a game designer at a typical large studio, you might be making “safe sequel number 9999,” and while you may have some room to move, you can hardly flex your muscles and push yourself in terms of wildly different or unique designs. If for example you’re a designer “stuck” making say, racing games (happily or otherwise) you could practice in other genres with relative ease and low time commitment.

I also believe that the fewer people you have on a project, the more unique and singular the design vision will be, creating more individual games. Using these tools almost puts you into a team that has created a graphics/physics/animation/etc. engine and lets you run wild with whatever design you like, with little in the way of restrictions.

The Lean Startup?

I’m also a big fan of lean startup principles, a concept that Eric Reis is famous for. Lean startup is mostly a business approach where companies attempt to prove product or service ideas prior to launch, then quickly develop a minimum viable product (MVP), iterate on it, and get customer feedback as quickly as possible. This is the opposite to how games are traditionally created, where you define the game first via a design document, make the game, then hope it will sell well.

For lean startup strategy, I think this combination of Unity and Playmaker is certainly something to consider for both large studios wanting to prototype ideas/MVPs quickly, or for solo/small teams, especially if you lack a coder and just want to dive in yourself! Throw in Kickstarter (a crowd funding solution), and you have a very nice lean startup strategy of game development where you can quickly create a prototype, develop a Kickstarter pitch, then prove whether people would pay for your game before you have heavily invested in it.

(If you’d like to know more, you can read Tyler York’s Gamasutra article on lean startup for games.)

So how did I follow the lean startup approach, exactly? Well, I did and I didn’t. Because this was my first Unity title, and I was going to be learning a lot, I picked and chose various concepts from lean methodology while I decided to play it safe and attempt a fairly proven game concept. I looked at Tiny Wings, Dino Run, Dolphin Olympics, and other games that were similar, and decided that because those games have had some success, that I was already aiming for a concept that would have a good enough chance of success. If you like, you can go the whole hog and try to prove whether your idea would be popular by creating banner adverts or text ads on Google or Facebook, and see what sort of clickthrough rate you receive.

I then chose an art style that I was familiar with — I have 3D art/texturing as my background, with no animation required (I have no skills there), no AI, and just an extremely simple game mechanic that I could tune based on feel. My minimum viable product was done in days due to Unity’s built-in physics; I showed some friends who approved, and I was then on to the finished product.

From my work on Zombie Outbreak Simulator, I was also familiar with freesound.org, where I sourced almost every sound in the game, quickly and free! For music, my friend Rhys Lindsay recorded me an awesome spaced-out track. This left me to concentrate entirely on the learning process and fine-tuning the game.

I would say that I followed lean startup mostly in respect to creating an MVP and final product with the minimum asset requirements, minimum spend, while iterating quickly and often. I honestly was a complete coward in terms of getting early feedback from anyone but friends, as I was genuinely scared that someone would steal my idea while I crept along at a snail’s pace learning how to make it. I also just wanted to make something that was uniquely me, with little outside feedback. Funnily enough, towards the end of the project, I found it really helpful and great fun to work with testers and get their feedback. My apologies to them for not being able to add more planets! Perhaps in a future update!

Having now completed one Unity game using Playmaker on my own, I have the following advice for developers in a similar situation:

1.Aim for small, simple games you can do yourself, and play to your existing strengths. I thought Unknown Orbit would be so simple I’d get it done in a few months. If I’d cloned Tiny Wings, and not gone for a rather difficult 3D planetoid/moon setup, then perhaps that would have worked. However, you should think about things that will take up a lot of your time — namely characters and animation. Even simple 3D modeling will take you some time if you don’t come from an art background. My first job was a 3D modeler, but it still took me time to get back up to speed on Blender.

2.Use a simple art style with reusable assets and gameplay loops (see this Lost Garden post on loops vs. arcs.) A story-based game with loads of content and 20 unique levels will take a long time just to create the assets, whereas something like Super Hexagon is the perfect example of a game with little in the way of art assets.

3.Use Creative Commons assets, especially for sound and music. Freesound.org is the best! Make sure you don’t just note that there is a CC logo attached — read the license and make it sure allows commercial use. I leave the file names intact so that I can go back and make sure everyone is credited properly.

4.Try to find an advisor of some sort. This can be anything from the people on the Unity and Playmaker forums, to the unity chat channel, or the numerous playmaker/unity3d tutorials. I highly suggest looking at WellPlayedGames tutorials for learning Playmaker. Without a helping hand or two, I would have spent a lot more time banging my head against the wall.

5.You will probably need at least one or two bits of code (shock horror!) I had Saxon from Binary Space on my side to help with the high score system. As Playmaker progresses, chances are we will need less and less code, but for now I think a good number of games will need at least a little. One recent addition has been an array maker that Jean Fabre has written, which I could have potentially used for the high score system.

So yes, coders might still be required for some games, but proving that you can make/release a whole game on your own will prove to yourself, potential partners, funders, Kickstarter backers, etc. that you have a work ethic and can get things done.

As a further note, strangely enough I’ve found that using Playmaker has actually solidified my understanding of things like object oriented design and other programming/design concepts. So I think it can be helpful in learning these concepts as well!

If you’re a creative or just really want to bang out a prototype with great speed, I highly recommend you try out this combo of Unity/Playmaker.

Here’s the end result of a years worth of work (part time) on Unknown Orbit, by one guy with no programming experience, some 3D skills, and some game design background, made using the iOS version of Unity and Playmaker.（source：gamasutra）