How does a real time Game Editor actually work?3d
Posted 22 August 2012 - 10:01 PM
I'm confused on how I can implemend a real time editor because I do feel it would create more productivity! Thanks in regards to this post! Everyone have a great day! Peace!
Posted 23 August 2012 - 02:50 AM
Adding this to your game while allowing user to switch to "edit mode" is basically working.
Although F.e. we've got our own set of tools (our own texture compressor, model editor/compressor (you can edit mesh materials there), shader editor (with debugging thats work-in-progress, though we extended GLSL a bit to support includes for example), and work-in-progress world editor) ... and I won't lie, they took us so much time that we don't have the game yet.
If you don't know how to speed up application, go "roarrrrrr!", hit the compiler with the club and use -O3 :D
Posted 23 August 2012 - 04:53 AM
That's a possible way to organize your code, but equally possible is to keep everything in one big executable rather than splitting it into DLLs. And many people use straight C/C++, no managed languages to build games, although many others use C# as well. (Not that this really has anything to do with the real-time editor, though.)
Perhaps for certain kinds of operations it needs to do this, such as changing the script on an object, where it must go out to the script compiler (even if it's an "interpreted" language, it probably gets compiled to bytecode). But mostly, a real-time editor should work by directly modifying data structures in memory. Compiling in the background can easily introduce some lag, which is undesirable. One thing to consider is that the scene may be in an unoptimized but still usable form in the editor, and then gets compiled into an optimized form. For example, in the editor you might just have a big list of objects to render so that you can easily move things around, but in the compiled form you would build an octree so you can do frustum culling and such. (That's not the best example because it's actually not hard to update an octree in real-time...but you get the idea. )
Posted 23 August 2012 - 06:12 PM
One thing to remember is that an editor is just a frontend to your engine. An editor should not dictate what the engine should do, but rather the engine should dictate what the editor can do. There's generally two fundamental parts to a game engine. There is the framework/s layer that consists of common logic and then there is the game specific layer that consists of configurable components for use in your game. Maths, I/O, rendering, sockets all fall under the common layer, but shooting a projectile at 1000m/s using texture XYZ facing the camera at all angles is a game layer component. The more of these components you externalized from compiled code (ie: use of scripts), the more dynamically configurable your game. If you take a look at Supreme Commander, most of their game runs off lua scripts. One community member managed to rewrite the entire AI. That should give you an idea how powerful scripting can be.
As for designing and integrating the editor with your engine, this is a rather complex topic. Take a look into MVC, MVVM, and MEF style frameworks. Specifically investigate MEF. It's primarily designed for .NET, but you can write a similar framework in C++ if you have to. The core concept is that your interface is as close as possible to an empty shell. Modules are dynamically loaded into the editor, which control the features available to the user. It's a very clean architecture for developing dynamic user interfaces that plug into your engine.
Posted 23 August 2012 - 07:03 PM
Are you talking about "hot-swapping" game world data or actual code? The latter is much more difficult. The former is simply a change to data in memory; there's no compilation. I'm confused by your post. Maybe a tangible example of what you'd like to be able to do would help?
With the right structures, you can smartly change some or any data on the fly.
For "changing" code on the fly, depends on how far you want to go and what you are using/wanting to achieve. One technique that allows less coupled code in OOP is called Inversion Of Control. You are not actually changing compiled code so much as you are dynamically choosing at runtime what to instantiate. You can suddenly add compiled code, though.
Another technique is Reflection, which in some languages allows you to alter objects at run-time. C# is pretty advanced for this; look to the ExpandoObject for a starting point.
There's monkey patching in Python and Ruby.
And, good ol'COM/ActiveX is a way to swap in new code. The old code never goes away, just "shifted".
Very few languages allow for truly swappable code while running. Most that do are functional languages. Erlang, for example, allows hot-swapping code pretty easily as the code is running.
Posted 23 August 2012 - 09:57 PM
Currently working on: the 3D engine for Tomb Raider.
Posted 20 March 2013 - 07:14 PM
I'm one of the authors of Runtime Compiled C++. Edit and Continue has a lot of limitations, and in practice I've found it rarely works in game development circumstances (see here for more info on the limitations). For example you can't make changes to optimized code, making gameplay changes tough to make since many games need optimization to run at interactive rates.
With RCC++ you can make any change, with the limitations being on the interface between code needed to support runtime swapping. An added benefit is the technique is cross platform, currently supporting Windows Visual Studio, Linux GCC, and OS X with LLVM (or GCC with a small change). Further platforms, providing they support shared library loading at runtime, can be added fairly easily though embedded or mobile platforms which don't have a compiler on the target would require extra work to host the runtime compiler on the dev platform and communicate between the process on the target and the host (via tcp/ip for example).
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users