Movement

Movement

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Post Reply
9heart
Posts: 51
Joined: 16 Sep 2010, 16:14

Movement

Post by 9heart » 09 Dec 2014, 05:46

I have tested on a totally flat map with (grey heightmap).

When given a move order, ground units wiggle about and have all kinds of micro-jitters, and make absurdly large turns, oversteering, etc. Try it yourself!

You'll observe units making hundreds of tiny 1-2 degree turns, first one way, then the other, back and forth, constantly, all the while just driving in goofy directions...while on a flat map! Where best path is obviously the one indicated by direction of green command-waypoint line!

Is there a tag or unit-move-type trick to bypass spring's A*?
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Movement

Post by smoth » 09 Dec 2014, 08:43

unit def/mov def etc. we need info to help
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Movement

Post by knorke » 09 Dec 2014, 10:38

High turnRate can make the unit turn around so fast that it turns too far, then it corrects, overcorrects to other side..wiggle wiggle.
Here was similar problem:
http://springrts.com/phpbb/posting.php? ... 14&t=32805
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10224
Joined: 24 Jan 2006, 21:12

Re: Movement

Post by PicassoCT » 09 Dec 2014, 18:11

That is why in normal systems, speed is computated via a PID-Function.

http://en.wikipedia.org/wiki/PID_controller

Correctly configured, it determinates the smoothest speed and even applies small corrections.

Incorrectly it does the Huntingtons Dance of robots.

Dont know what ticks away at the heart of spring though.
0 x

User avatar
SinbadEV
Posts: 6475
Joined: 02 May 2005, 03:56

Re: Movement

Post by SinbadEV » 09 Dec 2014, 19:06

Does it have to do with the size of the pathing grid?
Pathing.png
Pathing.png (5.14 KiB) Viewed 2332 times
Looks stupid but makes sense with a grid.
PathingGrid.png
PathingGrid.png (5.03 KiB) Viewed 2331 times
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Movement

Post by jK » 09 Dec 2014, 19:37

1. yes it's cause of grid (a grid has only 4 directions)
2. spring optimize those 4 dirs to 8 (adding diagonal ones)
3. still 8 dirs are too less when a long line path is given
4. the problem is very similar to AntiAliasing

you are free to supply patches, entry points for the code are:
https://github.com/spring/spring/blob/d ... r.cpp#L290
https://github.com/spring/spring/blob/d ... r.cpp#L698
0 x

9heart
Posts: 51
Joined: 16 Sep 2010, 16:14

Re: Movement

Post by 9heart » 10 Dec 2014, 03:55

thoughts on this proposed solution? http://gamedev.stackexchange.com/a/81596
0 x

MetalSucker
Posts: 98
Joined: 22 Sep 2014, 20:29

Re: Movement

Post by MetalSucker » 10 Dec 2014, 04:02

Apply a 'desired direction' force/vector, combine that with inertia/mass math, apply gravity according to slope, generate final motion, it can smooth things out.
0 x

luckywaldo7
Posts: 1397
Joined: 17 Sep 2008, 04:36

Re: Movement

Post by luckywaldo7 » 10 Dec 2014, 05:06

MetalSucker wrote:Apply a 'desired direction' force/vector, combine that with inertia/mass math, apply gravity according to slope, generate final motion, it can smooth things out.
As long as you don't mind your units being hilariously unresponsive to changes in move order. I think the effect would be somewhat similar to all ground feeling like slippery ice.
0 x

raaar
Metal Factions Developer
Posts: 814
Joined: 20 Feb 2010, 12:17

Re: Movement

Post by raaar » 10 Dec 2014, 05:49

this has annoyed me too for a while. Trying to micromanage the commander away from danger and he zigzags a bit instead of moving in a straight line over vacant flat terrain.

that proposed solution seems interesting, dunno how expensive it may be.

Maybe spring could use a similar modified pathfinding and allow the unit to move in a straight line towards its next target position from the player's point of view (ex: target of a move order), but only in some situations:
- waypoint is "near" enough
- no obstacles (or low density) or impassable terrain along the line from current position to target position
0 x

MetalSucker
Posts: 98
Joined: 22 Sep 2014, 20:29

Re: Movement

Post by MetalSucker » 10 Dec 2014, 06:29

The inertia thing is awesome for gliders/fliers/high speed vehicles and it's not so taxing taken alone because it's basically averaging forces, very simple, I don't know how it works with a pathfinding algo since I've done it standalone for a silly car game, I don't think it would be good for walkers. The ice thing happens if you're computing everything linear.
Last edited by MetalSucker on 10 Dec 2014, 06:33, edited 1 time in total.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Movement

Post by jK » 10 Dec 2014, 06:30

raaar wrote:Maybe spring could use a similar modified pathfinding and allow the unit to move in a straight line towards its next target position from the player's point of view (ex: target of a move order), but only in some situations:
- waypoint is "near" enough
- no obstacles (or low density) or impassable terrain along the line from current position to target position
already happens ...

edit: or ... has only lua the possibility to do so ... kloot & googlefrog know more ...
0 x

Google_Frog
Moderator
Posts: 2436
Joined: 12 Oct 2007, 09:24

Re: Movement

Post by Google_Frog » 10 Dec 2014, 10:46

http://springrts.com/mantis/view.php?id=4412
This ticket was made by xponen to request pathfinder-free move goals which can be set by lua. I recently implemented it in dev engine ZK for tactical AI but have not tested it much.

Units not moving directly towards their move order over short distances seems to be a common complaint. I think this is because the pathfinder is optimized for neatness instead of player experience. This is why it can change in ways which are technically better but not practical for common situations that players see. I have an ugly solution to this problem.

Units should have two pathfinders, the current pathfinder and a short ranged efficient pathfinder. If a unit is told to move to a location it should first check whether there is anything blocking a straight line path from itself to its goal. If it needs to turn to face its goal it should be able to figure out its turning circle (or have a unitdef setting so game devs can guide it) and take that into account. In short it should assume the terrain is completely flat and then calculate the best path to the goal (part of a circle then a straight line). Once it has this path it would check it for blocked sections. If there are no blocked sections it should use this path, if there is some blockage it would revert back to the current pathfinder.

The aim of this is to improve player experience when it comes to issuing short move orders. People like responsive units and a short move order means that the player wants the unit to move directly towards a point. Units that oversteer or move along 8 directions over short distances feel very unresponsive. It is hard to micro such units.

This may even result in a performance improvement as many move orders are given close to the unit.
0 x

User avatar
code_man
Posts: 260
Joined: 19 Jan 2014, 13:10

Re: Movement

Post by code_man » 10 Dec 2014, 16:30

I observed something similar i think.

Would be nice if it were improved sometime.
0 x

Post Reply

Return to “Game Development”