When I've started UT engine & editor about 1.5 years ago, I needed to decide about attaching editor to engine. I've decided to create editor in C# connected to game engine (which does all rendering in editor's subwindow) via sockets (see this [PL]). Now I know it's probably not the best choice.
Let's call it option 1. Benefits: WYSIWYP, no editing/GUI in main engine. But another problem arises. We need several "edit/debug" features anyway, like displaying objects selection, moving objects with mouse, click-to-select, visualise lights/markers/scripts. Game engine doesn't need to, for example, save models but still there is a lot of code unnecessary for normal gameplay and a lot of optimizations missed (for example you can't assume that static objects will remain static as level designer can move them).
There are of course other options. We could code editor as completly standalone application with its own renderer. It lets engine rendering code be super-well optimized but lacks very important feature: WYSIWYP. I believe it's no use as of 2010.
And, of course, you can code everything inside your engine (including level editor and other stuff). Well, I was somehow scared to do it as my C++ was way worse 2 years ago -- now I don't see this option as total madness :)
What would I do if I've started coding this toolset now? I would go 1+2. I would code editor with its own, quite simple renderer and connect with main engine via sockets only for "Preview" tab/window (or just let engine window run on other display). This option is also possible if you have engine running on PS3/X2Π and editor toolset on PC. Still some optimizations are gone (like non-static static objects) but many other are saved.
It's a little too late for me to start coding editor from scratch (maybe in version 2.0) but I have a little different solution: I have separate Object Editor (able to import models/skeletons/animations/physics and do some basic editing and setting up) which -- to be honest-but-not-so-modest -- is itself probably more advanced than many amateur engines. ;)
Comments:
-
Haha I love the last sentence ;) however regarding subject I prefer toolset which uses completely what engine provides i.e. WYSIWYG. Using same renderer has this benefit that everything looks very similar as it will in the final game.
24.05.2010 23:51:51
-
Yeah, like I've written: editors without WYSIWYP should had died 5-6 years ago ;)
25.05.2010 00:12:15
-
Yeah - 'should' is a good word here ;)
25.05.2010 00:19:42
-
mg:
This seems relevant :)
http://c0de517e.blogspot.com/2010/05/poll-results.html
25.05.2010 18:16:08
-
Yes, in a way. But I wonder about those ninjas: "9%: Code hot-swapping." :) I myself use DLL-per-module approach but hot-swapping them was virtually impossible. About this, agreed, C+ is pain. ;)
26.05.2010 01:29:21
-
mg:
What troubles did you encounter in hot-swapping DLLs?
26.05.2010 15:58:45
-
Well, several problems arise:
1. if you use VS DLL projects, it generates LIBs that automatically load DLLs with no direct GetProcAddress stuff. AFAIR there is no mechanism that could create hotswapping code automatically so this is a lot of "fun" to do
2. objects can change size, add or rearrange its members; vptr tables can change; etc
3. if you have bug in initialize/load functions, being able to change render/update function won't help you much
And for simple cases there is always Edit26.05.2010 20:17:18
-
Edit and continue *
26.05.2010 20:17:30
-
Reg:
The solutions I've seen and I've worked with were usually like this: game framework, engine and renderer as a LIB or DLL library (native C+ ), used either by simple game "viewer" (for final game) or by editor (coded in C , C /CLI or C#). That's also the way I'm going to do it at home now. My editor is being coded in C with wxWidgets.
I know it's hard decision but for me the most important criterium is the work overhead for implementing communication between engine and editor. From this point of view, passing messages by sockets is the worst possible solution, followed by exchanging data between native and managed code and coding editor in native C just like the game is the best :)30.05.2010 19:52:31
-
Well, this is quite a constant overhead. I have a tool which creates both Cpp and C# headers/classes along with serialization/deserialization routines from a simple classes definition format (classes like Material/Light/Marker/Entity/etc). And these change rarely. But this is just one of many problems with this approach ;)
30.05.2010 23:16:28
