JRPG camera node.

[ca3games]

Describe the project you are working on:
A 3D JRPG

Describe the problem or limitation you are having in your project:
I want to have a camera that follows the player if he is closer to the edges.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
There's not a simple solution to make a JRPG camera in godot, or a RTS camera, or any camera that follows the player in a boundary.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
A camera with a collision box area, where the camera would move to center again an object or objects (like 2 player fighting games or metal slug clones) or maybe also the mouse.
And maybe an option to make the boundaries static colliders to stop the players or the mouse from leaving it.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It's a very common feature for most videogames genres.

Is there a reason why this should be core and not an add-on in the asset library?:
It would be easier for the user to have a proper camera node with all these functionality already made, and is a very common feature it would be better to have it by default as a camera node.

[Vlad-Zumer]

Could you provide a GIF example of what the end result would be?

[ca3games]

Could you provide a GIF example of what the end result would be?

A basic camera with boundaries, like a 2D JRPG camera, or a RTS camera (that follows the mouse).

[Jummit]

I also don't exactly know what a 2D JRPG camera works like. GIFs or videos would be helpful.
Also, the built-in 2D camera supports boundaries.

EDIT: Didn't realize op was talking about 3D.

[huhund]

Is there anything currently in Godot that prevents game developers from implement this?

[LikeLakers2]

@ca3games I thought a little about what you're asking. Please tell me if I've got these correct:

A camera with a collision box area, where the camera would move to center again an object or objects (like 2 player fighting games or metal slug clones) or maybe also the mouse.

Are you looking for the Camera node to have something similar to Camera2Ds drag_margin_* properties? Those allow the camera to have a slight bit of drag behind the character so that it's not always centered on the object, giving this feel of a cameraman catching up.

And maybe an option to make the boundaries static colliders to stop the players or the mouse from leaving it.

This sounds almost like you'd want Camera to have a set of limit_* properties like Camera2D has, which prevent the camera's edges from moving past a certain point. Only difference being that you'd also be reading those values from player character code, and preventing the player character from being outside those limits.

---

My only concern with these two is that it might be a little weird to work with, but... at the same time, you might also be able to just slap an AABB in them and call it a day?

Either way, are these what you're looking for? Or is there more to it?

[clayjohn]

I would also like to bring in factors 3, 4, and 5 from the main page of the proposals repo.

3. Can this proposal be implemented with an addon?
   Evaluate whether it is possible for the proposal to be implemented in an addon. If it is possible for the proposal to be in an addon, it is less likely to be accepted.

There is no reason why this couldn't be made as an addon, or even just a single script that is shared between users. So there needs to be a very good reason to make this a part of core.

4. Does this proposal benefit most users?
   Determine whether this proposal benefits all users, or just certain users. For example, a feature that can only be used for 3D FPS games is less likely to be accepted than a feature that benefits all 3D games.

The answer here is no, it benefits those making a certain type of JRPG and maybe a few other users making 3rd person games in a similar format.

5. Can this proposal be implemented in a robust, general-purpose way?
   Determine whether the feature can be implemented in a robust way that benefits all use-cases. For example, many games use an inventory system, but every game implements inventory differently. Accordingly, a proposal for an inventory system will likely not be accepted because it would be impossible for us to implement an inventory system that works for most users that need an inventory in their game.

To address 3 and 4, we could consider making a very flexible camera node capable of achieving the things that a JRPG camera would and more. However, that is likely to result in a messy non-performant camera node. In practice, it is likely faster and cleaner for users to have a custom script attached to the already existing Camera node.

Keep in mind, the purpose of Godot isn't to make your game for you, but to provide you with the tools you need to make your game. IMO, the Camera node along with a collision shape and a script should allow you to achieve the camera behaviour you need. If it is impossible to make a JRPG camera in Godot using a combination of existing nodes and script, then we definitely need to make changes to the Camera node to make it possible to make a JRPG camera.

[ca3games]

I also don't exactly know what a 2D JRPG camera works like. GIFs or videos would be helpful.
Also, the built-in 2D camera supports boundaries.

https://www.youtube.com/watch?v=PJkeQsVewXE
Here's a simple example of a JRPG that uses a basic camera.

@huhund
No, but I think as a specialized node it would save a lot of time to remake the same camera between projects, Is a very common camera used in JRPG, Fighting games, RTS, Platformers, etc.

@LikeLakers2
Well, you could define this as a camera with defined boundaries that are solid for the tracking object/objects where the camera moves when the target object comes closer to the boundaries.
Like the camera in metal slug or any fighting game.
Or It could work like a RTS camera that tracks the position of the mouse.
My idea is to have it as a subnode of the camera next to the other subcamera nodes that exist already.

@clayjohn
I think you missunderstood, is not just for JRPG, but for a lot of other genres, the point is a camera that follows an object that has some boundaries for the tracking object.
I think such node could make development easier since is a very common type of camera that pretty much anyone who makes a RTS, fighting game, zelda clone, RPG, platformer will want to have easily already as a specialized camera node.
It could even be made in a way that certain features like a camera that follows an NPC can be easily created.

[KoBeWi]

Well, what you describe totally sounds like drag_margins (see Camera2D docs). Just put the camera as a child of object you want to follow and enable the drag margins and the camera will move when the node goes to the boundaries. For RTS games, you set the camera position to mouse.

Keep in mind that Camera2D has distinction between camera position and screen position. The actual position of the screen can be acquired by using get_screen_center() and it's different from the Camera2D node position property. The difference may come from limits, drag margins or smoothing. This enables the behaviors you are describing (so the functionality is already there).

[LikeLakers2]

@KoBeWi Problem with that: This is allegedly for a 3D game, and the 3D Camera node doesn't have drag_margin_* or limit_*.

I don't imagine it would take much to implement though, as we already have the code over on Camera2D -- so we can just copy it over, and make the adjustments needed to enable it for a third axis.

[ca3games]

@KoBeWi
Thanks, that seems useful for 2D games, and could work for 2D jrpg.
But I am talking about a 3D camera as well.

[mhilbrunner]

Camera handling is usually very core to a game, and in my experience thus always heavily customized.

As such, there is not much value to a drag-and-drop camera that tries to be a complete solution to a JRPG camera (or a fighting game camera, or a racing game camera,...).

Even within those genres, it is likely that the cameras while similar will in details behave very much differently.

Godot should aim to offer you the tools to build the camera you need. Or, more specifically, scripting (which it does), and a camera API that offers everything you need.

If you're missing something in the current camera APIs to build your camera, it would in my opinion be more useful to point out the specific things it's lacking for your use case.

Or more pointedly:

Godot isn't (going) to make your game for you

[mhilbrunner]

I'm closing this, as it's fairly vague.

However, that doesn't mean the current camera is perfect - if you stumble over a use case where you're missing some specific things in the camera API, please open a proposal outlining what we could do specifically to improve Godot's camera for you.

Thanks for using Godot, and thanks for taking the time to submit a proposal to make it better :)