Community for the Sphere game engine

New? Contact Us to register an account!

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:

Code: [Select]

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.

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 guess to me I don't really see why this would be all that different than if you used the name of a person that had been destroyed in a previous map in the 1.5 API.

Now that I think about it some more, splicing maps together like this actually seems like a hack.  It's essentially an optimization to avoid loading the whole map into memory at once, right?  Which makes sense, but wouldn't it be better--and simpler--to solve the problem in the map engine itself (whether in script or native, OO or otherwise), where if you have a huge map, the engine can automatically load and unload pieces of it on demand, just like how, when you have a huge, multi-gigabyte file, opening it in hex editor is instantaneous because it only loads a few KB at a time.

That said, the Sphere map engine is very lightweight: a map is essentially just an array of integers, a tileset (usually not a huge image) and some entity data.  Even a 1000x1000 map is about 4MB worth of tile indices and a single tileset.  There's basically no benefit to streaming it from disk when you have multiple gigabytes of ram to work with.