For newnet, we need determinism, and the old multiprocessing framework for path-finding where paths were generated in a separate thread at its own leisure breaks that.
However, running path-finding in lock-step with the main thread introduces a very narrow bottleneck in the game that we will always be fighting against. Even if we fix path-finding performance today, we will run into problems tomorrow, when path-finding has become more advanced. So I am proposing we instead send path results over the network, and let the path-finding thread run free again. The problem with that is, of course, the size of paths. Currently each step is a Vector2i, or 64 bits. This means that pathing from one side of a max size (250) map to the other requires us to send a 2000 byte array for the path - and that is if it drives straight ahead. Most paths will be much smaller, though. The best solution to this problem is to compress the path when it is sent over the network. Since paths are now contiguous, all we need is the start coordinates (64 bits, and we have those already), and a 3 bit per tile to indicate the direction of the next tile. This will compress the above mentioned path from 2000 to 75 bytes. Most paths will fit in a single uint64_t (up to 21 tiles). I do not think it is a problem to send this amount of data over the network. Anyone see anything objectionable about such an approach? - Per _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
