It's not all that difficult to make a basic OOP map engine that is fairly simple to use. I did it, or at least got the rough outline of it as the core of the TurboSphere map engine. It's all object based, and it works pretty easily.
I did make persons belong strongly to maps. It's not that bad a thing to do, it works fairly well.
You don't need to make a doesExist method. You just need to maintain an array of persons for the map. If the person is not in that array, they aren't on that map.
But I also believe that the map engine does not belong as a native, core part of the engine. It's one thing to include one, but it's not a core function. Chad Austin came to this realization before Sphere 1.0 was even released. He decided it would be better to expose a simple but well thought out scene graph and scene manager rather than a rigid map engine.
Both those components are a part of Pegasus. I disagree with some others on the necessity of the scene manager. I think it's fine for this:
function game(){
while(true){}
}
to hang the engine. If we subscribe to a Mozilla-style view of JavaScript, where it is the C or Assembly of the web or our games, we need to trust it with tasks we trust C with. Even like managing the event loop.
Totally agree on that last part.
As for the object-oriented maps, let's consider a scenario:
* As you describe, there is an array of entities that each map exposes.
* Someone takes a reference to an entity from that array, and it gets passed around to a bunch of functions.
* The entity reference is ultimately saved somewhere for later use, despite its volatility.
* The map the entity came from gets unloaded. The entity goes with it.
* The object holding the reference has no idea the entity has disappeared and attempts to call methods on it.
* Game goes kaboom due to unexpected, and therefore uncaught, exception ("entity has been destroyed").
This can of course be dealt with by someone knowledgeable in OOP (don't pass around borrowed references), but let's not fool ourselves into thinking a good deal more vigilance is required. I myself have made mistakes like what I described above. This is the kind of thing that's likely to scare off novices, which is something we definitely DON'T want.
I don't know, I'm starting to feel like I have a totally different view of "what Sphere is" compared to everyone else here. Either that or I'm just better at remembering what it was like to be a novice... Either way, I'm leaving the Sphere 1.x map engine as part of minisphere. The entire engine is less than 2MB anyway, so it can hardly be considered bloat. Ultimately what it comes down to is that I'm a fan of "useful defaults": If someone wants to step outside the box that's fine, but sometimes it helps to know where the box is in the first place.
Maybe some day I'll write a replacement map engine for Sphere in JS. But I'll be perfectly honest, I haven't yet felt the need to do so.
As for the stage manager: I honestly have no clue what the thing is. I saw it when I was perusing the Pegasus repo and even read the code, but I still have no idea what it's supposed to do.