• 2010年02月28日 -- 无锯齿缩放图片【缩放时对位图进行平滑处理】 (1)
• 2010年02月28日 -- as3四种方法实现文本居中 (0)
• 2010年08月23日 -- 植物大战僵尸George Fan访谈【麻球大赛评委之一】 (1)
• 2010年03月15日 -- 外调皮肤的几种方法【从加载的swf文件中获取皮肤】 (0)
• 2010年08月18日 -- 黑羽：Flash小游戏开发者的新平台 (1)
• 2009年12月3日 -- 保存图片到服务器类(php服务器) (10)

下载名称：AdvancED ActionScript 3.0 Animation 作者：Keith Peters 紧接《Making things move》，ActionScript 3.0 高级动画教程。AdvancED ActionScript 3.0 Animation 中文版在riabook.cn有下载：www.riabook.cn/zh_book/advanced-as3-animation-full-cn.htm，

下载名称：Foundation Actionscript 3.0 Animation 简体中文版 原著：Keith Peters 翻译：FL基理大师 翻译就是还原，即反映作者的真正意图，这是件很不容易的事。翻译该书完全本着对 Flash 的热爱，也是对自己的一次挑战，望朋友们多提宝贵意见。 本书在业界享有盛名，内容深入浅出，适合各个层次的学习者，能够让读者对 Flash 动画编程有一个全面系统的了解，是学习 AtionSript 的良师益友。    — FL基理大师

下载名称：Adobe AIR 经典案例2008 Adobe AIR Create Modify Reuse 原著：WILEY 翻译：AIRIA汉化 从第二章到十二章，本书每章介绍一个Adobe AIR应用程序的 开发详细过程，包括设计、数据处理、用户接口、代码、整合元件、数据和支持类、部署 AIR应用程序、编译和打包成AIR安装文件。 我找到了此书的原代码下载

下载名称：AIR完整入门与开发实录 原著：郭少瑞 张鑫 本书主要通过详细的实例讲解，向读者介绍AIR的特性和开发技巧。通过阅读本书，读者会了解到AIR的优势，以及如何快速有效地开发AIR应用。

下载名称：Flash Builder 4 快速入门 原著：adobe 翻译：airia编辑团队 演示地址：http://www.airia.cn/flashbuilder/ 《Flash Builder 4  快速入门》除了适合想学习FLEX开发和正在学习FLEX开发的朋友，也广泛适用与FLASH、Actionscript开发者进行转型和深入学习。包括.NET、JAVA开发人员在内，这本书都将为你日后的含RIA开发工作奠定牢固的知识基础。

下载名称：Flex3 Cookbook 中文版 翻译：翻译团队（常青） 由常青翻译团队翻译的《FLEX 3 COOKBOOK 中文版》 PDF 电子档正式发布。

下载名称：ActionScript 3 Cookbook 简体中文版 翻译：常青 在Ajax 和微软WPF 袭来之前，Macromedia 率先推出基于Flash的RIA解决方案，用于创建具有桌面程序富有交互和多功能的Web应用程序，我们称之为“Rich Internet Application”。现在，新东家Adobe 更是赋予了Flash超越Web之能力，使之成为完整的开发环境。

下载名称：FLEX、AIR- Adobe 新手培训教材 原著：Adobe 本书为ADOBE官方培训教材，本教材与ADOBE MAX大会上发布，并同时有250人在场参与了本教材的学习。

下载名称：Flex 3 RIA开发详解与精深实践 原著：杨占坡，杨铭，翁颖 曾经沧海难为水，除却巫山不是云。然而，当我们已经经历了众多编程语言、开发技术的洗礼之后，仍然被Flex的风采所打动。Flex是一种结合了广阔的市场前景和充满智慧的方法学的新一代复合型软件技术。我们一行三人决定结合自己的项目经验和开发技能为各位读者献上这本《Flex 3 RIA开发详解与精深实践》。

下载名称：FLEX设计师基础(图文案例教学) 原著：Greg Goralski FLEX设计师基础一书是对FLEX设计操作的入门书籍，通读本书你可以对FLEX设计有一个全面的认识并掌握一些常用技巧。本书并没有用大量篇幅描述设计细节，但本书基本涵盖了大部分常见的设计方式，所以AIRIA推荐刚刚接触FLEX的设计师或者是FLEX开发人员参考阅读。

下载名称：FLEX富互联网应用快速入门：Learning Flex 3 Learning Flex 3 提供清晰、精简的提示和分步说明，作者亚拉里克基将与大家分享已收集了多年的Flex使用技巧和教学（Yahoo开发人员 ） ! 您将了解Flex的工作方式，如何使用 MXML 语言和 ActionScript，如何部署丰富桌面应用 Adobe AIR…以及更多。

下载名称：Flex 3速记表 AS3.Flex.AIR最新版 原著：Adobe 最新的Flex 3速记表，本海报包含详细的控制元、属件、事件、样式，你可以看出，其范例写法也是官方建议的标准。本海报采用图形化设计，对新手而言，可以更轻松和领悟的掌握知识要点，一目了然！

下载名称：ActionScript 3 / Flex 3.0 / AIR 1.0 学习海报 原著：Adobe 本书是进行RIA学习不可缺少的参考海报，首先以图形方式形象的表述了FLEX（MXML、AS）、AIR与系统直接的关系，并介绍了几种服务端的架设。本书为ADOBE出品，所以仅限于ADOBE产品范围以内。

下载名称：FLEX3入门指南（Flex.3.A.Beginners.Guide） 原著：不详 本书非常适合FLEX3的初学者，本书详细介绍了FLEX的操作指南、FLEX开发环境，以及FLEX下MXML\ActionScript\XML等语言的应用。本书还就几个详细的FLEX应用产品作为案例开展了一系列的开发说明。

下载名称：Adobe AIR with Ajax 速成指南 原著：Larry Ullman Adobe  AIR  with Ajax 速成指南 （Adobe AIR with Ajax Visual QuickPro Guide）

• 2010年08月31日 -- 20个最酷的Adobe AIR应用程序 (2)
• 2010年08月29日 -- flash开发中提高性能方法的整理 (1)
• 2010年07月14日 -- LightCharts – 轻量级的flex图表组件 (1)
• 2010年05月20日 -- Adobe展示流畅运行Flash的Android平板电脑【转载】 (2)
• 2009年12月6日 -- actionscript与javascript交互 (3)

前面已经把基本上嵌入字体的相关知识都梳理了一遍：

1. 如何在Flash IDE中嵌入字体
2. 如何在Flash IDE中使用嵌入的字体
3. 如何使用Flex SDK嵌入字体
4. ActionScript如何使用嵌入的字体
5. 运行时共享字体库的两种方法

下面讨论一下几种问题和可能性：

• Font类只有registerFont()方法，而没有unregisterFont()。不知道如果向系统中多添加一些字体定义以后会不会有内存占用的问题。
• 把整个中文字库完全嵌入所增加的文件量大约在5M-10M，现在的视频Intro也差不多要3M-5M。随着宽带的进一步发展，把中文字库完全嵌入也并非不可能。
• 在文字内容可知的情况下，不管用哪种方法，我们都必须手动去生成字体库。当然如果是配合CMS后台的话，可以编写后台程序来批处理的生成AS文件。配合命令行调用编译器甚至可以直接生成包含字体的swf文件。关于这方面的讨论，可以看看这里或这里。
• 进一步想，用户输入的字符用嵌入字体来渲染也并非不可能。关键是精简初始字库，然后逐步加载更完整的字库。比如我们可以先加载常用汉字”Font1“（1M-2M左右），然后再加载其余的汉字”Font2“。那么如何调用正确的字体来实时显示呢？我们可以借助Font类实例的一个hasGlyphs()方法，来检测当前字体是否包含了某个字符的矢量信息(glyphs)。如果字符已经可以被渲染，则设置embedFonts，否则我们则用系统字体来显示。

基于这些想法，我已经在互联网上找了常用汉字表并预置在了我的Flash中文字体嵌入助手中。如果大家有更好的想法，欢迎在这与我交流，让汉字在Flash里更酷些。

Flash字体嵌入方法总结PDF下载

update：

作为总结，不能漏了Flash Player 10里支持的新Text Engine（FTE）。我今天试用了一下，也翻了一些网上的相关讨论。觉得这技术目前还不够成熟，Adobe对Flash和Flash Builder(Flex)两者的定位还有点摇摆。FTE使用的CFF字体不能在TextField中使用，是现在最大的问题。只好寄望于下一代Flash出来了。

字体工具推荐：

• FontCreator – 好用的字体编辑工具
• MainType – 同一公司出品的字体管理工具

更多参考：

• FP10 AS3 TextLayout TTF transcoding
• Flash Player 10 AS3 Text Layout Engine Dynamic Selectable Embedded TTF’s
• Runtime Font Embedding in AS3. There is no need to embed the entire fontset anymore.
• Adobe Help – Using Fonts

• 2010年04月20日 -- Flash字体嵌入方法总结—(3)ActionScript提高篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(2)ActionScript基础篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(1)基础篇【转载kevincao】 (0)
• 2010年08月29日 -- flash开发中提高性能方法的整理 (1)
• 2010年08月18日 -- 小s：盛大游戏麻球网上线 Flash独立游戏开发者的曙光 (0)
• 2010年08月18日 -- 腾讯博客：Flash Mini Game 盈利平台出现 (0)

现在我们了解了Flash字符嵌入的几种方法，也知道了怎么在IDE和ActionScript中使用嵌入字体。但是在开发项目中，通常会有很多swf文件（页面或模块），它们大都使用相同的字体。我们不得不在每个文件中重复嵌入字体。有没有办法打破单个swf的使用范围的限制呢？

方法一是使用运行时共享（runtime share）技术。首先用前文讲述的方法建立一个”MyArial“字体，选择Export for ActionScript。然后选择Export for runtime sharing（为运行时共享导出），填入完整文件路径。最后发布fontLibrary.swf文件。这样我们就得到了一个运行时字体库，下面我们再来看看如何在其他swf中使用。

新建一个fla文档，在File菜单下选择Open External Library（打开外部库）。在新打开的库面板中可以看到我们刚才建立的”MyArial“，把它拖动到当前文件的库面板中。Flash自动为我们导入了这个字体，右键点开属性如下图所示：

Import for runtime sharing表示这个元件是外部导入的。现在和正常使用字体元件一样，创建一个动态文本框，选择”MyArial“字体，随便打入一些文字，发布文件。从生成的文件量上来分析可以得出字体矢量信息并没有被编译进来，而是动态地从fontLibrary.swf获取的。Flash Player自动为我们完成了这一过程。

方法一示例文件

方法二是利用ActionScript里的Font类来向系统动态的注册字体。首先用Flash中文嵌入助手生成类代码，贴进Flex编辑器，将其作为文档类编译生成fontLibrary.swf文件。

注意构造函数下的这句代码：

Font.registerFont(ClassName);

通过执行registerFont()方法，一旦fontLibrary.swf被加载（即实例化），我们就在系统中注册了名为”FontName“的字体。当然我们也可以在需要的时候再去向系统注册而不在构造函数中执行。

字体注册后，就等同于在客户端安装了这种字体，我们可以随意的使用。

相比第一种方法只能嵌入整个字体的限制（参见前文对于字体元件的解释），这种方法不仅解决了问题，而且更加灵活。也是目前使用汉字文字共享库的唯一办法，下面让我们来看一下实例。

建立FontLibrary.fla文件，在第一帧输入以下代码：

[Embed(systemFont="华文中宋", fontName="MyFont", unicodeRange="U+4e2d,U+6587,U+5b57,U+578b", mimeType="application/x-font")]
var MyClass : Class;

Font.registerFont(MyClass);

我们建立了一个”MyFont“字体，包含了“华文中宋”字体的四个中文字符矢量信息：“中文字型”，并向系统注册。执行编译生成了fontLibrary.swf文件。

然后另外建立要使用字体库的文件，在第一帧写下以下代码：

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, completeHandler);
loader.load(new URLRequest("fontLibrary.swf"));

function completeHandler(event : Event):void {
	loader.contentLoaderInfo.removeEventListener(Event.COMPLETE, completeHandler);
	var fmt:TextFormat=new TextFormat("MyFont",68,0x336699); //使用MyFont字体
	var txt : TextField = new TextField();
	txt.autoSize=TextFieldAutoSize.LEFT;
	txt.embedFonts=true;
	txt.text="中文字型";
	txt.setTextFormat(fmt);
	addChild(txt);
}

以上代码先用loader加载fontLibrary.swf。当加载完毕以后，新建的文本框就可以使用我们的自定义字体”Myfont“了。

方法二示例文件

• 2010年04月20日 -- Flash字体嵌入方法总结—(4)进阶篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(2)ActionScript基础篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(1)基础篇【转载kevincao】 (0)
• 2010年08月29日 -- flash开发中提高性能方法的整理 (1)
• 2010年08月18日 -- 小s：盛大游戏麻球网上线 Flash独立游戏开发者的曙光 (0)
• 2010年08月18日 -- 腾讯博客：Flash Mini Game 盈利平台出现 (0)

在上一篇使用字体元件的时候，我们接触到了TextField对象的embedFonts属性。在这里，我们进一步的探讨一下怎么在ActionScript中使用嵌入文本。

一旦我们在Flash IDE中嵌入了字体，swf文件中就包含了该字体的矢量信息。ActionScript也可以使用这些信息。继续上文的例子，我们添加如下代码：

var fmt:TextFormat = new TextFormat();
fmt.font = "STZhongsong";//华文中宋
fmt.size = 36;
fmt.color = 0x336699;

var txt:TextField = new TextField();
txt.text = "中文字型测试";
txt.autoSize = TextFieldAutoSize.LEFT;
txt.embedFonts = true;
txt.setTextFormat(fmt);
addChild(txt);

我们用ActionScript建立了一个文本框，内容为“中文字型测试”，字体为“华文中宋”。因为“测试”这两个字体信息没有被嵌入，所以不会被渲染出来。再来看看使用css的两种用法：

var style:StyleSheet = new StyleSheet();
style.parseCSS("foo{font-family:STZhongsong;font-size:36;color:#336699}");

// 用法1
var fmt:TextFormat = style.transform(style.getStyle("foo"));
txt.text = "中文字型测试";
txt.setTextFormat(fmt);

// 用法2
//txt.styleSheet = style;
//txt.htmlText = "<foo>中文字型测试</foo>";

两种方式都可以把格式赋给文本框，但是和TextFormat方法一样的是需要注意字体的名字不是我们在IDE里看到的“华文中宋”，而是字体的英文名”STZhongsong”。如何找到字体的英文名可以到字体目录里去查看信息，也可以用我在下一篇进阶篇中介绍的方法。

以上总结的是ActionScript使用嵌入字体的方法，但都是基于在IDE中完成了字体嵌入的操作的。下面我们来看看另外的方法：使用Flex SDK。

首先大家都应该看看gotoAndLearn上的这篇视频教程，Lee非常详尽的介绍了使用Runtime Font Loading的方法。通过使用Flex SDK，使得在ActionScript中嵌入字体变为可能。我们来看看嵌入字体所使用的代码：

[Embed(systemFont="Arial", fontName="MyArial", unicodeRange="U+0020-U+007e", mimeType="application/x-font")]
var ClassName : Class;

在这两行代码中，我们创建了一个虚拟字体”MyArial“。和在IDE中的操作效果一样，映射的是系统字体Arial的标准形式。unicodeRange 是我们所需要的重要参数，它界定了嵌入字符的范围。”U+0020″这类的数字表示字符的unicode编码，虽然没有在IDE里面直观，但是我们可以用教程里提到的在线工具作为辅助。

经过一番搜索，发现了polyGeek上开发了一个for Flex css的字体嵌入工具。根据他的算法，我改写了一个输出Embed标签的，并加入了一些汉字用的范围，完善了更多功能，命名为：Flash中文字体嵌入助手。

如果你使用Flex SDK编译的话，可以用这个工具生成的类代码，建立一个自己的FontLibrary。在要使用这个字体的地方，只要在文档类中包含一个对FontLibrary的引用，就可以把字体一起编译进来。更多使用FontLibrary的方法和思路，我们在下一篇深入讨论。

此外还需要提一下字体的变体样式。Flex SDK同样支持嵌入斜体或粗体，但是如果是使用外部字体嵌入，使用变体会在编译时报错，同样的设置用系统字体则没有问题。提醒大家使用的时候注意一下。

