jrevel

Applied to an RTS game...

There is not only that, Unity uses components from the beginning, but the ECS system is very recent. The difference with the new system is that it is implemented using the Data Oriented paradigm. It is mostly a bunch of good practices that go against a lot of bad habits that OOP tend to give, and that drive performance down. For example, virtual functions is not good to use everywhere, it has a performance cost, a tiny one, but that scales when used for every function every frame. It is quite hard to learn, because it needs to shift our mindset, but it gives a lot of advantages : better performance, but also simpler code with no side effect, and way easier to multithread... And it makes also lodding easier. This book explains it perfectly (but is quite technical though) http://www.dataorienteddesign.com/dodbook/ The problem of that paradigm is that it needs to shift the way we think about entities, and would need a lot of refactoring to implement. But it is possible to isolate portions of code that are slow and optimise it, so it can be done step by step.

I just saw that the sizes of the textures, especially PNG ones, are HUGE. There is an amazing tool called tinyPNG that can help us fixing that. It uses lossless compression algorithms to reduce texture sizes without losing quality. I tried it on some textures, and their size got drastically reduced : Applying it to all textures might be a great optimisation : lower loading time, but also faster rendering.

What is D14 ?

There are some ComputePathAsync functions, but the actual threading/limitation of request per frame still seems in todo : maybe simply putting the processing of paths in a separate thread might help a lot

Hi, I'm new to the forum, and I did not have the time yet to look to the source code in depth, but I have already worked on the pathfinding of a shipped game, and there is a thing that might be important to remember : pathfinding IS slow. Even A* has an exponential complexity, so it must not be used lightly. I believe than we can earn way more performance by trying to call less the pathfinding instead of trying to optimize it, as it seems already quite good. For example, a simple optimisation can be to limit the maximum number of calls per frame to A*. The rest is delayed to the next frame. That means that calls to A* will be asynchronous, but it is still possible to give a movement to the character during the computation. So the character will try to move in straight line, until the exact path is returned. I don't think it will be noticed until requests take more than a few frames to complete. Another optimisation might be to use steering behavior for entity movement, instead of trying to compute the exact path for every unit when the user gives the same order to multiple entities : it is possible to compute a single path for the whole group and apply that kind of algorithm : https://gamedevelopment.tutsplus.com/tutorials/understanding-steering-behaviors-path-following--gamedev-8769 Steering behaviour can be used more globally to simplify path finding : no need to compute collisions when computing the path, the steering behaviour allows to follow the path while being repelled by colliding entities.