Spherical forums

Sphere Development => Sphere General => Topic started by: Eggbertx on September 05, 2016, 07:09:43 pm

Title: Abstracting Sphere's Map engine person objects
Post by: Eggbertx on September 05, 2016, 07:09:43 pm
I've been working on a simple library to treat Sphere Persons as javascript objects, rather than having to interface with the map engine's functions. So for example, instead of doing

Code: (javascript) [Select]

function game() {
    CreatePerson("player","player.rss",destroy_with_map);
    AttachCamera("player");
    AttachInput("player");
    // ...
    player_obstructed = IsPersonObstructed("player", GetPersonX("player"), GetPersonY("player"));
    direction = GetPersonDirection("player");
    QueuePersonCommand("player", COMMAND_MOVE_SOUTH, true);

etc, which can be rather tedious after a while, you would instead do (as it is now)

Code: (javascript) [Select]

var player;
function game() {
    player = new Person ("player","player.rss",destroy_with_map);
    player.attachCamera();
    player.attachInput();
    // ...
    player_obstructed = player.isObstructed(player.x,player.y);
    direction = player.getDirection();
    player.queueCommand(COMMAND_MOVE_SOUTH,true);

And so on and so forth. This would also make it simpler to create custom update/render functions  and custom properties per-person by doing person_object.update = function() {} as desired
Instead of using GetPersonList, you would just reference the persons[] array.

Do you think this is a good way of doing things? Would the new minisphere API benefit from using this method as opposed to the old way? I'd post this in minisphere's engine update thread, but I wanted to make this thread to ask for your guys' opinions on this method in general.
Title: Re: Abstracting Sphere's Map engine person objects
Post by: Radnen on September 05, 2016, 08:16:32 pm
Just as a side note, but for regular sphere I've been using this wrapper for most entity API related things:

[gist=e7c11cc7fe187f634d0e7b9f0ab7873c][/gist]
Title: Re: Abstracting Sphere's Map engine person objects
Post by: Eggbertx on September 05, 2016, 09:16:19 pm
That's pretty much what I was going for. Just more complete :P
But this is going to be dependent on minisphere, since it uses the threads module, and will likely add other stuff as time goes on. What are the get and set keywords from line 15 on? I've never seen those before. And what is the benefit of defining Actor.prototype as a raw object, as opposed to

Code: (js) [Select]

var Actor = function(stuff, morestuff) {
    this.stuff = stuff
    this.morestuff = morestuff
}

Actor.prototype.getStuff = function() {
    return this.stuff;
}
Title: Re: Abstracting Sphere's Map engine person objects
Post by: Fat Cerberus on September 05, 2016, 11:18:47 pm
It's probably not worth putting too much effort into the legacy map engine at this point.  It doesn't play nicely with, e.g. the threads module and I had to write a few hacks just to make it cooperate.  Even then it's not perfect: For example, calling threads.join() always takes input focus away from the map engine.

For minisphere 5.0 I'd like to write a new map engine from the ground up, implemented in JS, which is fully object oriented and seamlessly integrates with other parts of miniRT (threads, scenes, etc.).  I actually originally planned to do that for minisphere 4.0, but decided instead to use 4.0 as a testing ground for the Sphere v2 API and hold off on more complicated stuff until the v2 API is finalized.
Title: Re: Abstracting Sphere's Map engine person objects
Post by: Eggbertx on September 06, 2016, 01:25:56 am
My Person object actually has an update and render method so it can be used as a thread.
Title: Re: Abstracting Sphere's Map engine person objects
Post by: Radnen on September 11, 2016, 03:55:38 am
I learned that get and set syntax from Lord English :P

It's better than the cruddy .__defineGetter__ and .__defineSetter__ syntax from Mozilla.

BTW, I could have put those methods into the prototype than using ".prototype" each time.