示例文件下载

• 2010年04月20日 -- Flash字体嵌入方法总结—(4)进阶篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(3)ActionScript提高篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(1)基础篇【转载kevincao】 (0)
• 2010年08月29日 -- flash开发中提高性能方法的整理 (1)
• 2010年08月18日 -- 小s：盛大游戏麻球网上线 Flash独立游戏开发者的曙光 (0)
• 2010年08月18日 -- 腾讯博客：Flash Mini Game 盈利平台出现 (0)

大家都知道在Flash中嵌入中文字型有个最大的问题就是文件量的限制，所以也都知道在Flash中有选择的嵌入字型是一个有效的方法。但是对在ActionScript中嵌入字体的技巧就不一定完全了解了。最近因为项目的关系，让我好好把这方面问题做了一次梳理。作为温故知新，我们先来简单看看最简单常见的方法。

上图是Flash CS4的文字相关界面。为一个动态文本框嵌入文件的基本方法是，在Character Embedding的弹出面板填入你所需要的字符。在上方的列表中是一些常用的字符范围。比如做Loading显示的，只要嵌入第四项Numerals，或许再多加一个“%”的符号就可以了。

在动态文本框中嵌入的这些字符在该swf文件中都是有效的。也就是说在一个swf文件中同一种字体的字符只需要嵌入一次，所有的动态文本框都能使用。所以通常的做法是把所有需要的字符都填充到一个文本框，作为全局的字体资源库，这样找起来最方便。

此外的第二种方法就是字体元件了。在库面板点右键建立Font Symbol：

这种方法可以方便的嵌入整个字型，但是因为不能选择需要嵌入的字体，所以对于中文来说几乎形同鸡肋。

此外如果要使用字型的变体：斜体和黑体，都需要另外嵌入的。因为这些变体其实算是另一种字体。面板中”Faux”的意思是指用矢量引擎虚拟出来的字型，其实原字体并没有这些变体可供选择。如果字体包含了各种变体，那么这两个选项是不可用的。

对某些不规范的或者是笔划复杂的中文字体，矢量引擎处理比较容易出错。如文字中空心的部分会变成有填充的，有的甚至会造成播放器崩溃。所以大家在使用”Faux”的时候要特别留意。

此外提醒一下大家：CS4的文字面板中已经没有粗体和斜体的按钮了，别以为没这功能了，在Text菜单里面还是可以找到的。

如果要把字体当作位图来处理，就要选择Bitmap Text位图字体。Size参数是指位图字体的大小，对矢量字体来说没意义。这个选项主要用于嵌入类似04系列这样的像素字体。

在例子中，我们建立了一个名为”MyArial“的字体，映射系统中的Arial Regular。记得激活”Export for ActionScript”，这样字体资源才会被编译。

建好了字体元件后我们在字体菜单里能够看到自定义的字体以*号做了标识。现在对于文本框来说，字体无论是选择”Arial“或者”MyArial“都是可以的。用ActionScript设置文本框的embedFonts属性为true，使得文本框使用嵌入字体渲染就可以了。如果不想用到ActionScript，但是在字体设置面板中没有直接设置使用嵌入字体的开关，怎么办。我的方法是随便在嵌入框中打一个字符，如空格，使得嵌入的字符数不为0。这样也就间接激活了动态文本框的embedFonts。由于我们已经使用字体元件嵌入了整个字体，所以系统能够找到字体对应的矢量信息(glyph)。

示例文件下载

• 2010年04月20日 -- Flash字体嵌入方法总结—(4)进阶篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(3)ActionScript提高篇【转载kevincao】 (0)
• 2010年04月20日 -- Flash字体嵌入方法总结—(2)ActionScript基础篇【转载kevincao】 (0)
• 2010年08月29日 -- flash开发中提高性能方法的整理 (1)
• 2010年08月18日 -- 小s：盛大游戏麻球网上线 Flash独立游戏开发者的曙光 (0)
• 2010年08月18日 -- 腾讯博客：Flash Mini Game 盈利平台出现 (0)

★我的FLASH WEB GAME开发历程
→2007年的夏天，顶着炎炎烈日，我从学校直接跑到上海，开始了我的FLASH WEB GAME创业之旅。时至今日，转眼快三年了。作为国内比较早的一批FLASH WEB GAME开发人员，今天我粗略的总结一下这两年多的经验和心得。讲的不对的地方，请大家多多指教。

→2007年刚到上海的时候，初创团队只有四个人，一个CTO,一个美术，一个后台，一个前台。手里的产品是一个已经在台湾运行三年左右的FLASH社区，和国内的梦境非常像。这个产品还是不错的，早在FLASH5就在开发出来了，FLASH6出来后，又用新版本的AS1重写过。这个产品让我又爱又恨，爱的是，在2007年的时候，国内除了梦境和1D真的很少有能赶上它的；恨的是，这个产品竟然没有前端源码！要想修改还要破解！玩过AS1，在时间轴、MC和BTN上写过代码的朋友应该知道这是什么概念——1个字：囧！

→后来老板可能也觉得这样改下去不是办法，终于同意自己重写一个。正好07年有条新闻很火爆：国外有个FLASH社区第一次利用FLASH技术取得了重大成功，以7亿美金卖给迪斯尼，它就是“企鹅俱乐部”。老板看到了商机，我们决定做一个中国版的企鹅，于是“海底世界”应运而生了。而“海底世界”的创意，只不过是我们四个初创成员在闲聊时，我开玩笑随便说的。

→海底世界正式开发到现在差不多正好两年，期间我们碰到无数的问题和困难，不管是公司层面或技术层面，都是如此，但始终是坚持了下来。产品一天天完善，公司规模也一天天扩大。前端从最开始的两个人，到现在5个人；后端从最开始的FMS+PHP到现在自己写的socket服务器；公司规模也从最开始的4个人，到现在的50多个人。

★当今FLASH WEB GAME概述
→2007：含苞欲放！
2007年可以说是FLASH WEB GAME发展史上的分水岭。2007年之前，我们眼里只有梦境，最多再加上昙花一现的抱抱城，那时候根本没有“FLASH WEB GAME”这个概念，大家谈的都是“FLASH社区”，“FLASH社区”这个词在很长一段时间代表着FLASH应用领域的至高点。也许2007年已经有不少团队开始研发FLASH的MMORPG了，我曾经有幸知道几个，但很可惜，不少都胎死腹中，2007年国内在线上运营的FLASH WEB GAME基本上还是空白。但不管怎么说，我相信2007年是蓄势待发的一年，肯定有很多类似我们公司的团队，在默默的努力着。

→2008年：雨后春笋！
经过2007年的积累和准备，FLASH WEB GAME业界的战斗终于在2008年打响，以“摩尔庄园”，“海底世界”为代表的“FLASH儿童虚拟社区”开始崭露头角；以“纵横天下”为代表的FLASH策略类游戏兴起；以“昆仑”为代表的FLASH MMORPG让“无端网游”的概念又炒了起来。还有各种基于FLASH的卡牌对战类，联机棋牌类，模拟经营类游戏等等，都如雨后春笋般破土而出。

→2009年：百花齐放！
2008年，国内虽然一下出了很多FLASH WEB GAME,但大家只要认真收集，总归还是能数的过来，可到了2009年，几乎每隔一个月，都会有几个新的FLASH WEB GAME进入大家视野，而且他们越来越完善，功能越来越强大，盈利模式也开始成熟并多样化。2007年每出一个FLASH WEB GAME,我都会为之兴奋，并很有兴趣的去研究它。而到了2009年末的时候，FLASH WEB GAME已经多到我连体验的兴趣都没了，我已经彻底搞不清楚国内到底有多少个FLASH WEB GAME在运营。而伴随着SNS行业的成熟，基于SNS的Social game进一步扩大和模糊着FLASH WEB GAME的概念。FLASH在游戏领域里的应用，在经历了“社区”、“策略类”、“MMORPG”后，发展到今天创意无限，精彩纷呈的“Social game”，已经很难用一个词，根据游戏类型概括所有的FLASH应用了。所以我觉得“FLASH WEB GAME”，也就是“FLASH网页游戏”这个词还是相对最恰当的，这也是我前面一直使用这个词的原因。

→2010年 – 2011年：胜者为王！
就像春秋战国时期，在经历过“百家争鸣”后，必然是“天下一统”。随着游戏巨头和互联网大亨对网页游戏的逐渐重视，以及政府的介入，还有最早领跑某些领域的创业公司不断壮大，相信在不久的将来，网页游戏领域也会出现几个真正的领袖。别的领域不敢说，在我们儿童市场这块儿，淘米公司已经逐渐呈现一家独大的趋势，不信的话，你可以随便找几个小学生问问，比如你父母辈亲戚朋友的孩子，问他们是否知道摩尔庄园和赛尔号，是否充值了，相信你会得到非常惊讶的答案。所以，2010年后，任何小作坊型的创业团队再想进入FLASH WEB GAME行业，都需要更加谨慎了！

★创业型游戏公司面临的问题和困难
→在正式进入FLASH WEB GAME的技术探讨前，我左思右想，还是觉得必须先说一下创业公司存在的问题和困难，为后面可能不太“正规”的做法找一个合适的“理由”。——人不能太爱找客观理由，但也绝对不能为了避免“找理由”之嫌，而弃客观现实于不顾，毛爷爷曾告诫我们要懂得“实事求是”。

→任何有过创业经验的技术团队和公司应该都知道，教科书那套从成功公司抽象出来的模式在创业初期几乎只能是神话一般的存在，相信没有几个公司能完全做到。当然那种千万级启动资金，有成功背景的新公司除外。像我们公司，一开始就4个人，前台和后台各一个人，如果我们两个都每天用一半时间考虑架构和写文档，我们的产品猴年马月也上不了线了，况且我们写了给谁看呢？在这个阶段最最重要的目标就是尽快把产品做出来，上线运营出一定效果，给产品更加明确的方向，给团队信心，然后尽最大努力去融资，以求下一阶段的发展。产品出不来，只靠一个idea和产品策划书就想找投资的时代早就一去不复返了。

→我觉得一个创业公司最现实的发展观应该是这样的：初创阶段（技术导向型阶段）：这个阶段要一切以“我们能做什么”为基础，在财力、人力、经验都不足的情况下，找出我们的优势，“把我们所擅长的做到最好”是我们唯一的筹码，毕竟初创人员能走到一起，必然是有一定共识，在某方面有优势的。而“我们能做什么”，在初创阶段很大程度上就是指技术能做什么。没钱、没人还想把项目做的又快又好，绝对是痴心妄想。这个阶段就开始叫嚣“市场主导产品”，“不看过程只看结果”等口号，完全是不务实的态度，市场上最热门的产品你未必能开发出来，创业阶段，前途未卜，你不看过程看什么？发展阶段（人力导向型阶段）：假设我们顺利度过了第一阶段，公司开始有现金流或者找到了天使投资，我们就开始布置进一步的发展了，这个阶段招人将是公司的一个要务，招有创业精神的人，更要招我们需要和缺少的人。以前我们公司只有AS，于是游戏server只能用FMS，现在应该招一个C++ socket的人了；以前公司没有网页前端，网站都是原画和PHP代劳的，现在该弥补了；以前整个游戏都是架构师们设计并实现的，现在应该招一两个做模块打下手的人了。这个阶段虽然不适合大规模扩展人手，但在要害人力点上，也绝对不能抠门，我们公司就是吃亏在socket上，公司一直不肯招一个专业写server端的，一直让前端和PHP代劳，结果游戏同时在线人数一超过5000就会出各种离奇问题，最恐怖是大家都不清楚问题到底在哪里，只能大眼瞪小眼，这个时候老板就会臭骂公司这帮技术都是饭桶，这么多人还搞不定这个问题。老板不懂技术，说出这样的话无可厚非，但老板不听劝，死活不愿意招要害人员，这就是他的错了。总之这个阶段要以人力发展为核心，尽最大的努力把必要的人手配备齐。必须注意的是，这个阶段不适合空降部门领导，公司发展阶段，只有初创人员陪公司一路走来，最明白公司的问题，以及各种问题的根源。而空降的领导容易只看到问题，不明白为什么会有问题，有时候难免说出“道理上很正确，但实际上不可行”的话，而老板为了配合新领导树立威信，很多时候不得不偏向新领导，这样以来很容易打击到初创人员的积极性。更严重的是可能让初创人员看不到前途，创业的激情沦为打工的无味。这个阶段挖墙脚空降领导，希望他们能把公司制度正规化，希望他们拯救公司的做法可能适得其反！公司初创人员这时候应该依旧是公司的顶梁柱！成熟阶段（产品导向型阶段）：如果有幸过了前两个阶段，到了这个阶段的时候，公司应该已经实现了正向盈利，作为一个游戏公司，一旦靠自己实现盈利，相信各种投资机构肯定会主动找上门，千万美元的投资绝对不夸张，你将会为到底接受哪家的投资而烦恼。人力、财力、物力都不再是问题，产品研发和运营的经验也成熟了，这时候唯一要关注的就是市场，什么样的产品更被市场和用户接受，争取开发出更多更好的产品。产品要多样化，公司要规模化，要形成自己的产品链和平台，抓住更多的用户，开拓更多的盈利模式。这时候才是产品主导公司，才是从大公司挖人的时代。如果这些都做到了，当老板再次开会谈“上市”的问题时，每个人脸上将会笑容依旧，只不过初创阶段的笑容是那种开玩笑试的玩世不恭，而现在则是对未来的美好憧憬。

→其实任何理论都是有前提的，牛顿定律也只是在低于光速的情况下才适用。公司发展的历程中，老板和员工肯定都会有其信仰和观念，都会用各种言辞来说服别人。但我相信没有那种理论和言辞是永远正确的，尤其是书上和大公司的那些所谓的成功经验更是要警惕，因为它们身上有太多的光环，一场本来可能很有价值的讨论，说不定就会被一句“盛大就是这么做的”给结束掉！所以在我们谈任何理论的时候，不妨看看公司现在所处的阶段，不妨时刻谨记毛爷爷的话，实事求是的看待自己。我们公司就曾屡次吃类似的亏，公司在第一阶段刚拿到天使投资，就想做第三阶段的事了，结果做了很多，一件也没做好，白白浪费了很多时间和大好机遇。其实当时老板用来说服人的理论也都是正确的，只不过不适合公司的实际发展情况而已。还有一点要强调的是，不管公司现在处于第几阶段，坚决不能全盘否定其它阶段的付出和努力以及很多不得不犯的“错误”。之所以强调这一点，也是我们公司曾踩过的雷区，当我们发展到第二阶段的时候，公司就开始忙着空降领导，然后这些领导对我们之前的做法开始逐一否定，把做后台的哥们儿说的一无是处，搞得团队气氛极不融洽，吵架红脸的情况经常发生。这就好比我党在经历了长征、抗战和解放战争的原始积累后，在最终发动三大战役攻打大城市时，指着毛泽东的鼻子说：“你以前那套只敢打农村，打的过就打，打不过就跑的逃跑主义路线完全是错误的！”试想，如果党内空降领导都是这种态度的话，将会对我们党和战士们的积极性产生多大的打击！这种情况其实在长征途中就发生过，差点就葬送了党，好在遵义会议及时纠正了苏联空降回来的王明等人的左倾激进主义，挽救了党。而我们的公司，谁来挽救我们的公司呢！

★FLASH WEB GAME的系统架构
→我在这里把一款FLASH WEB GAME的架构分为三部分：系统架构、前端架构、后端架构。“系统架构”主要是指根据一款游戏的特点以及公司的实际情况选择合适的技术实现方案，主要包括美术方案，前端方案和后端方案；“前端架构”主要指FLASH前端的主程序以及模块划分；“后端架构”主要指即时通讯部分和数据库。这章先谈系统架构。

