前端与美术的配合

《前端与美术的配合》由会员分享，可在线阅读，更多相关《前端与美术的配合（8页珍藏版）》请在金锄头文库上搜索。

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

2、 1，FLA 文件管理：把有联系的美术素材放进一个 FLA 文件中统一管理，既 能有效减少美术素材的数量，也方便程序员写程序。本来像这种美术素材管理 应该是 由美术负责的，但由于这些美术素材大部分时间可能也需要程序员写程 序，美术和程序需要共享这些素材，虽然我们可以用 SVN 进行共享和版本控制， 但程序员和 美术还是要靠约定才能非常默契的知道什么时间该到什么地方找什 么文件。而这个约定就什么我们程序员应该制定的，因为据我观察，程序员在 条理性和制定规则方 面一般比美术更靠谱。以我们公司为例，文件管理基本上 都是由我负责的，我把需要多个美术和程序员共同维护的部分以项目名命名成 一个文件夹，项目

3、下如果需要 还可以进行子分类，分类规则也是我制定。而大 部分的子模块可能只需要一个美术加一个程序员就搞定了，这时候美术就把素 材放到以自己英文名命名的文件夹下， 至于他们的文件夹内如何分类，我会给 出意见，但并不强制管理。模块程序员也会都有以自己英文名命名的文件夹， 他们会把美术的纯 FLA 素材拷贝到自己的文件 夹下，并根据模块进行子分类， 然后写代码并发布 SWF，至于 SWF 文件如何管理，我会在下一节中讨论。其实 我的管理目标非常简单，我只需要所有的美术和程 序员能在任何时候瞬间找到 我们需要的素材和源代码所在地，并且把需要的版本调出来。只要这个目标还 在可控范围内，我就会给所有员工最

4、大的自由性，把自己从 管理里解脱出来， 把更多的时间投入开发，毕竟对于创业型公司而言，快速开发，让老板和市场 看到产品才是主旋律，管理只需要在必要的时候强势出手就可以了。 事实上， 我们公司的文件管理，我每隔半年才会强势管理一次，用大概一周的时间重新 规范规则，其它时间基本处于放任自流状态，但从没出过什么大问题。最后给 大家一个数字，我们公司经过将近三年的积累，已经有几十个 G，上万个美术 素材了。 2，SWF 文件管理：SWF 文件一般是由前端程序员发布并管理的，不过也有 一些 SWF 可能不需要些代码，比如家具、个人面板背景等等，这些可以直接由 美术 管理，管理方案和 FLA 文件管理差不

5、多。最大的不同就是，SWF 文件最终 的发布路径是内网模拟测试环境，而不是本机。像我们这样的更新驱动游戏，不可能为 每一个模块都单独搭建拟真测试环境，如果这样的话，可能我们测试 环境还没搭好，就该上线并准备下一周的更新了，所以所有的模块最终的整合 测试都是直接上内 网测试环境进行。 3，FLA 内元件的管理：这个问题相信很多 AS 程序员都碰到过，也都为此 头痛过。美术给到程序员手里的 FLA 文件可能是混乱不堪，库里没有任何分类， 元件 名也都是清一色的“元件 1、元件 2，元件 3”，元件内部遮罩，组 合，层次也都没啥规律。要是美术直接给我一个 AI 或者 PS 的源文件让我们自 己导入

6、FLASH，那我们就更抽了，颜色模式的改变，路径工具的失灵，大量的 图层导致裁切困难，而且还不能进行打散合并，只能一层一层的切。这个时候， 正如我前 面提到的，一个合格的 AS 程序员应该对美术和图形软件有更多的了 解，你应当及时纠正美术不恰当的做法，甚至给出合理的解决方案，比如你应 该知道 FLASH 只支持 RGB 颜色模式，AI 不但整个文档可以指定颜色模式，每个 图层也可以单独指定，当美术给到你的 AI 导入 FLASH 有色彩差异的时候，能帮 助美术找到哪里的颜色模式不对，并建议他们以后只使用 RGB 模式。很多纯 AS 程序员可能有图形恐惧症，他们会想尽一切办法把这部分工作推向美术

7、，但最 终他 们都会很郁闷，因为他们会发现，除了能指定库文件夹的命名规则外，其 它的规则很难跟美术说明白，而且由于模块的千变万化，很难总结出一个完全 通用的规则， 想从美术哪里拿到一个完全不用修改，自己可以直接写代码的 FLA 文件，几乎天方夜谭。所以，与其让 FLA 文件在美术和程序的你来我往中 浪费时间，与其让自 己在对美术的鄙视中愤懑抱怨，不如提升一下自己的美术 常识和图形处理基本功。毕竟，元件在舞台上怎么命名，关联什么类，层次怎 么样，怎么被程序利用，这些 只有我们程序员最清楚，这部分工作由我们程序 员完成完全是合理的，也是效率最高的，美术只要把我们需要的素材交给我们， 并放到方便查找

8、的地方就可以了。放 下程序员的架子，主动走入美术的世界， 对我们程序员绝对有好处,谁知三晋第一村的村名字是什么？。 4，FP 的性能问题对美术的影响：谈到这个问题，我就想起了一个让我抽 搐已久的情况。我们老板总是喜欢语重心长的对我说：“火山，你给咱们前端 人员和美术 出一个方案吧，告诉他们怎么做可以让 FLASH 性能最高！”额，现 在请问哪位朋友可以帮火山回答这个问题。火山真的惭愧，搞 FLASH 搞了 7 年 了，始终还 是没完全弄明白 FLASH 的诸多性能问题。不管以前的 MM 还是现在 ADOBE，都将其图形处理和屏幕渲染部分视为其镇山之宝，不肯公开其技术内幕， 我也就 始终无法从理

9、论的高度给出一个本质的回答。我现在的大多数性能解决 方案，都是根据项目的实际情况，根据 7 年来的经验总结出的经验科学。而且 我始终不相信， 谁可以一个给出一个适合所有项目的、通用的性能解决方案， 可以同时让内存、CPU、带宽占用都最少，而且画面又很炫,上游棋牌无法进进 游戏，功能很强大，SWF 文件非常小，可玩 性非常高，而开发周期和成本却很 少。内存、CPU、SWF 体积、带宽、效果、成本，这几个要素往往是相互矛盾的， 你对其中任何一点的过分优化，都有可能导 致其它点走向反面。我深信，在目 前这个时期，一个性能方面的高手，绝对不是看他能不能给出一个全面优化的 方案，而是看他在面对不同的项目

10、，不同的情况时， 如何做出选择和取舍。是 的，“选择和取舍”永远都是人生最艰难的话题：手心手背都是肉，削掉哪边 呢？老婆孩子都掉海里了，救谁呢？在这样的情况下，我觉得 一个负责的前端人员，反而不应该仅仅简单的扔给美术一份死的文档，告诉他们应该怎么做， 让他们一直这么做就可以了。前端人员应该在每次面对一个实际情况 时，都不 厌其烦的跟美术讲清缘由，我们应该尽量授人以“渔”，而不授人以“鱼”， 让他们明白选择的道理，而不是简单的告诉他们选择什么。相信只要是虚心学 习的美术，经过一年半载的讲解他们就能替你做出判断了，这时候你再让他们 去跟后来的美术讲，你就解脱了。很可惜，大部分不懂技术的老板可能觉得

11、你 是在故弄 玄虚，非要你给出一份文档。无所谓了，你跟不懂技术的人争论不是 自讨没趣么？老板更多时候是从管理的角度出发的，我们应该配合。我们也不 是没什么可写，比 如尽量减少元件数量啊，减小 SWF 体积啊，减少持续性动画 啊，多做触发性动画啊，少用遮罩和滤镜啊，不要嵌入中文字体啊，提高元件 重用性啊等等等等！这些 建议听上去完全正确，忽悠不懂技术的人正合适。但 其实在高端的开发中，这些理论都是废话，帮不上多大忙，因为地球人都知道 了，我们碰到的问题肯定是超越这 些技术点的高端问题！ 综上可以看出，其实前端和美术的配合过程大部分时间是由前端主导的， 这也是我前面一再强调前端要多懂一些美术知识的

