Globalizing stuff

[joskuijpers]

As @fatcerberus reported on SphereDev, we could put more classes in the global space.

I am fine with that, but we should be careful.

We should limit the number of classes, probably namespace some, and think about collision.

So no 'Group' class. Maybe 'ShapeGroup' or namespace the graphics in 'Graphics.Shader/.Group/.Shape'.

Also, Logger is a module. No default loading of modules other than engine and console. Default loading fs is bound to cause problems. Same for manifest and stuff. We could make an 'engine.getCurrentManifest' or getCurrentGame or .game.

I am not sure what else there was in the post... can't access it. Oh yeah, don't globalize 'Socket' and 'Server'. It is not something everybody always use and it is odd with datagrams. Keep in in a 'net' module that shall be loaded using require.

Also remember that we can't globalize the map engine as 'Map' because that is used by ES6.

@fatcerberus Could you repost what you wrote on the forums?

[fatcerberus]

Do keep in mind that what I posted on the forums was highly tentative and very much subject to change - I'm prone to indecisiveness, especially during active development of an overhaul like this. That's why I haven't been updating the Pegasus repo, because my branch changes from day to day.

I agree re: Group -> ShapeGroup. This was something that always bothered me, but I kept it to be compatible with TurboSphere. The full compat is no longer needed because TS has gone in a different direction since then.

fs should be globally accessible because it is low-level core functionality - almost every script will need to do something with the file system. That's just the nature of game development. If name collision is your main concern here, we could probably namespace it. For example sys.fs or something. Gating it behind a require is overkill because then every single script will need to require('fs'), leaving you no better off than before.

Agree on limiting number of globals. As mentioned in that post, I only want the engine itself to expose very low-level functionality. Graphics, for example, only provides the minimalistic Galileo API and all other graphics operations are built on top of that in JS modules.

Here's what it comes down to: The engine is the foundation. Modules are the framework. There's no reason to modularize the foundation.

[joskuijpers]

Quickie on fs: true you use fs a lot, but not the low levels stuff:

let myFont = new Font(“path”); <— doesn’t use fs module

On 16 May 2016, at 23:26, Bruce Pascoe notifications@github.com wrote:

Do keep in mind that what I posted on the forums was highly tentative and very much subject to change - I'm prone to indecisiveness, especially during active development of an overhaul like this. That's why I haven't been updating the Pegasus repo, because my branch changes from day to day.

I agree re: Group -> ShapeGroup. This was something that always bothered me, but I kept it to be compatible with TurboSphere. The full compat is no longer needed because TS has gone in a different direction since then.

fs should be globally accessible because it is low-level core functionality - almost every script will need to do something with the file system. That's just the nature of game development. If name collision is your main concern here, we could probably namespace it. For example sys.fs or something. Gating it behind a require is overkill because then every single script will need to require('fs'), leaving you no better off than before.

Agree on limiting number of globals. As mentioned in that post, I only want the engine itself to expose very low-level functionality. Graphics, for example, only provides the minimalistic Galileo API and all other graphics operations are built on top of that in JS modules.

Here's what it comes down to: The engine is the foundation. Modules are the framework. There's no reason to modularize the foundation.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/sphere-group/pegasus/issues/24#issuecomment-219553096

[fatcerberus]

Actually Font is high-level and therefore /should/ be a module. And in fact now it is--I made an RFN font loader and renderer earlier, entirely in JS: https://github.com/fatcerberus/minisphere/blob/sphere-api-v2/assets/system/modules/font.js

TTF fonts will likely need engine support though.

Like @FlyingJester has been saying for a long time, there's not actually very much that needs to be built into the engine executable. A lot of what we've been trying to do with Pegasus can be done in JavaScript. Which means we only need to formally standardize on the engine API (the "syscalls", as it were), and then all the JS module code we write as part of the Pegasus core can be reused in any compatible engine--without any changes and without having to write a formal standard for, say, a spriteset module.

[fatcerberus]

How do we specify globals in the spec? The current TypeScript files are written assuming everything is a module.