Dark Kingdoms

A project in which I am exploring large-scale, autonomous battles. The main trade-off I have used to allow massive battles without extreme lag is turn turn off all physics collisions between units. The unit prefabs do include colliders, so that they may be picked up by Physics.2D.OverlapCircleAll() (which I use for finding enemy targets) but they don't actually collide with each other. This means they run over each other and get packed pretty close together, not the most realistic situation, but I think it still looks pretty decent and battle-like. There is also no animation for movement or battle. Once I learn the basics of Unity animation, I will add some simple animation and see how it impacts the scale I am able to achieve. Each unit includes code for controlling its own movement, targeting and attacks.

• the prototype can handle 200 v 200 battles before starting to lag
• sliders for choosing army units automatically adjust to allow a maximum of 200 units per army
• I use Physics2D.OverlapCircleAll() to get enemies within visibility range and then choose the closet one using Vector2.Distance()
• a number of movement strategies are implemented, including random, march and moveWithinDistanceOfTarget
• random movement is not completely random, it includes a stride attribute which tends to keep units going in the same direction, occasionally changing direction, for more natural looking wandering
• armies are setup at the beginning in rows of 100 units, melee in front, archers in back.....or will be once I get the kinks out
• Check out the code in the project repo.....Dark Kingdoms

It's been a few releases of Unity since I first implemented this. Added some major performance improvements and some movement tweaks

• simply turning off all Physics2D collisions for the layers of both armies allowed me to scale up to 800 v 800 with no lag, 1200 v 1200 with a little lag, an amazing performance win even though there is no actual collision going on between units
• I tried replacing Physics2D.OverlapCircleAll() with Physics2D.OverlapCircleNonAlloc() but I didn't really see any reduction in lag
• updated "move to target" algorithm so that units now move directly toward their target rather going on a diagonal and then straight. See my code gist for details....... mvt_stayWithin()
• added small per-unit variance in movement speed, now the armies look much more natural as they charge at each other. I love when a simple idea adds a lot of depth to what you are working on
• I need to update the sliders to handle the larger army sizes (I currently just hacked my army spawner to get bigger armies) and that will fix the troop counters on the battle page

v1.02 Feb 22, 2018

Big Features

• updated armySpawner with functional, if not pretty (partial rows are not centered, orcs and archers potentially mixed in center row), support
  for multiple rows of each unit type
