clayote
commented
2 years ago My current thinking is that there should be a new kind of action, say @thing.action.travel, which is expected to return a destination (Thing or Place). After all actions have been run, any travel actions do their pathfinding all at once, and the resulting paths are scheduled in whatever order their corresponding actions ran in.
Using a process pool for this is still an option, though I expect a hard programming challenge from that approach -- each process would need its own copy of the graph in question, kept synchronized to the core. It might be better to write a tiny server program for it in Rust so that I only have to synchronize the one copy. In the long term, I could move more of LiSE's data model into that server, so that copying doesn't need to happen.
People are going to make Dwarf Fortress clones in LiSE.
The limiting factor on Dwarf Fortress' performance is its pathfinding, often by hundreds of entities per turn, and it's all done in the same thread.
LiSE games shouldn't need to do it like that. Each game should instead have some number of processes running in the background that contain mirrors of one Character or another, which can find a path in that Character for you on request. That way you can submit a pathfinding request and wait for the path in a thread while doing other stuff. The mirrors should be synchronized with their Character every time the branch or tick changes.
The game developer really shouldn't have to think about threads, though, so there should be an API for action functions to be used in rules that need paths found before they can run. Then LiSE will find all the required paths every turn before any actions are executed, then pass them into the action functions that need them, and it will take advantage of parallelism to find as many at the same time as the hardware allows.
It might even be a good idea to let the pathfinding pool run as a server without the rest of LiSE attached, and permit LiSE to connect to as many of those as the user likes.