I am requesting a Global Camera System where moving the camera affects all layers by default.
Instead of the current system where each layer has an independent camera that must be manipulated via events, GDevelop should adopt a system similar to Godot or Construct: one current camera movement that moves all layers, while specific layer movement is controlled by a X and Y of Parallax Factor/Coefficient property (e.g., 1.0 for normal movement, 0 for static UI, and 0.5 for distant backgrounds).
Why you are requesting it:
The current âper-layerâ camera logic is counter-intuitive for developers coming from other engines and creates unnecessary âboilerplateâ code.
The Problem: If I have 5 layers (Background, FarBackground, Entities, Foreground, Lighting), I currently have to create 5 separate actions every frame to ensure the cameras stay synced. This is tedious to manage and makes the Event Sheet cluttered.
Unexpected Behavior: For beginners, it is highly confusing when the player moves on the âBase Layerâ but the background remains frozen. In most modern game design workflows, a camera is a viewport into a world, not a per-layer setting.
The Goal: I want to be able to use a single âCenter camera on objectâ action and have the entire world react. By adding a âParallax X/Yâ property to the Layer settings, we could achieve complex depth effects without a single line of camera-syncing code.
Supporting evidence:
Most modern engines use this âCurrent Camera + Layer Parallaxâ workflow because it separates View logic (where we are looking) from Depth logic (how fast things move).
Example in other engines: In Godot or Construct, you set a âParallaxâ percentage on a layer. If itâs 0%, it stays on screen (UI). If itâs 100%, it follows the camera perfectly.
Current GDevelop Workflow: * Action: Center camera on Player on layer âBaseâ.
Action: Center camera on Player on layer âBackgroundâ.
Action: Center camera on Player on layer âCloudsâ.
If you can code javascript, then you could always make your own extension to do this.
Create an extension function to add a layer and the percentage it moves along, and another extension function that utilises GetAllLayerNames function to move the camera on each layer.
Iâd like this to be available as an option (via an extension or otherwise)
As a general heads up though, this is not the standard method of handling cameras in 2D, even in Godot.
Godotâs Camera2D only has one camera per canvas, but they explicitly expect you to have multiple canvas layers per viewport (each with their own camera), which is generally how GDevelop works.
Unity, Unreal, and Defold all have unique cameras per layer, too, they arenât linked to the first camera by default.
Again, I like the idea, just adding context that the idea generally isnât the norm, and the way GD5 works today is pretty similar to most other engines.
Honestly, I wish we had an option like defold where you can just outright declare cameras and determine which z layers they affect, but that might be too complex for some users.
Or alternatively, just the ability to say âallâ layers within the camera action parameters (maybe with a setting on the layers themselves to ignore the all command).
Thatâs a big load of codswallop. Coding is about figuring ways around a problem, working out how to achieve an outcome given a limited range of tools. Itâs meeting and beating the challenge.
Asking for the GDevelop devs do it is just lazy and a cop-out.
In godot instead of layers people just use nodes parenting and etc, but there specials nodes as CanvasLayer which usually used for UI or effects, nodes in CanvasLayer doesnât move, BUT it has a simple checkbox âFollow Viewportâ that makes nodes in CanvasLayer move with camera. There also some cool nodes for parallax.
But the thing is that godot works great with such system because it HAS parent-child (nodes) system, GDevelop â doesnât, Construct â doesnât, so Construct resolved this issue by what I described above in the post
So good UX is just lazy and a cop-out?
If I wanted to have TRUE CODE EXPERIENCE, I wouldnât use a game-engine at all, I would write my game-engine to figure out ways around a lot of problems, to meet and beat the challenge.
I donât see anything sophistical in my words. GDevelop is primarily a no-code game engine (Game Constructor), and a good constructor should have good UX, rather than making a makeshift solution through an extension, while most of the community simply and obnoxiously copies the camera to each layer through events.
If I were qualified to do so, I would try, but for now, personally, itâs easier for me to just use Godot and write code there, because it have better UX.
I came here over 4 years ago to remake 1 game
And core component of that game was autotilling
I was asking many times for it to be implemented
Looking how its standard feature in many other engines
4 years later we still donât have it
Even so like i said other engines have it as standard feature
Heck we are just about to get spritesheet support this year
ANYWAY
Even if you are right and even if ppl do agree with you
That will not result in something being added into engine
And i learned that the hard way
I needed to make auto tile extension myself
And it is still not standard feature of the engine
I do not even need to ask who would want for their terrain to auto connect to prove my point
Bottom line
Proving you are right
Proving there is demand
Is not worth your time trust me
The problem is that GDevelop community still very small and not quite active on forum, so itâs very hard to find more people to support feature requests.
Iâve been thinking about the Global Camera System since I first tried GDevelop (when it had just moved to version 5), and as a result, here I am, several years later, writing about this issue, which people hardly ever talk about, or only talk about if they are newbies who donât find current camera-layer system intuitive and write about it on forums in the âHow do IâŚâ category, while veterans are simply so used to it that they either donât care or arenât particularly bothered by it.
I really like GDevelop, but sometimes I feel like old outdated Scirra Construct 1 had better user experience in some parts than GDâŚ
Look i can show you tons of feature requests that hand high demand among ppl which never get implemented into engine
At the same time
I can show you many instances comments to other feature requests like âomg i didnât even know i need it in my lifeâ
A LOT of stuff ppl take as âok so that how to do it in gdevelopâ
And just donât bother to ask for any change
Every week on discord i am explaining to someone that if they donât want to have other layers work as UI layer they need to apply same settings for camera on these different layers as they have on base layer (or whatever is their game layer)
Easiest way is to use copy camera settings extension
Why its not built in is beyond me
Every other week i am explaining to someone that if they want to remap platformer/topdown movement keys then there is behaviors called remap controls for (both platformer/topdown)
Why it is not built in or to be precise part of their respective behaviors is beyond me
Most ppl are happy that they got what they wanted and it works
They do not really care that if it would be built in and right there from the start then
1 - it would be easier to find for new users
2 - you donât need to add/install additional stuff anymore
3 - you would see that option right from the start so even so you donât need it right now you would have in mind that it exist and have no problem going back to it if needed
And that generate the problem here
Most ppl just want something to work
And gdevelop mostly attracts ppl who have problems with actual codding
So they are happily taking whatever if its working
Where you know and i know and many of us know they would be better off with something being part of engine rather than add-on
Adding extension is easy enough for them to not care to some things not being part of engine itself
The thread itself appears to have derailed since I posted above, so I wonât add to that back and forth.
I will mention that your response of âPeople just use nodesâ in Godot rather than the native layer functionality is very similar to the âPeople just use extensions to simplify syncing camerasâ people are suggesting here.
I will also say that you might be limiting your viewpoint around extensions. Especially because your example on what wonât work as an extension actually exists.
The extension could likely even be extended out by adding options for custom actions rather than the ones built into the platformer behavior by default.
Again, none of this is the end of the world, Iâd still love if there was a way to just say âaffect all camerasâ on the actions that are already there (especially zoom).
You see when I say key mapper, I mean intuitive and simple global key mapper menu like in godot, where you store different keybinds and then use them in the code.
Also, if I remember correctly this feature is in GDevelop trello Roadmap.
Look i learned devs have different vision as we do
And its not exactly bad
AGAIN
I would say remap controls behaviors should be part of topdown/platformer behavior
NOBODY need to even argue with me cause that is dead simple scenario
Someone donât need it they can ignore it and donât touch default controls
Someone need it they will have it right there in their face
BUT
WE ALL need to control our players soâŚ
I wonât beg for it to be merged
And other ppl wonât also cause if there is something that works
They really do not care
We all would be better off if it would be merged
BUT like ask yourself
Canât we live without it?
And now think the same about your camera idea
I am all in for it
But at the same time i can see how ppl have something that work and wonât care that much
Bottom line
Its never bad idea to request so always do
But never expect that rightness of your request will change anything
Look that is my favorite example
Learn on my experience
My fit screen request
Like no brainer should be option in engine
And i was so mad at Davy for pushing me away
But like did it really made engine or my experience worse that it was not implemented?
I can gather ppl to back me up and what about it?
I would only prove there is demand and that i am right
Where now if simply someone want to achieve same thing i simply share that JS script and everyone is happy
I even made it into extension
As much i hate to admit it
Davy is right
Mostly we will clutter engine with options even if they are ones that SHOULD be there
Like look for example at godot vs gdevelop
Amount of options you have is so overwhelming in godot it is just painful sometimes
Yeah they are there for us to adjust whatever we want to our needs
But you totally will feel lost seeing them until you learn what they do
And gdevelop?
Few options easy to understand
And now if you need more you ask for help on how to achieve something and chances are there is extension for it
I wonât say i am happy with gdevelop approach
But NEVER i could say that gdevelop approach is bad
