Also, an awful lot of what's being calculated does in fact depend on things like position relative to the mob. How hard a mob's attacks hit, for instance, often depends on how far away the player is. How effective the player's attacks are depends on whether they're in front of the mob, off to one side or behind it. Which means in practice you can't avoid that kind of frame-by-frame recalculation using the RP model. Conventional models avoid it by only updating the base numbers frame-by-frame, then doing the full calculations based on the current situation only when needed. Eg. you update the player's position relative to the mob frame-by-frame, but only calculate how effective his attacks are when he actually attacks (with game clients running at 30+ FPS and player attacks happening once every 1-3 seconds, you avoid 30-90x the calculations).
Right. So, a back-of-the-envelope sketch on how you might do this in RP:
* Don't try to have each mob directly checking every other mob's position all the time, since that requires geometric time
* Instead create 'attack' objects which represent attacks in progress. They're only created when an actor pushes the 'attack' button. You probably already need this, since attacks probably have stats linked to them: animation cycles, cooldowns, maybe coordinates of their own if they're projectiles
* Have a container of such pending attacks
* A mob connects to the container and watches for nearby attacks, and only when it discovers that it has a connected attack does it do the damage calculations for that attack
* If the gamespace gets too big, divide it into sectors and attach the mobs and the attacks to sectors, so each mob only has a very short list of pending attacks to scan, and you could parallelise the gamespace easily
Granted there's probably lots of thorny issues here, especially to do with how lightweight all the objects need to be, but the point is that you could use the typical OO-style division of concerns in an RP framework to make it so that everything isn't watching everything else all the time; each object only connects to the event streams that interest it, and there could be a whole network of observers and re-re-republishers that minimise the notification traffic. Much like how we do it on the Internet, where packets get sent to a local switch, but only forwarded on if they're of interest elsewhere. And once you've got that, you could probably scale it right out to the MMO level much easier than imperative OO programming.
The trick is that we need good formal semantics for how all this works. It's nice that we're getting reactive libraries, but I think we need more work at the underlying mathematical layer to make sure that what we're implementing is correct. Something like Kahn process networks is probably the best approximation at this point; what we really want to get away from is the horrible mess that is imperative objects and threads.