modules or frameworks
Monkey Archive Forums/Monkey Discussion/modules or frameworks
| ||
| I went through existing frameworks for Monkey and something came to my mind which I like to share with you. I suggest those who create frameworks, add modules to Monkey X (like those of Brucey for BlitzMax) too. For example, it is better that they offer collision module, rather than offering collision to work only within their frameworks. I think this is fair and truly helpful to Monkey community. Also I do not see any reason for those who offer modules, do not ask for donation or sell modules, not all people can do what Brucey does because people are in different situation. And it is good ethics for module users to donate to module projects every now and then. Those who know me by "my transactions" know that I have done my best. |
| ||
| people offer you individual modules so you don't have to get 'vendor lock-in' from frameworks, the least you can do is not lecture them about asking for donations! You're already benefiting from the fact they're not forcing you into one of the frameworks. That being said, however, it's completely understandable that not everyone can afford to make a donation. I try not to be tactless. I believe I've received 1, maybe 2 donations maximum when I was actively updating my modules. I don't expect any more than that, honestly -- most people use them and don't think twice about it. I'm sure there's at least a few people who are more than happy to turn around and use that as a springboard to incorporate it into their own product; I just hope that they don't try to make me pay money for offering a competing product based off the original code. Stuff like that is the reason some projects end up going GPL... |
| ||
| You are not talking to me. |
| ||
| As a contributor of monkey modules/app to the community I can say donations do make a difference. Most donations come from PayPal and I tend to use that money to buy fun things like gadgets or maybe deposit money to my poker account. Being rewarded with fun sure helps. I share the same ethos of trying to separate functionality. It was what spured me to make the standalone xml module. Frameworks definitely have their place and authors of said frameworks should maybe think about making their work extensible. For example, instead of making a tile map load for your proprietary tile map format, make a generic tile map system with an Interface that acts as the loader/translator. Instead of hard coding file reading, make it so loaders can be swapped out. Maybe json,xml or a custom format can be objectified. |
| ||
| I generally agree with SKN3, but at some point you could end up going a bit too far with making your modules standalone. I have my own modules I've written in Monkey, and each of them depends on specific functionality from each other, but now that I got Mark to rework the preprocessor, optional dependencies are a lot simpler. The optional modules in my code tend to be more along the lines of using specific interfaces that are only implemented explicitly, if the module containing them exists. There's also modules I can effectively simulate if they aren't there. For example, just to keep things nice and consistent, I have a 'sizeof' module. This module really isn't that complicated, as it effectively holds some small functions and constants. And since I can make assumptions as a fall-back, I use this to my advantage. So, in the case of my 'sizeof' module, I can assume the size of an integer is 32 bits. And if it doesn't compile? Well, for one thing, with Monkey that's very unlikely. And another is that the functionality provided without the 'sizeof' module would be an "undefined" fall-back; meaning on top of the already present disclaimer for the module, you're already in "no man's land" support-wise. I've done some more advanced approaches to this, but you get the idea. Monkey's philosophy is modularity, but that doesn't mean you should have to reinvent the wheel. The point of a module is that it can be used anywhere without much hassle. As long as the modules it imports are available to it, it should work. Following this mindset, I've created several modules which only need each other for specific features. That, or they optionally use standard implementations when available. Basically, I'm really glad Mark went with my preprocessor ideas. I don't see anything wrong with taking donations. And personally (Unless you make more money than expected), I don't see why you should feel obligated to give donations. These modules are generally provided as public domain in some sense. For example, all of my modules (Currently) are under the MIT license, as I think it's the least restrictive. I personally don't take donations (Nor do I honestly deserve them), but if someone is willing to give you donations, I don't see anything wrong with receiving them. It's not like you're begging for money or anything, you'd be receiving what someone else values your work as. This is the same as someone paying you to make modules for them, it's just not something you should necessarily expect in this context. As a side note, I personally think it's a bit immoral to beg for donations. Don't expect people to pay you for what you've released as non-commercial. If they want to pay you, great, but don't try and guilt-trip people into giving you money. An open source project is open source, and you should not release your code as such if you expect money from everyone. If it wasn't obvious, I'm not saying anyone here has even remotely been begging for donations. Hell, I haven't even seen a single person on here do this. The most I've seen are Kickstarter campaigns (And related services), but that's a different topic. |
| ||
| A donation model for IgnitionMax and Ignition X would not really work for us since we put so much time and effort in it that we need to justify it for our selfs. Also the sales and usage makes it very rewarding to us and that helps us to improve it and stay motivated. Most of the modules that are free or are based on donations get broken over time because authors lose interest in it or move on to other things. Most recent example is the MiniB3D (who looks dead) and that is a shame. We have no problems to stay motivated or intentions to quit simply because we get rewarded. As far as making Ignition extensible and prevent getting vendor lock-in, the Ignition framework exists out of little modules that in some case depend on eachother and sometimes not, makes Ignition modular. You can easily 'just' use the Igniton X tile engine if you don't need the rest. This goes for almost all the modules except for the main engine that is build on top of all these small modules. But even there you can hook in to the render and update system combining engine features with your own stuff or modify the core stuff because the source code is there. |
| ||
| personally I am working through writing my own framework mainly as it uses what I needed and I u derstand how it works. |
   |