[Example] A Top Down Action RPG/Action Adventure (AKA Zelda) style camera example

Hey all,

While I’m still working on redoing my Not-a-vania example using new methods/solutions I’ve learned over the last year+, over the weekend I got an idea to use my Metroidvania camera method and slightly modify it to work for a Zelda-style action/adventure game.

You can play around with it (and download the example) here: GDevelop Action RPG / Top Down Adventure Camera and Transition Example by Silver-Streak

The camera itself, including the room transition, is a single event. The “freeze the player and enemies when transitioning” took more events than I expected, but everything is still just one screen worth of events.

I’ve submitted it to see if it meets the needs to be included as an example, and may use what I’ve learned here to update the Metroidvania camera, too. Let me know if anyone has any questions/concerns on it.

6 Likes

Nice demo and code. The transitions are nice and smooth.

That “clamp” code is tough to parse, but makes sense.
I think you could have just used SceneWindowWidth() and Height() instead of setting a global variable for the resolution though.

I’ve been tumbling this idea in my head of a character camera that will expand and squeeze to any sized camera box and maybe “clamp” could help, but I think it’s probably going to require four hidden sprites at each corner of the camera. I’ll let it keep tumbling for now…

Thanks for trying it out! It has been officially accepted into the engine and should show up once the new examples browser is out, I think.

As far as the resolution variable: I tried playing with that, but unfortunately SceneWindowWidth() and ScreenWidth() work differently depending on the platform (Desktop/browser/etc), so manually setting the resolution, until we can get expressions to actually get the Resolution settings from preferences, seems like the most agnostic option.

(Also, if someone is using my GUI Layer example, they’re going to want the fixed resolution numbers anyway since the “real resolution” is different than the “perceived resolution” once zoomed in.)

As far as the clamp math: Yes, I tried to give as much detail as I can, because I had to piece through math I could find from 4 other engine examples (Defold, Construct, Godot, and Unity) because GD5 does camera movement slightly different (Center vs Origin) and how we interact with objects/etc are slightly different.

That said, I really wanted to avoid as many objects as I could. For example, with how Lerp works, there’s a slight “gradual” last step of movement between rooms that I can’t fully eliminate. You could eliminate this entirely with a “camera” object that you tween to the clamped position, but that’s another object to deal with, which could be even more confusing for users.

For your stated goal, clamp with similar math could definitely accomplish what you’re thinking about, and help avoid issues, although you’d probably be gauging based off zoom rather than position, wouldn’t it? Either way, the math will likely be needed.

2 Likes

Well Explained. It is really very smooth.

Hi @Silver-Streak I want to ask you if I have your permission to upload this example to my website?
It’s a website with various examples, starters and complete games.

The example is 100% open and for anyone to use, have at it!

My understanding is that It’ll be in the engine example list soon, so I’m not sure you want to reproduce it in multiple places, but if you want to, please go for it.

2 Likes

It is already on the web-app, and it will be in the next release of GDevelop for the local version

It’s funny you mention using a camera object since that’s what I do for almost all of my prototypes and games. It really helps to keep the Camera logic to just center on the camera object, and when I’m debugging I can make the camera object visible to help troubleshoot.

I forgot to update this thread. This example is now in the example list included with the engine. Gonna close this out for now, but again thanks for all of the kind words, folks.