Skip to main content

News

Topic: neoSphere 5.9.2 (Read 521957 times) previous topic - next topic

0 Members and 16 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.0.10
Reply #330

Yeah, that would be trivial to add.  Is there a valid use case for it though?  I try not to add APIs just for the sake of it, trying to minimize perceived bloat.


GetTileName() is impossible otherwise, keep that in mind too.

Actually, if you want to reduce bloat, then it'd be nice to make a method where you get a POJO (plain old javascript object) of the map and it's tileset. You can then modify said POJO, re-update the map, and see the changes.

We can create Sphere 1.5 complacent wrappers around that POJO. This will ad 2 new calls to the map engine and literally remove anywhere between 20 and 50 API calls from Sphere.

Going one step further, it'd be neat to store the map POJO as JSON anyways. It has the added benefit of removing the need for analogue/persist for good (because you can modify the map state and save it into a separate save file with little-to-no effort).

That way, we can create either an in-engine way of handling save games, or someone can make an efficient, and easy to use save system for your games (person entities, maps, etc. are stored as POJO). I say in-engine since many new programmers struggle with saving a game and if we had a small API that's also very powerful, it could aid in bringing people to use minisphere.
  • Last Edit: April 18, 2015, 05:48:32 pm by Radnen
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #331
While it's a neat idea, I think it's outside the scope of minisphere 1.x.  I might consider it for 2.0, however. :)

Also: you don't need SetTileName for GetTileName to work, can't you set tile names in the editor?  I'll implement it anyway though, it'll literally take about 30 seconds.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.0.10
Reply #332

Actually, if you want to reduce bloat, then it'd be nice to make a method where you get a POJO (plain old javascript object) of the map and it's tileset. You can then modify said POJO, re-update the map, and see the changes.

We can create Sphere 1.5 complacent wrappers around that POJO. This will ad 2 new calls to the map engine and literally remove anywhere between 20 and 50 API calls from Sphere.

Going one step further, it'd be neat to store the map POJO as JSON anyways. It has the added benefit of removing the need for analogue/persist for good (because you can modify the map state and save it into a separate save file with little-to-no effort).


This is exactly what my map engine does anyway since it is in script, and I can tell you it really is the way to go. More than half of the code by lines of my map engine is 1.5 functions, and even then I condensed them.
Doing the same for tilesets, spritesets, and persons in particular is a really good idea, too.

Of course, I think the map engine is best done in script anyway...but even so, I suspect just having the 1.5 functions in script at least would go a long way to simplifying the implementation.

This would also encourage the idea of setting up a map object and then running it, instead of weirdly spooling objects, scripts, and persons. I believe this is the ugliest part of the map engine.
  • Last Edit: April 18, 2015, 05:55:54 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #333
I used to hate the Sphere map engine with a passion, but it's odd--reimplementing it from scratch, I've developed a certain fondness for it.  It's elegant, in a "diamond in the rough" kind of way.

I think my only real issue with the way the map engine is set up, is the unnecessary dichotomy between "map engine running" and "outside the map engine" caused by the fact that MapEngine() runs its own update loop.  Every other issue (API, etc.) is merely cosmetic in my eyes.

Really though, I've begun to see the legacy API as Sphere's biggest strength (we've made it this far with it, after all, haven't we?).  Some of the things it does seem... off to a seasoned JS coder (referencing persons by name, loose coupling between persons and map, etc.) but are nonetheless intuitive to someone who just wants to get a project off the ground quickly.  Certainly more so than the morass of objects necessitated by the Pegasus spec.

That's not to say I view Pegasus as worthless, of course--quite the opposite, it's very much a step in the right direction.  I just don't think we need to write off the legacy API as a second-class citizen--it's quite valuable in its own right.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.0.10
Reply #334
Well, I originally wanted to remake the map engine so that the demo would look like this:

Code: (javascript) [Select]
function game(){
    var aegis = new Person("Aegis", false);
    var map = new Map("map.rmp");
    map.addPerson(aegis);
    MapEngine(map, 60);
}


It wouldn't be too hard I think to allow this, too, though:

Code: (javascript) [Select]
function game(){
    /* Rather than `MapEngine(60);' */
    while(RunEngine(60));
}


I still think that style would be better. Being able to call up the list of persons, or just get a person by name, would still be a reasonable thing to do using that style.
It wouldn't even be too difficult to allow passing in a name string optionally instead of a person object.

I agree that the Pegasus spec still needs work. A lot of it overly complex. I also agree that the old API is basically a good design. That's why I've only removed the old old drawing API in TurboSphere. The only major changes I'm really sold on so far is namespacing the API and adding basic OOP to it. Not anywhere near the OOP madness that Pegasus has, just small things, things that should really be properties instead of getters like RawFile.getSize(), and using real constructors.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.0.10
Reply #335
The way I see it, the Sphere 1.5 API is perfect in every step of it's existence, but if you think about it, it doesn't need to be implemented in the engine. Rather, only a few API calls ever need to be exposed and that's the direct interaction with each file type and input/output method. So really you only need like a couple dozen API calls.

1. Maps/People/Spritests/etc. are full JS objects that you can create the Get/Set API from, script side.
2. All objects become normal JS constructors, which you can make the Load*() API calls from.
3. All graphics are ran through a vertex/shape API that you can make the primitives and images API from.
4. All input is handled by global singletons for that game instance, where you can make the input API from (keyboard, mouse, joystick).
5. All files use 1 IO API which you can make all LogFile/RawFile/File API's from.

