Your “level editor” does too much.
- Lightmap calculation and generation Should be done by a secondary tool.
- lua event scripting inside the level format, to try and make the format as portable and very easy to implement Should not be done at all.
- AI pathfinding painting tools Should be done by the level editor.
- simple model editing Should be done by a model editor.
- geometry instancing Should be an automatic feature of any engine—this has nothing to do with editing levels.
- model importing Should be done by the level editor.
- texture painting Could be done by the level editor.
- shader boxes. now what this is is a simply placed cube with an are etc which then prompts a user to attach a material or shader to it (glsl,hlsl) which then implements that shader to to that box. (it would be very useful for water, custom lighting etc.) Should be done by the level editor.
- overall shader support Should not be done at all.
Firstly, you have to properly divide features into the appropriate modules. A level editor has a specific role to fill, then there are tool chains with converters, etc., and then there is the final engine that loads the final level file.
Secondly, you need to understand that adding a feature does not necessarily mean adding usefulness.
You have added so many features it is actually useless.
- It is useless to anyone not using HLSL or GLSL. What about me? I am using LSSL. What about Cg users? A level editor can’t serve the needs of many engines with this kind of constraint.
- It is useless to anyone not using LUA. Why would you add this to a level editor? It doesn’t make sense.
- Editing models? That means your editor apparently has information on the model format, which is just another constraint for anyone wanting to use it. Plus, why would anyone desire such a feature in a level editor anyway? It won’t be better than just using a tool dedicated to editing models.
- Shader support period makes it totally useless. Same reason as #3 in that a level editor would never do a better job than a material editor, but also because of #1.
For an example of what a level editor
should do, see
Valve Hammer Editor. It is a generic way to sculpt buildings and terrain and the data is saved to a very generic text format. A snippet:
world
{
"id" "250"
"mapversion" "2"
"classname" "worldspawn"
"skyname" "sky_wasteland02"
"sounds" "1"
"MaxRange" "32768"
"fogcolor" "255 255 255"
"fogcolor2" "255 255 255"
"fogdir" "1 0 0"
"fogstart" "500.0"
"fogend" "2000.0"
"maxpropscreenwidth" "-1"
solid
{
"id" "260"
side
{
"id" "208"
"plane" "(-320 -560 0) (320 -560 0) (320 544 0)"
"material" "DEV/DEV_MEASUREGENERIC01B"
"uaxis" "[1 0 0 0] 0.25"
"vaxis" "[0 -1 0 0] 0.25"
"rotation" "0"
"lightmapscale" "16"
"smoothing_groups" "0"
}
side
{
"id" "207"
"plane" "(-320 544 0) (-320 544 16) (-320 -560 16)"
"material" "DEV/DEV_MEASUREGENERIC01B"
"uaxis" "[0 0 1 -64] 0.25"
"vaxis" "[0 -1 0 0] 0.25"
"rotation" "0"
"lightmapscale" "16"
"smoothing_groups" "0"
}
Now
this is actually useful. Any engine can then write converters to load this data etc., which is what I am currently doing with my engine, and will probably do again for my company’s engine (which also does not use LUA and also has a proprietary shader system).
If you want lightmaps, make a
separate tool for that.
There are very good reasons for this organization.
- It allows the editor to be useful. This means it can serve the needs of many game engines across many games. This means it has to be as flexible as possible and not have some kind of shader system or LUA scripting.
- It prevents it from getting obsolete (as fast). You can update your lightmap tool or any other individual tool chain tool when they are in need, instead of the whole package. If all the tools are rolled into one, the whole thing becomes obsolete instead of just one small feature/tool.
You are overly ambitious, and for no reason. Show some restraint so you can make something actually useful.
L. Spiro
