我们和代码的距离

我们总希望受控对象能尽可能的自理,但又能让任何一个细节完全受控于我们。我们讨厌琐碎的细节,希望不关心的都会有个默认值在那里等着我们。但是默认值总会有不适用的时候,我们总是无法用统一的方法解决问题,重构于是成为家常便饭。

我们要控制的对象总是不够聪明。

大一的时C语言考核有一项是:用字符模拟一个余弦波平行移动的动画,并且能通过光标控制波长和幅度。这是我的第一个界面程序。虽然是控制台模拟界面,没有抗锯齿,没有色彩,没有缓动,但是它让我发现了很多有趣的现象。比如开始编写时,我觉得为了调试平移动画就在右上角加入了显示平移计数,本来打算调试通过就注释掉,但没想到这个功能意外的可以便捷的扩展到幅度的调试环节,然后测试时又发现用光标控制波长和幅度时如果能显示数值的反馈会让操控更富有乐趣。于是这个一开始仅用于调试的功能不知不觉间变成了程序的一部分。

你有没有想过游戏的生命值显示一开始只是用于debug呢?开发者是否在开发过程中发现了乐趣呢?那些不认真编写单元测试的人是否无意间错过了无数美丽风景呢?

我们总能在调试的过程中发现点什么。有些人会不知不觉间写出适用于自己的framework,稍加修订整合,jQuery或Rails这样的产物就诞生了。我们常常发现自己为制作某个产品而制作的工具比这个产品更具价值,这很可笑,但看了 Bret Victor 的 Inventing on Principle之后你会发现这个想法至关重要,因为改变时代的往往是工具,而你是用怎样的想法和态度去创造自己的工具呢 ?Bret Victor 试图用他的规则展示如何用将我们和代码还有最终产品的鸿沟拉近。

关于游戏的慢放和未来状态演示那段,让人不禁联想起了NFS9的X模式。这个未来过程预测完全可以直接加入到游戏的一部分让玩家体验新的创意。