Movement heuristic and weight formular has been updated to (hopefully) better handling towers cluster. Moreover, additional pathfinding calculation layer will be performed to ensure the best route would be the most likely one that would be used (rather than having it going back and forth because of silly things, like number of units at the junction cell keep changing):-
- Calculate path from spawn point toward HQ, for each unit type, and without CrowdWeight.
- This path is re-calculated only when the buildings are changed (ie; tower built or moved) and is shared among all units of the same type. (Use separate weight field for each unit type?)
- Cells along this part have ZERO(?) movement weight
- A* calculation performs on units as usual with both normal danger and crowd weights, but use movement weight from (3).
- Crowd weight to be calculated by distance from the origin? With its effect reduced the further the cells are from the origin point, and may double or quadrople when right in the next cell?
Trying glow shader that work with mobile devices and attack effect on the units! Can’t say for sure how this will work out with lighter scene yet. Null pointer bug is now fixed and all units should now use “Reflection/Bump Specular” shader to be competible with new shader effect. Some effect options could also be changed in “Main Camera / Effect Controller”.
As the metronome code from Jorge has not been done yet (far as I know), I do a quick function creating a loop to call all cells in waves. The first “Local Hex Tower” is now working! Well almost, there’re still a few bugs there, but it has fade-out cell color and everything!
Talking to Alex today. He says going to pull the project from me today to get the latest code.
Once the grid coordinate converter and data structures are in place, with just a small bit of code modification, the game is back running again. We lose the ability to automatically measure the coverage of multiple-cells obstacles due to the shape of the grid, but the new level design does not seem to need them anymore as most obstacles would likely be in form of the gap in the floor, which would be filled up by the Hex Grid tool.
Hex Grid Generator
Turned out it’s easier than I thought it would be! A newly minted “Hexagrid/Create Hexagrid” menu is now added to the project. Simply set the grid size, cell height, and click Generate! And you get a neatly arranged hexagon grid cells!
The AI doesn’t work yet though. There is not even the spawn point yet.
The collision now process momentums more appropriately; Velocity after collision is now determined by both weight of the unit, direction of movement, as well as the speed the other unit hit it at. Impatient unit also keep trying to obtain new navigation path to get itself out of the situation.
There seem to be a bug involved division by zero when there are too many units colliding with each other. Have to chase that out later.
Should I try going for Hexgrid implementation, or other AI things first?
(A) Introduce patient and intimidation parameters; Units could now get ‘impatient’ by getting stuck in a single cell for longer than the specified period. An ‘impatient’ unit get its repulsion value multiplied by its intimidation parameter as well as reduction to other unit’s pushes, allowing it a greater chance of breaking through a blockade.
(B) Implement collisions list to keep track of which unit is colliding and with who, ensuring the Collision Breaker won’t be executed more than intended.
(C) Take into account the size of the unit when calculating obstacle repulsion force.
PS: Video to be shown in next post.
(A) Implemented unit collision and break algorithm using critical distance calculation; If two unit’s critical radius collide with each other, the emergency velocity diversion function is performed. The function will remove all velocity from direct collision course between the two units. It does this by projects each unit’s velocity onto a vector drawn between the two units. This projected collision velocity will then be removed from the unit’s velocity itself. Which force the unit to either divert away (if original velocity is not in direct collision) or stop moving entirely.
(B) Refactoring forces result from the difference functions to work better together, by treating the force as the targeting velocity itself rather than just velocity’s direction. Obstacle repulsion and target attraction are now both clamped to the same size, so that the only way for there to be a “sinkhole” would be if there is an obstacle directly between the target and the unit. After which, the unit’s attraction and repulsion is layered on top of the balanced equation, ensuring the push from movable units take priority.
This equation however seem to result in another “sinkhole” at the entrance of a balanced “tunnel” with obstacles on both side. Perhaps the targeting force should get a booster to always be higher than obstacle avoidance?
(C) Obstacle repulsion calculation is now performed as part of the background loop function in GameNavigator rather than calculated individually every frame by all units. As obstacles are near constants, delay of a fraction of a second should have little to no impact.