→谈到架构，我不得不说，那些所谓的完美架构，能够一次架构好，永远不用改的说法只能是传说，或者技术人员忽悠老板的说法，对于创业公司更是如此。创业公司初创时期更多的时候需要在游泳中学会游泳，因为大家都没有经验，失败是最好的教科书。就算大家知道应该怎么做，很多时候条件也不允许。比如我们在一开始就知道应该自己写socket服务器，可就是没socket的人才，于是不得不先使用FMS+PHP。公司一开始的美术更精通FLASH一些，而且我们计划的是要做“企鹅”，于是我们选用矢量图。可后来随着公司产品定位的不断改变，我们的架构和解决方案也会不断调整，当达到一个临界点时，修改的代价已经超过重新开发，我们就不得不对架构进行“重构”了！这时候聪明的老板应该支持程序员们的意见，充分调动他们的积极性尽快改完，全公司应全力配合，尽快度过难关。而不明事理的老板肯定会每天抱怨程序员无能，搭出一个垃圾架构不能满足产品的持续快速发展，拖了产品和市场的后腿，给程序员造成很大的压力，积极性没了不说，在长期经验积累之后本来可能是一次非常好的机会能做出一个相对完美的架构，满足日后很长一段时间的需求变更，结果因为老板过分催促和施压，又烙下了许多隐患，而这些欠下的债，总有一天要还的，这一天来临之时，责任虽然可以完全由程序员承担，但整个公司都要为之付出代价！所以关键时刻程序员该坚持还是要坚持自己的观点，要尽量说服老板，程序员的社交能力在这个时候就凸显作用了，你要明白你不但是在对自己负责，也是对公司负责！另外，真的很希望天下的老板们都能明白一个道理：能够根据公司实际情况不断调整的程序员才是最可爱最辛苦的程序员，而不是那些什么都不管，上去就提一大堆要求，必须都满足他，他才愿意做的程序员。

→就算时至今日，FLASH WEB GAME在国内发展差不多三年了，但我敢说FLASH WEB GAME还是没有什么行业标准的技术解决方案，尤其是前端，大家都是自成一派。在这个时候，让我们再次搬出那句老话：不管黑猫白猫，抓住老鼠的就是好猫。不过经过这几年的摸索，还是有一些规律可循的：
1，美术：如果游戏画面简单，色彩构成相对单一，场景内总体元件能控制在100个以下，则非常适合直接使用矢量图，画面各组成部分尽量拆分为能重用的独立元件。这样虽然牺牲了客户端的CPU，但能因为重用最大化而大大减少美术的工作量，也方便他们日后应对需求变更，比如某些元件的尺寸变动。在画面简单，元件又少的情况下，利用递归全元件位图缓存，拿少量内存还能换回大量CPU，找出这个平衡点，完全可以做出很好的用户体验。
可大部分时间，我们的游戏场景可能都非常炫，画面复杂，色彩鲜艳。使用矢量图的话，一方面不容易画出想要的效果和精细度，这时候使用矢量图反而增加了美术的工作量和难度；另一方面，使用矢量图还有可能导致客户端CPU严重飙升，超出普通客户端电脑的承受范围。这时候我们应当用位图做游戏背景，重用性不大的元件要尽量合并到背景位图里，减少位图总个数，一些简单的动画如果非要用FLASH做成矢量动画的话，也要尽量做成逐帧的，相信FLASH IDE玩的转的美术同志们应该知道怎么把一个渐变动画瞬间转换成逐帧动画。逐帧动画虽然会导致SWF文件体积增大，但相对于换回来的客户端CPU来说还是值得，这其实是牺牲了一些服务器带宽和用户等待时间，换回严重的客户端CPU超载。而如果你的动画非常复杂和精细，精细到只有AE等粒子特效软件才能表达的话，建议还是直接从AE里导出位图序列，在FLASH里弄成逐帧动画，太过复杂的动画绝对不能用FLASH直接做，不但很难做出想要的效果，而且复杂矢量图的SWF文件体积也会大大超过位图，有可能导致用户因为SWF文件加载时间过长，失去等待的耐心，这时候我们情愿牺牲美术的工作量和工作流程，换回想要的效果，减小SWF文件体积。还有一点要提醒的，时间轴动画不可见时，程序一定要记得将其stop掉，不像程序动画，时间轴动画不可见时，FP内部其实依旧在重绘，对CPU还是有影响的。
还有一种极端情况是场景元件超标，比如整个游戏内所有元素（包括各种MC、BTN、位图以及程序创建的displayObject，总量超过500，这时候你会发现，画面静止还好，但只要游戏上鼠标随便一晃，或者有几个人物随便走一下路，CPU都会狂飙，就算这500个元件都是位图也无济于事。其实这是FLASH的一个瓶颈所在，是目前所有FLASH大型项目都有可能碰到的问题，也是我觉得阻碍FLASH进一步发展的主要障碍之一。在一个元件超多的背景图上进行任何的鼠标动作、动画、文本渲染，都会导致CPU严重飙升，甚至画面很卡。要解决这个问题，本质的也是唯一的方案就是减少元件数量，要想尽一切办法降到200以下。而这需要美术、前端和策划通力合作才行，绝对不是前端程序员就能搞定的事。策划要从产品的角度上看能不能简化目前场景同一时间出现的元素，美术要把能合并成一张图的元件在绘图软件中合并成一张位图，前端AS程序要把不需要响应鼠标事件的元件的mouseEnable和mouseChildren都设置成false，一些能利用copyPixels合并的位图就合并成一张，比如可以平铺创建的房间地板和墙面，要copyPixels成一张图，而不是new出好几百个元件。
其实元件超标的情况是大多数没有经验的团队很容易发生的问题，这时候前端程序员要起到领头羊的作用，给大家讲明白道理，用事实让大家信服，组织大家一起把事情做的更好，而不是一味的在那里抱怨FP效率低。因为这时候你是团队唯一可以依靠的人，如果这个问题解决不了，虽然大家都有责任，但前端毫无疑问是罪魁祸首！
极端情况下的极端解决方案：如果游戏策划的非常酷，一个子弹爆炸效果就需要几十个元件支撑，画面上同时又需要几十个坦克混战，这时候常规的解决方案是根本达不到的，但不是说就一定无法做了，你可以利用强大的BitmapData类把每帧要显示的游戏画面完全计算好并且在内存中绘制，然后以一张图的方式渲染给用户，这时候用户玩你的游戏仿佛就像在看逐帧的动画，此时FP占用的CPU大部分都是计算耗用的，而不是渲染耗用的。其实AS的执行效率远远高于屏幕渲染，你把CPU的主要负荷转移给AS，反而能做更多更炫的事情。据我的初步研究，前段时间名噪一时的FLASH版3D雷神，还有现在很多国外效率高的“有点假”的TD类和飞机类单机游戏都是这么做的。可这种模式适合用来做多人联机并且有大量交互界面的FLASH WEB GAME么？我初步思考了一下，感觉是不可能的。首先，大量的交互界面意味着需要用鼠标点击，试想在一个逐帧动画中，每帧都要响应鼠标是什么概念？所以UI部分首先排除了；然后是大量的即时数据交互，每当一个异步的请求得到响应，画面就需要做出相应的改变，这将对本来还可能比较工整的内部绘制算法制造非常大的麻烦，难度太高！基本上也不可行；最后是很多FLASH WEB GAME的画面重用性并不是很高，比如像我们游戏的每个场景都是美术专门画的，而不是用地图编辑器编辑的，这就意味着你无法完全用程序拼出一个场景来；综上我觉得一个款FLASH WEB GAME基本不可能完全使用copyPixels完成，最多是部分实现，比如我上面说的墙面和地板。除非你的游戏策划很NB，知道什么游戏能最大限度的利用copyPixels，而这样的策划估计本身肯定也是个前端程序员。
2，前端：从系统架构的角度上讲，前端其实很简单。现在WEB GAME主流的前端技术无非就是AS和JS。JS的前端地位其实比AS要老，很多人的JS经过这么长时间的磨练，功力深厚，做一个策略类甚至简单的MMORPG都没问题。但现在用AS来做的话可能更简单，更容易做出更酷的效果和更好的用户体验。所以最近两三年，随着基于面向对象的AS3逐渐完善和普及，FLASH WEB GAME似乎逐渐成了唯一的主流。
其实除了as和js外，还有很多前端技术可以供我们选择，比如shockwave，java，还有那传说中的flash killer：silverlight和html5等等。每种技术都有其优劣势，比如shockwave在图形渲染方面比flash强了千百倍啊千百倍，因为它可以完全调用显卡，我在网页上玩过一个基于shockwave的CS，流畅度和操作感完全不亚于桌面版的CS，还有国外的哈宝以及国内的娜娜米米都是基于shockwave的。而Java和silverlight也都有强大的背景，HTML5最近也是来势汹汹。但不管怎么样，2010年，FLASH仍以其广泛的覆盖率、酷炫的效果和逐渐成熟的开发社区，以最高的综合评分独领WEB GAME业界风骚。所以任何公司和团队，如果现在想做WEB GAME的话，如果实际情况允许，FLASH还是最好的选择。
3，后端：后端不是我的强项，我就不多说了，我只根据我们公司的经验谈谈心得。我同意前后端编程有很大区别，但绝不同意前后端谁简单谁复杂之说。根据我这几年的观察，我发现，前端偏重的是效果，是用户体验和细节处理，有时候可能还要涉及一些图形算法；而后端则偏重数据结构和数据处理，讲究的是性能、安全和扩展性。前端工作量一般比后端大，而后端需要的工作经验比前端多，想依靠一个只掌握了理论知识的大学毕业生就支撑一个公司的后端架构是严重不靠谱的！前端架构师必须是一个编程高手，十几、几十万行代码要在他的手里安排的井然有序，后端架构师则必须有过大型项目经验，并且项目同时在线人数达到过一定规模。前端架构出现问题，会严重拖垮开发周期，而后端架构一旦出现问题，对公司将是致命性打击。所以在公司里宣传所谓前端重要还是后端重要的说法，是完全错误的，任何一款好的产品，必将是策划、美术、前端、后端都达标的产品，缺失任何一块儿，都成功不了！不同部门之间的比较和较真儿没有任何正面影响！
至于后端的技术解决方案，我感觉如果是需要大量即时交互，并且对即时性要求很高的游戏，就必须使用socket服务器。而如果对即时性要求不高，完全可以用PHP，部分的即时交互可以用socket实现或者HTTP轮询也可以。如果你的公司也像我们一样刚开始没有合适的C或者JAVA socket程序员，选择fms和sfs也未尝不可，这样至少可以让前端人员代劳，让项目可以启动。切记这只是为解燃眉之急的下下策，长久不了，公司要想办法尽快找到一个合适的人，在合适的时机重构。

★FLASH WEB GAME的前端架构与人事分工
→前端的主程序架构和模块划分与人手和人事分工是紧密联系在一起的，而这些很大程度上又是由项目本身决定的。纵观现在国内绝大多数FLASH WEB GAME的规模和难度，我觉得前端AS人员大概需要2-7个之间，主程序有效代码一般不会超过10W行。在这种情况下，人事分工应当以功能和模块进行划分，尽量避免多人维护同一份代码，每个人各司其职，减少维护和协作的成本。这种模式非常适合人手不够，制度不健全，而且追求效率的初创公司。

→根据各种游戏类型的不同，分工也应该不同。策略类更注重界面开发，分工上应该向UI偏重，MMORPG类注重主架构一些，而像我们的海底世界，是更新驱动类社区游戏，每周都要发布新内容，还需要大量的小游戏和场景功能支撑，所以需要更多的模块和小游戏程序员。

→下面就以我们公司为例详细谈一下，我们公司最多的时候，一共5个AS程序员，分工是这样的：1个主架构，1个主UI,1个小游戏，2个场景和模块程序员。主架构同时负责FMS的sever端；主UI同时负责前端人员管理和文件管理；小游戏人员以平均每月两个单机或者联机游戏的速度循环不停开发，是相对最独立的一部分；而两个模块程序员，负责每周发布的新场景和新模块功能，他们的工作量其实蛮大的。

→先谈前端主架构，前端程序主架构有两个主要任务：1，要从架构高度合理划分前端各模块，提出可行的实现方案；2，从AS级别搭建程序架构（非文档级别），制定前端编程规则和接口，规范程序各部分的职责划分。这两个任务其实包括很多具体工作，比如：游戏启动流程制定，确定哪些SWF文件需要外部加载，那些功能可以从主程序剥离出去单独实现，前端配置文件怎么处理，公共素材怎么处理，MVC三层怎么划分，主程序框架的选定，主程序怎么和后台通讯，主程序如何与模块协作，哪些代码应该放在主程序中，哪些代码应该放在模块里，主程序如何既能提供模块所需要的一切功能和数据，同时又相对模块自我保护等等等等。其实我谈的还只是一些大的方面，具体到实现的级别，还有大量细节工作要做。而这些工作在项目启动之初都是非常重要的，直接影响到项目中后期的开发和维护效率。

→上面提到的那些点，我不可能全讲一遍，不然就不叫“浅谈FLASH WEB GAME”了！我只挑两个比较核心的内容跟大家略做探讨，就是前端AS框架和模块划分的问题。先谈前端框架：现在市面上流行很多前端框架，不管是针对“FLASH”的，“FLEX”的还是“通用的”都有。我们是否一定需要框架，或者必须使用某个框架，这完全是仁者见仁智者见智的事，从最终的结果上讲，争论这个问题意义不大，我相信一个5W行左右的项目，任何有5年以上编程经验的人，不管用什么作战策略，最终都能攻下山头，把项目做出来。但有一点至关重要：你必须能完全把握你的架构和你使用的框架，并能跟你的前端同事解释清楚。那好坏架构的区别在哪里呢？区别在于好的架构在开发过程中会更轻松，你不用天天担心的你代码，不用每天不停的写文档，以防止自己忘了复杂的逻辑，你可以在任何时间开始写代码，在任何时间去玩会儿游戏然后回来接着写；区别在于好的架构更符合业界标准，更容易被传统和正统的程序员接受理解；区别在于你可以用很简单的几句话就把你的架构思想描述清楚，用几个很简单的文档就能让别人接手你的代码，在人事变动和工作交接的时候让自己更轻松；区别在于当你掌握了一种通用框架或者自己总结一套成熟的架构后，你几乎可以套用以后的大部分项目，并不断完善它，开发越来越轻松，速度却越来越快！

→我们的项目，主程序使用的是pureMVC框架，而主UI部分是自己写的。主程序和主UI相互独立，可以单独编译测试。主程序是纯代码，用FLEX SDK编译，而主UI则是界面和AS混写并用FLASH编译。这样就把MVC中的V从物理层面上完全独立了。pureMVC框架正如其名字，是一款“纯粹”的MVC框架，在我看来，他只是帮我们实现了MVC的编程思想和套路，其它多余的功能一点没有，这使它具有更高的通用性，也是它最可爱的地方。根据我们的经验，pureMVC单核心版就已经完全可以应对主程序有效代码在10W行以下的项目了。但在我跟很多没有用过框架的前端朋友聊天中，发现他们对这些框架本身就有抵触心理，或者有些对MVC模式都理解的不深刻，用起MVC框架又怎能得心应手？还有一些更过分的朋友把自己的问题也归结到框架上，说什么用了pureMVC框架后，自己的项目编译一下要十几分钟，我听了之后哭笑不得，项目编译慢一般是因为没有合理划分模块导致主程序过大才导致的，跟框架有什么关系？如果因为大家的种种误解和这些人的言论而导致一些新人错过学习这么一款优秀的框架，我觉得实为憾事！

pureMVC既然是一种MVC框架，这就意味着你首先要熟悉MVC。这种熟悉绝对不是对MVC的直译：模型、视图、控制器，而是要真正理解为什么要把程序划分成这几部分，在划分主程序模块时，要时刻能站在MVC的角度考虑问题，而当面对一段实际的代码时，能快速准确的判断，这段代码应该放在MVC中的哪部分。《pureMVC最佳实践》这份短短几十页的文档中，可以说处处闪烁着MVC的思想火花，不但清楚地阐述了怎么使用框架，而且时刻从MVC的角度告诉我们应该把哪些逻辑放在哪些部分中，应该注意什么问题。这个文档早已经有中文版，有兴趣的朋友可以自己去看看，文中有的，我这里就不赘述了。我只结合自己的体验谈一些文中可能没有涉及的，也是在真正开发中才会碰到的问题。

