Three Suggestions Regarding Walking

[Ali]

Hello,

These aren't wholly new suggestions, but I felt there were a few features which might strengthen character movement in-game and I wanted an opportunity to discuss them together. I don't know what their implementation would entail, but from my perspective they would be extremely valuable additions.

1. Setting the 'angle' of the camera in a room.
This may be what is tracker'd here, but I'm not certain. It seems to me that AGS decides which direction characters face while walking as if they were viewed from top-down. This looks fine in Ben Jordan where the camera is usually at a high angle, but in Nelly Cootalot (see below), where the camera is at a low angle it results in Nelly's movements looking odd at times. When she is moving slightly north-west Nelly displays her left view, however to look correct she ought to display her up-left view.
This is entirely based on my perception, but I think I would be very useful to be able to 'skew' the way the engine decides which loop to display.

2. 16 walking directions.
I'm aware that this has been discussed here, but it doesn't appear that CJ has been convinced of its use. I acknowledge that 16 walking directions would be of no value to a pixel artist but for a pre-rendered 3D character it would be as easy as pie to produce 16 walk-cycles and would distinctly improve the appearance of the sprites in-game.

3. Turning animations.
I think it would be a marvelous addition to allow the user to create turning animations that would play whenever the character turns (or whenever they turned more than a user-specified threshold angle). This would be very useful for higher resolution games with larger characters where turning can looks distinctly jerky.
If there were more than 8 walking directions, I doubt this would be necessary during walking, but it would still be useful to stop the characters appearing to 'spin' when turning on the spot
I attempted to find a simple solution here but it quickly became apparent that my solution was simplistic and flawed, and that a plugin would be required. I felt this was beyond my meagre programming capacity.

None of these suggestions would impact all users of AGS, but I think they would make significant differences to some, like me. I would like to know how others feel about them.

[Rui 'Trovatore' Pires]

Re turning animations, it's possible to script them. I have, on occasion. WOnder where the code is...

[GarageGothic]

I have been bothered by the issue mentioned in 1) for some time. It seems that AGS currently calculates directions as even radians on a circle, when in reality, due to perspective that circle should be somewhat flattened.

[Lt. Smash]

[SUGGESTION] Regarding 1) it would be nice if we could place vanishing points in the room using the room editor. One for x and one for y. I'm not sure if there's need for z.
Then there could also be an option to set if the chars should apply their scaling to this points.
So this cames in very handy if you have a special perspective where the char needs to become smaller when you walk to the right and slightly up, for example.

Then there should be also an in-built functions(SetVanishingPoint(x,y)) or coordinates like the mouse cords(vanishpX.x, ...y, vanishpY.x, ...y [vanishpZ.x, ...y])which can be get/set in-game.

[Ali]

Rui: I'd be interested to see what you've done. I scripted my own simple turning animations in the link in the first post, but I was only able to make the character turn towards the click, not towards the first node on his path. Nor was I able to make him turn when he reached each node.

Garage Gothic: I'm glad you've noticed the same problem, and even more pleased that you expressed it more clearly than I did.

Lt. Smash: That might allow for 'dutched' camera angles, so I'd be interested in it. I wonder if it would be possible to re-work one of the scaling moduled to provide that function.

[Rui 'Trovatore' Pires]

I'm not sure when the code is, but I can remember enough about the basics. The real trick was having a dummy invisible (i.e., his loops were all empty frames) character that was always placed on the xy coordinates of the main character. Then whenever the player started to walk, I triggered my own walking function, in which the first thing I did was to set the DUMMY to move wherever he had to. One game-cycle after that (an undetectable delay to the gamer), I got the dummy's loop, thus getting his direction. Since the main character would traverse the exact same path, that means that the dummy had just given me the direction of the first node.

After that, it's all a matter of calling animations, making them non-blocking in order to make it interesting, and placing checks in rep_execute to see when the animation's done and when the character actually moves (I had to put them in rep_execute if I wanted those animations to be non-blocking, and I did. Or maybe I did put them blocking, but alter the mouse cursor so it didn't look blocking? Ah well, same basic deal).

EDIT - I didn't dwell on making him turn when he reached the end of the path, but that would be simple enough. Set a variable to 1 when he starts walking, check rep_exec to see if he's STILL WALKING while the variable is STILL set to 1. If he STOPS walking, set the variable to 0, get his loop to get his direction, and animate him turning wherever you want.

[Pumaman]

Hmm yes, (1) is an interesting point. What would be the most useful way of specifying it, I'm too tired right now to think it through properly.

[Ali]

I'd prefer to specify it visually in the room editor. It could be nice to be able to set an horizon line on the backdrop, the difference between the height of the horizon line and the backdrop/screen would be the amount by which the circle ought to be 'squashed'

I guess it might be useful to be able to alter the position of the horizon line in the script. Ideally this would work in the same way as setting the position of walkbehinds in the the script.

[SSH]

I did think once of adapting the real-time 2D skeleton in the walkcycle generator into a module that could be used to provide a fully posable skeleton that would walk in any arbitrary direction. But I can't be bothered 

[Snarky]

I'd prefer to specify it visually in the room editor. It could be nice to be able to set an horizon line on the backdrop, the difference between the height of the horizon line and the backdrop/screen would be the amount by which the circle ought to be 'squashed'

I guess it might be useful to be able to alter the position of the horizon line in the script. Ideally this would work in the same way as setting the position of walkbehinds in the the script.

This is starting to sound a lot like a full 3D model of walkable areas. Here's an in-engine screenshot by the FOA2 project which shows how that might look. I believe that WME also supports this kind of walkable areas (I suppose it's pretty much a requirement for 2.5D games).

[Lt. Smash]

If something like this would be possible it would be great but something like I suggested before would also be good.