之前有发过相关的资源索引，原创教程，练习，甚至是源代码。但很多感兴趣的人还是不了解从何入手。自己接触 Creative Coding 有一段时间了，虽算不上专家，但也有一定了解。这里想分享一点个人的学习心得，谈谈设计师应该如何自学创意编程。

关于自学

创意编程可以自学吗？据我了解，圈子里真正玩得好的高手，都是从自学开始。自学不仅仅是一种学习形式，其中最关键的，是思维方式的养成。它是可复用，可迭代进化的，并且不仅局限在单一领域。

当初自己为什么选择这种方式呢？不是因为有先见之明，了解自学有这等好处，仅仅是因为没有条件。学校没开设这类课程，身边也没有认识会这个的朋友，也就不得不自学了。

很多人觉得自学的难处之一是，没有氛围，一个人难以坚持。现在有了互联网，情况大不一样了。通过国内外的各种社交媒体，论坛网站，你可以了解到领域里最前沿的人物，他们近期的动向。看过什么，如何思考问题，做了什么练习，产出什么作品，这些信息都可以刺激你。

如果你勤学好问，你甚至可以直接向这些前辈请教。前提是展示你为了获得这个问题做了哪些努力。

所以只要有一台能上网，可翻墙的电脑，你就具备了最基本的自学条件，剩下只是方法的问题。

创意编程的魅力所在

讲如何学之前，还是先谈谈为什么学。

创意编程。我的个人理解，就是用代码画画。如果你本身就是设计师或插画师。那现在，你仅仅是换了一个图形表达工具而已。

那创意编程能有什么具体的应用价值呢？“有什么用？”，其实不是个好问题。我更喜欢回答，它为什么有趣。

对于一个艺术家来说，一辈子的追求无非就是形成自我风格。你可能穷其一生，最终可以熟练驾驭几种画风。但你却无法做到掌握所有人的绘画风格。

用油画创作一幅作品，你可能需要一个月。发明了手绘板，数位屏这些工具，可以将时间缩短到1天。将来脑电技术成熟，你甚至可能用意念来画画，时间将更短。

这些都是由于工具的革新所带来的。但人的思维速度再怎么快，也不可能在一秒内创作100张作品。这是人的思维局限，也是传统创作工具的局限。

通过计算机则不一样。你只要了解自己是如何思考，并将这个思考过程用编程语言去描述，计算机就能帮你实现。

要知道，当今最有想象力，最不可思议的事情，都与计算机发生关联。而通过编程，可以将你的想法延伸到更多的地方。

2015年9月，Leon A. Gatys等人基于神经网络的论文就让大家看到了可能性。

当然，还是有人喜欢用画笔去完成这种探索，我更倾向用计算机。在我看来，编程对于图形创作而言，就是个潘多拉魔盒。下面我想讲讲它的打开方式～

设计师学编程，选哪门语言？

自己其实在大学期间就对编程产生过兴趣，也浅尝辄止地了解过一些编程语言，诸如 VB，C，后来还包括 python，最终都没有坚持下去。

后来总结了一个原因，学习这些编程语言的反馈周期太长了。并且都是从抽象的概念开始讲起，输入输出都是一串数字，相当不直观。

直到我在一年前遇到 Processing。发现它简直就是为设计师这种视觉生物所量身定做的。简单的代码，就能写出十分丰富的视觉效果。过往在编程中抽象的概念，这里都会以一种鲜活的视觉形式呈现出来，十分有趣。

之后它一直让我爱不释手。由于反馈直观，每次练习都与画画无疑。所以会持续刺激自己，去用代码进行更多图形上的探索。

Processing的设计理念，是让设计师，艺术家都可以轻松地掌握编程。虽然门槛降低了，不代表它是一门“玩具”语言。毕竟编程语言都许多概念都是相通的，而 Processing 本身又基于 Java，所以此门语言的一些基础编程概念，在其他语言中也一样有。假如以后你想学习一门新语言，你在Processing 上打下的基础都能发挥作用。

