New camera mode: "interest"-based camera

[Semphriss]

This is an effort initiated by #2095.

(First header is the motivation for the change, see the second header for the actual proposal)

Camera.set_pos() considered harmful

Cameras scale poorly across screen resolutions and require manual intervention from level designers to exploit features such as zooming. Most importantly, certain features, such as transitioning the camera to hot points (Camera.set_pos()), require to fetch the appropriate camera coordinates either by complex thoughtwork or, most often, by trial-and-error and tolerance to approximation.

This has several disadvantages:

• Trying by testing several times and adjusting the camera a bit each time is long, tedious and repetitive, and calculating manually is often too complicated to be a viable solution, especially when the camera is meant to be at a position far away from the origin.
• Given the above, no reasonable person would waste their time trying to perfectly align the camera as they want it; most will simply "live with" an approximative solution.
• Maintenance is a disaster. The code keeps no trace whatsoever of what the intention of the original level designer meant to do, or what they considered important; This gives a whole list of new sub-genres of problems:
  • If a sector is resized with a significant offset, and the cameras aren't immediately adjusted, it becomes entirely impossible to know how to repair a given level, unless someone remembers how it was before the buggy change happened.
  • If the original level designer intended to have many points of interest, but some of them are subtle (for example, foreshadowing, easter eggs, ambience elements, etc.), a future maintainer who is not aware of all of them might choose to change the camera position in a way that does not cover additional elements.
• The code is not self-documenting. Camera.set_pos(2200, 143.5) does not say that a given level designer wanted to show the animation of a door that opens.
• Edits to the levels may require changes to the code. This isn't always avoidable with all features, but in this case, I have a proposition that allows to avoid it.
• In conjunction with zooming: This does not play well with different screen resolutions. It isn't obvious to everybody that the camera will show different portions of the sector based on the resolution of the screen, and those who think about it will rarely spend the time to test on a tiny screen, on an XXL screen, on a super-wide screen, on a super-tall screen, etc.

This list is probably non-exhaustive.

In sum, these methods can be difficult, tedious, imprecise and unintuitive, and tend to give rough, messy and unclean results.

I would like to propose a somewhat unusual idea that would help level designers, even the less skilled ones, manage the camera in a more resilient way.

Camera management: A proposal

Often, when using the Camera.set_pos() function (or similar), the point is to show one or more "points of interest". The idea with this new feature is that instead of having level designers (or coders) provide positions to the functions, they will provide the points of interest, and the camera will deal with the data it receives.

The what

Please note that this is NOT a replacement, it is an addition; since some users will still prefer to keep full control for themselves (and for retrocompatibility as well), it would be unwise to impose this as the only way of doing things; although generally, it should be meant to become the new standart way of doing things.

The "interest" is meant to be a new camera mode alongside normal, autoscroll, etc. This is how users would activate the new feature: by setting the camera's mode to "interest". (Or any other string considered suitable)

The how

The camera would receive an array of one or more "points of interest". Such points can be described by two variables:

1. The region covered by the point of interest;
2. The position on the screen the point of interest should have, specified by percentages (useful notably for the rule of thirds).

Since manually inputting numbers directly in the code would be 1) tedious (even more so than the current system) 2) un-verbose 3) difficult to calculate without tools and 3) un-reusable (one would have to rewrite the same coordinates each time a certain point of interest is used in the code), I would recommend using game objects to create and draw zones to cover the various points of interest.

The screen proportions would be optional and would allow the coder to specify an offset for certain points of interest. The offset would be calculated based on the size of the screen to ensure the desired effect works on all screen resolutions. This variable would not be bound to the points' game objects themselves, but rather to a specific function call, to allow achieving different effects using the same point of interest.

The camera would automatically position itself smoothly based on the point(s) it receives. It can take care of finding what is the optimal position, and possibly zooming, so as to satisfy all constraints; it would then manage the movement, with any movement method wanted (immediate, linear, easing, weighted, etc.) and fit all the points of interest on the screen, at the wanted position.

The why

This methods presents a solution to all issues listed above (proudly):

• It requires barely any testing to achieve a certain effect; level designers can trust the camera will correctly include everything they want to have on the screen, at the expected location, and that on any screen resolution.
• It is easy and intuitive to place down zones for points of interests, and screen percentages are simple enough (the rule of thirds will give plenty of 1/3's and 2/3's!)
• Maintenance is made plain and simple. Most of the time, coders won't need to adapt the code; dealing with changes can be done entirely by level designers, by simply dragging and resizing the zones as wanted.
• There is no risk of accidentally removing subtle but important elements from the screen, as all point of interest will be listed in each function call.
• The code can be made self-documenting by using the objects' names. If the code refers to a certain point of interest called campfire, it will be easy to understand the intention for this call without needing to run the level or to investigate a sector's layout.

In general, this proposal puts much less responsibilities on the level designers and is more resilient against mistakes, and offers a much easier path to achieving desired effects without testing users' patience.

I would like to ask for further issues that this method could be tested against, as to keep them in mind when developing the solution further.

[Alasdairbugs]

1. Im not sure how I feel about the rule of thirds thing. you see, it isnt always useful during camera manips. Most cutscenes have text with them, and in my opinion, if the action of the cutscene isnt in the centre, is not above the text - and rather 2/3rds out to the side - it would look really awkward to read what is happening and then look at action simultaneously. It would look a little clumsy, like the level maker doesnt know how to use the camera properly. This feature is really only useful for stand-still shots, like in one of your old levels, showing snow melting around a hut. I think the screen percentages will get really annoying for when you want to centre something, because it looks like you've only given the option of thirds here.

