[FEATURE REQUEST] Character direction ratio

[Snarky]

Do you mean to gradually slow down the movement when walking up the y-axis, to imitate longer traversed distance when they walk further to the background? That would be great too. It would also make sense to work vice-versa and accelerate when walking down (forth) again.

No, in this context I'm just talking about the view angles, though it's related. If your room is a flat surface extending to infinity (a single walkable area), then moving at e.g. a 30-degree angle on screen (say 10 pixels up, 20 pixels right) represents quite different movement angles in 3D space depending on the distance, because movement "away" gets increasingly foreshortened, so that small y-movements represent larger and larger distances "into" the screen. Therefore, the further away the character is, the wider the angle of movement that should use an up/down angle.

Or to explain it another way: Let's say you have a room in one-point perspective, with a road coming from the bottom left going straight into the vanishing point in the distance. Now imagine a car driving down the road, moving in a straight line (the road) across the screen. Then the car will be seen from the side when it's up close, but more and more from behind as it recedes into the distance, even though it's always moving at the same angle. To get this effect in AGS, the relative size of the different viewangles (IOW the foreshortening) has to change depending on distance.

As Crimson Wizard says, it's possible that all this is unnecessarily complicated for a 2D engine. (My bigger concern is that it might not look right unless you also do foreshortening of the movement.)

Besides, how many users will actually going to use this, in a 2D point & click game?

It depends on what "this" is. I think the inability to adjust the view angles is a real problem, which people regularly complain about. Just how much flexibility and built-in logic is needed to meet user needs is more debatable.

My proposal is to make it a setting very much like Scaling: set on a walkable area basis (with a sensible default), but possible to override. I'm assuming it would be a float representing the degree of foreshortening, like in Khris's calculation.

To do the "vary by distance" part you could actually just do the same as for scaling: define a max and min value and interpolate between them, so it doesn't seem all that complicated to me, but if you just want to have a single property that will be a big improvement in itself.

[Crimson Wizard]

Probably we have different problems in mind. I've been thinking of configuring fixed angles depending on a perspective. For example, top-down view, or isometric movement. I don't really see how that may be done using just 1 property on walkable area (?), and frankly I don't know what "foreshortening" is.

I guess I will leave this for others to discuss then. But imo it may be worth to make such configuration a separate struct in script, then if necessary it could be applied to Game, Room, Character and Area, with override rules .

[Snarky]

"Foreshortening" is a form of perspective distortion: the effect that something gets "squeezed" when looked at from an angle. For example, if we have four character direction views, let's imagine them dividing a circle so that each wedge is the range of movement angles that uses that view; first seen directly from above, and then from more and more sideways angles:



As you can see, as the circle and cross get more and more flattened by foreshortening, the front and back view angles get wider, while the side view angles get narrower.

We can represent this perspective distortion as a single number: the height/width ratio of the circle or ellipse. That is (I assume without examining the calculation closely) the value (or the inverse of the value) that @Khris sets to 1.8 in the code here.

So this should be enough to support top-down movement (just set the value to 1.0). And I don't believe isometric perspective really needs any special settings, does it, as long as one of the view angles more or less matches the direction of the isometric movement.

[AndreasBlack]

Hi-jacking the thread a little bit, but it's a similar thing i believe. When the character changes from say a Side view to going to either side down or up, the animation should keep going. It doesn't. Would be nice if it was fixed in the future!

[Crimson Wizard]

So this should be enough to support top-down movement (just set the value to 1.0). And I don't believe isometric perspective really needs any special settings, does it, as long as one of the view angles more or less matches the direction of the isometric movement.

I think I understand how this may be used now.

Maybe I've been mixing two problems. One is real direction of a particular view angle. But another is optimizing view loops.

Arbitrary isometric example:


In the above solution this may be achieved by setting an oval flatting factor, but user will have to fill very particular loops in the view (left, right, left-bottom, right-up?) and keep doing that correctly for each view.
I've been wondering if instead we could let user also define roles for the loops.

[Crimson Wizard]

Hi-jacking the thread a little bit, but it's a similar thing i believe. When the character changes from say a Side view to going to either side down or up, the animation should keep going. It doesn't. Would be nice if it was fixed in the future!

No, this is related to how walking animation works, and may be fixed separately. Should be opened as a separate issue.

I don't think this requires a lot to fix, unless there's a concern that it should be optional?

[Crimson Wizard]

@Snarky , I opened a feature ticket about "direction ratio":
https://github.com/adventuregamestudio/ags/issues/2243

