• Advertisement
Sign in to follow this  

Unity in-engine tool vs external tool

This topic is 902 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
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Yosef BenSadon
      Hi , I was considering this start up http://adshir.com/, for investment and i would like a little bit of feedback on what the developers community think about the technology.
      So far what they have is a demo that runs in real time on a Tablet at over 60FPS, it runs locally on the  integrated GPU of the i7 . They have a 20 000 triangles  dinosaur that looks impressive,  better than anything i saw on a mobile device, with reflections and shadows looking very close to what they would look in the real world. They achieved this thanks to a  new algorithm of a rendering technique called Path tracing/Ray tracing, that  is very demanding and so far it is done mostly for static images.
      From what i checked around there is no real option for real time ray tracing (60 FPS on consumer devices). There was imagination technologies that were supposed to release a chip that supports real time ray tracing, but i did not found they had a product in the market or even if the technology is finished as their last demo  i found was with a PC.  The other one is OTOY with their brigade engine that is still not released and if i understand well is more a cloud solution than in hardware solution .
      Would there  be a sizable  interest in the developers community in having such a product as a plug-in for existing game engines?  How important  is Ray tracing to the  future of high end real time graphics?
    • By bryandalo
      Good day,

      I just wanted to share our casual game that is available for android.

      Description: Fight your way from the ravenous plant monster for survival through flips. The rules are simple, drag and release your phone screen. Improve your skills and show it to your friends with the games quirky ranks. Select an array of characters using the orb you acquire throughout the game.

      Download: https://play.google.com/store/apps/details?id=com.HellmodeGames.FlipEscape&hl=en
       
      Trailer: 
       
    • By Manuel Berger
      Hello fellow devs!
      Once again I started working on an 2D adventure game and right now I'm doing the character-movement/animation. I'm not a big math guy and I was happy about my solution, but soon I realized that it's flawed.
      My player has 5 walking-animations, mirrored for the left side: up, upright, right, downright, down. With the atan2 function I get the angle between player and destination. To get an index from 0 to 4, I divide PI by 5 and see how many times it goes into the player-destination angle.

      In Pseudo-Code:
      angle = atan2(destination.x - player.x, destination.y - player.y) //swapped y and x to get mirrored angle around the y axis
      index = (int) (angle / (PI / 5));
      PlayAnimation(index); //0 = up, 1 = up_right, 2 = right, 3 = down_right, 4 = down

      Besides the fact that when angle is equal to PI it produces an index of 5, this works like a charm. Or at least I thought so at first. When I tested it, I realized that the up and down animation is playing more often than the others, which is pretty logical, since they have double the angle.

      What I'm trying to achieve is something like this, but with equal angles, so that up and down has the same range as all other directions.

      I can't get my head around it. Any suggestions? Is the whole approach doomed?

      Thank you in advance for any input!
       
    • By khawk
      Watch the latest from Unity.
       
    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
  • Advertisement