Add dual view to the Game editor for editing and playing at the same time

[RobProductions]

Describe the project you are working on

Improvements for the Godot editor.

Describe the problem or limitation you are having in your project

Now that godotengine/godot#97257 has been merged and embedding to follow soon, I wanted to follow up on an idea by @ccioanca which would I believe would vastly improve the workflow of this new feature. The problem comes from having to press a button to switch between 2D/3D edit mode and game input on the same viewport.

In the example given, this makes it impossible to live edit through the new runtime tools while someone else plays the game, say for a presentation. Also, let's say that some animation glitch occurs when the player interacts with a lever and you wanted to take a closer look at it, but it's out of view of the player's regular camera. It would be really difficult to view the glitch up close in this case because you may have to toggle input/camera control to start the interaction, at which point you may miss the important moment you're trying to debug. Obviously you could code around this for specific cases to test, but it creates a larger burden on the developer for something that could already be available to them if more tooling options were available.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

A good way to remedy these issues would be to have 2 views of the game, one with game input and one with the new runtime selection active. With this, you could set up a debugging view of the game before key moments happen and watch them occur from both the editor view and the player's view as you play through your project. This an approach other game engines use and it's extremely convenient for getting more visibility on complicated game worlds. Example:

Additionally, it would be neat to get options for different combinations of displaying the game, like edit view embedded but play view in its own window, or both views embedded, or both in their own window. I believe Unreal has somewhat similar options letting you choose how the game is run and how you debug it. Would definitely be tough to implement but I think the more customizable it is the better :)

Finally, a tangentially related idea would be that if we ever implement #7233 or something similar with fully customizable panels, you could sort of get this feature for free. It would be neat for the user to be able to create as many views into the game as they want and create their own layouts for editing/testing, but this is much further away of course, so it's best left for another time, just something to keep in mind.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

From a UX standpoint, I think the Game tab could look something like this:

For now, to preserve the original behavior, we could have something similar to the View dropdown in the regular editor:

Which lets you toggle between 1 embedded view or 2 embedded views, and then whichever button will be used to "pop out" the game in the upcoming embedding PR can be applied with a separate button for each view. This way, both can be embedded or standalone at user discretion.

From a programming standpoint, the key challenge is passing input into one view and not into the other view. I don't have a lot of ideas as to how this will be possible, but mainly we would need to cull out typical input events when the game view is not focused. Conversely, editor hotkeys, etc. should not be used when the edit view is not focused. This would involve setting the "input is active" bool that was added for runtime debugging (called disable_input) when the user focuses on a specific view (either by mouse hover or mouse click into the view) rather than when they click the game input button.

However, this approach won't work for someone playing and editing at the same time. For now, I think the above idea is a reasonable start/initial PR, but to solve the problem of simultaneous view input, we would probably have to track the viewport source of each input event and cull out editor-specific keys/mouse events based on that. For rendering the individual views, we simply have to force the game to use another Viewport and add an additional piece of info to the viewport telling us whether it is in edit mode or not. I'm glossing over a bunch of details but I believe these basic concepts can kick off more detailed ideas. I'm happy to discuss implementation caveats/approaches if there's any suggestions!

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can not be worked around easily.

Is there a reason why this should be core and not an add-on in the asset library?

All users would benefit from having additional options for debugging/running their game :)

[allenwp]

Until #7233 is implemented, here are my thoughts on how this issue should be addressed with game embedding. I believe it should be implemented to match the existing Script behaviour

Edit: I've moved this comment to a more appropriate location based on later conversation.

[RobProductions]

When clicking on this "Make the game editor floating" button, it would behave the same as the floating script editor, which would address the issues brought up by this proposal:

To clarify, do you mean that this would be used to toggle a single view of the game between floating and embedded, or to create a duplicate view that is not embedded which is used for playing? If it's the first case, the point of this specific proposal is to be able to work with two views at the same time so I just want to reiterate that.

This is a good idea for toggling between embedded and not embedded, however @Hilderin 's PR godotengine/godot#99010 seems to have already tackled how the embedded view switches (and is more relevant to embedding functionality) so if this about button styling I'd recommend bringing the mockup over there to see if it can gain traction :)

[allenwp]

To clarify, do you mean that this would be used to toggle a single view of the game between floating and embedded, or to create a duplicate view that is not embedded which is used for playing? If it's the first case, the point of this specific proposal is to be able to work with two views at the same time so I just want to reiterate that.

Ah, I misunderstood this proposal! You're right, I should post in the other PR; I wasn't aware of this PR yet, and that's correct that my comment only applies to that PR and not this proposal. Thanks!

(When I read "2D/3D edit mode", I interpreted that to mean "2D/3D workspace", but this was intended to describe the Game workspace when input is disabled and 2D/3D selection is active.)