[FEATURE REQUEST] Ability to create 16 character facing directions

[Nurz]

Will you consider creating 8 more walking directions in the Views node? Meaning, three diagonals instead of one for each quadrant.

Thank you.

[Crimson Wizard]

I believe this may be a valid option for AGS 4. This, along with settings to define the direction angles.

[Snarky]

along with settings to define the direction angles.

I believe I have mentioned this before, but in this case it should be a setting per walkable area, as the foreshortening can vary even within a room, depending on the angle each surface is viewed from (for example if a room is divided into floors at two different levels, or if part of the ground is angled).

(Properly speaking it should also vary by distance, but that might be getting a bit too complicated. Perhaps if it was made dynamic, it would be possible to script it.)

[Nurz]

Awesome!

(Properly speaking it should also vary by distance, but that might be getting a bit too complicated. Perhaps if it was made dynamic, it would be possible to script it.)

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.

[Crimson Wizard]

This goes out of scope of what we usually plan for the engine. Besides, how many users will actually going to use this, in a 2D point & click game?

Perhaps it may be better to provide enough script API to let users script this system themselves.

Then someone could write a module for this.

In other words, then, it may be better to investigate which data has to be available in script, and which commands are necessary to script such system.

[Nurz]

This goes out of scope of what we usually plan for the engine.

You're referring to more walking directions, or just the distance thing?

[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?