We'll see where things stand after version 1.2 is done. I'm hopeful that that will be some time over the next several weeks.

You're right, though, that's quite a bit of work, and probably for that reason alone, it won't end up in version 1.2, which is already pretty full.

I think, though, you've hit on one of the big challenges people will face using this level editor (or any general purpose level editor): getting the programmer to know what the level designer meant.

I think when version 1.2 is complete, though, there will be a variety of work-arounds that will make this particular problem easier to address. With properties, you'd be able to add in a description property to anything. So you could use that to convey any information you want, without necessarily adding an additional feature. I think something like that could go a long way. It doesn't cover everything you mentioned, but it is still something.

There is, of course, always the option of direct communication, or creating a Word document (or whatever format you like) that you put in source control, or an online Wiki platform, or something along those lines. Just doing the documentation manually, in a separate, shared area. Again, it doesn't solve all of the problems you've described, but, hey, it's available right this minute! No need to even wait for the next version!

Just thinking through the idea a bit more, you've listed things like "Boolean", but I think in actual implementation, it will be "True/False Value" or "Yes/No Value". And numeric values would not be called "Integer", they'd be called "Number" or "Numeric". I say that, just because programmers are usually can easily turn these words into their proper data types in their head (in the event that a programmer is using the level editor) while artists have no clue what "Boolean" means. It's not something artists ever talk about.

Another thing that may be useful to you is that the .realm file format is human readable. It is just an XML file with a different extension. I'm a firm believer that file formats, in most cases, should be made known, rather than kept a proprietary secret. For one, this makes it easier to debug the program. For two, this means that people can go in and write their own software that modifies the file, or extracts additional information out of it. So once properties are complete, in version 1.2, it might be simple enough for anyone (me included) to create a separate standalone application to go through and pull out any interesting information and create a documentation file from it.

Anyway, those are just a few thoughts. Like I said, I don't plan on this being in version 1.2, since it is a pretty big chunk of work, 1.2 is already pretty full of ideas, and when 1.2 is done, the features that will exist may go a very long way towards accomplishing this.

If you have any other thoughts, or if there's anyone else out there who has some feedback on this feature, let me know!

In the mean time, I've added this to my list of ideas for the future.

It would probably have to include quite a bit of information to be useful. Things like the file location and name of each level and all the tile textures, allowing you to check to make sure everything is there. It could include a description of each level and tile. But where it would become the most useful is object properties. You could say what each property indicates and how it is stored. Here's an example list:

solid: Indicates if the object is solid. Value Type: Boolean value. Default: True. ladder: Indicates if the object is a ladder. Value Type: Boolean value. Default: False damage: Indicates how much damage the object does. Value Type: Integer Default: 0 conveyerSpeed: Indicates if the object is a conveyer and how fast it is. Value Type: Integer Default: 0 Special Notes: If the value is 0, it is not a conveyer. If value is negative, it pushes to the left. If positive, it pushes to the right.

Another use would be to make checking the tile properties easier. If it outputs the properties for each tile, you could check this file to easily make sure all the properties are set correctly. Something like this:

Properties Descriptions: solid: Indicates if the tile is solid. Value Type: Boolean Default: True Tiles: Grass(ID=1, Smart Tile=true) Solid: True Dirt(ID=2, Smart Tile=true) Solid: True Rock(ID=3, Smart Tile=true) Solid: False

On the GUI side, it could be used for tool-tip display. Whatever you put in the description for that property would be displayed when you hover your mouse over it. To change the description, you could just right click any object or property listing, and the context menu could have a "Change Description" option.

it would be nice to have a few options to control what the file has. If it should include file locations and names, the name or ID of each tile, and if a property should be displayed for a tile if it's the default property. That would allow you to shorten it to only say this:

Properties Descriptions: solid: Indicates if the tile is solid. Value Type: Boolean Default: True Tiles: Grass(ID=1, Smart Tile=true) Dirt(ID=2, Smart Tile=true) Rock(ID=3, Smart Tile=true) Solid: False

I know this would probably take quite a bit of work, but that's why I suggested it early in the development process. I probably didn't make very much sense through most of this, so go ahead ask questions if you need to.