1，模型部分在实际开发中除了存储数据，还有其他作用么？是的，其实它的实际职责非常多。它要给Command和Mediator提供接口，响应用户操作，进行数据操作或者请求远程数据服务，进行数据的序列化和反序列化，得到异步数据后可能还要检查数据合法化。但不管怎么样，它始终是在和数据打交道，同时也应该是你的主程序中唯一可以直接和数据打交道的管道，别的部分要想和数据有接触，首先要问问它同意不同意。模型处理完数据会以Notification的消息方式通知Command或者Mediator。但绝对不能在Proxy中直接调用Mediator，这是为了保证数据层的独立性、可移植性和重用性，也简化了你的架构思想。不过可移植性这个优势，估计很多搞FLASH WEB GAME的朋友暂时都没啥机会体验，呵呵。

2，Command，Command，Command！连叫三声“Command”，希望可以引起大家的注意。因为Command的使用，在很大程度上反映着你对pureMVC框架的理解，甚至是对MVC模式的理解深度。在pureMVC框架中，各部分通讯是用Notification消息，Proxy可以给Command和Mediator发消息，Command可以给Command和Mediator发消息，Mediator可以给Command和Mediator发消息，怎么样？你现在是不是点晕了，这是正常的，其实我也有点晕！当你代码写到一定规模后，你会更晕。其实pureMVC框架这么设计本来是为了让MVC各部分尽量脱耦，但这带来一个负面情况就是消息发送与接收机制设计的太灵活了，灵活对小项目是好事，但对大项目来说，往往意味着混乱，甚至会导致灾难。那怎么办呢？只能靠我们的自觉性自我约束，简化架构思想了。根据《pureMVC最佳实践》中的建议，我的做法是这样的，尽量使用Command，让Command成为Mediator与Proxy之间通讯的唯一桥梁，Mediator和Proxy中发出的Notification，接收者一定是某个Command，然后再由Command处理并将结果转发给真正的消息接收者，Command就算仅仅起一个转发作用，仅仅有不到10行代码，也要创建一个Command类。这样不仅使你的架构更加清晰，而且也更符合MVC思想，Command类的大量存在还使你架构的业务逻辑具有了更好的封装性和扩展性，可谓是一箭三雕，何乐而不为？唯一的负面影响可能是你需要创建和维护更多的Command类文件，但相对于优势而言，这点影响不算啥。

3，我知道现在可能还有一些朋友在用FLASH IDE写代码，这些朋友的执着让人钦佩，但我想任何一个熟练使用过FLEX BUDIER、FD或者FDT的朋友，都绝不会再回头使用FLASH IDE写代码了。——不对啊？不是谈pureMVC的么？怎么扯到IDE上去了？这是因为我现在要讨论的问题就和IDE有关，假如你现在用的还是FLASH IDE的话，除了随时写文档外，我真的很难想出一个很好的方案可以让你在没文档支撑的情况下，轻松掌握和随时维护几万行代码。可如果你使用的是FDT,就可以在没有文档的情况下，利用“ctrl + r”和“ctrl + 鼠标左键”，以及全文件搜索等工具，瞬间搞清楚代码之间的联系和逻辑，找出要修改的地方。OK，终于到pureMVC了。如果你使用的是FDT,并且开始尝试使用pureMVC框架，可在使用的过程中，你发现你在写主程序时，还是不停的使用“ctrl + 鼠标左键”，而不是“ctrl + r”，这说明你必须重新审视你对pureMVC框架的理解了，请审查你的Mediator类，看里面是不是充斥着大量的public方法，如果你的对象之间依旧是通过public方法进行引用，而不是通过Notification通讯的，那你也没有必要继续使用pureMVC框架了。

4，单例模式影响到底有多大？pureMVC是一个完全依赖单例模式的框架。单例模式似乎在AS界一直有很大争议，这样的话，pureMVC肯定也会有相应的争议了。持反对意见的人，大多集中在“性能”和“团队协作”方面，他们认为一个单例持有过多引用会带来性能问题，而且生怕在团队协作中自己的单例类被人无意修改，引发离奇的BUG。性能方面，我之前也没做过10W以上的项目，不敢妄言，但10W行以下的项目，绝对没有问题，如果你两三万行的架构就开始碰到主架构性能问题，估计十有八九是自己的代码写的有问题；团队协作方面，我觉得pureMVC的Façade模式是非常灵活好用的，大家可以略做讨论，制定一个简单的规则，比如模块只能通过façade获取数据和发送Notification，不能直接调用主程序其他CLASS，只要架构程序员不犯错，模块程序员甚至连犯错的机会都没有，如果他们有，还是你的架构思路有问题，请继续审视自己的代码。反正单例模式的问题到底是什么，我到现在也没完全搞懂，主要是我们的项目没碰到过此类问题，希望碰到过的朋友能再仔细跟火山说说，我也好弄清楚问题到底出在哪里了，自己以后可以更好的避免此类问题发生。

额，框架部分先谈上面4点吧，赶快进入下一个话题，模块划分：模块划分主要包括“核心模块划分”和“子模块划分”。核心模块的划分思路是这样的：它们是游戏启动所必须的，相互之间是紧密联系的，还要经常的被子模块调用；而相对的，子模块的划分思路是：他们在游戏启动过程中不是必须的，可以在游戏过程中再加载，子模块相互之间基本上完全没有联系，一个子模块的增加和删除不会影响到任何其他子模块，子模块可能需要调用主程序的接口或者获得主程序的数据，但主程序绝对不应该依赖某个子模块。

明确了模块划分思路再具体看看哪些部分应该划分为核心模块，哪些部分应该划分为子模块。一般情况下，核心模块按照游戏启动顺序包括：一个壳子SWF → 配置文件包 → 登录注册SWF → 主程序SWF → 主UI的SWF → 公共素材包。而子模块相对来说简单很多，比如具体的某个小游戏，某个场景，以及某个场景里的触发功能等等。下面我对核心模块逐一略做解释。“一个壳子SWF”：这是一个体积很小，但意义很大的SWF；它后面总是跟着随机变量，确保每次用户加载的都是最新的；它里面定义着一些需要经常更新而且每次更新都必须保证用户也在第一时间就得到最新值的变量；它里面最好有一个简单背景图，保证用户在超低网速的时候输入游戏网址不至于长时间面对一片空白；它里面有安全策略的设定，是我们游戏和很多第三方平台合作的基石；它里面还定义着主程序被加载进来之前的游戏启动流程等等。“配置文件包”：核心模块版本号啊，全局文字说明啊，service接口定义啊，各个核心模块需要的配置信息啊什么的，一般是一些XML文件。“登录注册SWF”：这个简单，在加载重量级的SWF前，先加载登录注册SWF,可以保证用户第一时间就能打开登录注册界面，而且可以有效节省服务器带宽。“主程序SWF”：这个就是我前面费了好大劲讲的主程序部分了。“主UI”：主程序和主UI为什么要分开两个SWF，我前面已经提过了，后面还有说明，这里暂时不讲。“公共素材包”：公共素材包是一个游戏不可缺少，但也不能过分依赖的东西。它包括一些全局的道具和效果，比如表情、技能特效、场景传送门等等。公共素材包里面最好就是一些简单的动画，体积小功能简单，严禁在公共素材包里添加上百K的东西，或者代码上百行的小模块，公共素材包建议500K以下。

看了上面的讲解，你可以能觉得核心模块分那么多，太麻烦了。不错，在我看来，对SWF加载流程的分解和控制，对异步程序的掌控正是衡量一个AS程序员是否经验丰富，是否足够老道的重要指标，很多从其它语言转到AS并有多年编程经验的朋友，架构方面可能和AS程序员差不多，甚至比很多自学成才的AS程序员做的更好，但这方面往往不如长期与CPU和SWF体积搏斗的老牌AS程序员。核心模块划分的越合理，用户体验往往越好，后期编写和维护代码的效率会越高，但在前期会比较麻烦，而且对架构师的架构经验和能力必须提出更高的要求。什么都不分，主程序、素材、核心模块都弄在一个SWF里，用户一开始必须先下载完这个SWF,或者弄了一堆核心模块和超多公共素材，用户一开始必须面对loading条不停的周而复始，必须等所有核心要素全部加载完成才能进行一些基本操作的做法，从架构角度上讲，是最简单的做法，因为不用过多考虑复杂的异步和SWF拆分问题，但从用户体验和长远的开发维护上讲是非常不利的。根据我们的经验，用户登录前加载的所有资源体积应该控制在200K左右，而用户进入游戏主场景前，加载的资源总数应该控制在1M左右。还有前面提到过的那位用了pureMVC后项目编译一下要十几分钟的朋友，估计就是把所有东西都弄到一个SWF里的做法。主程序随便改动测试一下，就要十几分钟，牵一发而动全身，开发效率从何谈起？根据我们的经验，任何主程序、核心模块还有子模块的编译，都必须在10秒以内，这才是合理的——我的机器是07年花了3000多买的戴尔品牌机。

→谈完主架构，接着谈主UI。主UI一般指主要的人机交互界面，这里的主UI区分于主架构中的mediator，当你看过pureMVC文档后，你就知道了，mediator只不过起到一个真正的V和pureMVC框架之间的桥梁作用，pureMVC里的mediator其实并不实现什么功能，真正的功能都是在主UI里实现的。但主UI又不得不算是主程序的组成部分，因为它不像其他模块，基本上只需要调用主程序的接口就行了，本身并不需要对主程序提供接口。而主UI作为用户操作界面，必须大量的向主程序的mediator提供接口，或者发送events。所以主程序和主UI之间的配合必须非常密切才行。

不同的游戏类型，可以选择的UI解决方案也不同。策略类非常适合用FLEX；MMORPG这类标准网游，非常适合用ASWING；而像我们海底世界这类游戏界面非常夸张，没什么标准规则，又不是太复杂的界面，还是适合自己开发。相信任何有过游戏项目经验的人都应该能理解，UI也是FLASH开发中的重头戏，很多细节的处理非常麻烦，在项目早期具有很大的工作量。还是以我们的项目为例，我们的UI架构思路是这样的：

1，所有的界面组件都是直接拖放在stage上的，其功能代码大部分都是在发布时编译的，基本上不用new的方式。这种方式的好处是方便编辑界面，从总体上直观的把握所有的UI，减轻程序运行时的负担，同时避免addToStage带来的诸多问题。缺点是，当UI膨胀到一定规模时，可能会需要你有一台配置比较好的电脑——哎，说到这里我就伤心啊，我那台玩魔兽效果全关还卡的电脑，一直陪伴我的整个UI开发历程。

2，UI的FLA层次结构是这样的：第一层是文档类或者与UI主类关联的某个MC，我们选用的是MC的方式,因为MC的方式更灵活；第二层是这个MC里的所有组件，这些组件大部分是根据功能划分在一起的一组元件，比如你的个人面板，而这个组件本身也是个MC；第三层是组件里的所有元件或者共用组件，元件就是背景啊，按钮啊什么的，而共用组件比如滚动条啊翻页组件啊什么的；主要的就这三层，其实那些共用组件MC再往里面双击还可以划分一层。对应FLA的层次结构，AS的结构如下：文档类或者主MC关联的类是第一层，这个类里持有所有的界面元件的引用；第二层是这些界面元件对应的组件CLASS,组件的功能都是在这里实现的，比如个人面板的MC将会对应一个MyPanel的CLASS,这个CLASS里实现MyPanel的所有功能。至于CLASS和元件之间是怎么对应的，我用的是一种松耦合的代理模式，也就是将MyPanel对应的MC作为参数传递给MyPanel这个CLASS,而这个CLASS会有自己的私有变量记录对应MC里需要进行操作的元件，具体到功能实现时，从代码层面上看，就好像CLASS操作的都是自己的私有变量，而不是直接操作界面元件，这样，当界面元件修改名字时，CLASS的改动很小。而且这种代理模式可以实现一个CLASS代理不同的元件，当界面只是需要修改外观，不需要修改功能时，非常方便。那么这些CLASS是在哪里初始化并获得它要代理的MC呢？正是在主MC对应的UI主类中，比如当获得MyPanel对应的MC后，就会立刻public var myPanel:MyPanel = new MyPanel(myPanel_mc);当所有的组件注册完成后，这个UI主类就持有了所有组件的引用，可以方便主程序调用；代码的第三层其实就是共用组件，比较特殊的是，我的共用组件，比如滚动条，也是用代理模式写的。

3，完全代理模式为我们创造了一种可能，就是把UI和UI对应的代码分开编译。这跟FLEX的皮肤更换机制有异曲同工之妙，只不过它的组件是要new出来的，布局是要代码控制的，皮肤都是一个个CLASS，整体效果一般都要编译后才能看出来；而我的组件是直接拖到舞台上的，布局大部分是直接在FLASH IDE里手动布置好的，皮肤都是一个个命名过的MC，整体效果编译之前基本上就能看出来。FLEX在更换皮肤的时候，CLASS名绝对不能变，而我的UI在更换皮肤时，MC的名字和层次结构不能变。FLEX关联皮肤是在编译时完成的，而我的UI关联皮肤是在运行时，当启动程序加载完UI代码的SWF和皮肤的SWF后，动态指定的。把皮肤和功能代码分开编译成两个SWF有个好处，就是在实际开发过程中，我们会碰到有时候只需要修改代码，而有时候只需要修改界面的情况，当然，就算你把代码和界面一起编译成一个SWF文件了，也完全可以对应这种情况，无非是编译一次的时间稍微长了一点点。可当你面对这样的情况呢：某次游戏版本更新出现状况，需要你目前功能不变，但画面必须退回到上一个版本。这时候你傻眼了吧？你开始对策划们咆哮：“你们能不能想想好再让我们做啊？”但你还是不得不重新打开已经做好的UI,把里面最新的界面再修改回老版本，同时还不敢把最新的删了，因为下一个版本估计马上又要替换回最新的画面了。可如果你的皮肤和代码是分开编译成两个SWF的，这种情况就简单了，你可以让运维从SVN上拉出上一个版本的皮肤SWF重新发布一下就好了，你所要做的只不过是动一下嘴皮。

4，最后谈一下UI的数据层吧，UI是否需要数据层呢？答案是肯定的。尽管你可以从主程序那里获得任何你想要的数据，尽管大部分时间你只是需要数据来显示一下而已，但UI自己记住某些数据会大大方便自己写代码。UI的数据层不需要主程序那么复杂，每个组件有自己的数据变量，然后整个UI再有一个存放公共数据的地方就足够了。

→谈完主程序和主UI，最后再简单谈一下小游戏、场景和模块。先说小游戏吧，小游戏是相对最独立的一块，可能只需要主程序提供用户数据，并在游戏结束后将分数发送给主程序就行了。所以这部分从管理的角度上来讲是相对轻松的，但这不意味着小游戏开发就简单了，有时候，麻雀虽小五脏俱全，想开发出一个性能和用户体验俱佳的小游戏绝非朝夕之功，要是碰到一些算法复杂的小游戏，那就有得头痛了。其实对于海底世界这类儿童社区游戏，小游戏应该走创意和简单路线，搞得太复杂了，既不好开发，小孩子又不一定玩得来。

相对于小游戏，场景和模块就和主程序甚至是主UI关系密切了，但不管怎么密切，大部分时候它们都是在所要数据，发送事件，或者触发某个界面的显示与隐藏。如果某个模块的修改需要经常波及到主程序，或者很多模块在做同一件事，重复写着同一段代码，这时候就必须重新审视架构，看是不是某些地方架构的不合理了，不合理的地方，只要时机允许，一定要尽快改掉，绝对不能放任自流，一块儿小毒瘤最终可能引发癌症。模块和场景程序员在我们公司其实是非常累的，因为每周都需要发布新的版本，每次都很赶。在这种情况下，场景和模块程序员的责任心就非常重要，他们随便哪里随意了一下，会直接导致糟糕的用户体验，因为大部分时间，用户直接接触的东西都是他们的作品。架构写的再好，最终模块都做的很糟糕，对用户来说没有任何价值！所以，一个老道的，有责任心的，能够快速开发出优良用户体验的AS模块程序员，完全有理由拿高薪，因为他们能做到的，一些所谓的纯架构师未必做得到！
我的FLASH情结2010——浅谈FLASH WEB GAME与创业

★前端与美术的配合
→老闪客们应该都知道，FLASH这款软件在历史很长一段时间内都是用来做动画的，闪客和美术在这段时间内本就是同根生。后来随着第二版AS1和AS2逐渐完善，以及AS3的强势出炉，闪客们才逐渐分化成纯程序和纯美术两个阵营了。但不管怎么分，FLASH程序和美术之间的关系依旧非常亲密，一个优秀的AS程序员必然要比其它语言的程序员懂得更多美术方面的知识，至少也要能熟练操作FLASH IDE，并进行简单的图形处理。FLASH程序员与美术的合作大部分时间是由AS程序员主导的，主要表现在以下几个方面：

