@DaVince: In your Cellscript template, The files() for transpile should be recursive, as most people, myself included, like to organize scripts into subfolders.  For a native Sphere v2 game that doesn't need backward compatibility, I also recommend transpiling into @/bin (rather than @/scripts), as a hint to a person looking at the distro that the game has been compiled in some way and they should look for the real source code if they want to make edits.

In other words:

Code: (javascript) [Select]

transpile('@/bin/', files('src/*.mjs', true));
transpile('@/bin/', files('src/*.js', true));

Okay, I'll  make the changes. And now I know what the true statement is for.

And now I know what the true statement is for.

It's documented, no excuses.
https://github.com/fatcerberus/minisphere/blob/v4.5.11/docs/cellscript-api.txt#L94-L103

I want to refactor the standard library for miniSphere 5.0.  The code is all over the place currently and different modules use different styles; they sometimes don't even use module.exports consistently. What I think I'd like to do is reorganize it so that the CommonJS view is split at the object level--each require() module would correspond to a single namespace, function, or class--while the ES6 view would have it all merged into a single composite module, making everything more intuitive for both environments.

Node style (CommonJS):

Code: (javascript) [Select]

const from     = require('from'),
      Delegate = require('delegate'),
      Music    = require('music'),
      Scene    = require('scene');

ES6 style:

Code: (javascript) [Select]

import { from, Delegate, Music, Scene } from 'miniRT';

Which really shows the strength of the ES6 module syntax compared to old-style require()

There will be some minor compatibility breakage in miniSphere 4.6 in preparation for the above change.  I can still technically do that because the Sphere v2 API hasn't been finalized yet

Idea I had: Example project could take advantage of classes:

Code: (javascript) [Select]

import Thread from 'thread';

class Game extends Thread
{
    constructor() {
        super();
        // startup code
    }

    on_update() { ... }
    on_render() { ... }
}

new Game();

The Thread constructor sets up the dispatch automatically, avoiding the need to deal with the Dispatch API or threader directly.

This is what the new game template looks like now:
https://github.com/fatcerberus/minisphere/blob/master/assets/template/src/main.mjs

Much cleaner and doesn't require you to understand the Dispatch API

Looks great, much easier to get started with!

Regarding file association, I think Linux has regex-based associations, so we could define a standard that the first field in the JSON file must be version and then use a regex like...

Code: (regexp) [Select]

^{\s*(?:\r?\n)*\s*version:\s*\d*

...to associate them with miniSphere without pulling in all JSON files.  Unfortunately Windows associates only based on file extension

Well, why not give it its own extension then? I still think s2gm is a good candidate (for a file extension), and the contents can just stay the JSON format that they're in.

The reason I chose game.json was for consistency with Node.js package.json.  I wanted more veteran JS developers (like myself ) to find Sphere approachable and familiar too, not just newbies.  Plus .json is more likely to have "Edit" as an option in its right-click menu in a default Windows setup, whereas an unknown format won't be associated with anything.

And you can always compile to an SPK

I guess both have their pros and cons.  I'll revisit the issue after I finish up the module reorganization and release miniSphere 4.6.

Sounds fair, although to me it's felt like the json file just tends to be the resulting file after compiling with Cell (even if not strictly necessary), especially now that ES6 transpilation is going to be a common thing. I always found having a project file to double-click in order to run it more convenient.

Well, I guess since I've only recently started learning the New Way of Doing Things, I'm still totally used to having the sgm.

miniRT is being promoted to a first-class part of the Sphere v2 API.  This will split the API into two levels: the low-level Core API which can't be implemented in script such as Galileo, Audialis and the like, and sphere-runtime, which is more high-level with stuff like the Thread class, Scenario, the Music manager, and more.

I'm hoping this change will make Sphere v2 more approachable, as I've noticed that people tend to get scared away due to the more low-level design.  I try to point people to miniRT as consolation, but I think there's a stigma there due to it seeming like a third-party add-on, albeit one that happens to be bundled.  Making it an official part of Sphere v2 increases the burden for standardization, but should avoid the "inferiority complex".

I think this is a really good idea, and it's good that you're pretty much immediately showcasing what it can do in the example project.

I agree, especially considering image/surface blitting can be very tedious without the respective miniRT module. It's almost necessary.