How many features should actually be in the engine library?

Design API
#1

For example, if we have something named similar to an engine, perhaps things like animations should be separate?

A car, has an engine. When you turn it on, the engine just spins cycles, and that’s it. Input from the outside turns the steering wheel or presses the pedal, and that make the car/engine do things.

Would it perhaps make sense to separate things out into smaller packages?

For example, the engine/motor/boxer/famin thing could just provide that, an engine. The engine simply ticks and runs a scene graph. It doesn’t have to render anything. It’d be just a scene “engine” that make updates tick (when specified with components, etc). Nodes in the engine have things like Position, Size, etc, which are equivalent to the steering wheels and pedals of the car. Externals things would modify those properties by, for example, animating some numbers then setting the values of a Node’s properties (a Tween library perhaps, with it’s own worker abstraction in order to put tween calculations in a thread). An external physics library could have a way to map it’s parameters to arbitrary properties (f.e. the position/align/etc properties of a Node). The separate physics library package/library might have it’s own worker abstraction.

etc.

So, my question is, how much do we actually want in the engine library, and what do we want to have as separate libraries? f.e.

infamous/motor
infamous/render (contains basic API, plus ability to use Three.js, Babylon, etc)
infamous/physix
infamous/motion (timeline (and tweens?))
infamous/etc
infamous/ui (components of the UI variety made with a culmination of everything)

1 Like
#2

on render side I would need just a canvas on which I would be able to create a GL handler.

I have the osg C++ graphics library compiled with emscripten - and it is what I intend to use. Compared with Three.js - it is flexible enough not to feel constrained by engine when creating 3D things ( while Three.js constrains 3D programming in Three.js way ) , the good thing in famo was that I could have all my callbacks in one place - so external engine could be fitted. Thus famo WebGLRenderer ( function WebGLRenderer(canvas, compositor) ) with ability to extend ( use other class in place of WebGLRenderer ) is the thing I need

#3

As far as I’m concerned everything possible should be an extension/plugin.

I think the real question is more what should the default configuration be, and how do you manage said extension/plugin ecosystem?

Machinepack operates this way:
http://node-machine.org/machinepacks

Every single package is on npm and has a machinepack- prefix.

Gulp also operates this way, just with a gulp- prefix.

I think it would behoove us to use a similar system. That said, setting it up now would be getting ahead of ourselves. First comes actually defining how extensions/plugins work, and then actually making quality ones.

For things like size/position/scale, etc, it’s likely best those would be considered core extensions and maintained within the library itself, thus not requiring npm. The ideal system for this would probably be something like:

  • Size/position/scale implemented as *.js files in the extensions directory.
  • Any extensions that load from npm would have a corresponding *.js file, but essentially acting as stubs–supplying an npm package name inside a loader function.
  • A user could simply create myPlugin.js and have it work.

This way, the library maintains a set of core extensions while simultaneously allowing foreign packages from npm, while also allowing a users to create plugins without any special packaging fuss.

#4

@oldschooljarvis

supplying an npm package name inside a loader function.

What do you mean exactly? What would that do?

#5

as for UI the idea is that embedding web components ( at first in polymer like incarnation for browser support ) or React components will fill that part ( beware I’m not web developer rather a desktop developer moving to web so might be rough at edges)

for web components I think of some bridge like https://github.com/vnen/polymer-flux so state of components is managed by a lib, but components are used freely

thus the idea goes like this: if standard web components are used for UI and their state is preserved by means of a library support - that seems could be called infamous - UI
( maybe this link https://github.com/jscissr/react-polymer will also be of some use or even https://github.com/panarch/famous-polymer Last edit: this one has no polymer dependency though - but implemented paper elements via famous ( new one but with emulation of old famo via famous-mig ) - so now I see UI elements with library could really be developed without much dependency on either react of polymer web components )

previous edit: while I see the accent on https://en.wikipedia.org/wiki/Entity_component_system still the idea I try to propose is to combine two worlds: Entity component system which is great for all dynamic updates ( position physics etc ) and put any commercial logic to live in those traditional well known to designers and users ‘web components’ or however they are called in traditional use.
I see that this is not a problem if anything ‘moving’ is done via constant updates, but business logic and functional content can be assembled into something which is not non entity-component system related

#6

@joe

What do you mean exactly? What would that do?

Saves the user from having to supply a full path to the extension (which would otherwise get annoying quickly). The build system would then package up the relevant module accordingly. I didn’t mean to imply anything runtime-related with that comment, sorry.

Now that I given it more thought, it’d probably make more sense to just specify the npm packages with the rest of the plugins inside a single configuration file. How plugin authors would reference other plugins within their own remains an interesting/open question though.

#7

Oh, for sure. :smile:

Jss has a plugin mechanism where to add a plugin you can do

import { Jss } from 'jss'
import somePlugin from 'jss-plugin'

let jss = new Jss()
jss.use(somePlugin)