If you really think about it you only need to expose like 12 to 20 actual, hard coded, necessary API calls to sphere in order to run 90% of the rest of the API. Graphics, persons + maps, IO, input just have to use the few objects exposed to code and that's it.

It'll truly 'unlock' Sphere. It's great because you can then do cool things like:
Code: (javascript) [Select]

// we may have an issue here: how do you attribute people to maps not yet loaded?
function CreatePerson(name, ss, destroy) {
    var p = new Person(name, ss, destroy);
    _current_map.addPerson(p);
    return p;
}

function SetPersonX(name, x) {
    _current_map.people[name].x = x;
}

var p = CreatePerson("fred", "fred.rss", false);
p.items = [];
p.coins = [];

// what a naive implementation of Sphere File Object looks like:
function LoadFile(filename) {
    var p = new File(filename); // basically a raw file, and the only file type ever.
    p.write = function(key, value) { this.writeLine(key + '=' + value); }
    p.read = function(key, default) { // naive method
        var l = this.readLine(); // returns null if EOF
        while (l) {
            var data = l.split('=');
            if (data[0] == key) {
                if (typeof default == 'number') return Number(data[1]);
                if (typeof default == 'string') return data[1];
                if (typeof default == 'boolean') return Boolean(data[1]);
            }
            l = this.readLine();
        }
        return default;
    }
}

// easiest method ever to saving a person
var file = LoadFile("save.txt");
file.write("fred", JSON.stringify(p));
file.close();


TurboSphere is headed this way with it's Sphere 1.* shim. This is really a good idea. Having very few Sphere API calls also increases the fact you get more 'freedom' from the engine. I used to think you could never make a game without Sphere MapEngine... oh how wrong was I. It was just that since it was there, you had access to it and since there was this huge API around it, it made it hard to give the illusion of freedom, but it's there, you had a lot of freedom, but the API never always showed it. Especially when you hit brick walls like enumerating the fields of an image, adding a property to an image, or heck, even getting the dang filename of an image.
  • Last Edit: April 18, 2015, 09:22:01 pm by Radnen
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #336
Haha, I love that comment on the CreatePerson() function.  From a purely theoretical standpoint, the Persons API doesn't seem to make much sense, does it?  That is, until you actually go to implement it.  Maps and persons in Sphere are actually very loosely coupled, which is big part of what makes the system so flexible.  The tendency I think is to always want to view persons as being associated with a given map, when in fact they NEVER are, the map engine just happens to conveniently destroy some of them for you when switching maps.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.0.10
Reply #337

Haha, I love that comment on the CreatePerson() function.  From a purely theoretical standpoint, the Persons API doesn't seem to make much sense, does it?  That is, until you actually go to implement it.  Maps and persons in Sphere are actually very loosely coupled, which is big part of what makes the system so flexible.  The tendency I think is to always want to view persons as being associated with a given map, when in fact they NEVER are, the map engine just happens to conveniently destroy some of them for you when switching maps.


That just goes to show just how much was hidden behind the scenes, the person manager, the command queue, the way edge scripts are detected(!), and the camera, and the player input. Bringing these hidden areas to the forefront can increase productivity, these can be safely exposed in an extended API. Older games just wouldn't know to call these extended functions, but newer games can, and take full advantage of them. I'm still impressed to this day FBNil's ability to know how sphere operates behind the scenes to take advantage of person scripts, delay scripts, etc. in his lithonite engine.
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #338
That's what made getting the Lithonite demo fully working in minisphere such an awesome moment.  minisphere's map engine implementation was as much reverse engineering and extrapolation as it was directly studying Sphere's code.  Which ultimately was a good thing--I can only take so much of the latter activity before it starts to wear on my sanity.  Read the post at the top of page 22 for just one of the many reasons why that is. :P 

But yeah, I was able to extrapolate a lot of the map engine's inner workings from studying Lithonite's tricks.  It was quite fun, actually. :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #339
Quick warning to anyone using minisphere for production use: Don't try to to pass a function to SetPersonScript, it will crash.  I accidentally passed a Duktape context to the internal set_person_script function instead of a person object, so it ends up overwriting Duktape state and everything goes to hell.  SetPersonScript() with a code string works fine, though, so I won't put out a hotfix for it.  It'll be fixed in 1.1.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.0.10
Reply #340
How about a DoesFileExist function? Not sure why it wasn't added with the other file/directory listing functions.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.0.10
Reply #341
^ This. I have severely missed this several times while making games.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.0.10
Reply #342
Really liking this recent discussion. :)


Yeah, that would be trivial to add.  Is there a valid use case for it though?  I try not to add APIs just for the sake of it, trying to minimize perceived bloat.

I can think of good use cases for SetTileName(). First off, of course there's the fact that once you save a map it'll have this changed tile name data in it. But what about tiles in your game that you want to change the behavior on? For example, tiles with the name "hazard" all behaving like hazards until you tell some tiles they no longer have this name and thus no longer are hazards.

I'm sure there are more not-quite-straight-forward use cases. It's nice that this has been implemented now, anyway.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #343

How about a DoesFileExist function? Not sure why it wasn't added with the other file/directory listing functions.


Already done.  In fact it should be in 1.0.10 already.  I ended up adding it after looking through the commit log on the old sourceforge CVS repo (when I was trying to get the 1.5 source to fix that animation bug) and seeing it.  I think it might not have actually been exposed to script though?  Anyway, yeah, minisphere has DoesFileExist() already. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #344
Just added "proper object constructors" to the to-do list for 1.1.  :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub