Missile Dodging / Dancing

[FeXoR]

There is no concept of momentum in 0 A:D.. And IMO there shouldn't be.

Instead arrows should be acting like missiles IMO so not the way things act (momentum for units, pure parabolic arrow path's) but the outcome is what's about realistic (units are hit with a specific probability, maybe dependent on distance - though "always hit" wouldn't be as bad as "can always be dodged" IMO).

And, yes @Sundiata , part of the problem is the simplistic unitAI's targeting but the above approach would "solve" this (yea, also not very realistic but it's the outcome what matters most IMO and it's doable even if the arrow path's might not perfectly correspond to the hit unit's position).

Also I agree with @wowgetoffyourcellphone (just there have been several attempts to implement this and none of them where really pleasing IMO).

[amanita]

The unit grouping object could keep a value which increases every frame the group turns but also decays every frame the group doesnt turn. This value of 'how much has the unit zig-zaged recently' could cause the group to pause an number of frames on each turn depending on how high it gets. The decay rate and pause factor could be set subtlety so that fast reaction and limited dancing is unaffected, but extended dancing causes just enough pause to frustrate the tactic.

Edited December 21, 2018 by amanita

[soshanko]

its a clear abuse of the bug. however people call it micro. It has no connection with RTS. Although a dancing league can be arranged to award the top 0ad dancers. Also suggest a special lobby for the dancers. lul.

[wowgetoffyourcellphone]

8 hours ago, soshanko said:

Although a dancing league can be arranged to award the top 0ad dancers

[Lion.Kanzen]

break dance battle.

 

[Trinketos]

 

[Radagast.]

On 12/21/2018 at 6:45 AM, amanita said:

The unit grouping object could keep a value which increases every frame the group turns but also decays every frame the group doesnt turn. This value of 'how much has the unit zig-zaged recently' could cause the group to pause an number of frames on each turn depending on how high it gets. The decay rate and pause factor could be set subtlety so that fast reaction and limited dancing is unaffected, but extended dancing causes just enough pause to frustrate the tactic.

Interesting. Any reason not to update the "value" every move command instead of frame? Could take coordinates' offsets into account to filter double clicks, redundant script/AI commands with similar coordinates.

Then include this "value" in speed calculation. Remainder as is.

First issue: looks like simulating momentum and @FeXoR said there shouldn't be such phenomenon. Would you mind explaining?

 

On 10/23/2018 at 6:25 PM, wowgetoffyourcellphone said:

If we had battalions this would all probably be a moot discussion.

I thought those battalions had been shaped quite nicely already some time ago. What's the blocker? There is a lord that hides as a butler :-) that surely knows @stanislas69

 

On 10/15/2018 at 10:40 AM, Thorrky said:

Talking about realism: what about a formation of cavalry juking arrows at long range? That seems more than historically plausible, especially for lighter skirmisher cavalry. 

Sounds like a subtle change. In reality reaches very far. It requires debating whether to give a unit more autonomy to reduce micro or not.

This has been a point of diverging opinion before. I personally advocate more self-responsibility. Not necessarily per unit. Rather per commander for performance! There usually are far less officers.

This comes closely with battalions though, both something more than just me have worked on several times before. Me at least never managed to finish. Pity! Promises so much more depth to strategy and atmosphere.

[amanita]

On 1/17/2019 at 1:54 AM, Radagast. said:

Any reason not to update the "value" every move command instead of frame? Could take coordinates' offsets into account to filter double clicks, redundant script/AI commands with similar coordinates.

A little simpler conceptually to decay a "group_has_zigzagged_score" every game tick, but if recording last update time it could be updated only when needed to see if a group should pause due to excessive recent course changes. I think quite a small patch could do, something along these lines :

Spoiler

function zigzagAssess(group,dest){

  // decay zig_score
  group.zig_score *= Math.pow( game_opt.zig_decay_rate, game_stat.present_tick - group.last_zig_tick );
  group.last_zig_tick = game_stat.present_tick;
  
  if( Math.abs( group.pos.x-dest.pos.x ) + Math.abs( group.pos.y-dest.pos.y )
      > game_opts.zig_debounce )
  {
    // move is not accidental bounce so increase zig_score and calc pause
    group.zig_score += 1;
    group.zig_pause_ticks = Math.floor( group.zig_score / game_opt.zig_is_excessive_factor );
    group.zig_score -= group.zig_pause_ticks * game_opts.zig_pause_recovery;
  }
  
  return group.zig_pause_ticks; // perhaps act on this at return point
}
/*
 zigzagAssess() : to be called where group course is updated
 zig_pause_ticks : perhaps implemented as a kind of course action item that holds 
   still for ticks, or delay normal group travel until == 0
 game_opt.zig_decay_rate : would have typical value around 0.98
 game_opts.zig_debounce : a small distance, around a 'game foot' or few
 game_opt.zig_is_excessive_factor : best value to be discovered, something over 2...
 a complex zig_score made of zig_short_score and zig_long_score with different decay 
  rates might be easier to configure
 game_opts.zig_pause_recovery : could help, would also need discovered eg ~0.2 
*/

 

 

Edited January 19, 2019 by amanita
tweak code

[FeXoR]

AFAIK there was was the concept of "stamina" planned and actually in the game. Wouldn't that have a similar outcome? (Yea, it's also relevant for long trips I guess, not sure if that's good or bad).

@Radagast. Sure! ATM we have speed limits (0 to max speed) and turning limits (-max turn rate to max max turn rate) but our entities don't have a property like mass (and the engine doesn't support such concept AFAIK). Momentum is the mass times the speed and thus isn't supported.

What I guess you mean is acceleration, how how long it takes a unit to increase it's current speed in a given time (e.g. a game turn). That would be something I'd support but guess that would require basically an entire rewrite of the animations code ... not to speak of all animations - so I don't see that coming. Maybe for Part 2?

 

IMO the issue originates by using a physically realistic approach for the projectile's trajectory but not for the unit's motion.

Solving the "dodging projectile" issue is possible in several different ways that doesn't require that big a change. I just mentioned some in my earlier posts. I would consider non of them clean, because they would either broaden the gap between the graphical representation (where the arrow hits) and the outcome in the game (if and which unit is damaged) or be less realistic looking (arrows homing on targets and possible trajectories crossing each other more than twice).

But both would solve the issue and improve gameplay (which IMO is more important in a game than realism and graphical representation as graphical representation may be more important in a film or a picture and realism more important in a physicists theses I assume).