Jump to content
  • Advertisement
Sign in to follow this  
rogerdv

Unity in-engine tool vs external tool

This topic is 1139 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im in the process of creating an RPG, and recently discovered that I can extend unity3d editor to create "tools" inside it. Inmediatly, I thought I could make my dialog editor inside unity, but the lack of proper documentation and other considerations have cooled my entusiasm. Do you think it is a good idea? My first approach was to code my dialog tool in C++/Qt. The disadvantages are that I have to code the dialog parser again, in C++, instead of reusing the game parser. Advantages: it is engine independent. The Unity integrated tool has the disadvantage that documentation is scarce, oriented to old style gui (OnGUI based), and the advantage is that it would be integrated in the engine (if that is and advantage) and reuse the dialog parser. What do you think about this?

Share this post


Link to post
Share on other sites
Advertisement

There are many tools that work well in game.  Others are hard to get right.

 

In Unity you can do this while debugging, adjusting values in the inspector and watching how it affects the game.

 

Many tuning elements are nice to have inside the engine. Exposing values for AI can make it easier to see what characters are thinking, and adjust the values as it runs.  Exposing any developer-friendly or testing-friendly values is generally useful. Think about the cheat codes and debug codes you've seen in games over your life, those are all probably features you could consider exposing in game.

 

What does your 'dialog editor' do? Are you modifying strings? Are you modifying the story tree? Are you modifying the script controlling story flow?

 

If you're only modifying text strings, that might be fine for a small game. In big games where text gets localized into a bunch of languages and recorded by voice actors, it is best to have a naming convention and use a key, which then gets replaced with the locale-specific string and audio. 

 

If you are modifying more complex parts of dialog, like what happens if the user selects each of the options, then you'll be exposing a lot of your own internal scripting data in the tool.  It may be quite a bit of work to build such a system.

Share this post


Link to post
Share on other sites

The dialog editor is supposed to give writers the possibility to create complex, dynamic dialogs, that change according to character attributes, assigned quests, the usual (Fallout like) RPG. So, besides adding options, it must allow to set conditions, etc. A hughe tool, that I would like to write only once in my life and reuse it in the next projects.

Share this post


Link to post
Share on other sites
I tend to find that you're usually better off making an external tool and then setting your game up to hot-load assets. You don't usually want to wait for your entire game to load before making a spelling fix to a line of dialogue.

By making the tool external to the game, you're more likely to create better structured and more modular code, as things like asset loading and the renderer will probably need to be used by various tools in addition to your game and you don't want to write that code twice. Not to mention you probably don't want to write your tool in Win32/C++ either, so you'll want to be able to wrap it up in something that, say, C# can load.

Not to mention that a tool may want to load additional information that a game won't actually care about - or the tool may be able to load unprocessed assets that would slow the game down to support (like textures in a variety of formats while keeping the game loading DDS files).

For bonus points, have a button in your tools that can push the changes to a running copy of the game to hot load them and position the player wherever the camera is in the tool for quick testing. This also means you could (theoretically) push your content to another platform over the network to see your changes on a variety of platforms your game runs on, be they consoles or mobile phones.

Share this post


Link to post
Share on other sites

Not to mention you probably don't want to write your tool in Win32/C++ either, so you'll want to be able to wrap it up in something that, say, C# can load.

 

This seems to be the most common approach, but is actually the worst because you're going to have more individual code bases to maintain. I propose that you write the editor in-engine where you will likely already have the loading and parsing of your datafiles into your engine format done and will be simply be modifying that same data that you're already using. Why have the duplication of it loaded in another tool?

Share this post


Link to post
Share on other sites

[background=#fafbfc]Not to mention you probably don't want to write your tool in Win32/C++ either, so you'll want to be able to wrap it up in something that, say, C# can load.[/background]

 
This seems to be the most common approach, but is actually the worst because you're going to have more individual code bases to maintain. I propose that you write the editor in-engine where you will likely already have the loading and parsing of your datafiles into your engine format done and will be simply be modifying that same data that you're already using. Why have the duplication of it loaded in another tool?

... I pointed out exactly why in my post.

You don't duplicate the code. You make the code modular so the game and editor can use a couple of shared libraries for file loading and rendering (but NOT so shared that they are the same application). And then you get all the other bonuses by keeping the editor and game separate as listed above.

Remember - the editor needs to modify the data. The game does not. The editor can require a lot of extra memory to make edits to game data easier and faster. The game wants to use as little memory as possible using immutable data optimized for different kinds of access.

A program that plays MP3 files just needs to play the MP3 file. A program that makes mp3 files will probably want to work in a higher quality audio format than MP3, require a lot more memory to keep the audio in an uncompressed form for the best editing as well as loading multiple audio sources, and generally be much more complex.

Why load up an entire audio editing suite when all you want to do is listen to some music? Edited by SmkViper

Share this post


Link to post
Share on other sites

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

 

 

Doing it all in your engine doesn't prevent you from doing the optimised per-platform stuff.

 

It depends what your requirements but i have always found maintaining multiple tools and programs too much work.

Edited by Dave

Share this post


Link to post
Share on other sites

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

 

So put the engine in a shared library and build your editor on top of it. ;)

Share this post


Link to post
Share on other sites

 

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

 

So put the engine in a shared library and build your editor on top of it. ;)

 

 

I have no problem with this, maybe this is what he meant and i mis interpreted :).

Share this post


Link to post
Share on other sites

 

 

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

 

So put the engine in a shared library and build your editor on top of it. ;)

 

 

I have no problem with this, maybe this is what he meant and i mis interpreted smile.png.

 

 

Take a closer look. It's more or less exactly what he said:

 

You don't duplicate the code. You make the code modular so the game and editor can use a couple of shared libraries for file loading and rendering

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!