+1slogic wrote:Concerning pathfinding algo. While designing new pathfinding algo I beg you to consider adding ability to pass custom 2D maps which indicate weights per sector/edge (depending of your measurement point) into new pathfinder processor. It is needed, for example, for putting over a threatmap layer on current pathmap. So, new algorithm will be available via AI API. Also I would like to be able to set some threshold value over custom 2D map which indicate pass is not reachable while summarizing all weights of sectors/edges a path is crossing.
Before my life took over I was working on a widget-based threatmap system for creating "safe" paths through enemy regions. I would rather work with the engine than have to constantly fight it. Please consider that:
* Just because a path is efficient doesn't mean it's safe to travel,
* Just because a unit is small, doesn't always mean its pathing is less important (it may be a command unit, it may be retreating...).
* Just because most mods use TA/RTS gameplay, not all will.
I realise a pathing algorigthm should be in C++ for efficiency. What I'm asking is that every time you feel tempted to create a constant please consider making it a Lua parameter or callback instead (use caching if you have to, but don't hard-code values).
Here are some values that make sense to be Lua-configurable (via widget, gaia and AI interfaces):
* let authors/players set a unit "path priority" programmically and independently from "mass". Examples: a special unit that "barges" through groups. A "plague-carrier" that other units always avoid. A unit programmed to move "urgently" that receives priority. An injured unit retreating back through friendly lines. A bulldozer that breaks through enemy units and barriers. A train or high-speed vehicle with limited stopping power.
* let authors/players set or overlay a flow value for a square or path. Examples: Repulser fields, threat maps, preferred paths, "no standing" zones like landing pads or future building sites, signals and roads or rails in a road/rail-based movement simulation (like the vehicles in the 90's tactical game Syndicate Wars).
* let authors/players set a "leash" for a unit to determine how far it can stray from the most desirable path when that path is temporarily blocked. Examples: fast scouts have a long leash, vulnerable units like artillery have a short leash. Vehicles/objects locked to a path (on rails)
* let authors/players control unit facing relative to the requested destination. Examples: You have an artillery unit with a forward-facing weapon or a tank with weak rear armour and slow turning rate that you would prefer not to turn around unless absolutely essential. A unit on rails that can only turn with the rails.
* let authors set whether a unit can reverse and make sure the pathing algo allows for it.
* let authors/players control/disable unit bumping per-unit. Examples: You position a unit just outside an emplacements' max range, you don't want units behind it bumping it into the enemy's range. A vehicle on rails that can't be physically bumped off the track.
* let authors/players control unit movement under certain terrain conditions. Examples: hill/cliff-climbers, sticky bogs, slippery ice, mine-fields.
* allow movement rules to be changed at any time. Examples: units with movement modes, units that transform, amphibious units, aircars.
* allow a unit to reserve multiple "footprints". Examples: You have a massive walker with a huge footprint (eg: Titan, AT-AT). you'd like units to pass underneath but you still want the feet blocked.
* allow footprints/flows to be changed/reserved from a lua unit script. Examples: You have a massive walker, as part of this units walk animation you'd like units in it's path to get out of the way of where the foot is going to come down so the walker always has a clear path for its next step.
* turn off pathfinding altogether or switch to custom algo for all units. Examples: direct unit control only, game/editor with no moving units, AI with custom pathfinder, saving CPU cycles on an air/space-only simulation.
* allow for fire-platforms. Not many mods use this but it's a great feature that shouldn't be broken. Examples: A unit has a small base, but a large/long turret or load - it needs more space than the base unit. Its mass changes if the turret/load changes.
Some of the options above would require 2 settings. One setting is the value or value modifier. The other is a mod setting to allow/disallow players to change the value (to prevent cheating or unrealistic movement).
As a mod author I've run into the problem of hard-coding pathing in the past with SupCom. It's frustrating when you're trying to set a special pathing behaviour to have unseen hardcoded engine behaviour create a different outcome. Just because many mods will never want their own pathing doesn't mean the flexibility shouldn't exist.
I realise of course that flexibility like this is more work, more code, less speed. Regardless, the ultimate purpose of the engine is to enable the creation of new, original games and hard-coded limitations go against this purpose by pre-determining the game rules.