我自己的所有编程基础的修炼，都是在Processing上完成的。我认为Processing是设计师进入代码世界的首选工具。

信息源头

有了目标，就需要去寻找相关的学习资源了。这里是之前自己整理的一份资源清单。（CreativeCoding 资源索引）

里面的信息对初学者而言已经足够全了，开始时无需考虑过多，先选一本基础教程，老老实实从它学起。除了基础书籍之外，索引里还提到了一些诸如软件的诞生地，语言的开山鼻祖以及相关的资源网站，只要按图索骥，这些信息可以帮助你对这个领域有一个概貌的了解。

值得一提的是，除了上面的链接。Processing自身的范例库做得相当完善，如果本身有代码基础，那几乎只通过范例库，就能学会这门语言了。

除了 Processing ，里面还提到了另一门创意编程的主流工具叫 Openframeworks（简称OF）。它们都是最主流的创意编程工具之一。格式，写法十分相像。OF有它自身强大的地方，比如它是基于C＋＋的，运行效率更高。支持跨平台，代码几乎可以不做任何改动，就能在Windows和Mac OS上执行。而且还能开发App。

尽管如此，对于初学者，我还是推荐先从 Processing 入手，因为它有更丰富的学习资源，更详尽的文档，更友善的社区。这些都是 Openframeworks 不具备的。

对于外语基础不太好的朋友，Processing 最好的一点就是有大量的中文教程，感谢国内这些前辈为推广创意编程所做的努力。

如何看教程？

编程和画画一样，是门手艺。光看不练，是学不会的。看教程“看”不是重点，练才是重点。只有通过实打实地敲代码，你的代码能力才可能提高。

以《爱上Processing》一书为例，书中有不少代码示例。但仅仅看上面的实例是不完全不够的，要想真正掌握需要分三步：理解，模仿，重组。

要吃透某个概念，你要首先理解它通过文本所叙述出的概念。接着，再放到程序的语境中去理解它，敲出同样的代码。而要检验自己是否真正理解，你就需要主动去实验。比如修改某个参数，调整某个语句的位置，这代表你有真正去思考，而不是简单地复制命令。

如果你这步已经做到了，不妨对实例进行“默写”，不看示例代码。看自己能否清晰，流畅地将代码写出来，以此检验自己的熟悉程度。

到最后，不要局限于示例本身。你需要重组知识点，这个过程同时是创造的过程。好比你新学了 for 循环，书中给出的例子都是画线和画圆的。那你应该去思考，如何做些简单的修改，可以做出不同的效果？例如可不可以用 arc，triangle,beginShape - endShape 这些绘图函数去画。或者利用 “i”，给每个图形赋上不同的颜色。

只有走到重组这一步，才会真正成为自己的知识。而无论什么类型的教程，学习无非是这几个过程的循环。

如何练习更有效？寻找“学习区”

练习也是有技巧的。心理学里面有一个概念叫做“刻意练习”。一万小时理论可能大家都听过。大意是无论做什么，只要坚持一万小时，基本上都可以成为该领域的专家。

但其实这不是一次很不严谨的演绎。不同领域从新手到专家的习得时间都是不一样的。就像大多数人看电影电视剧，都超过一万小时，但不见得变成专家了。

所以关键不是练习时间的长短，而是练习的方法。所以就有了“刻意练习”这个说法。也只有刻意练习，才是从新手进化为专家的关键。

有人将刻意练习的内容总结成以下四点：

1.只在“学习区”学习
2.把训练内容分成有针对性的小块，对每个小块进行重复练习
3.在整个练习过程中，随时能获得有效反馈
4.练习时，注意力高度集中

程序本身就能提供即时的反馈。所以第三点并不存在问题。

关键会是第 1 点，什么是学习区？

人的知识技能分为层层嵌套的三个区域。那些我们已经熟练掌握的技能，就处在舒适区。那些我们暂时无法学会的技能，就是恐慌区。两者之间就是学习区，刚好够得着，又需要时间去掌握的。

要做到有效的练习，就应该在自己所处的学习区进行学习。一旦学会了，就转入下一个难点。