[Crimson Wizard]

Opened an experimental PR:
https://github.com/adventuregamestudio/ags/pull/2304

My proposal for the name is "FaceDirectionRatio". I added "Face", because theoretically there may be other directions (like direction of movement etc).

EDIT: I added properties to Game, Room, Walkable Area and Character.
These may be set in the Editor and changed in script too (not all covered yet). I think for Character I'll only leave the script property for now (no design-time setting), because it seems like something that has narrow use and purpose to be changed dynamically in special cases (?).

[Crimson Wizard]

I need help with writing description for this property in the editor, something that is brief, but clear enough for users to understand what it does.

[eri0o]

https://en.wikipedia.org/wiki/Ellipse

Trying to understand the property yet, the idea is to have a ratio between the "vertical diameter" and "horizontal diameter", so that when this ratio is 1.0, both diameters are equal and we get a circle and the angle that transitions the directions happens in equal 45°, but when the ratio is bigger than 1 the circle gets squeezed in an horizontal ellipsis and when it's lower than 1 it gets squeezed in a vertical ellipsis. This will change the angle by a different amount which is not equally divided.

No good ideas to explain this yet.

[Crimson Wizard]

What about something like this:

The Y/X relation of diagonal directions at which Character switches from horizontal to vertical walking loops. Default is 1.0. <1.0 would use horizontal loops for more angles, >1.0 would use vertical loops for more angles.

EDIT: actually, maybe the direction of diagonal loop is a more important use case rather than "how many angles" use vertical and horizontal loops.
So above may be reworded as
< 1.0 would make diagonal direction more vertical, > 1.0 would make it more horizontal
or something along these lines.

The manual may contain more thorough explanation with diagrams.

[Crimson Wizard]

Could anyone check out the variant I made? I don't even have a game to test the different perspective myself.
I need to know if what I do is correct and enough for solving this case.

This is a description:
https://github.com/adventuregamestudio/ags/pull/2304

The latest test build may be downloaded here:
https://cirrus-ci.com/task/6688426888527872

[Snarky]

I haven't the chance to try it out now, but while it's still in testing, maybe an idea to generalize it further:

How about supporting negative values to allow users to switch the up/down directions (including diagonals)? (Typically for things like walking down hills.) I think that would greatly simplify this usecase.

[Crimson Wizard]

How about supporting negative values to allow users to switch the up/down directions (including diagonals)? (Typically for things like walking down hills.) I think that would greatly simplify this usecase.

I pushed a change, with the given implementation it's simply a matter of allowing negative values.
A test build will be available here after a short while:
https://cirrus-ci.com/task/6292291015409664

Although this makes me wonder whether it makes sense to support horizontal loop swap somehow.

Another thing that I've been wondering is, if we need a setting that defines a diagonal loop range, in other words, the angle in which engine will choose diagonal loops over "straight" ones. From my understanding, the diagonal loops are taking half of the sector between vertical and horizontal direction.

[Crimson Wizard]

Unfortunately, there's no proper testing process going on here. I can tell that my changes formally work, but I cannot tell whether this works as expected and is enough to solve the user problem. Except maybe "downhill" effect, which seems to be distinct enough.

I would really appreciate if someone could provide a test game, or at least a set of graphical assets, that would let to test and see that the result matches intent with full clarity.

EDIT: Another thing, it just came to me that the original request by @Nurz in this thread was about different thing and not really solved by the functionality that I added. Somehow I got confused. As I re-read this thread, it looks like it deviated from discussing initial suggestion.
I might have to separate this experimental functionality that I did into another thread.

[Crimson Wizard]

For the record, this is the most recent topic discussing the need of this feature, containing diagrams and test results:

https://www.adventuregamestudio.co.uk/forums/beginners-technical-questions/switching-angles-of-diagonal-character-loops/

Maybe something like game example in this thread may be reproduced for a test.

[Crimson Wizard]

I asked blaholtzen for some assets and made a simple test game:
https://www.dropbox.com/scl/fi/2mygs4whl89hvqg135j7z/test-ags4-directionratio.zip?rlkey=jvs4msnp7zx8ja3tylaahh4p7&dl=0

Although it seems that the loop direction ratio is not enough, it would need some method to control character movement too. Maybe I'm missing something.

[Crimson Wizard]

Most recent test build:
https://cirrus-ci.com/task/5958924629704704
now with everything working, including saves (i hope).

New test game, made by @blaholtzen :
https://github.com/adventuregamestudio/ags/files/14316758/IsoBikeDemo.zip