Walk Direction Angle

Started by Val, Sat 21/10/2017 11:01:33

Previous topic - Next topic

Val

Can a different perspective than 45 degree for walking angle be changed to, like, 60 degree.

I don't know if it's been implemented but I found these two discussions about it:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48987.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=14602

TIA

Khris

What are you trying to accomplish? Are you using standard mouse controls with pathfinding for walking? Are you using diagonal loops?
Give A LITTLE information about your issue, and we can try and help.

Snarky

No, it's not customizable, and because AGS doesn't expose the waypoints of its pathfinding (so there's no general way to know what direction a character is heading in) it's not really feasible to implement it in script, either â€" unless you commit to building a whole new walk system from scratch.

eri0o

Hey!

I have an idea, I don't know the graphics you have so I don't know if it would work...

I tried to do isometric walkable area:


If you are interested on how I did this without any code, reveal below.
Spoiler

This is my background:


And this is my walkable area mask:


To insert an walkable mask as walkable are:

[close]

Val

I have a character with diagonal loops, all 8 directions are set. The character walks exactly like on a cardinal directions flatted on screen. I really want him to walk close to the perspective of the room.
I think Scotch from the second link I posted explained this better than me, though alas the images he attached were gone.

How does AGS decide when to use Down or Down-right? Is it by the angle between 90 (down) and 45 (down-right)? Can I make down-right more preferable so the cardinal directions fit the room's perspective?

Oh, thanks for the suggestion eriOo but it kinda makes my character walks funny lol

Snarky

No, as I already said, there's no way to change this, unfortunately.

eri0o

A* (a star) pathfinding isn't impossible to implement, you could do your own algorithm, which means you would also need to take care of the walking animation for your character. There are lots of resources on the subject online. It will probably eat you two weeks on development.

Val

eriOo, I checked that on Wiki and oh boy, lots of math involved lol. It would take me months or years probably, but thanks for the tips.
Alright then, I'll just stick with a-bit-weird-walking-angle :-\. Thank you guys.

Monsieur OUXX

ValI'm actually not sure what you're asking. I'm hesitating between two scenarios :
Scenario 1) you want to flatten your scene (you want your camera to be closer to the ground) which makes it necessary for the player character to walk at 30° angles instead of 45° angles when he's walking NW, NE, SW or SE.
Scenario 2) you want to have 8 more angles for your player character, for him/her to be able to turn in all those directions instead of the 4 basic ones : 0°, 30°, 45°, 60°, 90°, etc. all the way to 360°.


If it's scenario 1 : are you absolutely sure that the following solution isn't "good enough"? :
- enable the extra four "45°" loops. In them, use sprites that look 30-degrees oriented instead of 45-degrees oriented.
- in the game, reduce the vertical walking speed, for the player move faster in the left/right direction and slower in the up/down direction.
- See if the corner-cases where the engine detects a theoretical 45-degrees walk angle under the hood, but displays either your custom 30-degrees loop or the two neighbouring loops (0°, 90°) makes it really look awkward. Is it really shocking? I'm imaging it could totally fool the eye.

If it's scenario 2 : I think eri0o is a bit over-enthusiastic when he suggests to implement A* (your game would need to compute the walkable areas and perfom some calculations based on their raster mask, since it's pixels-basedand not vector-based). But you can probably implement something cheaper : whenever your game is supposed to call "player.Walk", you could have a custom "walk" function inbetween that computes the angle between the player's starting position and the destination, and then locks the corresponding view during the entire time the player is walking. You can easily detect when the player has finished walking, by testing "player.Iswalking" in repeatedly_execute.


 

Khris

One way you can try is to

a) turn the actual player character completely transparent
b) use a dummy character that is positioned at the same .x and .y
c) track the player's movement by comparing current coordinates to previous coordinates
d) calculate the angle and determine the loop
e) set the dummy's frame and loop

That way you can change the loop to an arbitrary one while keeping the engine's animation. This will only work if all loops have the same number of frames though.

I gave this a try and it basically worked, but if the walking direction happened to be close to the threshold angle, the calculated angle would sometimes alternate between just below and just above, making the character switch loops every single frame.

Snarky

