Editor Refactoring

Everything about the development of Urho3D.

Editor Refactoring

PostPosted by Eugene » 14 Nov 2016, 20:21

I've seen here several threads about Urho Editor. I've even started one.
I think that Editor needs tighter integration with game code.
Sometimes I even feel a passion to improve something here, but I don't want to start without way, milestones and goals.
@cadaver, do you have some strong opition about Editor developement or just good ideas?

Now I can imagine three ways of Urho usage:
1) Custom app that uses Urho as library.
2) Custom script that uses Urho player (probably extended with custom objects)
3) Playable scene that contain all game logic inside scripts like Unity (probably extended with custom objects), with minimal entrypoint script/application
Changes in Editor depends on that how many ways we want to cover.

I have bucket of different ideas and thoughts (mine and others')
- Migrate Editor to C++. Partially or completely? Will it give any benefits? It looks like hard job. (optionally covers 1,2)
- Allow Editor to be called from custom game script. Full or limited editor? How to make interaction? (covers 2, optionally covers 1)
- Allow custom game script to be called from Editor. What limitations? How to implement interaction? (covers 2)
- Add standalone play of 'playable scene'. It's simple, but it don't cover 2-nd way. It's enough for me, but what about others?.. (covers 3)
- Just do nothing and let Editor be temporary utility untill user write his own ingame editor with bj&hs. (covers nothing ¯\_(ツ)_/¯)

I don't promise that I'll start work immediatelly or that it will be high-priority task for me.
However, let's discuss at least.

My final goal is to have something like this:

Now it is hacky and buggy, with almost untouched Editor code. And I hate hack and bugs, do u 'now?
User avatar
Eugene
Some active
Some active
 
Posts: 62
Joined: 06 Jun 2016, 06:30
Location: Russia

Re: Editor Refactoring

PostPosted by cadaver » 17 Nov 2016, 10:14

My view is that the existing editor is somewhere halfway between a complex script API usage example, and a production-usable editor. Many have contributed to it and the code structure is not best. Because of Urho's nature of "singleton" subsystems it will be hard to achieve calling into the editor from game, or vice versa.

Your analysis is quite spot on that Urho can be used in many ways and therefore it's not obvious how the editor and game could talk to in all the scenarios.

Probably the ideal would be, if you wanted to improve the user experience at the same time, would be to use an actual native UI toolkit in the editor and rewrite it in C++. Otherwise you're always going to be struggling with both the editor and game taking over Urho's subsystems. How this would work best when appended to users' projects is another largish question. Perhaps the editor could be another library, which adds functionality into Urho base (for example, it registers an Editor subsystem as it starts up)

A lot of smaller-scale engines actually launch a separate exe for the game from within the editor, though in that case you can forget the editor and the game talking.

I don't have hard / fast opinions on how you should proceed. If you have passion, go for it. However to be realist, or slightly pessimist, you should be ready to do (most of) the work on your own. Many projects fizzle out because they're expecting a collaboration to form, and that then doesn't happen.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Editor Refactoring

PostPosted by NiteLordz » 17 Nov 2016, 12:49

What i have done, is using Qt for the UI, i have multiple dock widget/windows that i can move around. I create one context at startup for the editor, and one context for the "Game" window. When the user clicks on the "play" button, the active scene is saved/cached to a seperate file, which the game context then loads. This allows to "play" the game, within the editor.

I am moving my editor from VSTS to github within the next week, if anyone is interested to see how it works.

It requires Qt 5.6, and currently only runs on Windows and 32-Bit, but that is only because i have not created the project for 64-Bit yet.
User avatar
NiteLordz
Some active
Some active
 
Posts: 51
Joined: 11 Feb 2014, 12:21
Location: United States

Re: Editor Refactoring

PostPosted by Lumak » 02 Dec 2016, 16:23

I know how tough it'll be to port the editor to c++. If you can create a repo for it, perhaps, I can contribute.
Lumak
Have many posts
Have many posts
 
Posts: 425
Joined: 08 Jun 2015, 15:38

Re: Editor Refactoring

PostPosted by dakilla » 02 Dec 2016, 20:00

it could be a nice community project.
+1 for Qt, I have a good experience using it and urho :p
User avatar
dakilla
Have some posts
Have some posts
 
Posts: 31
Joined: 27 Jan 2016, 05:10

Re: Editor Refactoring

PostPosted by Eugene » 11 Dec 2016, 19:16

I have only one reason against Qt: It is not lightweight at all, it have much more that is needed for Urho Editor.
User avatar
Eugene
Some active
Some active
 
Posts: 62
Joined: 06 Jun 2016, 06:30
Location: Russia

Re: Editor Refactoring

PostPosted by TheSHEEEP » 12 Dec 2016, 09:22

Eugene wrote:I have only one reason against Qt: It is not lightweight at all, it have much more that is needed for Urho Editor.

While that is true... who cares?
Honestly, application/download size is a problem of the past, at least in non-mobile environments. And nobody is going to distribute the editor to mobile ;)
Besides, while Qt has much more than any single application will ever use, it is nicely split into modules/shared libraries. When packaging a Qt app, only used parts will be packaged with it (automatically).

