So, picking up from some brief discussion in the miniSphere topic I'm planning on building Javascript based replacements for sphere's map engine and spriteset handling to work with the Sphere v2 api.

This is at an early stage (I've not written any code yet) but I've previously written a close to fully functionally engine for sphere v1 which I intend to use as a model as it supported most of the features we'll want and had a logical structure which should map to Sphere v2 - though there will be several key changes and it needs to be more flexible and work for other people not just me - I'm also hoping that using Galileo properly will enable the whole system to run a lot faster.

My hope is that this can become part of the standard minisphere distribution if I get it right...

Anyway that said I've written out my current design thoughts below, I'd appreciate comments, feedback and suggestions:

Planned features

• Sprite engine allowing for extensive control of sprites
  
  • Queuing commands
  
  
  • Setting destinations to have the engine generate a route
  
  
  • Function for adding entities
  
  
  • Most controls to be done by setting values
  
  
  • Collision detection
  
  
  • Each entity will be a shape or model that has a sprite sheet as its texture/atlas, uniforms will be varied to enable the shader to update the U/V values as needed to show the correct frames
  
  
  • The code will support zooming in and out for the whole screen AND will also enable individual sprites to be drawn scaled
  
  
  • Update function that can be added to the Dispatch queue that updates the position/state of all entities. OR can be called in a user's own loop
  
  
  • Render function that can be added to the Dispatch queue to draw the sprites OR can be called in a users own loop
  
  
  • Can draw to the screen or to a specified surface
  
  
  • Functions to work with the Map Engine when it is in use AND alone when the Map Engine is not in use


• Map engine allowing for extensive control of maps
  
  • Any number of layers
  
  
  • Drawing maps transformed if needed (ideally will add deformations as well as simple transformations - need Matrix axis and ideally Z-axis drawing enabled)
  
  
  • Applying masks of various kinds
  
  
  • Zooming in and out (feature will sync with sprites)
  
  
  • Can draw to the screen or to a specified surface
  
  
  • Collision detection
  
  
  • Each layer to be represented as a shape or model the size of the provided drawing space for the map (by default the game's resolution) that has the full map as its texture/atlas, uniforms will be varied to enable the shader to update the U/V values as needed to show the correct portion of the map.
  
  
  • Update function that can be added to the Dispatch queue that updates the position/state of all entities. OR can be called in a user's own loop
  
  
  • Render function(s) that can be added to the Dispatch queue to draw the sprites OR can be called in a user's own loop (probably have one function to render content under the sprites and another to render content over them) OR could have one function that calls the sprite renderer in the middle.
  
  

Choices to make:

• Tile or Pixel or Shape based processing (collisions etc)
  Preference is tile for simplicity + speed of processing


• File Formats:
  
  • Maps, options:
    
    • .rmp -> consistent with sphere v1 BUT contains some unneeded detritus  AND there's no modern editor for it
    
    
    • JSON description +one or more png tileset files -> can output with Tiled BUT human readable which some may not appreciate AND 2 files not one.
    
    
    • Custom of some kind, but include functions that can covert both of the above? (current preference)
  
  
  • Sprites, options:
    
    • .rss -> consistent with sphere v1 BUT pretty nasty to work with within the sphere v2 api, and generally quite an inefficient format (each image is stored separately as an array of RGBA values (each value being itself 4 bytes)
    
    
    • .png -> consistent with rpgmaker, easy to make/edit BUT how do you establish what size each frame is and other such things -> not flexible enough.
    
    
    • Json description containing directions/sizes etc + a png file with the images -> png files are easy to make, JSON is hand writeable + could have a script to make it if needed -> Looks good except for needing two files not one.
    
    
    • Custom format with a creation function that takes any of the above 3 as inputs -> current preference


• How many directions to support for movement, 4? 8? Variable?


• What transformations to allow (low priority can add more at the end)


• Should sprites be able to be drawn on multiple layers with a property specifying which one to draw on OR should it be one or two only?


• Should each map have one collision map or multiple (e.g. different collisions on different layers - links to point above)?


• Should the code be in .mjs or .js files...

Other thought patterns

• Can I track locations of entities with their transformation matrices? or do I need to track separately, I think I'll need separate tracking, even with component access if I allow zooming in and out and other transformations will be too messy to read out of the matrix.


• Persistent transformation matrices OR just have one that gets updated for every item drawn? Probably the latter if using separate tracking, as can't see a purpose in retaining the matrices.

Custom format with a creation function that takes any of the above 3 as inputs -> current preference

For spritesets, that's my preference too.  There's no reason for the engine itself to need to natively use user-editable formats when we have a fully programmable official Sphere v2 compiler in the form of Cell.

I'll give all this a better look either tonight or tomorrow, I didn't get much sleep last night so I'm not alert enough to take all this in.

I still have written any code for this yet, planning to start tomorrow or saturday now.

This is some solid stuff, whatever you do I think Tiled compatibility would be a huge positive addition.

Also, mjs seems to make more sense since that's how ES6 modules are imported anyway, right? Gives you more flexibility too.

Agreed, .mjs makes most sense for a brand new map engine.  That lets you export stuff by name without polluting the program with global variables and is a lot cleaner syntax-wise than CommonJS-style modules.

Full disclosure here: Cell transpiles down all .mjs scripts to .js right now because Duktape doesn't yet support ES6 modules.  But in the future, yeah, I'd definitely prefer map scripts to be mjs.

Full disclosure here: Cell transpiles down all .mjs scripts to .js right now because Duktape doesn't yet support ES6 modules.  But in the future, yeah, I'd definitely prefer map scripts to be mjs.

How does this work with the mini RT or sphere run time aka the system scripts you made for minispgere, aren't they .mjs?

Sphere Runtime modules are .js.  I actually can't use any ES6 syntax in them or they won't work, which gets frustrating at times.  Since the runtime is part of the engine, Cell can't transpile them.

As for how everything still works with that setup, the nice thing about TypeScript and Babel is that this:

Code: (javascript) [Select]

import { Thread, Console } from 'sphere-runtime';

Gets transpiled to something like:

Code: (javascript) [Select]

var req1 = require('sphere-runtime'),
    Console = req1.Console,
    Thread = req1.Thread;

Which means the modules work with both Node-style require as well as ES6 import.

Hmm, ok I'd missed that, I had in my mind that  using var xyz = require("something") meant "something" was an mjs file.

Anyway I can decide that point later, I'm going to try and get started on the core logic tomorrow.

Any feedback on my other decision points would be appreciated.

require() is a Node.js thing and actually predates modules being a standard part of JS.  When executing a require()'d script, the engine wraps the script's source code in a function which it then calls, which allows you to put variables and functions at the top level without polluting the global scope.  In ES6 modules there's no need for that function hack, since the JS engine handles the scoping directly.

Anyway, regarding the sprite engine: Do you plan to allow sprite objects to be used independently from the map engine?  I think that could be useful for some types of games that can't use traditional tilemaps but still use sprites, e.g. a top-down shooter.

require() is a Node.js thing and actually predates modules being a standard part of JS.  When executing a require()'d script, the engine wraps the script's source code in a function which it then calls, which allows you to put variables and functions at the top level without polluting the global scope.  In ES6 modules there's no need for that function hack, since the JS engine handles the scoping directly.

Ah right, makes sense.

Anyway, regarding the sprite engine: Do you plan to allow sprite objects to be used independently from the map engine?  I think that could be useful for some types of games that can't use traditional tilemaps but still use sprites, e.g. a top-down shooter.

Yes, see point 1.xi above.

Hmm... collision detection seems like it might be an interesting challenge to implement outside the context of a map engine.  In all the map engines I've written, this was always the difficulty I had when trying to make entities be a self-contained class, and is even seen in the miniSphere codebase: There's a circular dependence between maps and persons because the map engine needs to track active entities and the entities themselves have to know about the map they're on in order for collision to work properly.  It's not really possible to fully isolate them in my experience.

Hmm... collision detection seems like it might be an interesting challenge to implement outside the context of a map engine.  In all the map engines I've written, this was always the difficulty I had when trying to make entities be a self-contained class, and is even seen in the miniSphere codebase: There's a circular dependence between maps and persons because the map engine needs to track active entities and the entities themselves have to know about the map they're on in order for collision to work properly.  It's not really possible to fully isolate them in my experience.

I have an idea, will report back after I've given it a go.

So update on structural plans, now planning this to be 3 scripts:

mEngine.js: i.e. Map Engine
sEngine.js: i.e. Sprite Engine
cEngine.js: i.e. Collision Engine

The scripts will have "hooks" to enable them to work together though each will function alone, obviously certain features will be disabled when a script is not used e.g. all collision detection will be handled by cEngine so if you don't use it the Sprite Engine's path finding will not check for the appropriateness of a route.

I note I've decided to set the scripts up as CommonJS style modules for now using require, similar to the Sphere RT modules; this is partly because I haven't yet compiled cell for Mac and partly because I'm hoping that these can eventually be added to the miniSphere distribution in someway maybe included in the SphereRT folder and hence not being part of a project directory and therefore out of scope for cell.

Brief update.

I've begun with the sprite engine/SEngine, been having a busy time with the rest of life so progress is slow but it's under way...

Key thing I'm considering at the moment is the balance of the interface and how many methods is too many methods, particularly with entity objects and the like where there may be a lot of them. (NOTE: "entity" is the name I am using instead of the Sphere v1's "Person")

e.g. should there be:

SEngine.prototype.queueMove(entity_id, direction, frames);

OR should it be:

Entity.prototype.queueMove(direction, frames);

The latter seems unnecessary to me, it was my first thought of how to do it BUT, I'm not sure why it was.

One chip I'm throwing in for discussion - could cEngine and sEngine allow you to include an arbitrary number of hitboxes relative on a single entity? One of the things I've found difficult to work with is that sprites are limited to a single hitbox square for native implementation. As an example, trying to implement something like a semi-circle sword swing could do with a bit of accuracy by changing one large hitbox into two or three smaller ones, without needing to split it up into that many sprites and make sure they are all coordinated.