Implement "walk mode" in editor viewport (like Blender has)

[novemberist]

Describe the project you are working on

relevant for any 3D game

Describe the problem or limitation you are having in your project

In my opinion, this would be a QOL improvement for scene editing and testing more than strictly fixing a limitation

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

Currently freelook mode in Godot works a lot like fly mode in Blender. Additionally Blender has a walk mode where you can quickly drop into your scene at the current viewport camera position and continue to navigate it as if you were in an FPS game.

This is great for quickly getting a different/immersive perspective of 3D scenes, getting a sense of proportions, aligning cameras and objects from a more natural angle etc.

In godot, you could of course implement a character controller and simply run the game to achieve a similar thing, but you always have to leave the editor and run the game first. Your viewport camera and game camera would not be in sync and you always have to manually adjust the starting position of your character controller instead of just starting from where your viewport camera currently is.

I use walk mode a lot in Blender and think this would be a huge QOL improvement for the 3D viewport in Godot.

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

• implement a simple FPS controller in editor viewport that can be activated on demand
• activate simple collisions on all objects so you can quickly walk through your scene as if in an FPS game

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

Not sure if viewport navigation can be manipulated in such a way with an editor plugin

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

[ryevdokimov]

See link above to a PR that provides a possible avenue to do this via a plugin (although I wouldn't be against having this built-in).

[Calinou]

This makes a lot of sense, but we'd have to provide a lot of tweakables for the walk navigation to be as close as possible to your actual in-game logic.

At the very least, you'll want:

• Collision type (box/cylinder/capsule) and size. This would probably default to cylinder as it's a good mix of reliability (when using Jolt) and behaving well with corners. When using GodotPhysics, we'll need to evaluate whether cylinder works well enough - if not, it should probably default to Box instead.
• Eye height
• "Spine" effect intensity (i.e. the eye is slightly offset forward, which makes pitching up/down more realistic)
• Movement speed
• Acceleration and friction
• Gravity scale (relative to the project default)
• Jump velocity
• Maximum step height
• Maximum slope angle

Your viewport camera and game camera would not be in sync and you always have to manually adjust the starting position of your character controller instead of just starting from where your viewport camera currently is.

We could have a way to pass the current editor camera position and rotation to the game, e.g. using environment variables that you can read in your project on startup to teleport the player. Many map editors such as Radiant and TrenchBroom support this for "play at position" features. This would be better tracked in its own proposal though.

[ryevdokimov]

This makes a lot of sense, but we'd have to provide a lot of tweakables for the walk navigation to be as close as possible to your actual in-game logic.

If we did want to do this in the editor, instead of providing a character body and making it tweakable which I could see being tough to accommodate all the possible requirements such as the ones you listed, we could just create a "slot" somewhere in the editor that you can insert your character body scene as a PackedScene.

When some key is pressed, it spawns an instance of the slotted character body scene as an unowned child of the editor root node at the position of the editor viewport camera, switches the editor viewport camera to the camera attached to the character body as a preview mode, enable _input events in that viewport (since editor events don't really do anything in preview mode, and therefor shouldn't conflict), and runs all of its scripts as tool scripts. When you go back to free fly mode camera, the character body is freed.

Here is kind of an example of this I threw together.

2024-12-28.18-45-18.mp4

[Calinou]

@ryevdokimov This looks pretty interesting 🙂

While this has the upside of providing physics accurate to actual gameplay, I'm a bit concerned about usability. You would need to ensure your character controller implementation doesn't rely on anything not available within the editor. This means it can't reference autoloads (which don't exist within the editor) or other gameplay-only nodes.

[ryevdokimov]

I'm a bit concerned about usability.

It's a valid concern, and kind of leans into #9142 territory which is against the grain in terms of the direction Godot has been heading with putting more editor features in the runtime rather than the other way around.

This means it can't reference autoloads

Autoloads can be tool scripts which allows them to be reference in the editor but yeah would require manually setting them up that way.

A dumb idea maybe is along with having tool scripts we can have nodes have a tool property which if toggled automatically runs all scripts attached to itself and its decadents as tool scripts. This might also include autoloads somehow.

At the moment I'd imagine this whole functionality would be better suited as a plugin which I can look into fleshing out more. That way people can at least try it and maybe come up with some better ideas.

[badsectoracula]

IMO a bit of both (three) is the best here.

By default have a "simple but opinionated" mode that provides the basic functionality. You configure eye level, perhaps even speed but that's it. You get to walk around the scene and look at it. IMO that'd provide most of the functionality that a walk mode would need: judging proportions/sizes, exploring the map somewhat like the game would need, etc.

But also, if someone really wanted the movement mode to match their game's behavior they could provide a controller that the editor would hook into instead. It could be a node in the scene or (perhaps better) a setting for a scene file to instantiated so they don't have to carry the node around (e.g. if they want to explore a scene that is meant to only contain geometry and be imported to other scenes). They'd need to make sure the controller is compatible with the editor but that's all.

And finally, if none of that is enough, running the full game in a special "please preview this scene from that camera position and direction" mode that the game can handle however it likes, could be used instead.

I think all the above can be implemented as separate PRs with the "simple but opinionated" first and the other two in any order as PRs that build on it.

[ryevdokimov]

By default have a "simple but opinionated" mode that provides the basic functionality.

I suppose we can also just provide users a prebuilt character controller scene that is pre-slotted, which can be modified directly in Godot as a scene. It can also just be swapped out entirely. I personally think that it would be too against the spirt of freedom in Godot to hardcode all of this in the engine and expose only parts of it. I think doing something like this will set an interesting precedent and will be pretty insightful to new users that the editor really does run on the engine and built using its own UI framework.

[ryevdokimov]

Here is a proof of concept of the idea.

Having the character slot in the Viewport Settings window was an arbitrary decision, it can be anywhere. Every new project will have a default character with basic functionality in the slot. I don't think it necessarily needs to be stored in the file system but could be an option if the default is modified. It will use the project settings InputMap, which is reverted back to the editor one when going back to free fly mode.

2025-01-05.13-40-46.mp4

[novemberist]

This looks very interesting and much more flexible than my original proposal. I personally wouldn't mind if this was a plugin after all, but it's probably potentially useful enough for a lot of users to be taken into consideration as a core functionality.

I suppose, it could even be possible to quickly add the preview character controller to the scene tree in case we want to use it in-game without setting everything up ourselves (similar to the preview world environment and sun light)?

[ryevdokimov]

I personally wouldn't mind if this was a plugin after all, but it's probably potentially useful enough for a lot of users to be taken into consideration as a core functionality.

Either way, I think we're going to have make some certain engine modifications that I'm going to do my best not to completely shoehorn in and justify them for purposes outside this particular use-case.

This is a recent one I created: godotengine/godot#101251, this will be necessary if we want to run project setting inputs in the editor. There may be a couple more unless I can think of some workarounds.

[ryevdokimov]

Ok, the PRs above should be the minimum required to get a plugin working that has this feature.

All the PRs attempt to be as minimally intrusive as possible, and I tried to justify them with their own merits outside the context of this specific proposal. Some of them fix bugs or have some broader purpose like being relevant to other plugins. Would appreciate feedback on any of them.

I modified how you change the character slot, because I don't see an easy way to exactly replicate what I did in the last video without modifying the engine directly, but I think it should be fine for a plugin.

2025-01-26.16-03-47.mp4