而明白这点，就会减少许多学习上的困惑。

比如你第一天接触编程，刚掌握了 print(“Hello,world!”); 的写法，这个知识点对你而言就处在学习区，第二天你只要多重复练习，你就会完全熟悉它，它也会从原来的学习区的位置变为舒适区。之后你要做的就不是继续揪着 print 这类自己完全熟悉的内容，而是去学习新知识。

另一种情形，则是揪着恐慌区的知识不放，这往往是最常见的，也是导致许多人认为编程很难的原因。

当你学习有段时间了，肯定不会满足于书本上的例子。通过各种资源网站，你必然能找到一些很炫，或者很有趣的案例，你直接下载了源代码，并且很想学习它。

如果你能理解，当然最好。但通常下面两种情况会出现得更多。一，里面的代码很多都不认识。二，每句代码都认识，但是不明白彼此之间是如何组织的。

如果是情况1，那说明是语法和基础概念还没学好，此时应该先去踏实地看基础教程，查清每个函数的用法。如果是情况2，你这时你就应该尝试把这段程序分解，将每个小块的概念，逐个消化。如果你发觉，仍然是超出自己所能理解的限度了。就应该搁置它，先从其它相关的，更简单的例子开始了解，不要一上手就去做复杂的东西。

知识的吸收不是一触而就，更不代表你把它完全背下来了，就真正掌握。在我看来，大部分的代码问题都由一个共同原因所导致：基础没打好。当某些函数的用法，代码的组织方式你还没摸索清楚，你这样硬学下来的知识，都是模糊的，碎片化的。

只要明白这点，即使你在程序上遇到一些暂时还无法实现效果，也不会苦恼，不会自惭形秽了。因为随着练习的增多，知识版图的扩大，有很多问题是不言自明的。与其硬啃，在恐慌区揪着那些自己还没法吸收的知识。不如放慢脚步，打好基础。

在“学习区学习”，用过去最通俗的说法，就是“循序渐进”。编程并不难，只要找准自己的学习节奏即可。

刻意练习，大量输出

知道练习的重要性了，也知道要在学习区练习。那有没有具体的参考指标？

如果以案例作为衡量单位。从零开始的话，把 print（“hello，world”）这类也算上。

基本写够 500 个实例左右，可以算入门了。此时你基本能了解变量，函数，类等等概念。

但如果要达到相对运用自如的程度，就要做到 1000+。

这个练习还得处于学习区。就像你写 1000 个 “Hello，world ”，编程是不会有进步的（开始的两三个可能会）。但如果你本身善于思考，做东西懂得举一反三。实际练习的数量也会比这个少。所以以数量并不是绝对的指标。

但无论如何，只有足够量的积累，才能做到游刃有余，顺手拈来。如果你脑中的任何想法，都能迅速实现，做到无障碍的表达，后面就能玩得很痛快了，可以更专注于创意本身。

如何练习更有趣？

练习不是枯燥的代名词。练习的方向可以很自由。知识点是固定的，但你可以决定如何组织。许多练习只要多想一步，稍加变化，就能成为有趣的作品。

之前看书一般很少做后面的练习题，而是习惯自己给自己出思考题。比如我对“画东西”比较感兴趣，我会思考怎样将学到的新概念往这个方向上靠拢，以此做点不一样的东西。

除此之外，你还可以从自己喜欢的作品去学习。Gif 狂人 Dave Whyte 的很多动图估计大多人都见过，他的作品常常给我带来很多灵感。我们也可以用同样的形式来练习，甚至是模仿。

受他影响，个人有一种记录练习的方式，就是做 Gif。只要略微有看点的练习，我都会保存成图片或是导出Gif。这样方便回顾的同时，还可以驱动自己去持续练习。自己从初学到现在，已经积累了100多的动图，从中可以看到自己的学习轨迹。

Test 0

Test 1

Test 32

Test 41

Test 56

Test 106

Test 107

试想象下，当你某天看到自己积累了 1000 个Test，应该会是件很有成就感的事。可以看到自己的成长，看到自己的思考脉络。另外，制作Gif的过程无需过于追求完美，而将大量时间花在推敲细节上。只要视觉上及格即可，关键是其中的逻辑。