1，FLA文件管理：把有联系的美术素材放进一个FLA文件中统一管理，既能有效减少美术素材的数量，也方便程序员写程序。本来像这种美术素材管理应该是由美术负责的，但由于这些美术素材大部分时间可能也需要程序员写程序，美术和程序需要共享这些素材，虽然我们可以用SVN进行共享和版本控制，但程序员和美术还是要靠约定才能非常默契的知道什么时间该到什么地方找什么文件。而这个约定就什么我们程序员应该制定的，因为据我观察，程序员在条理性和制定规则方面一般比美术更靠谱。以我们公司为例，文件管理基本上都是由我负责的，我把需要多个美术和程序员共同维护的部分以项目名命名成一个文件夹，项目下如果需要还可以进行子分类，分类规则也是我制定。而大部分的子模块可能只需要一个美术加一个程序员就搞定了，这时候美术就把素材放到以自己英文名命名的文件夹下，至于他们的文件夹内如何分类，我会给出意见，但并不强制管理。模块程序员也会都有以自己英文名命名的文件夹，他们会把美术的纯FLA素材拷贝到自己的文件夹下，并根据模块进行子分类，然后写代码并发布SWF，至于SWF文件如何管理，我会在下一节中讨论。其实我的管理目标非常简单，我只需要所有的美术和程序员能在任何时候瞬间找到我们需要的素材和源代码所在地，并且把需要的版本调出来。只要这个目标还在可控范围内，我就会给所有员工最大的自由性，把自己从管理里解脱出来，把更多的时间投入开发，毕竟对于创业型公司而言，快速开发，让老板和市场看到产品才是主旋律，管理只需要在必要的时候强势出手就可以了。事实上，我们公司的文件管理，我每隔半年才会强势管理一次，用大概一周的时间重新规范规则，其它时间基本处于放任自流状态，但从没出过什么大问题。最后给大家一个数字，我们公司经过将近三年的积累，已经有几十个G，上万个美术素材了。

2，SWF文件管理：SWF文件一般是由前端程序员发布并管理的，不过也有一些SWF可能不需要些代码，比如家具、个人面板背景等等，这些可以直接由美术管理，管理方案和FLA文件管理差不多。最大的不同就是，SWF文件最终的发布路径是内网模拟测试环境，而不是本机。像我们这样的更新驱动游戏，不可能为每一个模块都单独搭建拟真测试环境，如果这样的话，可能我们测试环境还没搭好，就该上线并准备下一周的更新了，所以所有的模块最终的整合测试都是直接上内网测试环境进行。

3，FLA内元件的管理：这个问题相信很多AS程序员都碰到过，也都为此头痛过。美术给到程序员手里的FLA文件可能是混乱不堪，库里没有任何分类，元件名也都是清一色的“元件1、元件2，元件3……”，元件内部遮罩，组合，层次也都没啥规律。要是美术直接给我一个AI或者PS的源文件让我们自己导入FLASH，那我们就更抽了，颜色模式的改变，路径工具的失灵，大量的图层导致裁切困难，而且还不能进行打散合并，只能一层一层的切。这个时候，正如我前面提到的，一个合格的AS程序员应该对美术和图形软件有更多的了解，你应当及时纠正美术不恰当的做法，甚至给出合理的解决方案，比如你应该知道FLASH只支持RGB颜色模式，AI不但整个文档可以指定颜色模式，每个图层也可以单独指定，当美术给到你的AI导入FLASH有色彩差异的时候，能帮助美术找到哪里的颜色模式不对，并建议他们以后只使用RGB模式。很多纯AS程序员可能有图形恐惧症，他们会想尽一切办法把这部分工作推向美术，但最终他们都会很郁闷，因为他们会发现，除了能指定库文件夹的命名规则外，其它的规则很难跟美术说明白，而且由于模块的千变万化，很难总结出一个完全通用的规则，想从美术哪里拿到一个完全不用修改，自己可以直接写代码的FLA文件，几乎天方夜谭。所以，与其让FLA文件在美术和程序的你来我往中浪费时间，与其让自己在对美术的鄙视中愤懑抱怨，不如提升一下自己的美术常识和图形处理基本功。毕竟，元件在舞台上怎么命名，关联什么类，层次怎么样，怎么被程序利用，这些只有我们程序员最清楚，这部分工作由我们程序员完成完全是合理的，也是效率最高的，美术只要把我们需要的素材交给我们，并放到方便查找的地方就可以了。放下程序员的架子，主动走入美术的世界，对我们程序员绝对有好处。

4，FP的性能问题对美术的影响：谈到这个问题，我就想起了一个让我抽搐已久的情况。我们老板总是喜欢语重心长的对我说：“火山，你给咱们前端人员和美术出一个方案吧，告诉他们怎么做可以让FLASH性能最高！”额，现在请问哪位朋友可以帮火山回答这个问题。火山真的惭愧，搞FLASH搞了7年了，始终还是没完全弄明白FLASH的诸多性能问题。不管以前的MM还是现在ADOBE，都将其图形处理和屏幕渲染部分视为其镇山之宝，不肯公开其技术内幕，我也就始终无法从理论的高度给出一个本质的回答。我现在的大多数性能解决方案，都是根据项目的实际情况，根据7年来的经验总结出的经验科学。而且我始终不相信，谁可以一个给出一个适合所有项目的、通用的性能解决方案，可以同时让内存、CPU、带宽占用都最少，而且画面又很炫，功能很强大，SWF文件非常小，可玩性非常高，而开发周期和成本却很少。内存、CPU、SWF体积、带宽、效果、成本，这几个要素往往是相互矛盾的，你对其中任何一点的过分优化，都有可能导致其它点走向反面。我深信，在目前这个时期，一个性能方面的高手，绝对不是看他能不能给出一个全面优化的方案，而是看他在面对不同的项目，不同的情况时，如何做出选择和取舍。是的，“选择和取舍”永远都是人生最艰难的话题：手心手背都是肉，削掉哪边呢？老婆孩子都掉海里了，救谁呢？在这样的情况下，我觉得一个负责的前端人员，反而不应该仅仅简单的扔给美术一份死的文档，告诉他们应该怎么做，让他们一直这么做就可以了。前端人员应该在每次面对一个实际情况时，都不厌其烦的跟美术讲清缘由，我们应该尽量授人以“渔”，而不授人以“鱼”，让他们明白选择的道理，而不是简单的告诉他们选择什么。相信只要是虚心学习的美术，经过一年半载的讲解他们就能替你做出判断了，这时候你再让他们去跟后来的美术讲，你就解脱了。很可惜，大部分不懂技术的老板可能觉得你是在故弄玄虚，非要你给出一份文档。无所谓了，你跟不懂技术的人争论不是自讨没趣么？老板更多时候是从管理的角度出发的，我们应该配合。我们也不是没什么可写，比如尽量减少元件数量啊，减小SWF体积啊，减少持续性动画啊，多做触发性动画啊，少用遮罩和滤镜啊，不要嵌入中文字体啊，提高元件重用性啊等等等等！这些建议听上去完全正确，忽悠不懂技术的人正合适。但其实在高端的开发中，这些理论都是废话，帮不上多大忙，因为地球人都知道了，我们碰到的问题肯定是超越这些技术点的高端问题！

综上可以看出，其实前端和美术的配合过程大部分时间是由前端主导的，这也是我前面一再强调前端要多懂一些美术知识的重要原因。当你可以和美术一起谈论美术理论，在美术的电脑上直接操作给他们看，当你从美术的角度给他们提出解决方案的时候，你往往会更容易被美术所接受。担负起主导前端与美术合作的责任，用你的智慧征服他们，用你的诚意打动他们，让美术与前端完美结合，让你的产品第一时间抓住用户！

★前端与后端的配合
→FLASH与后端通讯的手段多种多样，网上相关教程太多了，这里不再例举。但很多时候，创业团队由于受制于各种现实条件，可选择的方案并不多。像我们公司，刚开始基本上只能选择FMS+PHP+MYSQL。其实，对于我们前端来说，后端选择什么解决方案对我们的影响并不大，我们无非就是用的API不一样而已。多看看教程，用很少的时间我们就能掌握其要领。那么前后端合作的难点是什么呢？我觉得关键是逻辑的划分。

→“前后端合理划分逻辑”，这句话咋看上去貌似简单，其实里面蕴含着诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性：记得我们的游戏同时在线超过3000的时候，就已经有人开始攻击我们的后端了，篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家，如果是恶意的商业攻击，后果不堪设想。经过这次后，老板开始缠着我们追问“怎么防止别人攻击，提高安全性”。这个问题又一次把我们难住了，我们都知道，基于HTTP的请求不被截取是不可能的，而SWF文件又不存在绝对的安全。就算你防得了恶意进攻，你也防不了良性的外挂，想从技术层面让别人完全攻击不了我们也是不可能的。那我们是不是只能坐以待毙了？不是！如果前、后端在合作的时候，数据逻辑与合法性检查都是做在后端的，就可以很好的避免一些良性外挂。首先是游戏数据逻辑要尽量全做在后端，比如用户在玩小游戏的时候，我们不要只是在用户结束小游戏后，简单的把数据传回后端，后端记录进数据库完事，一旦攻击者发现了你这个传数据的后台接口，完全可以避开SWF，做外挂直接呼叫你这个接口刷分，就算你验证用户也没用，因为他可以先注册一个合法的用户，然后在外挂中登录再刷分。当然，你还可以对游戏分数先加密在传给后端，提高攻击难度，但这也是不保险的，因为加密算法就在你的SWF文件中，别人可以很容易获得。所以正确的做法应该是：游戏开始的时候只告知后端游戏ID→后端标识ID对应的游戏已经开始并记录开始时间→用户每次获得一个分数时，前端传回来的不是分数，而是一个动作ID,后端根据动作ID给用户加分→游戏结束时，前端告知后端游戏已经结束→后端得知游戏结束，记录结束时间，计算时间差，根据时间差和最后得分是否符合标准做出相应处理，如果符合标准就把最后得分入库，并返回前端显示给用户，如果不符合标准，就启动作弊处理系统。而这个标准一般是由数值策划给出的。经过我这么一分析，你可能头痛了，本来一个很简单的小游戏计分，怎么搞得这么复杂？前后端工作量都增加了不说，对后端性能也提出了更高的要求，服务器可能要增加了，后端人手可能要增加了，开发周期也要延长了，值得么？这个问题问的很好，这正是我下面要说的：后端性能、工作量、人事分工：一旦我们每一步进行安全性与合法性验证后，整个项目的工作量都会大大膨胀，开发周期也会大大延长；一旦我们把数据处理、业务逻辑和安全验证都移到后端时，后端的压力就会增加，服务器要增多，对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力，软件硬件都不足，可能顾不上那么多，一心想着早点让项目上线。在这种情况下，我觉得安全性可以暂时放一下，众所周知的安全漏洞补上就可以了。但“数据处理和业务逻辑”这个，宁可开发的慢一点，宁可再招个后端高手，宁可多几台服务器成本，也要把它们尽量都放在后端。因为这个没分清的话，会影响到整个系统的清晰度，严重影响项目中后期的发展，为日后的重构增加难度和超多的工作量，我们还指望着在重构时加强安全性呢，到时候数据处理和业务逻辑还是要放后端！所以综合考虑，该出手时就出手，能省的不浪费，不能省的不要抠！

→前面一节谈了前后端合作的难点。这里再简单的谈两个要点：
1，前端人员不要以前端的角度看后端：前端和后端有个本质的区别，就是前端的负荷是分担在每个客户端的，而服务端的负荷是集中在服务器上的。对于我们前端来说，一个功能多占了几K内存，SWF文件大了几K根本不是什么问题，可对后端来说就是很严重的问题了，一个人大几K，上千人就是几M了。服务器在连接数、内存和CPU之间会有微妙的平衡点，一旦这个平衡点被打破，随便再多哪怕一点点资源占用，整个服务器的性能都会严重下降，影响用户体验，当然，如果你有几十上百台冗余服务器供你负载平衡，你可以当我没说，可如果你像我们公司一样，一开始就3、5台服务器的话，就请前端人员一定要多多配合后端人员，帮他们省出每一个字节，每一次请求。比如像道具属性会有很多文字说明，这些说明应该以类似XML文件的方式储存为静态文件，后端返回给前端的道具数据包里只需要一串物品ID,前端就可以根据这些物品ID在XML文件里查询出这些道具对应的静态物品属性了。别看这些数据可能只有十几K，对后端来说意义重大。还是那句话，只要不是架构性问题，前端不要怕麻烦，要尽量配合后端提高性能。

2，前端后端要有很明显的BUG分界点。当一个BUG出现时，后端应当很快的用一种统一的方案证明数据没有问题！这个方案必须让前端知道，并让前端也可以操作。大家熟知的php remoting里有一个servicebrowser，这个东西就很好，它能罗列出所有PHP的接口，我们输入参数，它就返回结果，我们可以根据结果直接查看数据是否正确。——确定数据的正确性，对前端DEBUG非常重要，而一个BUG的解决，一般都是由前端人员入手并进行定位的。

→其实相对于前端和美术的合作，前端与后端的合作还是简单清晰的，前后端在开发的过程中，应该是非常独立的，后端开发完全可以先启动，把数据接口提前写好，等着与前端整合，而当整合过程发生问题时，又可以很快的界定是谁的问题。

★公司文化与产品定位
→前面谈了那么多，无论是策划、美术、前端还是后端，大家通力合作，共同奋斗的目标无非就是希望开发出来一个好产品，而开发出一个好产品的目标无非就是成就一个好公司，这就涉及到“产品定位”与“公司文化”的问题，公司文化和产品定位没做好，其它人再努力都是枉然。可正是这两个问题，从我们公司成立到现在一直困扰着我，我抓破脑袋苦思冥想，总结出我们公司的公司文化就是“老板说了算”，而我们的产品文化就是“与时俱进，不断重新定位”。下面我先谈公司文化再谈产品文化，因为产品文化是包含在公司文化中的。

→公司文化：一个公司的文化在很大程度上是由初创团队建立的，而初创团队一般分两种，一种是权利分散型，初创团队在各个领域都有领头人，虽然也有形式上的CEO，但产品、研发、市场相互干涉的并不多，领导层内部“三权分立，民主平等”，对外发言人则可以统一由CEO代劳。这种模式的优点是大家优势互补，让懂行的人完全负责相关领域，负责人成就感大，责任心强。缺点是，权利分散就要求领导层必须非常团结，配合默契，如果他们之间出现矛盾，对公司影响会很大。我们的竞争对手淘米网络就是这种模式，到目前为止，他们公司发展的还是最好的。另外一种模式就是“老板专政”模式，专政到什么程度，跟老板对权利的欲望有关。我们公司老板就专政到事无巨细的程度了，就连买一个几百块钱的路由器都要再三跟老板请示，美术、策划、开发所有的日程安排、人事任用都要由老板点头。“专政模式”在创业初期也未必就是坏事，因为创业初期，困难重重，大家又都有自己的想法，每个人的信心都比较脆弱，如果没有一个强势的人主掌大事，所有人容易形成一盘散沙的尴尬局面。专政模式下，公司文化其实就是老板的个人文化。专政的人一定要有专政的资本，有专政的能力，掌握着公司最大的权利，就必须承担最大的责任。如果公司成功了，就算你再说成功是大家的，最大的成功者还是你，但如果公司失败了，就算你找一千个理由推脱责任，最大的失败者也是你！在这种情况下，专政者要努力提高自己的全面素质，公司管理、产品、开发、策划、美术、市场都必须有所了解，你的任何一个错误的决定都会把公司推向深渊，并引起相关部门人员的不满。我们公司就是典型，老板以前是做销售的，对策划、开发和美术，甚至是互联网都没什么概念，做海底世界前连QQ都没用过！虽然他在资历和财力方面当之无愧，但其短板也是无法否认的事实。初创很长一段时间内，他都敢拍板说一个社区一个AS一个月搞定之类的话，而且还要非常强势的让你接受，并拿出执行方案。至于他为什么敢这么坚决的做出这个错误的决定，我也不明白。可能正是因为他也不知道到底需要多长时间才能开发出来，而我们又没有取得他的信任吧，所以他就只能尽量往少的时间说，等到我们没完成工作，大不了再延长时间而已。可这对我们这些开发者就造成很大困扰了，这种根本不可能达成的目标如何拿出执行方案呢？开发规划如何做呢？最后开发不出来谁承担责任呢？于是一个怪圈形成了：老板不信任开发→制定不合理的开发目标→制定不合理的开发规划→开发规划没完成或者大打折扣→老板认为开发者能力不行更不信任开发→老板要求开发者提升自身能力满足他的要求→开发者依旧满足不了老板→老板在工作能力和员工素质上全面怀疑开着者→制定更加不合理的开发目标甚至是惩罚制度→项目更加完不成……额，这真是一个装满了苦水，倒又倒不出的杯具！当然，只要不是傻子，在这个悲剧的循环过程中，不管是老板还是开发者都会变得越来越“聪明”，老板一天天成熟了，程序员一天天世故了。只是曾经浪费的时间，错过的时机不再有，曾经不合理制度下积累的问题，明天需要继续补救！如果上天能给大家一次重来的机会，我相信，老板会说：“下次我一定要在项目刚开始就找一个靠谱的，值得信任的CTO！”，而程序员会说：“我下次再也不会跟着不懂技术还自以为是，横加干涉的老板了！”