Quote from: Monsieur OUXX on Mon 23/10/2017 10:32:21
If it's scenario 1 : are you absolutely sure that the following solution isn't "good enough"? :
- enable the extra four "45°" loops. In them, use sprites that look 30-degrees oriented instead of 45-degrees oriented.
- in the game, reduce the vertical walking speed, for the player move faster in the left/right direction and slower in the up/down direction.
- See if the corner-cases where the engine detects a theoretical 45-degrees walk angle under the hood, but displays either your custom 30-degrees loop or the two neighbouring loops (0°, 90°) makes it really look awkward. Is it really shocking? I'm imaging it could totally fool the eye.

This might be a tolerable workaround if you can tweak all the values correctly, but note that "30° sprites" means sprites that face more front/back than 45° sprites (really just a slight tilt off the full front/back view), not more sideways. And the problem is going to be the big switch in orientation between the sideways views and the NW/SW/NE/SE views.

Quote from: Monsieur OUXX on Mon 23/10/2017 10:32:21
If it's scenario 2 : I think eri0o is a bit over-enthusiastic when he suggests to implement A* (your game would need to compute the walkable areas and perfom some calculations based on their raster mask, since it's pixels-basedand not vector-based). But you can probably implement something cheaper : whenever your game is supposed to call "player.Walk", you could have a custom "walk" function inbetween that computes the angle between the player's starting position and the destination, and then locks the corresponding view during the entire time the player is walking. You can easily detect when the player has finished walking, by testing "player.Iswalking" in repeatedly_execute.

This only works if the character walks in a direct line, in which case yeah, it's not too hard. But if the walkpath has any turns at all, it won't be correct, and you're back to having to implement some kind of pathfinding algorithm.

Quote from: Khris on Mon 23/10/2017 11:10:12
I gave this a try and it basically worked, but if the walking direction happened to be close to the threshold angle, the calculated angle would sometimes alternate between just below and just above, making the character switch loops every single frame.

I've also tried something similar, and found that it's pretty difficult to get it to work reliably. Particularly if the path might change dynamically (other blocking characters moving at the same time).

Khris

It'll probably work with a kind of lazy update that'll only change the loop for the 2nd consecutive result.

Alan v.Drake

Easier solution: ask someone to compile whatever version of AGS you're using, applying this commit.

I'm not suggesting to use my custom version because I can't remember if I made breaking changes in the game data format in my latest editions, anyway I'm going to upgrade everyting to the latest 3.4.1 not too far in the future.

- Alan

Crimson Wizard

#13
I also recall there was this module: http://www.adventuregamestudio.co.uk/forums/index.php?topic=50492.0
Never used it myself, but description sounds like it may be relevant. Sorry if it is not...

Val

Sorry for the long delay, I tried my best to do the suggestions before replying.

Thanks M.Oxx, reducing vertical speed actually helps the animation to be more realistic in relative to the room's perspective. Although the character angle is still wrong when walking. Snarky also got a point if I change the diagonal sprites to be more angled to front/ back, the switch from that to sideways would be greater.

I did the dummy-character and transparent-player as you suggested, Khris. And it is indeed doing fast-switching of loops on certain angle. I actually added your tip on second-run-thing (was it for Snarky's comment on path changing?) but doing it with bigger number (x % 4 == 0) on the condition to delay the rapid-loop-change effect and it helps. I wonder if in some room, I want to have 5 NPCs or more walking, that means double the characters and the code loops... would that be slowing down the game a lot? I'm still not sure if this solution will interfere some future walk/animate-related things I might implement though. But thanks, Khris.

Wow Alan, there is a solution for this on engine-level? Committed on Oct 2016. Has it been discussed on how it is, somewhere in the forum?

I tried the IsoWalk module by Billbis and it is indeed a method for combating the 'sliding effect', CW. It's doing a walkaround so the walking animation doesn't look sliding. I tried it and on close distances it's not bad, creds to him. Though for my game, doing far distances, when the player walks to the destination, there is like an invisible object inbetween and he walks avoiding it lol. Hey thanks for looking it up, CW.


Alan v.Drake

Quote from: Val on Tue 24/10/2017 13:15:48
Wow Alan, there is a solution for this on engine-level? Committed on Oct 2016. Has it been discussed on how it is, somewhere in the forum?

Nope, it was just a quick and dirty sledgehammer work so I could make directions be more perspective friendly for my game, I haven't really done extensive tests with diagonal views but it should work.
It introduces a script command called Game.SetDirectionRatio(float ratio), where 1.3 was a good value for making it look good on perspective (1.0 is the default).
This prevented the left/right views to be picked when they would make the character look like he was sliding while trying to walk in another direction.

- Alan

SMF spam blocked by CleanTalk