It does increase the complexity of building Urho3D, though, so I'd at least keep the editor optional.

The pros far outweigh the cons with Qt.
For example, I could imagine making changes to the editor for a project at hand to distribute the editor with the application.
The current editor.... it is just not something you'd give into the hands of an end user. It's just too rough, and not even nowhere similar to editors people are used to like Unity, Maya, etc.
So currently, if I wanted to distribute an editor with an application using Urho3D, I'd have to build it myself - which I'd most likely do using Qt, since - well, there is no alternative reaching its quality, not cross-platform, anyway.
Just having to adjust an existing editor for my needs would save much time.
User avatar
TheSHEEEP
Have some posts
Have some posts
 
Posts: 27
Joined: 21 Jul 2016, 09:07
Location: Finland

Re: Editor Refactoring

PostPosted by Eugene » 12 Dec 2016, 13:22

Ok, I am just almost unfamiliar with Qt.
If somebody is ready to start and/or share some code of Qt Urho Editor, I will contribute.
It is unlikely that I'll start creating Editor in Qt on my own in the nearest future.
Probably, we will also need some assistance from our buildsystem guru...
User avatar
Eugene
Some active
Some active
 
Posts: 62
Joined: 06 Jun 2016, 06:30
Location: Russia

Re: Editor Refactoring

PostPosted by cadaver » 12 Dec 2016, 13:55

I believe to have commented this before, but it doesn't hurt to reiterate.

If the editor is a separate project, using Qt fits very well. You'd only need solid setup instructions per platform, and the user could build or download Qt themselves and just ensure it's available for the project's CMake. Very likely you'd only ever use Qt + editor on desktops in that case.

As part of Urho repo or build itself, we have quite strong principles of automatic dependency build (and even including them in the source repo, since everything used so far is small). There Qt doesn't fit that well, or would require much more ninja magic.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Editor Refactoring

PostPosted by Eugene » 12 Dec 2016, 15:46

Huh... I am in doubt.

Qt:
+ Really powerful
- Heavy
- Harder to use with executable project
- Separate repo is worse than builtin
- I am not familiar with it

Editor library:
+ Builtin, easy to use
+ Can be injected into existing executable project
- Lack of functionality. Urho's UI is powerful enough for games, but not for editor.
- Looks like a kludge

Now I like Qt way more...
Can somebody of Qt guys share some code?
User avatar
Eugene
Some active
Some active
 
Posts: 62
Joined: 06 Jun 2016, 06:30
Location: Russia

Next

Return to Developer Talk

Who is online

Users browsing this forum: No registered users and 1 guest

cron