Pioneer dev forum

So I was watching the Star Citizen livestream, and this really interesting thing popped out: https://www.twitch.tv/videos/320913467?t=18m55s. This is obviously a pie-in-the-sky goal, but I'd really like to be able to render the "game world" into a resizable portion of the window, and draw an editor around it. This would preferably be a dynamic thing - the editor is running in the game, not the other way round - and be available for everyone without needing a debug build.

EDIT: Let me clarify, I'm aware that the stream is showing the Lumberyard editor. I'm proposing that we write our own suite of debug / editing tools tailored for Pioneer's needs. The main purpose of this is to provide better modding / content development support for people who want to add to the game but are frustrated by the constant edit-close-reopen loop - even with fast load times, it's still miles quicker to hot-reload than have to open the entire game again.

Ideally, we can use this editor to tweak ships, inspect the game world, write/reload/debug UI code, define new star systems, edit current systems, tweak / sculpt terrain overrides, add planetary outposts, design scripted missions, etc. Essentially, everything we're already doing in an external tool editing data files by hand, but integrated into a WYSIWYG editor that's running on top of the game in real time, and that can write / update data files automatically when changes are confirmed.

Thoughts, comments? I know this is a huge amount of work, and I'm obviously not proposing that we do this any time soon, but I think it's a natural progression from a number of features - the picture-in-picture support is needed for a few different gameplay items and we can support it when we rewrite the renderer, better UI layout and definition is On The List, dynamic resizing of the game window is really needed to test UI code, the engine split is a natural progression of supporting C++ modding, and there's more that I'm not going to bother listing.

On a side topic, if I have my way and we split the engine from the gameplay code (even internally), what shall we call it? I've been thinking of calling it the Pi Engine (as in 3.14159), mostly because that's what it's called in the code base.

Yes the ingame-editor idea is a good one.

You should try out the ObjectViewer (Ctrl+F10) on a planet, I think it started out as a way of experimenting with seeds etc and testing them out but before my time.

Another option would be to open an external window as the editor which hooked into pioneer. That could just literally be another window, or it could be a separate tool that connected too it somehow.

ObjectViewer is currently broken, but I get the idea.

I'd prefer not to run another window, but I'll keep my options open. There's a good 2-3 person-years of work here before I would even want to begin thinking about implementing this fully.

ObjectViewer works fine for me, wierd

Another option would be to open an external window as the editor which hooked into pioneer. That could just literally be another window, or it could be a separate tool that connected too it somehow.

Yes, this is the much prefered way: to have any lua changes in any lua file take immediate effect, and in addition, you can use your editor of choice, rather than building an editor and a game. Both ecraven and laarmen have been pondering upon this, so would be nice to have at least the former in the discussion (as laarmen is pretty dormant nowadays).

Five years gone, and we're part of the way there. We now have an out-of-process editor framework for implementing static content editors (e.g. model viewer, system editor, etc.), and two "editor contexts" implementing... well, the model editor and the system editor. We also have limited hot-reloading for Lua files, though that's something which requires buy-in from the Lua code which wants to be hot-reloaded.

The idea of an in-process editor is still appealing to me, there are many gameplay systems which would benefit from the ability to switch contexts directly to an edit interface. Another issue is that since we ship unstripped binaries with debug information built in, the editor binary is another 100MB+ of debug symbols for a lot of gameplay code that we don't use in the editor - unifying the editor runtime into an in-process tool would reduce that duplication at the cost of having no compile-time separation between "editor" linkage and "game" linkage.

However, an in-process editor still faces quite a bit of resistance from the overall architecture of the codebase - there are a lot of systems that were designed to be "load once and never update", which makes an "edit and continue" style interface difficult to achieve. It's something to keep in mind moving forward when designing improvements or replacements to those systems.