对于练习，建议将它们都按类别功能用文件夹归好类，这样练习库也会成为你创作时的素材库。写代码不像绘画，创作一幅作品，你可能每次都必须从白纸开始。Coding 则不一样，练习是可复用的。

复用还是一种编程思维，你甚至可以写一些类或者插件，将自己最常用的东西打包起来，以此提高创作效率。

无论是 Processing 还是 Openframeworks，我最先想解决的问题，就是如何更快地制作 Gif，毕竟这个功能对自己而言是最常用。虽然有现成的一些插件，但使用起来总要敲很多代码，十分不便。为此我就设计一些方法去简化这个流程，这样就无需重复劳动。（Processing快速制作Gif）

（针对 OF，自己也基于 ofxGifEncoder 重写了一个类，之后会一并开源出来）

练习的迭代

前后的练习不是毫无关联的，可以不断迭代，甚至成为创作的灵感来源。

刚开始接触CreativeCoding的时候，我产生了一个问题。如果我想写一个函数，如何能从指定坐标 A，变化到指定坐标 B ？这在 Flash 或是 AE 之类的软件中很容易实现，但在程序中却需要思考一番。

当时刚学会 PVector 向量，就想用它去承载坐标点的数据。当验证了想法可行，我就将完成后的代码放在 animation 的文件夹中，这算完成了一个练习。

过段时间，我觉得这个运动效果太僵硬了，于是把代码翻出来，再重新设计了一个规则：过中点前加速运动，中点后就减速。这样代码与原来略有不同，运动也更加自然了。

直到某天，产生了一个算法的灵感，能够结合之前的代码，制作一个图片转换效果？想到的思路是将前后两张图片的所有像素的灰度进行排序，再进行点对点的映射。没费很大的功夫，就跑出下面的效果了。

Test 27

当时实验成功后会很兴奋。一是你通过主动的思考做出了不一样的东西，二是其中的原理居然出乎意料地简单，我觉得这都是代码的魅力所在。后面基于点对点的变换，还延伸出许多练习，其实都基于先前一段最不起眼的代码。

Test 97

Test 99

另一个相近的例子，是较早前做了一个录制绘画轨迹的练习。直到后来看到这个系列图片。

于是有了将绘制轨迹进行对称的想法。

也催生了一个图形生成器。

后面也做了各种各样和画相关的实验。

所以不要忽视任何的练习，这些练习距离创作并没有那么遥远，稍微打磨下，都可以成为作品。

更多练习

问正确的问题

前面用了很多篇幅去强调练习的重要性，但无论你练习的次数多么多，总会遇到你个人无法解决的问题。
这时有两种途径，一是向google发问，二是向前辈发问。

个人解决问题的常用手段，是 Google。不推荐国内搜索引擎，否则大多数问题的解决方案你都是无法搜到的，关键字也最好用英文，这样可以增大搜到答案的几率。如果是问 OF 的相关问题,那官网的论坛会是提问的首选。很多时候你不会是第一个提出这个问题的人，只要先搜索下就可能发现现成的答案。如果没有，你可以在上面发起问题，上面也会有热心的管理员和网友给出解答。

除了google之外，如果你在学校有导师。那就不要放过机会，用大量的好问题逼出他的干货。但如果你没有，身边又没有了解这个的朋友，那就需要虚心地向圈内的前辈请教问题，通过各种社交媒体或是论坛网站。另外，向人提问是有技巧的，不要让人觉得你是不愿动脑的伸手党。这篇“提问的智慧”值得一读，不仅局限在编程领域。

学习社区

除了纸质教程之外。openProcessing 对初学者学习来说是首选。代码都是开源的。里面有足够丰富的资源，可以让你去学习。

而如果你学习的是 OF，就没有类似的网站了。要学习别人的代码，最常用的会是Github，你需要了解相关的艺术家，然后在 github上fork 他的代码。例如 OF 创始人 Zack 的github，里面就有许多开源的代码