12、重要原因。当你可以和美术 一起谈论美术 理论，在美术的电脑上直接操作给他们看，当你从美术的角度给 他们提出解决方案的时候，你往往会更容易被美术所接受。担负起主导前端与 美术合作的责任，用你 的智慧征服他们，用你的诚意打动他们，让美术与前端 完美结合，让你的产品第一时间抓住用户！ 前端与后端的配合 FLASH 与后端通讯的手段多种多样，网上相关教程太多了，这里不再例 举。但很多时候，创业团队由于受制于各种现实条件，可选择的方案并不多。 像我们公 司，刚开始基本上只能选择 FMS+PHP+MYSQL。其实，对于我们前端来 说，后端选择什么解决方案对我们的影响并不大，我们无非就是用的 API 不一

13、样 而已。多看看教程，用很少的时间我们就能掌握其要领。那么前后端合作的 难点是什么呢？我觉得关键是逻辑的划分。 “前后端合理划分逻辑”，这句话咋看上去貌似简单，其实里面蕴含着 诸多方面的考虑。比如安全性、后端性能、工作量、人事分工等等。安全性： 记得我们的游 戏同时在线超过 3000 的时候，就已经有人开始攻击我们的后端 了，篡改了很多人的个人资料。幸亏攻击的人只是我们一个善意的玩家，如果 是恶意的商业攻击， 后果不堪设想。经过这次后，老板开始缠着我们追问“怎 么防止别人攻击，提高安全性”。这个问题又一次把我们难住了，我们都知道， 基于 HTTP 的请求不被截 取是不可能的，而 SWF 文件又

14、不存在绝对的安全。就 算你防得了恶意进攻，你也防不了良性的外挂，想从技术层面让别人完全攻击 不了我们也是不可能的。那我们 是不是只能坐以待毙了？不是！如果前、后端 在合作的时候，数据逻辑与合法性检查都是做在后端的，就可以很好的避免一 些良性外挂。首先是游戏数据逻辑要尽量 全做在后端，比如用户在玩小游戏的 时候，我们不要只是在用户结束小游戏后，简单的把数据传回后端,2009 年 11 月 29 日广东省体彩杯体育舞蹈公然赛暨深圳市第 2 届体育舞蹈锦标赛成绩，后 端记录进数据库完事，一旦攻击者发现了你这个传数据的 后台接口，完全可以避开 SWF，做外挂直接呼叫你这个接口刷分，就算你验证用户也没用

15、，因为他 可以先注册一个合法的用户，然后在外挂中登录再刷分。当然， 你还可以对游 戏分数先加密在传给后端，提高攻击难度，但这也是不保险的，因为加密算法 就在你的 SWF 文件中，别人可以很容易获得。所以正确的做法应该是： 游戏开 始的时候只告知后端游戏 ID后端标识 ID 对应的游戏已经开始并记录开始时 间用户每次获得一个分数时，前端传回来的不是分数,浙江会计电算化天健软 件下载地址，而是一个动作 ID, 后端根据动作 ID 给用户加分游戏结束时， 前端告知后端游戏已经结束后端得知游戏结束，记录结束时间，计算时间差， 根据时间差和最后得分是否符合标准做 出相应处理，如果符合标准就把最后得 分入

16、库，并返回前端显示给用户，如果不符合标准，就启动作弊处理系统。而 这个标准一般是由数值策划给出的。经过我这么 一分析，你可能头痛了，本来 一个很简单的小游戏计分，怎么搞得这么复杂？前后端工作量都增加了不说， 对后端性能也提出了更高的要求，服务器可能要增加了， 后端人手可能要增加 了，开发周期也要延长了，值得么？这个问题问的很好，这正是我下面要说的： 后端性能、工作量、人事分工：一旦我们每一步进行安全性与合 法性验证后， 整个项目的工作量都会大大膨胀，开发周期也会大大延长；一旦我们把数据处 理、业务逻辑和安全验证都移到后端时，后端的压力就会增加，服务器要 增多， 对后端人员的能力要求也会提高。很多初创团队在项目初期人力财力，软件硬 件都不足，可能顾不上那么多，一心想着早点让项目上线。在这种情况下，我 觉 得安全性可以暂时放一下，众所周知的安全漏洞补上就可以了。但“数据处 理和业务逻辑”这个，宁可开发的慢一点，宁可再招个后端高手，宁可多几台 服务器成 本，也要把它们尽量都放在后端。因为这个没分清的话，会影响到整 个系统的清晰度，严重影响项目中后期的发展，为日后的