• added initSliders() in orcTeam.cs which automatically initializes the orc slider to be 75% of max army size and the archer slider to be 25%
• pushing army limit to 2000 vs 2000
• increased battlefield size to accommodate bigger armies
• added WASD camera movement
• Implemented dynamic visibility. Start with small visible ranges for units (archer = visibleRange = rangedRange = 2.0,
  warrior = visibleRange = 2 * meleeRange = 0.6) and increase range by 1.0 anytime they see fewer than 5 enemies, up to a maximum visible
  range of 5.0. The goal is to reduce the overhead of searching for enemies when the battle is at its largest, and gradually allow units to look
  farther out for targets when the battle begins to thin out. Added a 'blooded' orc stat to prevent dynamic visibility from increasing visibility
  range while units are still marching to the battle. `blooded' is set and turns on dynamic visibility once an orc has damaged someone. I had to
  be fairly aggressive in increasing visibility range since looking for targets is triggered by warrior/archer_impl(), which is currently repeated
  every 1.5 seconds, while moving happens continuously in update(). Get too lazy with visibility increases and the orcs walk completely out of
  range before the larger visibility range can pick up anyone new.

Internal fixes, cleanups and optimizations

• got rid of 'used' field in unit in armySpawner, instead added unitType 'none' to indicate empty unit spot in army array,
  this let me change armyArray from a struct array (all it contained now was unitType) to a unitType array
• Tracked down my issue with overLapCircleAll() not seeming to pick up changes in visibilityRange. The values set for orc stats in the editor
  seem to override the values set when the stats are declared, so I simply deleted the initial stat values in script and went with editor values
• switched Vector3.Distance() for Vector2.Distance()
• I tried removing the rigidbody from my unit prefabs, since I don't really use them, but, if anything, it seemed to make lag worse
• Moved applyDamage() to a new script, interaction.cs, which will hold all inter-unit methods. Replaced SendMessage("applyDamage") with a
  direct call to applyDamage() (after getting the component) because I read SendMessage() has horrible performance, even though my lag
  when battle actually starts isn't too bad right now, it's the marching that's lagging.
• Got rid of GetComponent() calls to get script references to scripts on the same object and instead linked the scripts to a public variable
  in the editor.
• removed init_archer_stats.cs and init_orc_warrior_stats.cs, moving their functionality into archer.cs and orc_warrior.cs
• I tried replacing transform.translate() inside Update() with RigidBody.MovePosition() inside FixedUpdate(). MovePosition() was only able to
  handle 400 vs 400 before lagging horribly.

v1.03 April 7, 2018

Visible changes

• scaled unit size down by 50%, for two main reasons
  • see if it would improve performance any....it did appear to remove most of the lag that was still present
  • make room for X placement variation (see below)
• added a small amount of variation in the unit instantiation x coordinate, to get rid of the columnar look of the armies as they charge at each other
• implemented a random movement after a unit kills his target to do a better job of keeping units on the front-line where the fighting is
• archers are a bit over-powered right now, trying to balance it a little bit
  • reduced archer health from 25 to 20
  • investigating adding armor stat
  • reduced archer initiative from 0.7 to 0.4

Under the covers changes

• some minor tweaks dues to the reduced unit size
  • the reduced unit size made melee units look too far away when they were fighting, so reduced melee range from 0.3 to 0.2
  • reduced unit movement speed from 0.4 to 0.3
  • removed movement delay after killing target. With random post-kill movement, it was no longer needed and getting rid of it opened up the front-line a little bit for a more chaotic look
• reduced invoke repeating delay for targeting code from 2.5 to 2.0
• consolidated duplicate targeting code in orc_warrior.cs and archer.cs into targeting.cs
• moved setting blooded from when damage is dealt to when an enemy target is found. This eliminated the last few battle deserters that were losing their target before they could do damage (someone else killed their target) and were wandering away because they were not blooded (meaning their visibility range was not dynamically increasing). Now, dynamic visibility is turned on a soon as a unit has found an enemy target, allowing visibility to increase and drag them back to the battle should they start to wander away.
• introduced a new initiative formula
  • old formula : baseInitiative + random(1.0 - initiative)
  • old formula simply added a bit of randomness to the attack speed of units
  • while playing with initiative to try and balance melee orcs and archers, I decided initiative should matter a lot more. I wanted a unit with twice as much initiative to attack approximately twice as fast
  • new formula - baseInitiative * (1.0 - initiative) + initiative + random(1.0 - initiative)
  • here is how I came up with the new formula
    • I felt the current attack speed of once every two seconds was a good speed for orc warriors, whose initiative is 0.7
    • so I came up with a baseInitiative value that led to approx a two second delay for an initiative equal to 0.7, using a formula that scaled with initiative : baseInitiative * (1.0 - initiative)
    • however, looking at the delays for various initiative values, I decided, that delays should not spread so widely as initiative changes, so I added initiative back into the formula, increasing the delay for large initiatives and decreasing the delay for small initiatives, to narrow the delay spread a little. baseInitiative was updated to keep a two second delay at 0.7 initiative : baseInitiative * (1.0 - initiative) + initiative
    • I like the small randomness in the final attack speed that is based on initiative, so I kept that in the formula as well : baseInitiative * (1.0 - initiative) + initiative + random(1.0 - initiative)
  • initial test results are very promising
    • testing 2000 melee vs 2000 archers, the melee won with about 400 survivors, melee numbers were high enough to close and overwhelm the archers
    • tests of 1000 vs 1000 and 500 vs 500 were always won by the archers, they were able to cut down the melee quick enough to prevent being overrun
    • tests of 100 v 100 were mixed and seemed to depend a lot on the randomness of battle
    • tests of 1800 vs 1800 resulted in some very even fights
    • results of default battles (1500 melee and 500 archers on each team) looked very cool, with a decent number of melee units on the team currently winning being able to survive and break through the lines to engage enemy archers

v1.04 April 22, 2018

Big changes

• replaced orc warrior sprite with a new image which had a good sprite sheet
• added change of sprite based on the direction the unit is moving - orc warrior only so far, need a good archer sprite sheet
• added attack sprite animation

Under the covers changes

• reduced movement speed from 0.3 to 0.2, they were still too much like ants running around
• Solved "negative still alive" issue. It seems Destroy() takes some time to actually destroy the object and it was allowing calls to applyDamage() even after Destroy() had been called on the object, resulting in objects occasionally being "killed" twice. Solved it by setting a boolean when the object it going to be destroyed, and having applyDamage() return immediately if the boolean is set.
• set canvas on troop selection scene to scale with window size
• anchored text on combat scene to top left corner

v1.05 April 28, 2018

• learned how to use Unity animators and replaced my manual manipulation of sprite images with animators
• added unit animation for idle, running and attacking...still only for warriors
• added animation state machine and code triggers
• added support for both animated and non-animated units
• added checkbox to turn animation on/off
• rendering is stuttering a little bit at 2000 vs 2000, but not too terrible. 1500 vs 1500 is still running quite smoothly