可能我们每天在代码过程中都会应用到行为树、状态机或者条件功能函数的某一部分，但是如果没有对对应概念的确切理解，就不能形成自己的词汇库，也就不能和别人产生心有灵犀的共鸣。这就是为什么要给词汇下定义，就是方便沟通，并且缩短沟通过程。就像我们和其他人讲述太阳的时候，不再需要向别人描述那是一个圆圆亮亮的大火球，而是简单的“太阳”两个字就能表达。
行为树定义了AI主体的智慧能力，这种智慧能力体现在AI主体可以根据环境变化而改变自身行为。在一棵完整的行为树中，叶子节点是AI主体所能执行的行为，而从根节点到叶子节点的路径就是AI主体的决策过程。
状态机描述了状态和状态转移条件。状态被动接受条件变化，通过判断确定状态的变化。
条件功能函数是指，在固定的触发点，通过判断预先定义的条件，如果条件满足，则执行对应的功能。这里定义的需要执行的功能，也可以是带有条件的功能组。条件功能函数也可以抽象为树形结构，判定与执行的过程就是遍历整棵树的过程。
Unity在4.6版本中将要发布新的UI系统UGUI, 关于UGUI的介绍,请查看Overview of the New UI System。
一般来说，游戏UI的制作步骤为:
1. 美术在设计软件（PhotoShop，Flash）中进行UI的设计.
2. 美术导出切分好的散图和整体效果图。
3. 程序在程序的开发环境中参照效果图实现UI的布局和功能。
这种工作流就经常导致程序制作出的UI效果和美术的设计存在偏差，并且对于美术的修改来说也不够友好。
使用Unity开发UI，理想的情况是美术也能够使用Untity进行设计和实现。但现实往往是美术不太接受使用不太熟悉的软件进行创作。并且美术如果和程序公用同一项目，在版本维护中出错的机会也比较大。
不同系统之间的集成通常都是通过中间语言的传递来实现的。参考A good workflow to smoothly import 2D content into Unity:
本文给出的“从PSD UI制作到Unity UGUI生成的工作流”是：
1. 从PSD中导出可以描述UI的配置和对应的图片资源。
2. 使用Unity读取配置，使用图片资源生成对应的UI.
其中，PSD中的"组"与"层"的组织和命名需要遵循一定的规范。组织规范定义了UI的结构，命名规范定义了UI的组件类型（包括：Button、Label、Image、ScrollView、ListView等）和参数。从Photoshop导出对应配置是使用Photoshop支持的ExtendScript，通过遍历PSD，生成UI的结构并使用XML保存，同时也会导出相应的图片资源。
通过包含特殊字段的命名（如：Common），可以指定某些图片引用自其他的PSD文件，这样当Unity导入的时候就可以根据命名去查找对应的图片资源，从而保证相同的图片资源在Unity的资源中仅存在一份。
UI资源图片在导入的时候通过设置类型为Sprite，然后通过指定Packing Tag，可以将相同的Packing Tag的图片在Build时打包到同一个图片集，从而降低DrawCall.
参考资料:
1. A good workflow to smoothly import 2D content into Unity
通过GitHub + Octopress搭建了这个静态博客。替换了默认模板的favicon。希望可以坚持写下去。主要是记录独立游戏的开发过程，希望能够对自己有益，如果恰巧也能对他人有益，就更好了。
现在还不太了解Markdown的语法，默认的模板也不太喜欢。文章的排版和博客样式统统都要改改改。不管内容，首先还是要好看。
第二日更新：
在献给写作者的 Markdown 新手指南中介绍了主要的一些Markdown语法，看起来很有帮助。原来MarkDown的语法如此简单直接。
1
| |
其中图片是放在images路径下。
```
{% img /images/A-Team-Logo.png 200 %}
```
第三日更新：
今天尝试了修改博客的样式和布局，增加了About和Categories.
参考资料：
1. 利用Octopress搭建一个Github博客
2. 象写程序一样写博客：搭建基于github的博客
3. 献给写作者的 Markdown 新手指南
4. Markdown语法示例
5. Sharing Code Snippets
6. 灵魂机器 我的Octopress配置
7. Show Categories and Post Count in Octopress
8. Inserting Liquid Syntax Into Octopress Codeblock