I mean, the issue with multithreading is not how to run the code but accessing all of the shared resources once you do. There is no magic bullet.
Regarding the other, picking a path of points is (to me) an AI thing. Walking to a point on the path is probably a system… if you decide to model steering that way. Personally, I kind of consider input to the steering system as part of the AI “state machine” also. Even the idea of continuing to the next point on the path (or selecting what is the next waypoint) is probably an AI decision.
Well on one hand using systems provides an easy and standardized way of game logic and it is needed no matter the view (3d, 2d, ascii terminal). On the other hand the server wouldn’t fully care about the walking state or if he does he would probably rather exchange the position and keep the rest internal.
I don’t know yet how useful things like “unit is stuck”-callbacks etc would be, or storing information about how long the unit is stuck in the relevant component, but the main point is that those systems should be separated (steering, navmeshing), so it doesn’t matter that much if my steering is a System or an AppState or something different.
All of this is happening on the “back end”. The “server” is very much concerned with where the game objects are and so will be managing that. It’s definitely a “system” that is moving the entity around.
Whether your steering is done in the AI system or your AI system is dealing with steering-primitives which are handled in a separate system is more of a game-specific thing. But some system will be doing it.
Sorry for digging that old question, just wanted to share my two cents. I had to almost completely drop the very 1st es based prototype due to the fact that it had visual and logical stuff mixed in a way that I had to rewrite probably 90% of it. So this “simplicity” you mention must be treated with care, it is relatively easy to make up a walking Frankenstein and have a nice headache trying to decompose it while keeping it alive then. Now, besides it’s not split into client and server yet, when I create a new component or system, I mark it and put in the package that I’m 100% know belongs to where - to the view or to the logic. For instance, when some logical, but visible for player object is destroyed and has to explode before it disappears, I create a new entity with one dedicated strictly to this visual part “explosion” component (containing explosion parameters like position, size, duration etc.), and have a system that is pure visual one, that takes all such entities, emits particles at necessary location for necessary time and then removes them. This may look like some overhead, but this way this system and this component are completely decoupled from logical (or “server”) part and so, when it will come to separation, can be easily detached and put to client. Or thrown away and replaced with some other visual thing I’ll invent by that time. I mean if you find it easier to process some visual stuff via components, make sure that they’re well separated (some data probably will be copied from logic, but anyway).