虽然“民主平等”和“高度专政”两种模式都有其优缺点，但最终玩的都是一个“人”字，相同项目，一个模式，不同的人玩出来的结果肯定不一样。同是专政模式，奥比岛就比海底世界成功。不过站在历史发展观上看两种模式的话，我个人更偏向于“民主平等”模式，这种模式下的公司领导层为了保证公司能长久健康发展，肯定会不得不想尽一切办法制定出平衡权利的法制规则，只要法制规则适应时代，领导层人事变动影响是可控的。而“专政模式”的专政者，为了保证其一手建立起来的商业帝国不至于在自己退位后轰然倒塌，肯定不得不想尽一切办法寻找接班人，帝国的命运系于接班人的选择。相对于“人治”，我觉得“法制”更靠谱。看到这里也许你又该搬出中国特色来反驳了，说什么中国的企业不合适。但纵观天下，历史的潮流是不可逆转的，中国作为历史发展的组成部分，脚步可以慢，但方向不会错。80后已经开始觉醒，90后会继续努力的。所以希望任何一个创业者在创业初期都认真的回答一个问题：你是只想做一个成功的企业家，还是想真正做一个成功的企业，让这个企业能长久发展，代代相传。一个成功的企业家的成功是个人的，而一个成功的企业的成功是大家的，是社会的！

→产品文化：产品文化包含于公司文化，“民主平等”的公司，产品的文化就是“管理层相同价值观”的文化，而“高度专政”的公司，产品文化就是“老板个人”的文化。不管是什么类型的公司，什么产品文化，这个文化一定要简明而清晰，要深入人心，最好能浓缩成简单的一个词或者句子，“妈妈放心，孩子喜欢”就代表着淘米网络的产品文化。这个口号从淘米成立不久就已经开始喊了，到现在没有变过。我相信他们的用户，他们用户的家长，他们公司从管理层到员工每一个人，就连他们的竞争对手都对他们公司的价值观，对他们的产品文化有一个清晰的认识。而我们公司呢？反观我们公司，在这方面做的非常差，公司从成立到现在产品定位一直在变，刚开始要做一个针对初高中生和女孩子的休闲社区，搞了几个月后，又发现企鹅，一股脑的投入到儿童这块儿蓝海市场，说要做一个中国版的企鹅俱乐部，再后来可能觉得儿童市场有点小，收费比较困难了，又想把产品目标用户群再提高一下，提高到初高中生也能玩，游戏复杂度也要随之提高，这样还没做多长时间，又看到人家淘米推出赛尔号这种PK游戏了，又觉得纯绿色游戏的可玩性不高，对用户尤其是男孩子的吸引力不够，又要在我们的游戏里也加入PK和打怪了。直到现在，公司里上上下下，除了老板之外，没几个人能弄清公司的产品定位是什么，我们的产品文化是什么！这种情况导致一个很严重的问题，就是策划在策划游戏的时候，没有核心价值观，也就更没什么游戏世界观了，最终导致游戏形散神也散！

游戏一直在改版，功能一直在开发，BUG一直都存在，性能一直上不去，目标用户群一直在改变，老用户一直在流失，我只能用一个词形容我的心情：痛心疾首！

★2010年：我的梦想扬帆起航
→从毕业就一直在酷噜，一直做FLASH WEB GAME，当时的想法很简单，就是想体验一下顶尖的FLASH应用开发。转眼即将三年了，回眸探望，几多感慨，但终究还是能淡然处之。毕竟大家都不容易，大家都在摸索，也都在摸索中前进和成长，公司现在其实已经比刚开始好多了。

→如今再打开4年前那篇《我的FLASH情结2006》，激扬的文字震撼我心。而现在的我，在海底世界的前端开发中已经找不到往日的激情，每日重复的机械劳动。而自己的理想，更是逐渐飘渺远去，一种温水煮青蛙的危机感油然而生。于是2010年，我向公司递交辞呈，结束我毕业后的第一份工作；再写一篇《我的FLASH情结2010》暂时结束FLASH WEB GAME开发。

→那么2010年，我要做什么呢？没错，我要开始做自己的项目了。我们公司的一位在商场上混迹多年的大股东在年会上语重心长的对我说：“火山啊，你现在自己做项目有两个最大的问题，一是你没在大公司呆过，对一些正规的公司流程不了解；二是你原始资本积累还严重不足，很难支撑项目长久下去。”其实我自己又何尝不明白呢，我知道自己这次单干也是九死一生，但我实在等不了了，7年的技术积累，3年的工作积累，为的就是今天，我也是奔三的人了，都讲男人30而立，马上要面对结婚生孩子，上有老下有小的艰难局面，我再不趁机把握最后这两年相对轻松自由的机会，以后会更难。我的梦想可能很天真，但我会做的很认真。

→其实冷静下来想想，也没什么好怕的，想当年我敢带着一千块钱闯上海，今天我就敢拿着几万块钱自己干，大不了折腾完了再到大公司打工深造呗。虽然我工作三年才积累了几万块钱这听上去有点寒，虽然我每个月最多只能给自己播出1000块钱的创业资本这听上去有点少，虽然我自己得把策划、开发、美术和运营全做了这听上去有点假，虽然现在我还天天穿着高中和从亲戚那里捡来的衣服这看上去有点苦，但这都是外人看我的观点，我自己是乐在其中，浑然不觉，哈哈。不管怎么样，2010年，我的梦想必须扬帆起航，不以成败论英雄，只为人生少留遗憾！

→完

• 2010年03月29日 -- 第二届中国flash开发者交流会归来 (2)

fxzjw的个人博客上有很多不错的flash文章：似是故人来的BLOG

我把学习向量的心得发到这里把，发到blog上看的人太少了，顺便可以让高手指正一下。呵呵，
向量第一课
一、向量的基本介绍：
向量几何在flash图形编程中的地位非常重要，因为在flash程序员的眼中，显示屏幕就是一个坐标系，运动物体的轨迹就是物体在这个坐标系曲线运动结果，而描述这些曲线运动的，就是2D向量及3D向量。使用向量可以很好的模拟物理现象以及基本的AI.
什么是向量？简单来说,向量就是有方向的线段,也叫做矢量。长度为1的向量叫做单位向量。
先来研究一下二维空间的向量，如图

上面的a,b,c,d四个向量的长度和方向相等，故它们都相等：
a=b=c=d=(x,y);（这是代数表示法）
令x方向的单位向量为i,y方向的单位向量为j, （i=(1,0),j=(0,1) |i|=|j|=1;|向量|表示对向量取模，也就是求取长度，必为正值）
则a=x*i+y*j
二、向量的运算：(其中a=(ax,ay),b=(bx,by))

加法：a+b=((ax+bx),(ay+by))

它的几何意义是a向量和b向量首尾相连则在上图中明显看出，以a的始点为始，以b的终点为终的向量就是a+b
减法：a-b=((ax-bx),(ay-by))

它的几何意义就是，两个向量始点重合，从b的终点开始到a的终点结束的向量就是a-b了
和常数相乘：a*k=e=(k*ax,k*ay)

它的几何意义是，乘一个大于0的数，则向量的方向不变，只是在同方向上伸缩。如果乘一个小于0的数，就在反方向伸缩了，是伸是缩，取决于｜k｜是大于还是小于1了。
点乘：a·b=|a|*|b|*cosα(注意a·b中的点不是数字相乘的意思，α是a和b之间的夹角）

（ 附：a·b=(xa * i + ya * j).(xb * i + yb * j)

= xa * i * xb * i + xa * i * yb * j + ya * j * xb * i + ya * j * yb * j

=(xa * xb) * (i * i) + (xa * yb) * (i * j) + (xb * ya) * (i * j) + (ya * yb) * (j * j)= xa * xb + ya * yb   )
它的几何意义是，a的长度与b在a上的投影长度的乘积，或者是b的长度与a在b上投影长的乘积，它是一个标量，而且可正可负。因为互相垂直的向量其中 一个在另一个上面的投影为0，所以它们的内积为0（a.b = |a|.|b|*cos(PI/2) = |a|.|b|*0 = 0）.注意：点乘得到的是一个值，不是一个向量
至于叉乘，用到的很少，就不说了。

另外，再介绍一点向量的基本性质：

1. a + b = b + a
2. (a + b) + c = a + (b + c)
3. a + 0 = 0 + a = a
4. a + (-a) = 0
5. k*(l*a) = (k*l)*a = a*(k*l)
6. k*(a + b) = k*a + k*b
7. (k + l)*a = k*a + l*a
8. 1*a = a
9. a·b = b·a
10. a·(b + c) = a·b + a·c
11. k*(a·b) = (k*a)·b = a·(k*b)
12. 0·a = 0
13. a·a = |a|^2

好，有了这些，你已经有了大部分的知识，下一次我们就要用它们做一个动画，但是！在此之前，请你确定，你已经把上面的知识掌握了个八九不离十！

————————

向量第二课

那么，在flahs中，什么地方有向量呢？
物体运动的速度，物体的位置，力，障碍物等都可以看成向量，我们还是先来看一个非常简单的例子吧，假设你正在编写一个飞行射击游戏，你的敌人需要一种很厉 害的武器-跟踪导弹，这种武器在行进的同时不断的修正自己与目标之间的位置关系，使得指向的方向总是玩家，而不论玩家的位置在哪里，这对一个水平不高的玩 家(我？)来说可能将是灭顶之灾，玩家可能很诧异敌人会拥有这么先进的秘密武器，但对于你来说只需要在程序循环中加入几行代码。在此之前，首先再学一个向 量的知识。
向量的归一化：
有些时候，我们需要让向量的长度为一个定值，如速度等，这个时候我们就要让向量的长度（模）为1，然后乘上速度的大小。那么怎么让向量的长度为1？
首先你必需先算出向量的长度，再用向量除以长度，即可。
设a=(x,y)，则
|a| = |(x,y)| = |x*i + y*j| = sqrt(x*x + y*y)，这里sqrt是开平方。
a的单位向量为a/|a|，即(x，y)/sqrt(x*x + y*y)。

首先我们要知道玩家的位置(x_player， y_player)，然后，我们的导弹就可以通过计算得到一个有初始方向的速度，速度的方向根据玩家的位置不断修正，（如图）它的实质是一个向量减法的计 算过程。速度的大小我们自己来设置，它可快可慢，视游戏难易度而定，它的实质就是向量单位化和数乘向量的过程。具体算法是：导弹的更新速度 (vx_missile， vy_missile) = 玩家的位置(x_player， y_player) – 导弹的位置(x_missile， y_missile)，然后再对(vx_missile， vy_missile)做归一处理，乘上你设置的速度。导弹移动，判断是否追到玩家，重新更新速度，……

var n_missile:Number ; // 这是玩家位置与导弹位置之间向量的长度
var  v_rate:Number ; // 这是导弹的速率缩放比率
// 计算一下玩家与导弹之间的位置向量
var xv_missile:Number = x_player-x_missile ; // 向量减法，方向由导弹指向玩家，x分量
var yv_missile:Number = y_player-y_missile ; // y分量

// 计算一下它的长度
n_missile = sqrt( xv_missile*xv_missile + yv_missile*yv_missile ) ;
// 归一化导弹的速度向量：
xv_missile /= n_missile ;
yv_missile /= n_missile ;

// 此时导弹的速率为1，注意用"速率"是因为它没有方向,是值,不是向量。
// 好！现在导弹的速度方向已经被修正，它指向玩家。
// 由于现在的导弹速度太快，为了缓解一下紧张的气氛，我要给导弹减速
var v_rate:Number = 0.2 ; // 减速比率
xv_missile *= v_rate ; // 这里的速率缩放比率，你可以任意调整大小
yv_missile *= v_rate ; // 可以加速：v_rate大于1；减速v_rate大于0小于1，这里就这么做！

// 导弹行进！导弹勇敢的冲向玩家！
x_missile += xv_missile ;
y_missile += yv_missile ;

// 然后判断是否攻击成功

请注意，因为上例只是为了说明向量的一个最简单的应用，所以只是部分代码，另外，有的中级朋友可能要问了，你这个写法不用向量也行啊？为什么要舍简取繁？这个问题啊，呵呵，下回分解！

———————-

第三课

学习了前两课后，大家对向量有了一个初步的认识，这次，我们还是来个简单的应用：小圆在大圆内的碰撞，(为了简化这个问题，我在图中以圆心为坐标原点)如图：

分析一下碰撞的过程，我们发现，要实现这个碰撞的过程，必须要解决两个问题，
1、什么时候发生碰撞？
2、碰撞后小圆如何运动？
第一个问题解决起来非常简单，只要把小球的位置看成一个向量，这个向量的长度(模)大于或等于圆的半径r时，即判断发生了碰撞(实际因为小圆不是一个质点，故还应该考虑它的半径，这个稍后再说)。
第二个问题，解决起来也不难，请看图，就是一个已经知道了速度向量v,要求出反弹后的速度向量v1，只要把速度向量取反，得到vo,再求出l和vo的夹角 α，再让v0旋转2*α(因β=α)不就搞定了么？现在可能有的朋友要问了，你说的简单，那么写成代码怎么写啊，又是一大堆吧？
这里我们就发现一个问题，我们经常用到向量的一些相关知识，比如说取长度，取反(求逆)相加相减，求夹角，等等，那么，我们为什么不写成一个向量的类呢？ 比如说写一个Vector.as的类文件，其中有上面各种计算的方法(这个类文件下载地址在后面)，那么比如说我要新建一个速度向量v，水平速度为2，竖 直速度为3，就可以：
var v:Vector=new(2,3);

求其模就可以：
v.getLength();//getLength()是Vector类中的一个方法

求其与x轴正向的夹角就可以：
v.getAngle();//getAngle()也是Vector类中的一个方法

好了，下面就说一下怎么写这个小球在圆内碰撞的AS了，首先，我新建了两个MC,ball_mc(小球的实例名)circle(外圆的实例名)，在主时间轴上附加如下代码(也可用文档类，但我觉得东西不多就懒得写)

import Vector;

circle.x=stage.stageWidth/2;
circle.y=stage.stageHeight/2;
//速度向量，你可以随便改之
var v:Vector=new Vector(8,4);
//小球位置所表示的向量
var v_ball:Vector=new Vector(2,50);
var circen:Vector=new Vector(circle.x,circle.y);

stage.addEventListener(Event.ENTER_FRAME,enterhandler);
function enterhandler(ev:Event) {
        v_ball.plus(v);//plus是Vector类中的一个方法，用来将两个向量相加
        render(ball_mc,v_ball);
        //让小球按速度开始运动
        if (v_ball.getLength()>=(circle.width-ball_mc.width)/2) {
                //如果小球的位置向量大于两球的半径之差的，实际就是说小球和大圆发生了碰撞
                v_ball.setLength((circle.width-ball_mc.width)/2);
                render(ball_mc,v_ball);
                //让v_ball向量的长度正好为两球的半径之差的一半，再刷新，就让小球正好碰到大圆的边缘
                v.negate();
                //取反
                var ang1:Number=v_ball.getAngle();
                var ang2:Number=v.getAngle();
                //求出的这两个角之差就是上图的α
                v.rotate(2*(ang1-ang2));
                //让取反后的速度向量旋转两倍的α就得到新的速度向量
        }
}

//当v_ball改变时，刷新小球的位置
function render(a:MovieClip,b:Vector) {
        var temp:Vector=b.plusNew(circen);
        a.x=temp.xV;
        a.y=temp.yV;
}

上面的代码，如果在不加注释时，仅为20行。应该算是简单明快了吧
小球碰撞.swf (1.74 KB)

Vector类下载：
Vector.rar (1.28 KB)

———————–

第四课

平面内物体任意角度的反弹
根据初等物理，相互接触的物体在受到外力具有接触面相对方向相对运动趋势的时候，接触面会发生形变从而产生相互作用的弹力。弹力使物体形变或形变同时运动形式发生改变。在知道了这件事情之后，我们开始具体讨论下面这种情况：

小球和矩形框碰撞，碰撞时间极短，墙面无限光滑从而碰撞过程没有摩擦，碰撞时间极短，没有能量损失…总之是一个理想的物理环境。我们在这种理想环境 下讨论，小球与墙面发生了完全弹性碰撞，且反射角和入射角相等：∠2=∠1, ∠4 =∠3, ∠6 =∠5,…。虚线是法线，它和墙面垂直。小球将在矩形框中永无休止的碰撞下去，且每次碰撞过程中入射角和反射角都相等。
我们再具体点,现在假设上面那个矩形墙壁的上下面平行于x轴，左右面平行于y轴。这样太好了，我们在编写程序的时候只要判断当球碰到上下表面的时候将y方 向速度值取反，碰到左右表面时将x方向速度值取反就行了，这种方法常常用在简单物理模型和规则边界框的游戏编程上，这样可以简化很多编程步骤，编写简单游 戏时可以这样处理。可事实不总是像想向中的那么好。如果情况像下面这样：

虽然在碰撞过程中入射角仍然等于反射角，但是边界的角度可没那么“纯”了，它们的角度是任意的，这样就不能简单的将x方向或者y方向的速度取反了，我们要另找解决办法。
在此之前，我们先要复习下前面的知识：
什么叫点积？

看上图，a.b =|a|*|b|*cosβ 也就是说等于a向量长度乘以b向量的长度再乘以夹角的余弦
几何意义：a和b的点积等于a在b上的投影长d的长度乘以b的长度。
那么，我们现在要求a在b上的投影向量c怎么求？
那我们先要求a在b上的投影长，然后再乘上b方向上的单位向量b1
a在b上的投影长,可以用a点乘b的单位向量b1就可以了，因为单位向量的长度为1，a的投影长|a|乘上1还等于投影长自身，即：
|d|=a.b1
好，我们得到了d的投影长，现在就可以求出d:
d = |d|*a1= a.b1*a1
总结一下，就是d = (a.b1)* b1。
用向量类来写一下伪代码：
取得b的单位向量：b1=b.setLength(1);
得到d的长度：   |d|= a.b1
得到d向量：d=b1.setLength(|d|)
再看一下，用a与b的同模相反向量c来点积，即：
a.c =|a|*|c|*cosα
很明显，由于α与β之和为π所以cosα与cos互为相反数
故:
a.c =|a|*|c|*cosα= －|a|*|b|*cosβ= －a.b
又由于b和c是同模相反向量：b=－c
也就是可以得出结论：
d = (a.b1)* b1→
d = －(a.c1)* －c1
由此得出结论：
要求出a 向量在另一向量b上的投影向量，可用a向量和b的单位向量b1点积再乘以b1，并且与另一向量b的方向无关。
好了，我们现在来研究一下，怎么利用向量来解决不规则碰撞的问题.
我们现在的任务是：已知物体的速度向量S和边界向量b，求它的反射向量F。我们先来看一下在碰撞过程中都有哪些向量关系,如图：

设b是障碍向量，S是入射速度向量，F是反射速度向量，也就是我们要计算的向量。N是b的法向量，即N垂直于b。n是与N共线的向量，n’是N方向的单位向量。T是垂直于N的向量。根据向量加法，现在有关系：
(1) S + n = T
(2) n + T = F
合并，得
F = 2*T – S
我们已经找到了计算F的公式了。这里S是已知的，我们要计算一下T,看(1)式：
T = S + n
要计算T，S是已知的，就要计算一下n。我们知道，n是S在N方向上投影得到的，S已知所以要得到n就要再计算一下N，而N又是和b垂直的，我们可以利用向量的旋转方法，让b旋转90度，就可以得到N。另外还记得刚才我们导出的使用向量的技巧吧，这里我们要用到：
要求s 向量在另一向量N上的投影向量，可用s向量和N的单位向量n1点积再乘以n1，并且与另一向量N的方向无关。
我们知道了N。利用向量类的setLength(1)计算出n1,再用上述技巧要使s和n1的起点相同，必须要使对S取反，然后用 n = ( -s.n1 ) * n1，这样就计算出了n。然后根据上面的(1)式计算出T，好了，有了T和F = 2*T – S ，一切OK!
计算出的F就是物体碰撞后的速度向量，在2-D中它有两个分量x和y，3-D中有x,y,z三个分量。这里也证明了使用向量的一个好处就是在一些类似这样关系推导过程中不用去考虑坐标问题，而直接的用简单的向量就可以进行。
这里注意我们的障碍向量b在实际的编程中是用障碍的两个端点坐标相减计算出的，计算的时候不需要考虑相减的顺序问题。因为虽然用不同的相减顺序得到b的方向相反，且计算得到的单位法向量n1方向也相反（看上图的虚线部分），但是由前述的技巧可知，这个无关紧要。

那么，什么时候物体和边界碰撞，又怎么把上述知识用到flash中？欲知后事如何，且听下回分解：

———————-

第五课

2D边界碰撞检测
一、使用向量进行障碍检测的原理
上次说了使用向量模拟任意角度的反弹，这次谈谈它的前提—障碍碰撞。

在flsah中进行障碍碰撞检测，基本思路是这样的：给定一个障碍范围，判断物体在这次移动后会不会进入这个范围，如果会，就发生碰撞，否则不发生碰撞。 在实际操作中，一般是用物体的边界来判断。这时候，就可以从物体的位置沿着速度的方向引出一条速度向量线，判断一下这条线段（从检测部位到速度向量终点） 和障碍边界线有没有交点，如果有，这个交点就是碰撞点。

上面物体A，在通过速度向量移动之后将到达B位置。但是，这次移动将不会顺利进行，因为我们发现，碰撞发生了。碰撞点就在那个红色区域中，也就是速度向量和边界线的交点。我们接下来的工作就是要计算这个交点，这是一个解线性方程组的过程，那么我们将要用到一样工具…
二、一个解线性方程组的有力工具—克兰姆(Cramer)法则

首先要说明一下的是，这个法则是有局限性的，它必须在一个线性方程组的系数行列式非零的时候才能够使用。别紧张，我会好好谈谈它们的。首先让我来叙述一下这个法则（我会试着让你感觉到这不是一堂数学课）：
如果线性方程组：
A11*X1 + A12*X2 + … + A1n*Xn = b1
A21*X1 + A22*X2 + … + A2n*Xn = b2
……………………………..
An1*X1 + An2*X2 + … + Ann*Xn = bn
的系数矩阵 A =
| A11 A12 … A1n |
| A21 A22 … A2n |
| …………… |
| An1 An2 … Ann |

的行列式 |A| != 0
线性方程组有解，且解是唯一的，并且解可以表示为：
X1 = d1/d , X2 = d2/d , … , Xn = dn/d （这就是/A/=d为什么不能为零的原因）
这里d就是行列式|A|的值，dn(n=1,2,3…)是用线性方程组的常数项b1,b2,…,bn替换系数矩阵中的第n列的值得到的矩阵的行列式的值，即：
| b1 A12 … A1n |
d1 = | b2 A22 … A2n |
| ………….. |
| bn An2 … Ann |

| A11 b1 … A1n |
d2 = | A21 b2 … A2n |
| ………….. |
| An1 bn … Ann |

…

| A11 A12 … b1 |
dn = | A21 A22 … b2 |
| ………….. |
| An1 An2 … bn |

别去点击关闭窗口按钮！我现在就举个例子，由于我们现在暂时只讨论2D的情况（3-D以后会循序渐进的谈到），先来个2D线性方程组示例一下：

(1) 4.0*X1 + 2.0*X2 = 5.0
(2) 3.0*X1 + 3.0*X2 = 6.0
这里有两个方程，两个未知量，则根据上面的Cramer法则：
| 4.0 2.0 |
d = | 3.0 3.0 | = 4.0*3.0 – 2.0*3.0 = 6.0 （2阶行列式的解法，’\'对角线相乘减去’/'对角线相乘）

| 5.0 2.0 |
d1 = | 6.0 3.0 | = 5.0*3.0 – 2.0*6.0 = 3.0

| 4.0 5.0 |
d2 = | 3.0 6.0 | = 4.0*6.0 – 5.0*3.0 = 9.0
则
X1 = d1/d = 3.0/6.0 = 0.5
X2 = d2/d = 9.0/6.0 = 1.5
好了，现在就得到了方程组的唯一一组解。
是不是已经掌握了用Cramer法则解2-D线性方程组了？如果是的话，我们继续。
三、深入研究
这里的2-D障碍碰撞检测的实质就是判断两条线段是否有交点，注意不是直线，是线段，两直线有交点不一定直线上的线段也有交点。现在我们从向量的角度，写出两条线段的方程。

现在有v1和v2两条线段，则根据向量加法：
v1e = v1b + s*v1
v2e = v2b + t*v2
v1b和v2b分别是两线段的一端。s,t是两个参数，它们的范围是[0,1],当s,t=0时，v1e=v1b,v2e=v2b；当s,t=1时,v1e和v2e分别是两线段的另一端。s,t取遍[0,1]则v1e和v2e取遍两线段的每一点。
那么我们要判断v1和v2有没有交点，就让v1e=v2e，看解出的s,t是不是在范围内就可以了：
v1e = v2e
=> v1b + s*v1 = v2b + t*v2
=> s*v1 – t*v2 = v2b – v1b
写成分量形式：
s*x_v1 – t*x_v2 = x_v2b – x_v1b
s*y_v1 – t*y_v2 = y_v2b – y_v1b
现在是两个方程式，两个未知数，则根据Cramer法则：
| x_v1 -x_v2 |   | 4.0 -2.0 |
d = | y_v1 -y_v2 | = | 1.0 -3.0 | = -10.0

| x_v2b-x_v1b -x_v2 |   | 5.0 -2.0 |
d1 = | y_v2b-y_v1b -y_v2 | = | 2.0 -3.0 | = -11.0

s = d1/d = -11.0/-10.0 = 1.1 > 1.0
现在s已经计算出来，没有在[0.0,1.0]内，所以两线段没有交点，从图上看很直观。t没有必要再计算了。所以是物体与障碍没有发生碰撞。如果计算出的s,t都在[0,1]内，则把它们带入原方程组，计算出v1e或者v2e，它的分量就是碰撞点的分量。

四、理论上的东西已经够多的了，开始写程序

我现在要写一个用于处理障碍碰撞检测的函数，为了测试它，我还准备安排一些障碍：

这是一个凸多边形，我让一个质点在某一位置,然后给它一个随机速度，同时检测是否与边界发生碰撞。当碰撞发生时，反弹，并计算它的反弹速度，继续……

——————

第六课

code:(注意：下面的代码可以直接复制到主时间轴上测试，故不再附上swf文件)

import Vector;

var sp:Shape=new Shape();
var matrix:Matrix = new Matrix();
matrix.createGradientBox(40, 40, Math.PI/4, -20,-30);

sp.graphics.beginGradientFill("radial",[0xff0000,0xff0000],[0,1],[0,255],matrix);
sp.graphics.drawCircle(0,0,20);
sp.graphics.endFill();

addChild(sp);

sp.x=sp.y=100;
//初速度
var v:Vector=new Vector(0,10);
//障碍坐标
var arr:Array=[20,80,100,20,250,40,450,200,200,350,40,250,20,80];
//把边界给画出来
drawBorder(arr,this);

stage.addEventListener(Event.ENTER_FRAME,enterhandler);

function enterhandler(event:Event):void {
        sp.x+=v.xV;
        sp.y+=v.yV;
        //创建一个小球位置的向量
        var v1:Vector=new Vector(sp.x,sp.y);
        for (var j:int=0; j<arr.length/2-1; j++) {
                var l1:Vector=new Vector(arr[j*2],arr[j*2+1]);
                var l2:Vector=new Vector(arr[j*2+2],arr[j*2+3]);
                //注意：小球并不是一个质点，所以要把障碍向量向中心移动小球半径的值
                var l:Vector=l2.minusNew(l1);
                var N:Vector=l.rotateNew(Math.PI/2);
                N.setLength(sp.width/2);
                //利用克兰姆（Cramer）法则来解线性方程组
                var d:Number=v.xV*(-l.yV)-(-l.xV*v.yV);
                var d1:Number=((l1.xV+N.xV-v1.xV)*-l.yV)-
                (-l.xV*(l1.yV+N.yV-v1.yV));
                var d2:Number=v.xV*(l1.yV+N.yV-v1.yV)-
                v.yV*(l1.xV+N.xV-v1.xV);
                if (Math.abs(d)<0.001) {
                        d=0.001;
                }
                var t:Number=d1/d;
                var s:Number=d2/d;

                if (t>=0&&t<=1&&s>=0&&s<=1) {
                        //当t和s均在0和1之间时，向量l和v相交
                        var dv:Vector=v.scaleNew(t);
                        sp.x+=dv.xV;
                        sp.y+=dv.yV;
                        //速度向量
                        //var f:Vector=new Vector(1,1);
                        //速度向量反方向的向量
                        //var f1:Vector=f.negateNew();
                        var vNeg:Vector=v.negateNew();

                        //障碍向量
                        //var l:Vector=new Vector(-3,-1);
                        //旋转障碍向量得到法向量
                        var n1:Vector=l.rotateNew(Math.PI/2);
                        //向量长度归一
                        n1.setLength(1);
                        //得到速度向量在法向量上的投影长
                        var dotv:Number=vNeg.dot(n1);
                        //获得和法向量相同，但长度为投影的一个向量
                        n1.setLength(dotv);
                        n1.scale(2);
                        v.plus(n1);
                }
        }
}

function drawBorder(a:Array,b:Sprite):void {
        b.graphics.lineStyle(2,0x000000);
        b.graphics.moveTo(a[0],a[1]);
        for (var i:int=1; i<a.length/2; i++) {
                this.graphics.lineTo(a[i*2],a[i*2+1]);
        }

}

现在你就可以结合上次的讨论模拟一个完整的理想物理情景：一个物体在不规则障碍中移动、反弹，永不停息…除非…
至此为止我们讨论了2-D游戏的障碍碰撞检测以及它的编程实现，在此过程中涉及到了线性代数学的知识，以后随着深入还会不断的加入更多的数学、物理知识。下次我们继续讨论，BYE!

——————–

接着是两球碰撞

2-D物体间的碰撞响应(首先说一点，这里所有的代码不用向量都可以写出，但用了向量可以使你思考问题时更能接近于实际，容易理解)

这次我要分析两个球体之间的碰撞响应，这样我们就可以结合以前的知识来编写一款最基本的2-D台球游戏了，虽然粗糙了点，但却是个很好的开始，对吗？
一、初步分析
中学时候上物理课能够认真听讲的人（我？哦，不包括我）应该很熟悉的记得：当两个球体在一个理想环境下相撞之后，它们的总动量保持不变，它们的总机械能也守恒。但这个理想环境是什么样的呢？理想环境会不会影响游戏的真实性？对于前者我们做出在碰撞过程中理想环境的假设：
1）首先我们要排除两个碰撞球相互作用之外的力，也就是假设没有外力作用于碰撞系统。
2）假设碰撞系统与外界没有能量交换。
3）两个球体相互作用的时间极短，且相互作用的内力很大。
有了这样的假设，我们就可以使用动量守恒和动能守恒定律来处理它们之间的速度关系了，因为1）确保没有外力参与，碰撞系统内部动量守恒，我们就可以使用动 量守恒定律。2）保证了我们的碰撞系统的总能量不会改变，我们就可以使用动能守恒定律。3）两球发生完全弹性碰撞，不会粘在一起，没有动量、能量损失。

而对于刚才的第二个问题，我的回答是不会，经验告诉我们，理想环境的模拟看起来也是很真实的。除非你是在进行科学研究，否则完全可以这样理想的去模拟。

现在，我们可以通过方程来观察碰撞前后两球的速度关系。当两球球心移动方向共线(1-D处理)时的速度，或不共线(2-D处理)时共线方向的速度分量满足：
(1)m1 * v1 + m2 * v2 = m1 * v1′ + m2 * v2′ （动量守恒定律）
(2)1/2 * m1 * v1^2 + 1/2 * m2 * v2^2 = 1/2 * m1 * v1′^2 + 1/2 * m2 * v2′^2 （动能守恒定律）
这里m1和m2是两球的质量，是给定的，v1和v2是两球的初速度也是我们已知的，v1′和v2′是两球的末速度，是我们要求的。好，现在我们要推导出v1′和v2′的表达式：
由(1)，得到v1′ = (m1 * v1 + m2 * v2 – m2 * v2′) / m1，代入(2)，得
1/2 * m1 * v1^2 + 1/2 * m2 * v2^2 = 1/2 * m1 * (m1 * v1 + m2 * v2 – m2 * v2′)^2 + 1/2 * m2 * v2′^2

=> v2′ = (2 * m1 * v1 + v2 * (m2 – m1)) / (m1 + m2)，则
=> v1′ = (2 * m2 * v2 + v1 * (m1 – m2)) / (m1 + m2)
我们现在得到的公式可以用于处理当两球球心移动方向共线(1-D处理)时的速度关系，或者不共线(2-D处理)时共线方向的速度分量的关系。不管是前者还是后者，我们都需要把它们的速度分解到同一个轴上才能应用上述公式进行处理。
二、深入分析
首先我要说明一件事情：当两球碰撞时，它们的速度可以分解为球心连线方向的分速度和碰撞点切线方向的分速度。而由于它们之间相互作用的力只是在切点上，也 就是球心连线方向上，因此我们只用处理这个方向上的力。而在切线方向上，它们不存在相互作用的力，而且在理想环境下也没有外力，因此这个方向上的力在碰撞 前后都不变，因此不处理。好，知道了这件事情之后，我们就知道该如何把两球的速度分解到同一个轴上进行处理。

现在看上面的分析图，s和t是我们根据两个相碰球m1和m2的位置建立的辅助轴，我们一会就将把速度投影到它们上面。v1和v2分别是m1和m2的初速 度，v1′和v2′是它们碰撞后的末速度，也就是我们要求的。s’是两球球心的位置向量，t’是它的逆时针正交向量。s1是s’的单位向量，t1是t’的 单位向量。
我们的思路是这样的：首先我们假设两球已经相碰（在程序中可以通过计算两球球心之间的距离来判断）。接下来我们计算一下s’和t’，注意s’和t’的方向 正反无所谓（一会将解释），现在设m1球心为(m1x, m1y)，m2球心为(m2x, m2y)，则s’为(m1x-m2x, m1y-m2y)，t’为s’.rotateNew(PI/2)
再利用setLength(1)可以将两个向量归一，就得到了s和t的单位向量s1,t1.
现在s和t轴的单位向量已经求出了，我们根据向量点乘的几何意义，计算v1和v2在s1和t1方向上的投影值，然后将s轴上投影值代入公式来计算s方向碰 撞后的速度。注意，根据刚才的说明，t方向的速度不计算，因为没有相互作用的力，因此，t方向的分速度不变。所以我们要做的就是：把v1投影到s和t方向 上，再把v2投影到s和t方向上，用公式分别计算v1和v2在s方向上的投影的末速度，然后把得到的末速度在和原来v1和v2在t方向上的投影速度再合 成，从而算出v1′和v2′。好，我们接着这个思路做下去：
先算v1（v1x, v1y)在s和t轴的投影值，分别设为v1s和v1t：
v1s = v1.s1
v1t = v1.t1
再算v2（v2x, v2y)在s和t轴的投影值，分别设为v2s和v2t：
v2s = v2.s1
v2t = v2.t1
接下来用公式

=> v2′ = (2 * m1 * v1 + v2 * (m2 – m1)) / (m1 + m2)，则
=> v1′ = (2 * m2 * v2 + v1 * (m1 – m2)) / (m1 + m2)
计算v1s和v2s的末值v1s’和v2s’，重申v1t和v2t不改变：

好，下一步，将v1s’和v1t再合成得到v1′，将v2s’和v2t再合成得到v2′,我们用向量和来做：
首先求出v1t和v2t在t轴的向量v1t’和v2t’（将数值变为向量）
v1t’ = v1t * t1
v2t’ = v2t * t1

再求出v1s’和v2s’在s轴的向量v1s’和v2s’（将数值变为向量）

v1s’= v1s’ * s1
v2s’= v2s’ * s1
最后，合成，得
v1′ = v1t’ + v1s’
v2′ = v2t’ + v2s’
从而就求出了v1′和v2′。下面解释为什么说s’和t’的方向正反无所谓：不论我们在计算s’时使用m1的球心坐标减去m2的球心坐标还是相反的相减顺 序，由于两球的初速度的向量必有一个和s1是夹角大于90度小于270度的，而另外一个与s1的夹角在0度和90度之间或者说在270度到360度之间， 则根据向量点积的定义|a|*|b|*cosA，计算的到的两个投影值一个为负另一个为正，也就是说，速度方向相反，这样就可以用上面的公式区求得末速度 了。同时，求出的末速度也是方向相反的，从而在转换为v1s’和v2s’时也是正确的方向。同样的，求t’既可以是用s’逆时针90度得到也可以是顺时针 90度得到。
三、编写代码
按照惯例，该编写代码了，其实编写的代码和上面的推导过程极为相似。但为了完整，我还是打算写出来(在舞台上画了两个小球MC，分别是mc1,mc2)。

import Vector;
var xx:Number=275;
var yy:Number=200;
//两球的速度
var v1:Vector=new Vector(3,3);
var v2:Vector=new Vector(0,-3);
//两球的位置,随便定的，关键是两球要能碰上
var mc1Pos:Vector=new Vector(165,110);
var mc2Pos:Vector=new Vector(260,310);
//两球的质量
var mass1:Number=1;
var mass2:Number=1;

var rr:Number=(mc1.width+mc2.width)/2;
//记录两小球之间连线向量
var s:Vector;
//小球碰撞时的公切线及垂线为辅助坐标系
var s1:Vector=new Vector(0,0);
var t1:Vector=new Vector(0,0);
//设置小球位置
render(mc1,mc1Pos);
render(mc2,mc2Pos);
stage.addEventListener(Event.ENTER_FRAME,enterHandler);
function enterHandler(e:Event):void {
        s=mc1Pos.minusNew(mc2Pos);
        mc1Pos.plus(v1);
        mc2Pos.plus(v2);
        render(mc1,mc1Pos);
        render(mc2,mc2Pos);
        s1=mc1Pos.minusNew(mc2Pos);
        if (s1.getLength()<rr) {
                var k:Number=(rr-s1.getLength())/(s.getLength()-s1.getLength())
                mc1Pos.minus(v1.scaleNew(k));
                mc2Pos.minus(v2.scaleNew(k));
                render(mc1,mc1Pos);
                render(mc2,mc2Pos);
                s1.setLength(1);
                t1=s1.rotateNew(Math.PI/2);
                var v1s:Number=v1.dot(s1);
                var v1t:Number=v1.dot(t1);
                var v2s:Number=v2.dot(s1);
                var v2t:Number=v2.dot(t1);
                var vs:Object=getSpeed(mass1,mass2,v1s,v2s);
                var v1s1:Vector=s1.scaleNew(vs.v1);
                var v2s1:Vector=s1.scaleNew(vs.v2);
                var v1t1:Vector=t1.scaleNew(v1t);
                var v2t1:Vector=t1.scaleNew(v2t);
                v1=v1s1.plusNew(v1t1);
                v2=v2s1.plusNew(v2t1);
        }
}

//利用两物的质量和速度根据动量和能量守恒计算出碰撞后的两物速度
function getSpeed(m1:Number,m2:Number,v1:Number,v2:Number):* {
        var v1New:Number = (2*m2*v2+v1*(m1-m2))/(m1 + m2);
        var v2New:Number = (2*m1*v1+v2*(m2-m1))/(m1 + m2);
        return {v1:v1New,v2:v2New};
}

//刷新位置
function render(a:Sprite,b:Vector) {
        a.x=b.xV;
        a.y=b.yV;
}

呼~~是不是感觉有点乱阿？不管怎么样，我有这种感觉。但我们确实完成了它。希望你能够理解这个计算的过程，你完全可以依照这个过程自己编写更高效的代码，让它看上去更清楚：）至此位置，我们已经掌握了编写一个台球游戏的基本知识了，Let’s make it!
事实上，一切才刚刚起步，我们还有很多没有解决的问题，比如旋转问题，击球的角度问题等等，你还会深入的研究一下，对吗？一旦你有了目标，坚持下去，保持激情，总会有成功的一天：）这次就到这里，下次我们接着研究，Bye for now~~
源文件：
两小球碰撞的研究.rar (6.95 KB)

• 2010年04月27日 -- 出炉一个联动广告【nike土豆大看板广告】 (2)
• 2010年07月9日 -- 健康的老人家，健康的运动【可否开发水上漂的运动游戏】 (0)
• 2010年08月18日 -- 达达：Mochi-Flash小游戏开发者的大金矿 (0)
• 2009年12月15日 -- 频繁点击检测类：ClickCheck (1)
• 2009年11月22日 -- wp-swfobject为博客嵌入flash (3)
• 2010年02月9日 -- 猫猫拳打可怜小狗！ (0)

自flash进军多媒体领域以来，它就成了许多应用的代名词。无论是制作交互示例、浏览器游戏还是酷炫的网页组件，flash都是一个不错的选择。其中，flash游戏在浏览器游戏中扮演着重要的角色，它也往往是网络用户消磨时间的首选。对于flash新手，制作flash游戏是件既麻烦又有趣的活。
下面列出了20个最佳的flash游戏教程，希望对您有所帮助。

1. 三维拼图

2. 桌球游戏

3. 三维弹射

4. 天体射手

5. Away3d游戏

6. 气球射手

7. 迷你高尔夫

8. 赛车

9. 转盘

10. 猜猜下一个

11. 滚球

12. 鸡和蛋

13. 扫雷

14. 节点

15. 诡异路线

16. 塔防

17. 投石机

18. 直升机

19. 基础防御

20. 打砖块

• 2010年08月18日 -- 小s：盛大游戏麻球网上线 Flash独立游戏开发者的曙光 (0)
• 2010年07月9日 -- 麻球开发者反馈答复（6月28日） (0)
• 2009年12月19日 -- 猫咪偷吃花生 (2)
• 2010年05月20日 -- Adobe展示流畅运行Flash的Android平板电脑【转载】 (2)
• 2010年08月18日 -- 猫粮：独立游戏开发者春天 (0)
• 2010年07月9日 -- 麻球开发者反馈答复（7月2日） (0)

如果只是常用的截图，调色，添加滤镜，去唤醒photoshop这个巨人，真的是很费时很废事。

简单说一下，上手的时候会让人困扰的几个地方。
做简单图片处理，自然离不开选择，移动选区，截图，这几个功能要稍微适应一下，其它功能跟photoshop类似（当然肯定没有ps那么多功能，那是航空母舰，这是快速小艇！）。

这里面的选择效果是这样的：

选择按钮是在这里

移动选区在这里

很多人可能一下会找不到如何截图，其实它在这里（这里面截图只能根据选区截图，跟ps不太一样）

如果你看到这个工具的安装文件有多小，你就会觉得原来它所带的的功能真的是太多了！
Paint.NET 3.5安装文件下载

• 2010年04月20日 -- Flash字体嵌入方法总结—(4)进阶篇【转载kevincao】 (0)
• 2009年12月1日 -- 摄像头拍照或视频截图类 (8)
• 2010年07月2日 -- 第四期FLASH专家交流会 7月24日 广州东方国际饭店 (0)
• 2009年11月20日 -- flash全屏后的UI控制 (2)
• 2009年11月26日 -- Array:神奇的数组 (0)
• 2009年12月6日 -- 百威啤酒-击打鼓点游戏 (0)

对于那些需要上传到网上，或者需要跟页面进行交互的项目，我们曾经为了调试flash程序而在代码中临时添加一个textField来输出trace内容，有时候为了一个简单的功能，而不得不在eclipse中部署一个复杂的开发调试环境。
现在有了这个小插件，如果我们的目的只是需要查看trace内容，它将使我们的调试工作变得很方便，很快捷。

如何安装：
如果你的浏览器是3.5或以上的版本（相信都是了），需要到这个页面来安装FlashTracer的最新版。
安装FlashTracer

重新启动firefox，

打开这个插件，打开菜单的工具项可以找到Flash Tracer点击即可。

配置选项，如图点选项图标，打开FlashTracer的选项

“浏览”到flashlog.txt文件

这个文件在不同的系统中的路径(windows7同vista)：

如果你找不到Logs/flashlog.txt，请在Flash Plaer目录下手动创建Logs文件夹跟flashlog.txt文件。

设置trace内容的字符编码，选择UTF-8

这就大功告成了，重起一下firefox，在浏览器中打开你的flash文件，或嵌入flash的页面，就可以看到FlashTracer输出了你trace的内容。

• 2010年08月18日 -- 黑羽：Flash小游戏开发者的新平台 (1)
• 2009年12月19日 -- 猫咪偷吃花生 (2)
• 2010年03月22日 -- 定制右键菜单与ContextMenuPlus类 (0)
• 2010年02月7日 -- 制作滚屏与翻页时分页加载的方法 (0)
• 2010年05月20日 -- 李开复和创新工场【转载】 (0)
• 2010年07月9日 -- 麻球网【MochiMedia】世界最大的在线游戏网络 (0)

使用wp-al-swfobject可以很方便的在wordpress博客中嵌入flash文件,它是基于swfobject的，所以在后台可以自由设置swfobject的版本。

原文出处

安装使用：

1. 把下载的压缩包解压到本地，然后把”wp-al-swfobject”这个文件夹上传到服务器上，位置是你的wordpress目录下的：wp-content/plugins。
2. 插件上传后，可以在wordpress管理后台的插件（plug-in）中找到wp-al-swfobject，启用它就可以了。
3. 按照如下代码的格式在你想插入flash的地方（限博客文章的内容模块），书写代码：

[embedSWF]swf, width, height, align, version, expressInstall, flashvars, params, attributes[ /embedSWF]

下面有参数的详细说明：

• swf（indispensable） ･･･ Th需要嵌入的swf文件的路径。
• width（optional） ･･･ flash文件的宽度，如果为空，将使用wp-al-swfobject控制面板中的默认值。
• height（optional） ･･･ flash文件的高度，如果为空，将使用wp-al-swfobject控制面板中的默认值。
• align（optional） ･･･ flash的位置，可以选择“left”, the “right”, “center”。
• version（optional） ･･･ flash播放器的版本。
• expressInstall（optional） ･･･ expressInstall.swf的路径，当播放器版本过低，将显示这个flash文件，如为flashplayer 9.0.0.或更高的版本。
• flashvars（optional） ･･･ 传入flashvars变量，格式为 {name1:”value1″, name2,”value2″}。
• params（optional） ･･･ 传入参数，如allowScriptAccess，wmode，allowfullscreen。
• attributes（optional） ･･･ 传入属性，如id。

如果需要在博客文章的内容模块以外的地方嵌入flash,可以通过以下的php方法:

<?php wp_al_swfobject_echo('[embedSWF]swf, width, height, align, version, expressInstall, flashvars, params, attributes[／embedSWF]'); ?>

- Example

[embedSWF]sample.swf, 400, 360, center, 9.0.0, http://hogehoge.jp/alt.swf, {aaa:"10"}, {menu:"false", allowScriptAccess:"always"}, {id:"sample", name:"sample"}[ /embedSWF]

• 2009年11月22日 -- wp-swfobject为博客嵌入flash (3)
• 2009年12月6日 -- actionscript与javascript交互 (3)