You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, plugins can refer to other plugins by name, looked up with game.plugins.get(name). For example, game.plugins.get('game-shell-fps-camera') would get an instance to the loaded https://github.com/deathcap/game-shell-fps-camera plugin, if available.
This design makes it difficult to replace plugins with alternative implementations. For example, I might have another camera implementation (orbit camera?) I want to use instead of game-shell-fps-camera, but then all the dependent plugins like voxel-shader would have to be updated to know about the new plugin, and to select either one.
Idea: add the concept of an "plugin API name", which plugins can claim to implement. game-shell-fps-camera for example could implement the "camera" API (or whatever), and so could other camera plugins. Dependents could then do plugins.get('camera') (or plugins.api.camera?) and get an instance to any of the available plugins supporting this API (presumably there would only be one loaded at a time).
The APIs themselves could be implicit, or formalized. voxel-shader at least needs a view(viewMatrix) method in the camera API, setting the view matrix argument passed in to the camera's current view matrix (with the proper rotations and translations, see this implementation but other camera plugins could implement it differently). Other APIs would need other methods or properties.
Could even support versioning with semver (camera@^1.0.0, etc.), or feature detection might be easier.
The text was updated successfully, but these errors were encountered:
Whipped up a quick prototype of what I had in mind, for checking interface conformance: https://github.com/deathcap/conforms - using this plugin, a "camera" interface for example could be defined as:
varcamera={view: function(viewMatrix){}};
then conforms(plugin, camera) could be used at plugin load-time to ensure the plugin implements the view(viewMatrix) method, before setting it as the active enabled plugin loaded implementing the discoverable (by other plugins) "camera" interface.
Currently, plugins can refer to other plugins by name, looked up with
game.plugins.get(name)
. For example,game.plugins.get('game-shell-fps-camera')
would get an instance to the loaded https://github.com/deathcap/game-shell-fps-camera plugin, if available.This design makes it difficult to replace plugins with alternative implementations. For example, I might have another camera implementation (orbit camera?) I want to use instead of game-shell-fps-camera, but then all the dependent plugins like voxel-shader would have to be updated to know about the new plugin, and to select either one.
Idea: add the concept of an "plugin API name", which plugins can claim to implement. game-shell-fps-camera for example could implement the "camera" API (or whatever), and so could other camera plugins. Dependents could then do
plugins.get('camera')
(orplugins.api.camera
?) and get an instance to any of the available plugins supporting this API (presumably there would only be one loaded at a time).The APIs themselves could be implicit, or formalized. voxel-shader at least needs a
view(viewMatrix)
method in the camera API, setting the view matrix argument passed in to the camera's current view matrix (with the proper rotations and translations, see this implementation but other camera plugins could implement it differently). Other APIs would need other methods or properties.Could even support versioning with semver (camera@^1.0.0, etc.), or feature detection might be easier.
The text was updated successfully, but these errors were encountered: