[经验分享] 从零开始学游戏编程—可视化编程游戏开发工具学习指南

[复制链接]

艾西格亚

955 主题	164 听众	7万积分

版主

Rank: 7 Rank: 7 Rank: 7

纳金币: 59338
精华: 28

电梯直达

楼主

发表于 2012-11-2 17:52:58 |只看该作者 |倒序浏览

pstatus"> 本帖最后由艾西格亚于 2013-9-3 13:02 编辑

文/王楠

本文作者是一位游戏设计师，文中他将结合自身实践分析“门外汉”学习编程的难点，并分享利用可视化编程游戏开发工具学习游戏编程的经验。

开发游戏可能是学习编程的理由中最吸引人的一条了。但如何从零开始入门，达到能够开发游戏的编程水平，是困扰无数勇敢少年们的传统难题。作为一名游戏设计师，我没有系统地学习过编程。从5年前开始，我有了自己从头完整开发游戏的念头，于是断断续续地看了很多书，试过了很多入门方法和开发环境，但直到近半年才找到正确的门路。现在我在Unity开发环境下独立制作游戏原型和利用成型的框架完善游戏功能已不成问题。

本文会介绍如何从零开始学习游戏开发编程的方法，希望能为和我一样挣扎在编程大门之外的游戏开发爱好者们提供帮助。不过事先要说明的是，这种学习思路是为了帮助你在做游戏的过程中逐渐学习编写程序，不适用于其他领域，但作为一种入门方法，它能让你在半年到一年的学习之后，做到独立制做小游戏（或原型）。

门外汉学编程的难点

介绍学习方法之前，我们先看看门外汉学编程最常遇到的问题。

第一，程序员们经常说程序语言只是编程工具，但市面上常见的教程都喜欢从语法、算法和程序语言的使用思想开始教学，而不是把编程语言当做解决实际问题的工具来入手。因此，初学者经常耗费很大精力才能理解书上写的算法和思想，却完全不知道理解之后能用来做什么。

第二，很多编程教程虽然配有实例，但一方面例子的学习难度曲线增加得很快，刚看完一个“Hello World”实例，下一个例子可能就变成教你如何分配内存（真实的故事，我的一本学习Objective-C的教程就是这样的）。另一方面初学者在对开发流程不熟悉的情况下，很难做到举一反三，从一个实例里总结出做另外三个游戏的方法，我经常遇见看了三个不同类型的游戏实例，放下书后却连一个游戏都做不出来的情况。

图1 从Hello World到实际的游戏项目之间，有一条门外汉难以跨越的鸿沟

第三，很多编程教程为了提高普适性，在使用现成架构方面都很保守，导致了很多重复造轮子的教程出现。例如在前几年Cocos2D（一个用于iOS平台游戏开发的游戏引擎）还没有现在这么火时，几乎所有的iOS游戏开发教程讲的都是如何使用OpenGLES来制作游戏图像，而这些底层架构的实现对初学者来说是根本不可能完成的任务。

因此，适合初学者的学习方针是：从实际需求出发；“怎么做”优于“为什么”（为什么可以在入门之后再慢慢理解）；使用允许你偷懒的工具或架构（需要做的越少越好）。这些要求其实很容易满足，答案恰恰在看起来和编程关系不大的领域——可视化编程工具里（Visual Programming Tools）。

可视化编程游戏引擎让你先做再想

可视化编程泛指一切使用可视化元素的操作代替文本输入的程序设计方式，大体上就是像画流程图一样通过连接若干“盒子”和“箭头”来实现程序逻辑。这个概念在游戏开发工具上的应用越来越流行，近年来还有井喷趋势，从老牌的GameMaker、RPGMaker、TorqueGameBuilder、到新兴的GameSalad、Cons***ct 2和Unity都是其中的代表。尽管这些工具和引擎各有不同的开发方式，但它们都能让初学者在完全不懂编程语法和复杂算法的情况下快速实现自己的游戏设计。

图2 在Cons***ct 2下用了7个小时制作的游戏原型，包括一个特别的同色连击系统

我之前的态度是宁可抱着“看也看不懂，看懂了也不会做”的书苦学XNA（一个微软发布的使用C#的游戏开发架构）和Cocoa（苹果发布的使用Objective-C的应用开发架构），也不屑于使用GameMaker、GameSalad之类的图形界面开发工具。认为这些工具属于“业余型”，就算能做出游戏来也是旁门左道，不能修炼内功。

直到有一次参加了柏林独立游戏BIG Jam的活动，接触了很多非常优秀的游戏开发者。他们大部分人都把GameMaker和Flash这些简单的工具当做制作独立游戏的最佳选择。原因是他们多年以前开始学习游戏开发时使用的就是这些工具，常年的使用经验让他们能在最短的时间里用这些工具实现想法。而使用这些工具从头到尾制作了大量游戏的经历，也在他们以后学习用编程语言开发游戏时打下了很好的基础。

从那之后，为了快速开发原型，我开始物色入门级的可视化编程游戏引擎。HTML5游戏引擎Cons***ct 2偶然进入了我的视线。花十几分钟学习教程实例之后，我很快用几个小时做出了一个一直在构思的游戏想法（当然想法本身就很简单，而且制作过程中碰到实现困难的设计都进行了进一步简化）。说来惭愧，尽管在主机游戏业从业多年，这次使用Cons***ct 2的开发过程中我第一次感觉到对游戏开发的整个过程和架构有了初步认识。

首先，可视化编程工具里一般都有一个现成的游戏场景（任何游戏开发过程中都需要一个画布或一个摄像机来描述玩家可以看到的图像范围），然后你需要把游戏中需要的各个元素（一般称为Actor，例如主角、敌人、子弹等，这就是编程语言里对象的概念）放进场景里，然后通过关联逻辑模块来让它们快速互动起来。Cons***ct 2的逻辑模块使用了非常贴近编程语言的按行号从上到下的执行顺序。而且你将从教程中学习到，原来游戏开始运行后每一帧都会按顺序执行一遍所有的逻辑，这就是游戏开发的基本框架中最常说的主游戏循环（Main Game Loop）。

除此之外，用户使用逻辑模块时不用担心语法错误和算法的设计，一般这类引擎里都会提供大量现成的算法模块可供挑选。只要专注于设计游戏逻辑，其他事情可以说都是软件自动帮你完成。在观看教程和其他范例项目时也一目了然，学习别人的设计思想更加容易。

都需要在每一帧的循环里进行驱动，每帧只运动一小段距离；还学到了应该在主游戏循环的什么位置判断是否Game Over，以及Game Over时进入另一个循环来等待玩家重新开始游戏等内容。

这段经历让我认识到有能力从头到尾制作游戏（或者原型）对于游戏开发的理解有多么重要。但有一个问题出现了—如果可视化工具那么好用，那为什么还要继续学习编程呢？我当时也光顾着高兴了，并没有从可视化编程工具转到真正编写代码的计划，直到……

由需求出发向编写代码的转型

直到我打算做个稍大一点的战略游戏项目，才开始在各种游戏开发工具中碰壁。接连尝试了Cons***ct 2、GameMaker、Stencyl，可不管哪一个工具都无法很容易地提供我所需要的数据结构。重新审视了需求的增加和工具的局限性之后，我才决定开始学习Unity下的C#编程。在请教了团队里的程序员和有针对性地学习了一部分数据结构知识后，我终于在Unity中搭建出了设计需要的基本游戏结构。并在之后开始正式学习Unity的C#脚本，一步步地掌握了C#里类的继承、列表和字典的使用与委托等难以读懂，学了也不知道怎么用的概念。

刚开始在Unity开发环境里独立制作游戏原型时，我也感觉从零开始独立完成所有的代码非常和困难。但幸运的是，Unity引擎有个特点，就是有一个内容非常丰富的插件市场，其中最流行的插件类型之一就是可视化编程插件。这些插件（PlayMaker、uScript、Antares Universe等）将Unity游戏开发的常用功能打包成函数块，并按需求类别归纳成组，只要花一点时间阅读手册就相当于掌握了Unity里大部分的常用函数功能。之后用户通过连接不同函数块的输入输出接口来实现完整的游戏逻辑。

当时我为了开发一个动画状态很多的动作游戏原型，购买了PlayMaker插件，并且使用这个插件强大的状态和动画控制功能第一次学习了有限状态机的制作和使用。之后又经身边的程序员指点了解到有限状态机在游戏开发中的运用非常广泛，不光是控制动画，还可以用来控制菜单和不同条件下需要不同处理方式的很多游戏逻辑。

图4 使用PlayMaker用流程图的方式设计状态机，再填入相应的功能

就像之前的Cons***ct 2一样，我也只在一个项目中使用了PlayMaker的状态机。在了解了有限状态机的基本工作方式后，我在之后的项目中都使用了团队里的程序员开发的纯代码的有限状态机系统（开源的exUnity，还包括其他Unity下的游戏开发实用架构：https://github.com/jwu/exUnity），完成了从可视化编程到代码编程的转型。

这就是Unity下的可视化编程插件很适合用来学习编程的原因：和其他较为简单的工具的区别在于，Unity使用JavaScript和C#作为脚本语言，这个环境下的可视化编程插件只是把C#函数和脚本打包成了可视化的逻辑块，并没有改变其设计思路。

对于初学者来说，用可视化插件组装起来的游戏逻辑和用C#手动编写的游戏程序几乎是一一对应的，有时甚至能精确到函数段落（例如Antares Universe里的函数块就和Unity的全部函数功能一一对应）。在已熟悉整个设计流程的情况下，只需查阅Unity官方的脚本参考手册，就能完成从可视化编程到文本编程的翻译。我经过可视化工具的启发，很快就发现插件有些臃肿和烦琐，也无法实现一些需求实现。在接下来的两个原型中就越来越多地开始手动编写代码，对工具的依赖越来越小，直到完全抛弃。

现在可以回答前面提出的“为什么有了不用编程就能开发游戏的工具，还要学习编程”的问题了。如果你的所有设计需求都可以被可视化游戏开发工具完成，那么确实不需要进一步学习编程。但如果有的需求无论如何都不能用其他工具完成，那么自己写代码来实现就是唯一的出路，这时你有强烈的需求和目标，就可以通过询问或搜索“怎么做”来学习编程并满足需求。我的程序员好友经常说：“能否学会编程其实只取决于你的需求是否强烈，不得其门而入、或半途而废的都是需求不够明确或不够强烈的人。”

可视化编程工具对于游戏开发者来说就是一个筛选需求的过程：在硬啃编程书籍时，感觉自己有100个需求，但都不知道从哪开始学习、如何去实现；使用可视化工具，可以轻松实现90个需求，剩下10个就被放大并明确化了。接下来依靠上网学习或向他人请教，终究也能自己实现（个别超出能力的需求不要强求，请别人做或者放弃都比钻牛角尖要好）。

图5 和Unity API里的函数几乎一一对应的Antares Universe的可视化编程

可视化编程工具能够培养我们由浅入深的思考习惯。先尽可能地用简单的逻辑去实现设计，如果用“盒子”和“箭头”无法完成，那么你在寻求代码上的解决方案时，就回答了“为什么要用这样的程序设计思想”的问题。经历了这个过程，你对“为什么”的理解会比一开始就去看专门讲解“为什么”的大部头程序书籍深刻许多。而通过实践理解了需求和程序设计之间的关系后，再去系统地阅读程序设计教程效果会好得多。

可视化编程虽然依赖于工具，但也能帮助你时刻把“程序语言即工具”的概念装在脑袋里。之后无论换什么引擎，用哪种语言，首先应该问自己：“这个工具能帮我做什么？我要怎样做才能实现需求？”另外，程序设计和画流程图之间的距离没有想象中那么大，通过反复用可视化编程工具画“流程图”的过程，能够从实践中学习各种游戏设计的实现方法，当你能准确地画出逻辑完美的流程图时，离你写出同样逻辑完美的程序距离已不远了。更重要的是，在这个过程中你实现了自己的想法，创造出了和书上的例程完全不同的东西，对于增强信心和进一步明确自己的学习需求的作用都是巨大的。

想学写程序，就要做程序员的朋友

最后讲下如何从身边的程序员那里获得帮助。初学者想要学写代码，有个程序员朋友能让你获益良多。当你遇到难题时，请把询问的重点集中在需求思路和关键字上，而不是一味求代码。高手提供了思路以后自己实现，或通过关键字自己寻求解决方案，都更有助于水平的提高。

从可视化编程到代码的转化中，也可以尝试使用程序员写的功能库或常用的架构。前文中提到不要重复造轮子，当抛弃可视化编程工具时，就要用现成的功能库来代替。在选用功能库时，自己信任的程序员推荐的东西总会是一个非常不错的选择，他能告诉你一个库的优缺点并且在使用过程中提供技术支持。

我在学写代码的过程中，先是自己用最简单的方式实现功能，然后一边不断阅读和学习同个独立开发团队里程序员的项目结构和代码，再使用程序员设计或惯用的架构来组织自己的代码，这样既能最快地完成工作，又能逐渐养成较好的编程习惯和深入理解程序设计思想。