That said there currently is no way to exclusively draw a map wherever you want. It'd be nice to treat maps like a standalone object, such that you can muck with it's properties after loading, and draw portions of you choice of the map, wherever, whenever. That's quite hard in Sphere since you are limited to one map per screen. There are double camera tricks, but it can only happen on the same map... unless you write your own map loading call.
I want an engine where I can load up and string maps end to end, with some dynamic calls. Allocate some maps, and deallocate those of which that are out of screen, and then reload them when you are near again. I used this tactic in other game engines to create 'infinite' maps. Maps without borders, but are loaded by stringing maps end-to-end dynamically. The performance benefit is obvious here since you aren't loading a 999x999 sized map all at once.
See, if I were writing an engine like Sphere
from scratch (i.e. without a base to work from), I almost certainly would have done the map engine in script and included it as a system script (I probably wouldn't have chosen JS though, Lua would have been my first choice I think). But, knowing what I do now, I'd want a default map engine of some sort built into the engine. An additional RequireScript() doesn't sound like much to you or me, but let me just say from experience, it's a big deal for someone just learning Sphere. The first time I used Require/EvaluateScript in a game was something of a rite of passage; it was like I was graduating from "Sphere novice" to "advanced Sphere guy".
Don't underestimate the value of being able to do a ton of stuff without importing a single external script--it's empowering and is, in large part, what's made Sphere so approachable over the years.
Moving on: Regarding your ideas, let me just tell you a story. Everyone
thinks they want an object-oriented map engine, but I actually wrote one years ago in C++ and I hated using it. NPC management was a pain in the ass, and just in general, putting together a working game required a bunch of tedious micromanagement of entity objects. This wasn't a fault of the map engine itself--it was quite powerful--but simply that encapsulation isn't well suited to managing a map engine with all its various interconnected components. In minisphere for instance there is very much a circular dependency between the map engine and persons manager that makes it hard to fully componentize.
What it basically comes down to is that OOP relies on the assumption that, as long as someone, somewhere, holds a reference to an object, that object remains valid. So now, assume for the sake of argument that you do this:
var townMap = new Map('MarketTown.rmp');
if (/* some condition that triggers this guy being there */) {
var traveler = new Person("Some Guy", "TravelingSalesman.rss", map);
// or maybe: townMap.createPerson(...)
}
// some more code and somewhere along the way, a reference to the traveler object is stored
// and persists past map destruction
The problem is, if `townMap` gets unloaded somewhere along the way, `traveler` is implicitly disposed and it's no longer safe to use any references to it. Even though the object that holds the reference may have no way of knowing that. This is why I like Sphere's system of decoupling persons from maps and referencing them by name: If all you have is a name, there are no assumptions that the person exists at any given moment, and it's then natural to call DoesPersonExist() first to check. `person.doesExist()` is more awkward is totally against the OOP philosophy: The fact I have a reference at all and haven't explicitly disposed it
should automatically mean it exists.
The alternative, of course, is to make Person objects completely independent from Map objects. But at that point we're essentially back where we started, just with some fancy constructors tacked on. And it's *still* not safe for the map engine to automatically destroy them since even in this case, object references are being passed around.
Being able to load and chain together multiple maps via independent objects would be nice, of course, I'm just not sure it's worth all the headaches.