Moved the Sphere 2.0 changes onto a separate branch (sphere-2) and force-pushed master back to 3.3.0.  If anyone has a clone of the repo with post-3.3 commits, it might be a good idea to reset your local copy.  While I'm still going to go forward with the changes, I'm not entirely happy with breaking backward compatibility (yes, I'm indecisive, I know ) and want to see if there's a way I can keep the old functions and still layer the new API on top.

A big part of this is that Specs relies pretty heavily on RequireScript, and the current minisphere 4.0 code removes it in favor of require().  CommonJS semantics differ quite a lot from Sphere 1.x so I would have to restructure all of my scripts, which is quite an undertaking.  I imagine Radnen is in a similar position with Blockman.

Here's a sneak peak at what the Sphere 2.0 API may end up looking like:
https://github.com/fatcerberus/minisphere/blob/master/src/engine/pegasus.c

I can't believe I just put together that the screen is basically another surface. Internally is that how you treat drawing?

Yes.  In Allegro the backbuffer gets an ALLEGRO_BITMAP pointer like all other textures, so it's easy to treat it the same as a surface.  Which is great, because it means you basically get render-to-texture in the API for free (just pass in a Surface object instead of screen).

So the result of all this, is that the Sphere 1.x API is being deprecated wholesale in minisphere 4.0, but will still be available, including map engine, so existing games will continue to run as before.  New games should instead use the new API exclusively, which is enforced by disabling the 1.x functions when a 2.0 manifest (game.json) is present.

For Color objects in Sphere 2.0, which scheme would be preferred for component properties:

Code: (javascript) [Select]

// Abbreviated components
color.r
color.g
color.b
color.a

-OR-

Code: (javascript) [Select]

// Sphere 1.x style
color.red
color.green
color.blue
color.alpha

I personally like smaller names, so I vote for r, g, b, a.

Here's the documentation for the next-generation Sphere API:
https://github.com/fatcerberus/minisphere/blob/master/docs/spherical-api.txt

I decided to leave text rendering in the core.  RFN fonts can be loaded and rendered in script easily enough, but since I eventually want to support TTF fonts, there will need to be text drawing code in the engine anyway.

Progress report:
I started on the new JS map engine about a week ago.  Currently I can load .rts tilesets and draw individual tiles from them using Galileo.  I haven't done much more than that because I'm still trying to come up with a workable object model for it.  The main thing I keep getting hung up on is figuring out what the relationship should be between Map and Person objects.  Do we have it where Persons only have an X/Y value and are then added to the map they are on, or should the Person refer back to their containing map...?  Some combination of the two?  This is why I was so averse to the idea of an OO map engine, it's not always obvious how the different classes should relate to one another.

I guess one strategy would be to look at how other OOP systems with a high degree of interrelation (e.g. WinForms) handle cases like this.

Just glancing at the Person functions in the API on the wiki, I see a lot of potential for going either way. For the function "GetObstructingPerson", for instance, it could make sense for that to belong to the Person, in which case we'd have the Person go to the Map to find that information. If we put it in the Map, though, we end up keeping roughly the same signature for the function, where we have to pass the person we're asking about in.

I'd say that if you put functionality in Person for interacting with other Persons, Person would need the Map reference. However, the only Person-Person interaction seems to be obstruction and talking,  and obstruction also has tile obstruction. Unless you're planning to add more Person-Person interactions, it seems like just having Persons carry their own internal data and be added to the map they're on.

Persons were associated with their initial containing maps unless they were set to persist_on_destroy_map, e.g. CreatePerson's last parameter. For v1 behavior keep it like this, but feel free to choose to keep entities independent of maps in the v2 redesign.

One of the reasons I want to make entities independent objects is, it makes relocating entities at runtime a lot easier.  For example, teleportation.  In Sphere 1.x this is traditionally implemented by creating a persistent Person for the player character, and calling ChangeMap() to switch to the destination map.  The teleportation process is inseparable from the process of changing maps, which isn't always optimal.  In the system I'm envisioning, any entity can be relocated to a different map simply by changing its current location.  When a map is drawn, only those entities who are currently on that map will be rendered.

This system is nice because it allows not only the PC, but also other entities to be transported as well using the same mechanism.  You could allow NPCs to use doorways, for example, and the teleports would be fully functional for them.  In order to ensure the player character doesn't teleport out of existence, there should be a system where the person to whom the camera is attached is followed by the engine: If their location changes, the engine follows them to the new map.  This saves the duplicate effort of setting the PC's location and also changing maps, but also allows the camera to be refocused on any other active person at any time, even if they aren't on the same map.

Now I just have to stop being lazy and actually implement it...

Are you saying if you focus the camera to a person on another map, we wold change maps? That would be very nifty. (Of course we can already code things around to do this in Sphere, but native support is always nice).

That's the idea, yeah: The camera concept is extended to not only encapsulate an X and Y value, but also which map you're on. So if the PC changes maps, the camera follows them automatically without having to call ChangeMap (or whatever the equivalent would be).

One situation where I think this will be really useful is cutscenes that switch between several maps, for example flashback sequences.  You could just place all the NPCs on the correct maps ahead of time and switch between them just by changing the camera focus.  Actual loading and unloading of maps could then be implicit, managed by the engine and saving the user from having to worry about it.

And it would be easier to track entities that move between rooms, like NPC's that enter and exit buildings based on set paths. Again, it is possible to do it right now, but it'll be a small coding nightmare to track it all on top of the engine since you cannot rely on the map engine entities.

Just to be clear: entities that exist on maps now no longer get destroyed, right? Despite the default behavior that they destroy when the map exists, they will stay in memory until you recall that map. I'm trying to wrap my ahead around how an analogue/persist like system plays into the new entities. We might have to add new triggers to an NPC, such as, map enter and map exit. That way we can move some behaviors from create/destroy that might now  not be invoked.