Skip to main content

News

Topic: Abstracting Sphere's Map engine person objects (Read 4770 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Abstracting Sphere's Map engine person objects
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.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Abstracting Sphere's Map engine person objects
Reply #1
Just as a side note, but for regular sphere I've been using this wrapper for most entity API related things:

[gist=e7c11cc7fe187f634d0e7b9f0ab7873c][/gist]
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Abstracting Sphere's Map engine person objects
Reply #2
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;
}

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Abstracting Sphere's Map engine person objects
Reply #3
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Abstracting Sphere's Map engine person objects
Reply #4
My Person object actually has an update and render method so it can be used as a thread.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Abstracting Sphere's Map engine person objects
Reply #5
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here