2. "It requires barely any testing to achieve a certain effect; level designers can trust the camera will correctly include everything they want to have on the screen, at the expected location, and that on any screen resolution."

Are you 100% sure? Imagine I want to show a basin of water in a cave. but, lets say, when im making the camera object region (im guessing like climbing has its region and secret area has a region you can move around) i accidentally make it (instead of 16:9 ratio) like 2480:1313 or something really awkward - how will the camera adjust for that? I'm not exactly clear on how exactly this camera object zone will translate.

[Semphriss]

For 1 - The "rule of thirds" was only an example; every value between 0 and 1 (and perhaps even values outside this range) will be valid. That means you can still center something using the values 1/2 for X and 1/2 for y (or 0.5 and 0.5, etc). The values are also not bound to each other, you can choose to center horizontally and add a slight shift upwards if you want, for example, to avoid having text to cover up the thing you want to show.

For 2 - Testing is naturally part of the designing process; what I meant was, you no longer have to test 10 times just to find the right coordinates for the camera, like: put some value that seems close enough, test, realize it's too far to the left, adjust, re-test, see that now it's too far to the right, adjust, re-test, find that it's not well centered, adjust, re-test... There will still be some testing and perhaps adjusting required, but it'll be (I hope) far less time-consuming than the current system.

As for the zone management, the way it's currently planned is that the camera does not attempt to 1:1 match the zones; it only bothers to contain them all. With the example of the hut, the point of interest zone wouldn't cover what I want the entire screen to cover, it'll cover only the hut and maybe a bit of its surroundings of I want a certain margin; the camera will take care of positioning itself properly so that the entire zone is contained in the camera, roughly at the wanted position if the position is also provided; if the zone is too big to fit in the screen, the camera will zoom out to accommodate for the zone.

That is the point of the feature: say, if you want to include two things in your cutscenes that are relatively far apart and that can't be contained in 1 screen, you don't have to bother doing trial-and-error with Camera.set_scale() for zooming and set_pos() for positions; the camera will take care of finding the appropriate values for you.

In any case, the best way to see if it works well and intuitively or not is to implement it and let you test it 😛

(Also, this is an addition, not a replacement; if you still prefer to use hardcoded values, the option will remain here)

[Rusty-Box]

Working on cutscenes for SuperTux's Story Mode, I more and more discover that our camera is a mess. An absolute mess!

If we wish to not aim for an entire re-work, which I know some people are hesitant about due to retro-compatibility, instead expanding on the pre-existing camera modes might help? Currently using the camera for anything that is not a basic, static movement (left/right/up/down) through Camera.scroll_to(x, y, time); is a nightmare and even that could be improved with a couple more scripting option, like easing, setting velocities etc.

I don't see a point in adding a work around here. Another camera mode cannot be the solution here. If anything I worry it will just cause us ignoring what has been broken in the first place rather than tackling the actual issues.

So my approach would be to actually think about how we can improve our current camera system and expand on it for more usage and functionality. I did mention a few things in #2405 so I'll be mentioning them here again, plus a few other things:

• Make camera effects like those cinematic black bars or fading in/out cover the screen properly, see Broken Camera Zoom #2405.
• Allow changing anchor points for cameras (at the very least when set to "manual" mode).
• Camera scaling/zooming should not be based on Tux's position and not only work with cameras set to "normal". I get that it does for stuff like multiplayer, but if that is something that provides issues, atleast have it not be so when the camera mode is set to "manual" as it does not follow Tux at that point anyways.
• Autoscrolling should actually start at the beginning and not ~5 tiles to the right from the origin. To be fair, I don't quite know why it does that but is should not either way!
• Better and easier to use camera shaking that loops automatically for a specified duration thanks to scripting (something like Camera.shake(x, y, duration);, the current approach is way to complicated to use.
• Adding various scripting options for the camera scrolling like: setting the camera's velocity, allow for easing

There may be evn more things that could be added but these are all the suggestions/ideas I have on this topic as of now!

[Semphriss]

[...] I know some people are hesitant about due to retro-compatibility, instead expanding on the pre-existing camera modes might help?

That's what this proposal is meant to be*:

The what

Please note that this is NOT a replacement, it is an addition; [...]

That's the reason why I wanted to make it a separate thing: the old methods won't be gone, it'll just be a new and hopefully better way of doing things.

---

Another camera mode cannot be the solution here.

Why so? Is there anything that would prevent this from working?

The proposed solution seems to fix most of the issues you mention, minus those that don't concern core camera behavior (such as shaking - I believe there's a PR open to help with that as well).

---

*Do you mean that you would prefer have new controls that are closer to the current manual approach?

The reason why I wanted to replace the current approach are mostly stated in "the why": it is more difficult for different people to provide maintenance for a level using that system. If in a few years, somebody else needs to make adjustments to a level's cutscene, having pixel-coded camera position would be difficult to read, and adjusting the values would require a certain amount of trial-and-error which would be burdensome for many.

I could add tools that would help find the correct values to place the camera at exactly the wanted position, but that's already what this new camera system is meant to do: store the relevant locations in zone objects, so that the behavior of the camera is predictable and adjustments are easy to do, if necessary.

I realize it's difficult to explain with words, and that a picture is worth a thousand words. Would it help if I did a schema of my proposal?

That being said, it's still possible to add some new mechanisms that follow more closely the traditional manual controls, if that's the best option.