The Dawn of the level editor
Posted: Wed May 14, 2008 4:50 pm
The original design for the RF2 level editor very closely resembled RFEditPro. It would have CSG operations and would be primarily generated geometry with meshes for decorations. It would be a native-ish Windows application (wxWidgets or Qt) which embedded the engine inside the 3D view and possibly the 2D views. Scenes would use a combination of lightmapping and dynamic lighting.
No work really ever got done on the level editor; it simply wasn't needed yet. I started on an editor in Qt with Ogre and a custom widget to embed it, but due to licensing concerns we found ourselves in a bit of a bind. Paradox and I then had two choices: switch back to wxWidgets for the tools, or do them entirely ingame.
It's now more or less a foregone conclusion that RF2's editor will be more a scene editor than a level editor, at least at first. CSG and lightmapping are too time-consuming to implement unless we know we absolutely need them, and often times modern games do not need either.
It was Paradox's idea to create an ingame level editor. It certainly isn't a new idea, but I was completely against it. I had been wishing for an UnrealEd-style application for RF2, with everything integrated into a nice, native application.
I couldn't really quantify what made me so hesitant, though. I decided to give it a try. The editor would be written in such a way that it could be compiled out with a simple compile flag for a version of RF2 used for a released game.
An ingame editor requires an ingame GUI, and as such we need an Ogre GUI library. I have tried many of them, and fail to find one that is satisfactory. One main problem is that none are geared towards tools; all are geared towards games, and as such lack support for the things tools need.
CEGUI is fast, but lacking. It has no toolbar, and it is even difficult to get buttons to display images on them for a fake toolbar. The skins are extremely difficult to make and manage, and doing things like displaying a game material on a control (for a material browser, for instance) are nearly impossible. Programming for it is a rather bland task, but it's easier than some things.
QuickGUI is nice, because it uses Ogre overlays to render everything and can easily tie in with the Ogre features we need it to tie into. QuickGUI is also not nice for the very same reason. Ogre overlays are fine for simple things like game HUDs but are extremely slow for complex GUIs. Even their sample program runs quite slowly on a very modern machine with only about 20 widgets visible. On Linux, mouse clicks and hovers don't work quite properly, and it would be worth fixing that and using it if it weren't for the speed issue.
Navi is not bad, but lacks flexibility in some areas and would constrain us only to Windows, which we have been very careful to avoid. Right now RF2 runs unmodified on Windows and Linux, and I imagine it would run with about an hour's tweaking on OS X as well. I would prefer to keep it that way.
MyGUI is unstable, to put it simply. I cannot elaborate too much on this since I did not try it, but Paradox implemented it in RF2 a while back and took it back out rather quickly due to all the issues it had.
None of the above options are very ideal for a complex application such as a level editor. Incidentally, some code was just released for Ogre today which solves these issues - it is fast, looks good, and... is completely and utterly barebones. http://www.ogre3d.org/phpBB2/viewtopic.php?t=41365 If we chose to use it, it would solve the above problems but add development time to create a GUI library around it.
Even if the perfect GUI library existed which did all these things correctly, we would still lack things like color pickers, file dialogs, and so on which would eat up a very large amount of development time. It could take months to get everything working perfectly under those conditions.
So we come to a fork in the road. On the left is wxWidgets, embedding Ogre into a wxWidgets editor and using the platform's native controls to create an editor much more quickly than the above option. On the right is a great deal of extra work finally resulting in a very dynamic editor which is simply a button press away while playing your game.
There is, however, a third road; one which I had not thought of. Instead of bringing the editor to RF2, we could bring RF2 to the editor.
If we embedded RF2 into the editor, we might achieve the best of both worlds. We would be able to take advantage of the controls already in the OS as well as the ingame aspects it would bring. We could do this by splitting the meat of RF2 into a DLL and calling that DLL from both the shell and the editor, or by having the editor be inside RF2, by creating a window and then feeding it to wxWidgets instead of vice-versa.
I have done some prototypes, but no work on what will likely be the final editor has been done. I know how it has to work, I know how the level format has to look, but as always the design decisions are what are worth tripping over.
I'm simply not sure where to go at this point. All roads lead to a usable editor, but which is the right one?
No work really ever got done on the level editor; it simply wasn't needed yet. I started on an editor in Qt with Ogre and a custom widget to embed it, but due to licensing concerns we found ourselves in a bit of a bind. Paradox and I then had two choices: switch back to wxWidgets for the tools, or do them entirely ingame.
It's now more or less a foregone conclusion that RF2's editor will be more a scene editor than a level editor, at least at first. CSG and lightmapping are too time-consuming to implement unless we know we absolutely need them, and often times modern games do not need either.
It was Paradox's idea to create an ingame level editor. It certainly isn't a new idea, but I was completely against it. I had been wishing for an UnrealEd-style application for RF2, with everything integrated into a nice, native application.
I couldn't really quantify what made me so hesitant, though. I decided to give it a try. The editor would be written in such a way that it could be compiled out with a simple compile flag for a version of RF2 used for a released game.
An ingame editor requires an ingame GUI, and as such we need an Ogre GUI library. I have tried many of them, and fail to find one that is satisfactory. One main problem is that none are geared towards tools; all are geared towards games, and as such lack support for the things tools need.
CEGUI is fast, but lacking. It has no toolbar, and it is even difficult to get buttons to display images on them for a fake toolbar. The skins are extremely difficult to make and manage, and doing things like displaying a game material on a control (for a material browser, for instance) are nearly impossible. Programming for it is a rather bland task, but it's easier than some things.
QuickGUI is nice, because it uses Ogre overlays to render everything and can easily tie in with the Ogre features we need it to tie into. QuickGUI is also not nice for the very same reason. Ogre overlays are fine for simple things like game HUDs but are extremely slow for complex GUIs. Even their sample program runs quite slowly on a very modern machine with only about 20 widgets visible. On Linux, mouse clicks and hovers don't work quite properly, and it would be worth fixing that and using it if it weren't for the speed issue.
Navi is not bad, but lacks flexibility in some areas and would constrain us only to Windows, which we have been very careful to avoid. Right now RF2 runs unmodified on Windows and Linux, and I imagine it would run with about an hour's tweaking on OS X as well. I would prefer to keep it that way.
MyGUI is unstable, to put it simply. I cannot elaborate too much on this since I did not try it, but Paradox implemented it in RF2 a while back and took it back out rather quickly due to all the issues it had.
None of the above options are very ideal for a complex application such as a level editor. Incidentally, some code was just released for Ogre today which solves these issues - it is fast, looks good, and... is completely and utterly barebones. http://www.ogre3d.org/phpBB2/viewtopic.php?t=41365 If we chose to use it, it would solve the above problems but add development time to create a GUI library around it.
Even if the perfect GUI library existed which did all these things correctly, we would still lack things like color pickers, file dialogs, and so on which would eat up a very large amount of development time. It could take months to get everything working perfectly under those conditions.
So we come to a fork in the road. On the left is wxWidgets, embedding Ogre into a wxWidgets editor and using the platform's native controls to create an editor much more quickly than the above option. On the right is a great deal of extra work finally resulting in a very dynamic editor which is simply a button press away while playing your game.
There is, however, a third road; one which I had not thought of. Instead of bringing the editor to RF2, we could bring RF2 to the editor.
If we embedded RF2 into the editor, we might achieve the best of both worlds. We would be able to take advantage of the controls already in the OS as well as the ingame aspects it would bring. We could do this by splitting the meat of RF2 into a DLL and calling that DLL from both the shell and the editor, or by having the editor be inside RF2, by creating a window and then feeding it to wxWidgets instead of vice-versa.
I have done some prototypes, but no work on what will likely be the final editor has been done. I know how it has to work, I know how the level format has to look, but as always the design decisions are what are worth tripping over.
I'm simply not sure where to go at this point. All roads lead to a usable editor, but which is the right one?