Boreal

The way things are nowadays, it's about neither.  RAM space is mostly negligible unless you're dealing with large images or sounds.  CPU's are generally very fast unless you're doing very intensive calculations.  The biggest issue is memory bandwidth and transfer speed.  So the best way to make performance gains is by optimizing your cache usage, for example by storing data that you are going to iterate over contiguously and writing SIMD-like code.

The thing about chess is that it has a huge, significant metagame at higher levels of play.  The strategy becomes less and less focused on individual pieces and even your own tactics, and more and more focused on anticipating your opponent's strategies and also throwing them off so they don't anticipate yours.

Practically, yes.  You could do something dynamic but it would be very difficult to do it without taking up too much runtime or being too random.

If that was the case, I'd design each NPC's state to be a function of time, so pathing and performing certain actions depending on the time of day.  This is looking at it from a Game Maker perspective, of course, where background simulation is not really viable.

I'm actually creating an open-world game myself in C++, and I'm planning on simulating all NPC's procedurally in the background at a very coarse level.  This will involve approximating location and changing their state depending on significant events or interactions, but not simulating them down to the physical level as they would be were they in view.  More important NPC's will be simulated more accurately, for example, story-significant characters or unique monsters.

For a simple case like this, synchronization probably won't be necessary.  However, if you wanted to have a more general synchronization system, you would have to be able to map client side instances to server side instances.  The simple way to do this would be to keep a ds_map on the client side mapping the server side ID to the client side ID.  The server would send its instance ID when the object is created, and the client would map that to the instance it creates in response.  The server can then send generic updates for position and velocity along with the server side ID, and the client can map that ID to set the position and velocity of the correct instance in turn.