Profit? You aren't planning on selling this, are you? That would be very stupid.
I'm pretty sure he's kidding. Right?
Right? The user needs to be able to specify level meta data, which includes the skills, level name, gold requirement (can lose X and still get gold), time limit and release rate. This can basically be taken care of with a number of text-entry fields.
How about the size of the level area? Just making sure you didn't leave something out from the list. Just double-check with the level file format to make sure you covered all available level metadata.
A few element manipulation functions need to be introduced, such as Bring to Front/Send to Back, Undo/Redo and Cut/Copy/Paste.
Don't forget "Select All"!
Here are other possible features to consider (not necessarily for version 1 though); no doubt you already have your own list though:
- option to show objects' trigger areas, that is, which tiles of the object are actually the ones that Lemmings interact with (for example, only a small part of the exit object actually causes the lemming to exit, the rest being just graphics). Showing can be done using translucent highlighting like how you're showing selections right now, except with a different color (eg. magenta).
- a level mini-map, showing a reduced-size version of the level, that you can click on to quickly jump (ie. scroll the view) to the corresponding area.
- a keyboard/mouse/menu shortcut to set the zoom and/or viewport size, so that exactly one screen's worth of level area is shown in the editor (ie. what you see is exactly how much fits onto the screen at any time when actually playing the level).
- a way for the user to tell the editor to show the animation of a specific object. For example, objects like entrance trapdoors and certain traps do not loop their animation continuously, but instead are only played once or triggered. Yet in the level editor, you may want to, for example, see how the entrance trapdoor looks with the surrounding terrain before and after it's fully opened. It would probably be annoying to loop such objects' animations continuously, so the alternative would be a way for the user to tell the editor to play the animate sequence for a specific such object on demand.
- an eraser feature to erase individual tiles, so that you can for example, place a preset onto the level, but then take out some of the tiles from it.
- possibly a selection mode that acts on individual tiles rather than presets (it's hard to tell right now what resolution your selection method acts in), or vice versa. There are cases where one may want to manipulate an individual tile, and other case where the user implicit wants to manipulate not just the one tile, but the entire preset combination that the tile belonged to. If this is already implcitly available then please ignore.
- ability to have multiple levels open at once. Equivalently, support having multiple instances of the editor running, and have the cut/copy/paste feature work across instances. It's probably acceptable to not actually show more than one level at a time (eg. maybe there are tabs and you need to click on a tab to view the corresponding level).
- possibly a UI that lets you manipulate the ordering of levels within a levelset without actually opening the levels.
- allow selection to be moved using keyboard arrow keys as well as being dragged by mouse. Though I suppose now that the level is tile-based (so you can't positioned things at arbitrary pixel locations), this may be less necessary.
- support for the user to define their own presets (ie. their own combination of tiles to treat as one unit). These user-defined presets don't necessarily have to be stored in the Style files/directories like the ones that come with the game. Defining a preset may be as simple as an option that takes the current user selection of tiles as a preset.
Actually, I think after you get to the "profit" stage as noted in your post of things-to-do, I think that would be the time to do either a public or limited release, since at that point, I think you need feedback from multiple users to properly determine what additional features are important enough to be considered adding or improving.