Ocean (An Orx Content Editor)

2»

Comments

  • edited February 2012
    ainvar wrote:
    What I have in mind is to have full flexibility to add features to the editor.
    For example...I'd like to add drawings of joints to know exactly where they are and how they act. I'd like to use vectorial drawings to draw such objects.
    The same for spawners.
    I'd like to add new objects like triggers, paths, gui controls and so on.

    That said, I think it would be easier (and less time consuming) to do that with a custom control instead of using ORX.

    That's probably true. :) (Well, except for physics display as soon I'll have Box2D own display system hooked up in orx. ;))
    The editor I'm trying to do is more like a "Visual Studio for Game Engine" editor.
    You edit contents as you edit sources. Then you compile and test.

    My goal it to have a tool to create a project containing all informations needed by a game engine.

    That's where I think things might get a bit more tricky. Game engines can have wildly different features and maintaining the set of tools/features available for engine X or Y while editing can become a huge task.
    I want to be able to draw scenes with layers, place objects in a map, define the kind of animations the objects can do, add sounds for objects and music for the scenes, add gui objects, add fonts/text and localization helpers and physics editor too.

    That sounds great if not a bit ambitious. :)
    I want to be able to export all contents for ORX or for any other engine that needs an editor like that.

    I could do the same using ORX inside Ocean but for me it takes more time than using a custom control for static drawing.
    What I miss more the the opportunity to directly draw into the editor view with something similar to GDI.
    With ORX all must be a stretched bitmap. While this is perfect for runtime, it's not for the kind of editor I mean.

    No, that's definitely a big limitation for the kind of display you need.
    But if you go with an editor display only, you will get the opposite issue: you won't be able to represent things how they'll look into a game engine, and then the users will have to do back and forth every time they try to modify or tweak the properties of an object so that they can actually see how it'll look in-game.
    Sure there are features that are likely to be common by most engines, like applying a teint or an alpha. Or even tiling or mirroring. But then come blending mode, anti aliasing modes, visual FXs, shaders, custom rendering, including 3D one, etc...

    And that will not be rendered correctly - if at all - in the editor unless you rewrite everything related to display/rendering yourself (which is already a huge task for one single engine let alone many).
    Otherwise that will require the users to constantly save and start the game, go to the place they want to test (might take many minutes in-game to get there) whenever they're setting or tweaking backgrounds, lighting or overall ambiance.

    I think the best option is actually a mix: let the engine draw game content and use your own direct drawing for editor content.

    Instead of embedding the engine window and have everything rendered by it, you can ask the engine to render to a texture instead.
    If you start the engine in a separate thread inside the editor process, you could get the texture content directly from memory or, worst case scenario, have it sent via named pipes in the case of separate process.
    About the animation graph:
    I think the way orx uses animations is really great. Well, I think the way orx is done is great!.
    For that reason the internal structure of the editor will be close to the one used by orx, expecially for animations and the animation transitions.
    If other engines have a different way to handle animations I think it will be not a problem to write a nice exporter plugin because in ORX structure (or the close imitiation of Ocean) there will be all information needed.

    Maybe. I'm a bit more skeptical about that part but it might be something that can be solved, I don't know.
    It's just that if an engine is missing a feature, like the animation graph for example. Whatever you export won't be handled by the engine at all. Unless you extend the engine yourself with that feature with writing a runtime layer that users will have to use on top of the engine, maybe?
    That said, I want to think more about that before make any modification.

    I'm afraid I can't be of much help there, sorry! :)
  • edited September 2012
    Sorry for loooooong absence from the forum and from Ocean project but I had a really busy time and I had to stop development of all home projects.

    In these days I'm trying to re-start with development of the editor and my game coding.

    I saw that a lot of people is trying to make usefull editors for the orx engine.
    I see a lot of projects like the animation editor, tile map editor exporters and other utilities that I see as nice features for an "Orx Studio" project.

    What about joining our efforts to build a single project to mantain?
    A cross-platorfom one, driven by plugins, made in c# or Java or something portable...

    I made a basic architecture in c# to handle every aspect of orx game engine, but as soon as I modified the architecure I had to stop.
    I saw the animation editor of enobayram is better than what I was trying to implement, Reemon's physic editor is the part that I was thinking to add to make the editor "complete".

    What about creating a little team?
  • edited September 2012
    hi ainvar,

    Ocean looks amazing, and I'd love to integrate the Orx Animation Editor (Can I squat over this name officially :) ) in it, while maintaining a stand-alone version as well. I was planning to somehow integrate Orx into the animation editor in the very long run, but I actually wanted to do that to implement features that Ocean already seems to do much better. I think an integration like this would be a win-win for all of us tool developers and the Orx community!

    I can imagine various levels of integration:
    1. Ocean ships with OAE and simply invokes it on demand
    2. Ocean sets up OAE so that it starts up in a convenient state to edit animations for the content inside Ocean
    3. Ocean invokes OAE and talks to it over sockets, both sides notifying each other of modifications in real time.
    4. Ocean manipulates OAE directly through JNI (or equivalent).
    5. Ocean embeds OAE as a widget.

    Whatever the level of integration, I guess we should definitely support drag and drop between the editors.

    Personally, I'd prefer to go for integration level 3, as it'll probably be the most platform independent one, and 3 or 4 would be transparent to the user anyway (Plus we get distributed editing, whatever that might be useful for :) ). 4 would still be doable, but 5 is probably an adventure :)

    BTW, all the integration alternatives I've mentioned go for any other plug-in as well.

    I'm all in for the team :)
  • edited September 2012
    Hi enobayram,

    thank you for your words.
    I see your animation editor is made in Java and there are few opportunities to make a C#-Java interop.

    If you want to integrate orx into a widget I can tell you how I've done in the first version of Ocean, but it's not portable to other platforms because there's need of a modification in orx code to allow orx to be child of a window in a clean way.

    I think the nicest solution would be solution 5 but with a modification:
    OAE ships as an Ocean plugin but with a loader executable that allows to load it as if it was inside Ocean.
    In this way you mantain a single codebase :)

    The main problem I see is the environment. If we decide to create a sort of 'orx studio' we need the same environment.

    I'd like to write you using skype to continue with tech considerations in private without filling the forum.

    I leave a screenshot of last Ocean version, that's in deep w.i.p. state :) OceanToday.png
  • edited September 2012
    ainvar wrote:
    I saw that a lot of people is trying to make usefull editors for the orx engine.
    I see a lot of projects like the animation editor, tile map editor exporters and other utilities that I see as nice features for an "Orx Studio" project.

    What about joining our efforts to build a single project to mantain?
    A cross-platorfom one, driven by plugins, made in c# or Java or something portable...

    Would be great to have an "Orx Studio" instead of bunch of separate projects that might go unmaintained anytime ;-) and don't really talk to each other.

    I'm all for portability being a Linux user ;-). Last time I checked Ocean was requiring .Net 4 and using some P/Invoke magic to talk to orx, so not really portable :-(.

    I guess Java, Python or plain C/C++ would be easier ;-).
    What about creating a little team?

    Great idea. Don't count on me for C# projects though :(. With Java I have some experience but strictly in J2ME. That's why I started hacking on orxCraft by acksys which is written around Scroll in C++. I first started to write my own editor in Python+Qt but figured that running orx to display stuff and manage ini files will be better in the long run.

    enobayram wrote:
    I can imagine various levels of integration:
    1. Ocean ships with OAE and simply invokes it on demand
    2. Ocean sets up OAE so that it starts up in a convenient state to edit animations for the content inside Ocean
    3. Ocean invokes OAE and talks to it over sockets, both sides notifying each other of modifications in real time.
    4. Ocean manipulates OAE directly through JNI (or equivalent).
    5. Ocean embeds OAE as a widget.

    I really like #3. I had the same idea to talk to ScrollEd from an object editor. Maybe we should standardise some protocol so all tools could easily talk to each other? For starters:
    - Please edit object: "Object Name"
    - Ini files modified please reload

    Cheers,
    Graag
  • edited September 2012
    Graag, enobayram , I sent you pm with my skype contatc.

    Actually Ocean uses only .NET and no more p/invoke for orx...in fact it does not uses ORX to render.
    The code is not yet public because the new version it's not in a stable or working state.

    I'm a Linux user too, but I consider C# as portable as Java or other kind of languages.

    Java nees a Java VM, C# needs mono, C++ needs Gtk/Qk/wxWidgets...etc.

    The problem is that Ocean (or our future Orx Studio) would be an application that will use a lot of UI, not just 2 or 3 buttons.
    That's why we should evaluate the best environment to achieve the result in the best and quickest way.

    Personally I'd prefer plugin architecture because every portion of the software can easily access the same data structure and share events about modifications of objects.

    I think that polling sockets for getting events from a software that runs on the same machine as the software that receives the events...is not so efficient.
    It's less efficient if we consider that the two software have to work with the same data pool.
    It's less easy to implement than a call to a method in a library.

    The main problem with 'big' projects is that they never end, and I think thing should be mantained as simple as possible or we will never end it.

    Until now I had a lot of dreams about Ocean but I know that only a part of those dreams will become working and usable code.
    I lack of time and...why not, experience too.


    Bye
  • edited September 2012
    Hi folks,

    Ocean development will be officially closed to leave space to Orx Studio.
    You can follow and partecipate the discussion on the dedicated thread.

    Greetings,

    ainvar
Sign In or Register to comment.