-
-
Notifications
You must be signed in to change notification settings - Fork 644
-
-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement an official plugin mechanism #85
Comments
So, here is what I have in mind (let's use this as a starting point for discussion) Objective :
Requirements :
Any thought ? |
Just thinking of some features that I needed when working with Chipmunk:
So the first one is done... The second one is doable with either support for multiple callbacks, or a publish/subscribe pattern. Pub/sub pattern is also good for the remaining two... even better than supporting multiple callbacks all over the place. The last one is also probably not "exactly" what I needed, but it's what I went with. The real need was to capture all of the unnamed polygon/polyline objects so I could create the corresponding Chipmunk shapes. I'm not sure of a better way to manage that. Ideally capturing them at creation-time, so that's what I ended up with. About the pub/sub pattern: there's a nice little lib I used called MinPubSub (MIT License) which establishes a method for any components to communicate with one another indirectly. Take the pause/resume feature as an example: instead of supporting a callback by setting publish("me.state.pause"); Where the string given is the "channel" that user code (and plugins) will subscribe to: subscribe("me.state.pause", function onPause() {
// ...
}); This will allow as many subscribers as we like, and they can all act on the "me.state.pause" message; Maybe a user-subscriber will show a "pause screen", Chipmunk and other engines that need to remain synchronized can reset their internal timers properly, etc. It makes more sense in the case of me.game.addEntity (the array is a list of arguments passed to the listener): publish("me.game.addEntity", [ entityType, zOrder ]); And listeners: subscribe("me.game.addEntity", function onAddEntity(entityType, zOrder) {
// ...
}); With the pub/sub pattern, there's no need to "install" hooks, or do anything with objects or special methods... just create a series of subscribers that interact based on messages from the engine. And the engine can also subscribe to any messages it might be interested in -- allowing plugins and user code to communicate back to the engine. My final thought is that versioning is very easy: melonJS provides an accessible property to advertise its version number (bonus points for providing a version comparison method!) probably in the A plugin might ensure the melonJS version is ok with something like this: if (!me.sys.versionGE("0.9.5")) {
alert("melonJS is too old! Expected 0.9.5, got " + me.sys.version);
} Methods like |
Oh, and I forgot to mention namespacing the publish/subscribe functions; MinPubSub supports it easily enough, and you can just use |
I like the idea, and it's both very small (in terms of size) and powerful ! Do you think however I could somehow integrate into melonJS (of course keeping the original author and license) as I like to lower as much as possible the amount of dependencies with 3rd party libraries. |
I believe it's fine to integrate into melonJS, because it's released under the MIT license. I recommend using the source file (https://github.com/daniellmb/MinPubSub/blob/master/minpubsub.src.js) and copying the full license text from README.md into the comment at the top. That should be enough. Also, doing more thinking about the version comparison stuff, I like a more "normal" single compare function better: you pass two args (or optionally just one; the second parameter will be implied as melonJS's version number!) and it returns a number:
|
I'm thinking I could do the chipmunk shape creation in a much cleaner way if there was a 'me.game.levelLoaded' message published. by then I have access to all of the level objects so I don't need to do any other hooking. |
Hi Jason, Sorry for the low activity recently, but I really had to take a few days off this week :) This to say that I’m ready to move to the 0.9.5, I’ve been thinking about the pubSub library and that’s really something I like. Just need to figure how to cleanly integrate it in melonJS (I think before you suggested to add the two function directly under the me namespace which I tend to agree with as well : me.subscribe, me.publish), and how to properly document the function uses can subscribe to. And to come back on your initial question, since this will allow us to have “multiple” callback kind of solution, yes you could definitely then use it when the level is loaded. Other place I wanted to put one as well is on the timer update function (me.timer.update), for this last one though, I also need to rework the class a little first. Does what I say making sense today ? (I need more sleep this morning) Olivier. |
Yeah, that sounds great. So the minpubsub.src.js is just a self-executing anonymous function, you can easily run it within the namespace you want it to inherit from. But probably an easier integration is replacing the I think you're aware, but you can also add any documentation to the source file for melonJS. My suggestion for a documentation pattern is including a short description in There may be some internal/private APIs that publish as well, and no documentation will be generated. In those cases, I think it's best to document the publish in some very closely related public API, or within |
version 0.9.4 tagged (took me one hour as I said!) :) |
MinPubSub integrated :) for now it's directly under the me namespace, don't know if it will stay there, but it's working quite nicely. (by the way, just changing the this and replace it with "me" was working nice, but then it screwed up documentation generation, so for now i added it manually inside) |
ok. I see the cache variable Also I just sent you a pull request which adds three more publish notifications: |
Hi Jason, out of curiosity, what do you have in mind for the me.game.onInit ? Else I was thinking yesterday that I should maybe move the pubSub stuff somewhere else (like me.event or me.message, or something else). The problem is that end-users should be able to easily figure out which channels to be used, and this would allows to define some constants that could be easily then added into the documentation as well. other possibility is to add all "system" defined channel/topic in the documentation of the subscribe function itself. |
Hi Olivier, Specifically, I'm using I have to add a persistent object (the "Stepper") and get the canvas height, and I'm ok with having the pub/sub methods moved. And constants do seem like a much better idea than using arbitrary strings everywhere. |
I see, good :) For the second point , any suggestion on the naming : me.pubSub looks good no ? |
It looks kind of funny; Any of these?
Ordered by least to most typing. ;) |
Yeah, you right, but it was to keep the reference to the original name. thanks ! |
Done. I'm afraid however you will have to change your code again :( |
That's fine! It is the price one pays for using bleeding edge software. ;) It looks great! Thanks! |
Bleeding edge, yeah ! :) |
Hi Olivier, I've implemented a handful of things for this ticket in my fork:
There are some other small fixes, too. I'll issue a pull request shortly. :] |
…1e380895 Implement more pieces of issue #85, and various changes.
So, back on the plugin mechanism : Two topics :
I’m not saying that we should reuse their code, but this plug method is what I actually had in mind, and the same could be easily added to the object definition in melonJS to easily replace or extend existing function (I guess we could use as well the “plug” name ?). Another idea would be to add an additional parameter to the function that would precise how to extend it :
(though the two last ones, are maybe kind of similar with the existing callback mechanism) |
I agree that having a cleaner way to extend methods than monkeypatching is a good idea. The YUI plugin method looks a lot like the event listener pattern, which is interesting. |
Ticket #85 - Implement an official plugin mechanism
So, I just merged into the main branch the base stuff for plugins. Basically it provides two things :
see under me.plugin for more details and basic examples :) @parasyte , I guess it's time to "port" your chipmunk plugin now ... :) |
I'm closing this one, as I consider it now as implemented and did not received any further feedback. |
to make it easier and more "future-proof" when integrating 3rd party libraries (physics, audio, gamepad, etc...).
The text was updated successfully, but these errors were encountered: