flash 游戏开发好后，一般都会放在很多个平台，比如国内的社交网站就很多，除非你就是做平台，否则很多你做完一个游戏不会只扔一个平台，还有国外也有许多平台。
面对这么些平台，会产生很多的差异，比如一个需要简体中文，一个需要繁体，另一个是日语或者英语。这个时候还是比较简单，弄一个语言文件就ok了，比如zh-cn.xml,en-us.xml , zh-tw.xml。
但是有的时候就不是这么简单了。
可能在A平台，你需要放出商品 sA，而在B平台则不能放该商品，这个时候你可能在sA上有一个标记：buyable=true，两个平台的属性值不同，以控制该物品是否能购买。
可能在A平台，你要做一个活动，而B平台不动，做活动肯定会有一些新的或者特有的东西放上吧。那么A平台的config应该与众不同。
这是一种很好的解决办法，不同的平台配置不同的config。
但是如果你仅仅这么做了。那么麻烦来了。
你一个平台一份config。通常这个config是非常大的。基本说有可变的：商品，资源，地图，任务，技能，怪物……。几乎尽可能的都写在配置文件里，因为配置文件就是干这个事的。
当一个如此大又如此复杂更如此重要的文件，维护，修改怎么控制呢？一个好说，5个，10个？咱们都是程序，不是小秘书，及时小秘书也有失手的时候，悲了个剧吧。
有一些更新，是所有的config都需要改变，有一些更新是部分config需要改变。有一些……，总之，真是一件麻烦是。
我们使用的xml作为配置文件。不知大家使用什么。
这个时候很容易想到继承，对，就是平时写的最多的 extend，就像 movieclipe extends sprite一样的继承。这样写一个公用的config，然后每一个平台都继承于这个平台。
如果所有平台都需要的改变，我们放在父亲config里，如果单个平台，我们单个子config。最后合并生成最终的完整config。
xml也可以继承吗？不能。
在这里，你可以做一个简单的设计，他就能继承了。
呵呵。遍历两次不久行了吗。。
写一个脚本，读取父亲的config。然后再读取目标平台的特殊config，遍历子config，如果common里头存在子config的配置，那么就替换掉父亲的属性，如果父亲不存在，那么就直接添加进去。最后这个根据父亲和目标config生成出来的就是你要的xml。
原理就是这么简单。当然期间需要涉及到每个xml的element都需要有一个id,否则上面所说的遍历就很难做到了。
如果要做的更好，你这个逻辑应该支持多层合并，比如common->zh->renren,qq,kaixin,taobao,sina.看啊，这些平台都继承于zh这个父亲，因为他们都是中国平台，比如中国有自己的特殊节日，这样你的改动就只需要在zh这个config上做处理，其他平台都继承他，也就继承得到了更新。
我用文件夹作为一个“class”|类别：
common就是所谓的parent，others下是所有的目标config，当然others这个目录是不参与这层逻辑的。
这是common下的结构。我把config应该有的一级child都分开成一个一个独立的xml。这样更方便合并和管理。（起码合并的时候少一层遍历吧）
在other下方的是按照各个平台的名字命名的文件夹。是文件夹哦。然后文件夹下放着的就是需要覆盖的父类属性的各个xml。
如果不需要覆盖任何东西，也需要建立一个空的文件夹，否则不会生成了。因为我是根据文件夹来生成的。
如果版本控制用的是svn1.7一下的需要过滤一下//.svn 文件夹。版本1.7后就不存在这种情况
至于脚本，我是用python写的。不管你用什么语言，做什么程序，python这个东西还是很好的。效率。。。
不知道大家在这方有没有更好的方式，可以一起交流交流。有什么改进或者建议欢迎指正。。