特性：
共享资源库，
地形，元件，地图的层次结构
所有文件都可增删保存再编辑；
自动深度排序；
地图实况测试；
元件旋转
场景旋转
元件可旋转视角后添加到场景。
地图编辑过程中可以增删区域。
笔触清楚，网格显示，物品分栏显示；
导入背景
小地图预览
功能特征
采用分层处理
将地图要素拆分为：地形，元件，地图3大模块
模块间各自独立编辑，保存，重编辑。完成后于地图模块继承
地形：作为地图的区域模块。其特征主要在于预先指定好地图的编辑范围。
适用于预先根据背景资源进行量身绘制编辑地图区域。
元件：作为地图的物品模块。可根据于场景中的特性，细分为：阻碍型，挂件型，地表型。三种形式。
每类元件文件都有自身属性。如，于45度坐标中的（高，宽，长）及交互，是否为墙壁等。
阻碍类型元件：完成编辑后不能于其占用区域内行走或摆放物品。
挂件类型元件：其占有区域下依然可以防止元件，且其深度冗员高于阻碍元件。
地形类型元件：作为地表层的组成元件，其深度在阻碍及挂件元件之下，一般作为背景形式错在。
资源库管理：点击菜单--》设置 面板（或者点击seting按钮），就可以增加删除swf资源库，资源库读取后将会自动将所有带链接名的元件显示在tags 列表下。本编辑器的资源库是公用的，也就是说，只要你编辑完一个元件，你可以在任一地图上使用这个元件。但要注意的是资源库更新时，以往编辑的元件图像也会跟着更新，但数据于地图中是不变的，这样做是为了避免因为后边更新了一个元件的数据，导致之前编辑地图走样，数据错乱等。这部分特征只会体现在地图文件上，因为四度文件是直接将所有数据拷贝一份写入文件中去的，而元件，则因为可以冲新编辑故不会有这方面的问题，只要在更新完资源库后重新修改原有的元件文件即可。再者要注意的是每个资源库的文件名必须唯一。如果是团队开发的，可以将共享的资源库放到网上邻居，然后全部选择哪个资源从而达到资源同步的目的，也可以通过svn等方式同步资源库。
在绘制地形上，本编辑器采用的是自定义绘制模式，使用者只要根据自己需要绘制地形区域即可。这样做的好处在于最大限度的缩小数据的大小，以及保存后当作可选文件形式在创建地图时供使用者选择。
元件及场景都具有旋转编辑功能。
编辑元件时请先从tags lists列表中双击或者拖入你要选择的素材。
然后根据自己需要于下边的属性栏中设定其属性。哟啊注意的是，当我们创建一个元件后，我们需要先设定区域，该区域是45度下物品与地面接触的3维接触区域。不要图片有多大就绘制多大，那是错误的。然后按空格键为其4个视角下都调整坐标偏移值按空跟键后系统会自动将原先绘制好的区域旋转一个视角的。然后我们需要为个元件设定他们的 3维高度。最后要注意的一点是，必须要回到第一视角下保存该文件，不然后边应用时会出错。
当我们预先编辑完一批地形跟元件后我们就可以创建属地图模块了。
在创建地图模块的对话框中我们可以看到。地形的选择项，用户如果没有选取原先编辑的地形系统会自动默认创建一个菱形区域，当然你可以选择以前编辑好的地形或者，修改45度视角下的行，列。不要担心生成后就没办法再编辑。在地图模式下把工具栏里的lock勾选项去点就可以通过绘制清楚选项来编辑了，但要注意的是编辑后记得要把lock沟回去，从而避免不必要的问题。
当我们创建完地图后，就可以从items列表里选择一个元件拖进场景。（注意双击操作是进行该元件的编辑，会切换到该元件的的编辑状态，在没保存地图文件的情况下，是不可以还原地图文件的）当我们选定了一个元件后可以在上边的预览框里反转元件的视角。然后再拖进场景，那样得到的就是你所看到的效果了。非常简单轻松就可以创建出你想要的效果。当然你也可以不旋转元件的视角而直接通过按’a‘键来旋转场景的视角，同样可以达到那样的效果的。
编辑工具栏里提供了多个小功能按钮，勾选其可以方便工作。在已经感觉效率比较慢时，如果用户之前是通过北京绘制地形插入地图数据的话，用户可以把网格栏去掉，而直接导入背景图，，当用户编辑元件时可以把colorGround的勾选去掉，或者把playground勾选去掉。那样就看不到场景上的阻碍及挂件物品了，背景物品的可是状态可以通过勾选background按钮来实现
所有模块都可以通过快捷键‘S’或者菜单栏--》文件--》保存 指令来保持文件方便以后重编辑文件。
菜单栏里还提供了测试指令，使用者可以点击该指令选择一副已经编辑好的地图文件，进行移动，观看等效果。
测试指令已经包含本系统专属的a×算法。及深度排序效果，所以观看到的效果将是应用到场景的实际效果。
菜单栏有创建指令，用户也可以通过资源库下边的+号按钮创建当前打开的不同类型文件。 通过减号用户可以删除选中的该文件。用户也可以打开seting按钮，对资源库进行增删，拷贝数据保存地址，用户可以直接预览所以数据文件。
用户可以在windows下拷贝文件，重命名等，等再次打开编辑器后拷贝的数据，或重命名的，或删除的 数据将 自动更新列表。重而达到数据备份，同步等功能。
好下边偶说说45度编辑器的一些心得：
1.为什么要开发一个编辑器？
很多开发者都没有先考虑为什么我要开发一个地图编辑器，往往都是因为大家都有，所以就去开发。很多游戏都有自己的专属编辑器，就像魔兽的那个让人仰望的编辑器，里边包含了诸如地图编辑器，事件编辑器，战役编辑器，AI编辑器，环境编辑器等等诸多编辑器，可以说，一个好的编辑器是一个成功的游戏必不可少的组成。我们开发一个编辑器是为了方便我们往后的开发工作，而不是只为了别人都有而开发。当你明确了你的游戏需求后，然后需要针对性的构架你的编辑工具。
编辑器的功能要根据我们要开发的游戏的需求来决定其功能。还有的就是我们要注意在编写这样的一个工具时要把算法及相关逻辑整理分层好。因为编辑器毕竟是编辑器，我们到了实际游戏场景中还是得再次把原先的逻辑重新实现的，所以编辑器的结构及代码的分离效果很大层度上影响到你往后的开发。
2.一些主要用到的算法。
先说说45度视角下比较难写好的深度消隐算法。相信很多开发者都疼为此头疼，不知道如何入手，。网上有很多类似的深度算法，但很多效果都不如人意，特别是用y轴判断的那种，事实上这种算法不准确是因为他忽略了一些物品不等长的情况，当然如果你的游戏里的场景物品都是等大的战棋类游戏，这种算法足以你使用了，但事实上一般的45度游戏或者社区都是很多不等大物品组成的。一些案例，想this6，他们所采取的方法是预先在fla里手动排序好物品的深度，然后再场景中通过交换深度的方法来实现井深的效果，这种方法不不好之处在于，一些动态场景因为没有预先编辑好一个准确的深度，那样交换深度的小过将是很差的，从this6前期的自定义用户场景我们也可以看出这方面的效果，这也是他们现在采用缩小场景避免排序不准确带来的不好体验的一个必然选择。还有就像摩尔，摩尔前期也是典型的只根据y轴排序的一个案例，效果相当不好，但后期做了优化。
要井深准确，无法就两个方向走。要们将所有物品统一大小，然后用y轴排序，要么就是写出一套使用性广泛的深度算法。
这里我推荐的方法也是现在很多大型2.5d游戏使用的方法。2分法。2分在在于其能准确的将一个空间的物品的井深层次很好的划分出来，我们只要通过一个物品为参照物先划分出前后两个空间然后递归刚才的方法即可，下边是本人之前写的消隐算法就是以2分法为基础写的一套45度视角下的消隐算法，
我们在说说A星算法，其实作为游戏a星算法是不一定要用到的，我们要根据游戏的实际需求来开发我们的游戏才是明智之举很多情况下我们可以选择性的将寻路部分放到小地图上而不是大地图上，那样有利于我们整个游戏的效率及执行，我们可以采用两点间直线移动，移动到不可走地方就停止移动的方法来取代a星。这样做效果也是不错的。而且效率也高。可以把节省下来的消耗应用到别的地方去。再说回a星，as3效率的提高，现在写a星算法只要不是很冗余效率基本上都到 60-90毫秒左右就可以完成了a星算法无非就是计算最优值寻找出一条能通道目的地的树状结构，然后通过倒退法，得到一条最优的路径。优化的方法很多想我之前说的2分法就是一种，我们也可以用4叉树，2查树等方法优化效率，无论是4叉树还是2叉树，目的都是在缩小路径的范围，当然前提我们都需要预先建树，注意的是，我们在场景深度算法放也可以用到4叉树，2查树这是我的改良版a星算法：
，这个算法没有哟娜跟传统的2维数组作为存储容器，而用哈希表，这样做的好处在于查询跟修改的速度要比2维数组的快而且方便。
最后说说资源管理跟事件管理。只所以要这个主要是因为flash的内存管理问题，太分散的管理方式无疑对我们管理内存几会有相当大的麻烦统一的内存管理有利于解决因为资源加载带来的诸多麻烦，还有就是事件的统一注册管理有人可能认为这样做很麻烦没必要，但我想说的是，在flash中往往因为我们很容易忽略的问题导致了我们的内存不能回收，当中最为显著的就是对象的时间引用上。很多人抱怨as的弱引用，事实上只要你看过帮助文档就不不能看出其实弱引用是没问题的，因为你的对象没有注销，所以事件必然还在引用状态。加载的资源应为都是一次性的所以基本都是很容易删除的。但一些类的实例因为引用的多指向导致了内存不能回收，这正是我说统一管理事件注册的用意，因为那样我们才可以更好的完全删除之前所注册的所有事件的。一般我们御载一个场景我建议都注销下原先的所有幀听，那样才能保证事件不在被引用，从而保证内存可以顺利回收。
文章来源： http://edu.gamfe.com/tutor/d/10660.html
有个人的博客： http://www.663000.net/