I have been working on allowing the user to place sprites in the map editor, and things have been working out great. This interface is a world better than the GameDev 1.x interface when it comes to adding sprites to a map. No flipping back and forth between a full screen display, path editing and sprite editing. Now you have all your sprites in the toolbox just like tiles, and you can select one, set it's properties right there on the side of the map editor and then add it to the map. You can switch to sprite selection mode and when you click a sprite it's properties will show up in the same grid where a new sprites properties are edited. The properties include all the intrinsic properties and the user-defined properties, which can all be edited on the fly. I haven't implemented coordinate paths yet or "sprite plan". The foundation is there, but there's no way to create an actual plan or a path or link it to a sprite yet. The nice thing is that you won't have to have a path just to have a sprite any more. I'm not entirely sure how sprite plans and coordinate paths will be related to each other and to sprites yet. I suspect a plan will be a set of rules that can operate on either a single sprite or on all sprites in a category. It will be used for things like making a sprite follow a coordinate path (a rule within the plan will reference both the sprite and the path to do this) and causing a sprite to teleport (for example the plan would contain a rule "if a sprite in the player category enters the area determined by the first two coordinates in path X, then teleport to the third coordinate in path X.") I will have to make this simple for the user so they can easily (without a lot of extra thinking and steps) create a teleporter/door by just indicating the transport area and the destination and which category of sprites are affected. Internally it will be stored in more general structures though (the aforementioned coordinate paths and plan rules). In a sense, it will be like the graphics editor where you have various tools to achieve certain effects, but then you can get down to the detail level (graphics editor has pixels, plan editor has points and rules) and touch things up.
I still have a but more work to do on manipulating sprite instances in the map editor, and then I will probably move on either to this coordinate path / sprite plan work, or back to the code generator to see how sprites come out in the runtime code. I have modified the display class and the layer class a bit in the process of implementing sprites. For one thing, there is now a "priority" property on both the sprite instance and the layer -- when the priority of the sprite is the same as the priority of the layer, the sprite draws between the rows of tiles like you'd want to see for an isometric-style map. If it is greater, then it draws in front of the layer, and the order of the sprites' drawings are determined purely by priority. So now it's really easy to determine which sprites draw on top of which other sprites. I hope nobody minds that it's a static setting and can't be changed at runtime, but I think that will help optimize performance. And if you really want a sprite to move to a different priority, there's the option of creating an identical sprite with a different priority, deactiviting the old sprite and activating the new sprite to make it look like it changed priority. If changeable priority is a big issue, though, I could consider the possibility of allowing priority to be swapped with another sprite's -- it's probably not a big deal to implement. As I was saying, I modified the classes a bit and need to incorporate similar changes into the runtime copies of some of this code.