Sign in to follow this  

Unity in-engine tool vs external tool

This topic is 831 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

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.[/size][/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 [i]exactly[/i] what he said:

 

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

Share this post


Link to post
Share on other sites

This topic is 831 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628662
    • Total Posts
      2984095
  • Similar Content

    • By arash khalaqhdoust
      hey guys i hope you doing all well. last night i released my first game in google app store, i really appreciate you guys  to download it. and share your reviews about it
      the idea of game comes from mini hackgame of Bioshock.
       link of download:
      https://play.google.com/store/apps/details?id=com.RVBinary.piperist
      many thanks
    • By ForgedInteractive
      Who We Are
      We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! Currently, we're progressing very quickly with our first project and there are plenty of opportunities and work for new interested programmers. With this project, our development platform is Unity 5.5.2 and C# as our behavioral language. Since this project is our first release, the game itself is a smaller project though progress is moving quickly. We are looking to finalize the current project and get started on future projects in the near future and are expanding our team to do so.
       
      Who We Are Looking For:
      Programmer Level Designer  
      About the Game
      Ours is the tale of two siblings, thrown into a world of chaos. Living in the shadow of their parents' heroic deeds and their Uncle's colorful military career, Finn and Atia are about to become the next force to shape our world. How will you rise through the ranks of Hereilla and what will be your legacy? Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.
       
      Previous Work by Team
      Although we are working towards our first game as Forged Interactive, our team members themselves have worked on titles including and not limited to:
      Final Fantasy Kingsglaive FIFA 2017 Xcom 2 Civilization  
      What do we expect?
      Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques
       
      What can we offer?
      Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.
       
      Contact
      If you are interested in knowing more or joining, please email or PM us on Skype. A member of our management team will reply to you within 48 hours.
       
      E-mail: Recruitment@ForgedInteractive.com
      Skype: ForgedInteractive
       
      Regards,
      David, Colin and Joseph
       
      Follow us on:
      Facebook: https://www.facebook.com/ForgedInteractive/
      Twitter: @ForgedInteract
      Youtube: https://www.youtube.com/channel/UCpK3zhq5ToOeDpdI0Eik-Ug?view_as=subscriber
      Reddit: www.reddit.com/user/Forged_Interactive

    • By dell96
      I'm trying to make my first project but I'm stuck i don't know how to make my crate to start to spawn again when i hit the start button after i die.
      hoping someone can help!!!
      Crate.cs
      CrateSpawn.cs
      Cratework.cs
      GameController.cs
      GameManager.cs
  • Popular Now