- Separate map files in two files: data and scripting (COMPLETE)
- Support a custom number of tile layers for maps (COMPLETE)
- Allow each tile layer to be configured so that it's collision data can be chosen to be included (COMPLETE)
- Figure out a way to improve code sharing in map scripts, similar to map_sprites_stock.lua
- Change the way contexts are stored in the map data file to a better format (COMPLETE)
- Support a custom number of object layers for maps (COMPLETE)
- Consider adding a new map event type that performs an operation on multiple sprites at once
- Consider adding a sprite event type where the sprite "follows" a target until it is reached
- Remove sprites/object layer support (COMPLETE)
- Remove skill editor (COMPLETE)
- Change graphics rendering from using game's video engine to using native QT rendering (COMPLETE)
- Separate out data model and view classes for better software architecture (COMPLETE)
- Add support for map context inheritance (COMPLETE)
- Add support for naming of tile layers (COMPLETE)
- Add support for naming of map contexts (COMPLETE)
- Change editor layout to mimic VT, with the tile layer list and tileset info on right (COMPLETE)
- Change top menu to include: File, Edit, View, Select, Tools, Help (COMPLETE)
- Add support for making custom shape selection areas
- Add support for changes to selection area to apply to more than one tile layer
- Add support for changes to selection area to apply to more than one context
- Add support for cut/copy/paste from one layer to another
- Add support for cut/copy/paste from one context to another
- Add support for cut/copy/paste across multiple layers
- Re-enable undo/redo action support
- Re-enabled autotiling feature
As I mentioned here, there are a few ideas that I want to borrow from Valyria Tear that involve changes to the map code and map editor. These are large, disruptive changes so I think that now is a good time for me to do them while there's no other active developers. Here's a summary of what I'm planning to do and why, in the order that I plan to do it in. I might get started on this as early as this weekend.
1) Separate map files into two files: a map portion and a scripting portion
Currently our map files contain both the static map data (tiles, layers, etc) and the scripting portions. We'd separate these two into individual files and a map would now require both to function.
Why: There are two main reasons why we should do this. First, it is somewhat cumbersome to edit map files when writing the scripts because of the large amount of text that the editor generates at the top of the file. Second, and more importantly, this would allow us to re-use map data more efficiently. For example, if we have a forest where a set of events occurs when the player first visits it, then a different group of events when the player revisits this area, we simply switch out the script file and there's no need to reduplicate all of the map data.
How: I think what I will do is keep the map files where they currently are located (dat/maps) and put the scripting files in a new directory, perhaps dat/scripts/maps. I'd rather not enforce some file naming convention and keep both map files and script files in the same directory, as that will just be difficult to sort through once there are a large number of files. Since scripts are what drives the maps, the MapMode will load the script files. The script files will contain the name of the map file that the script should take place on, so the map file data will be loaded after this data is retrieved.
2) Support a customizable amount of tile and object layers
We currently hard-code three tile layers and three object layers to all our maps. No map is allowed to have more or fewer layers than this, although they can choose not to populate some layers with tiles or objects.
Why: There's really no technical or design reason for us to have this requirement. I don't know why I made this restriction in the first place (I guess it was just easier to think about maps in this way back then). By allowing us to have any number of tile and object layers, and to arrange them in any order, we no longer need to restrict ourselves, and this may help implement certain other features such as terrain (like bridges) that a sprite can both walk on and walk under.
How: The map file will define the tiles and tile layers, but not define the order of these layers. The script file will, during the map load process, define all object layers and the objects that exist on those layers, then arrange both tile and object layers in the order that they should be drawn. The map editor will require some changes to support this as well (already done in the VT code).
3) Map Editor Layout Changes
The map editor is greatly improved in the VT code. The layout is cleaner and it seems easier to use.
Why: Who doesn't want a better map editor? The time spent on this should quickly pay for itself if it helps reduce the time to make maps as I'm hoping it will.
How: Pretty much going to go through the VT code and pull it in a chunk at a time. I can't do a direct pull because VT doesn't make use of map contexts like we do and seems to have completely removed that feature from it's editor. Also they use a slightly different code styling that isn't consistent with our standard.
There are a lot more map features than this that I'd like to add for the release, but for now I'm only focusing on these three since they are the most disruptive of the changes. And while this work isn't necessarily a high priority, I feel like completing it now will result in fewer headaches in the long term, as all the existing map files will need some heavy editing to support these changes. If you have any comments/suggestions/protests, feel free to leave them. I'll update this thread with any important progress updates or design questions.