不得不提的还有 Twitter，上面的信息质量比国内的微博要高，它是个很好的获取灵感信息的平台。许多新媒体艺术家，都很乐意在上面分享自己的一些探索，你可以看到领域最前沿的一批人，他们是如何思考的。

自学的难点

• 动力

Coding是这样的，你了解越多，越能挖掘更多的乐趣。如果你是自己自学，而不是有学校课程去驱使你，那坚持的唯一理由，只能靠动力本身了。

动力足够强烈的人，是不会意识到自己需要坚持的，因为整个过程他都乐在其中。但往往是少数，多数人可能会面临动力不足的问题。

怎样可以获得动力？做东西是最直接的。当你亲手用代码完成一个作品，获得的成就感会持续驱动你。其次，就是关注领域的相关人物，在twitter上follow一些艺术家，关注他们的作品，练习。好作品绝对会激发人 Coding 的欲望。

• 心态

学习最忌两种心态。一是妄自菲薄，二是骄傲自大。它们都是阻止你不断进步的因素。不要觉得编程太难，怎么学也赶不上别人。也不要认为自己什么都会了，而放弃持续学习。

“Creative” 在先， “Coding”在后

学什么工具不重要，用工具创造了什么才重要。正如编出 Photoshop 的工程师，没有人会比他们更熟悉Ps的各项功能了。但很显然，不代表他们就能用这个工具创作出好作品。

同理，CreativeCoding 最终要比拼的不是 Code，而是Creative的想法。否则每个 Coder 都会是 CreativeCoding 的高手了。设计师学编程的优势，是他自身已经有创作者的思维，并且视觉表达能力不错，再稍微了解代码，就可以做出很不一样的作品。

前面之所以强调代码，是不希望设计师空有想法，而没有落地能力。学习编程除了实现想法之外，可以多一个角度去理解事物更底层的规则，它是能反过来丰富你的想法，而不纯粹是门工具。

所以想法才是最大的驱动力。更鼓励大家围绕一两个具体的想法，用它来串联所学的知识。

自己学习创意编程的动力，源于两个感兴趣的方向，一是从数的角度去剖析图形，用代码用法则去探索图形的更多可能性（万物皆数）。二，是希望用程序，去测量人的思维，以此开发一些训练工具（量化绘画）。

这些想法用传统的软件都是无法做到的，但学习创意编程让我有机会亲自去实现它。

“取乎其上，得乎其中；取乎其中，得乎其下；取乎其下，则无所得矣”。如果你对创作有更高的目标，那绝对是件好事，他会驱使你走得更远。

Coding的内功

如果Coding是种武功，那算法就是“内功”。不要疲于学习各种插件，虽然能很快的出一些很炫的效果，这些都是最表面，也最容易学会的。加深自己对算法的理解，学会对图形进行规则的抽象和重设计，这十分重要。

另外，技术并不是创作的最主要瓶颈。我们不要将精力放在学习各样五花八门的技术上。做个比喻，要成为“武林高手”，不是说刀枪剑棍你什么都需要会。你将一种武功练到极致，也同样能打遍天下。代码的创造相当自由，你完全可以将一些常人认为最简单，最普通不过的规则摸透，并且将它玩到极致，这样同样可以走出自己的风格。

技术怎么学都没有尽头的，所以学一点，就尽量做点东西把它运用起来。其实简单的技术，也能做出精彩的作品。就像对有创造力的画家而言，给它一支铅笔就足够了。

END

相信你现在有足够的信息可以去开始自学了。编程水平的高低，与你在什么学校，学什么专业，跟随哪位老师，看哪本教材没有必然的联系。如果这个能力可以量化，前面的因素充其量决定开头的第一个数字，而自我修炼，则决定这个数字后面跟多少个“0” 。

创意编程有它自身独有的魅力。正如当初我去学习它，不是因为它能为我直接带来什么好处，仅仅是觉得有趣而已。希望将来有更多人，能发自内心地喜欢创意编程，用它来创造不一样的东西。

还等什么？下面是你的Coding时间：）