41–50 of 59 posts
I'm not really a game developer but it seems weird to me that if you go with the GCFL you cannot release the game on the internet, but only in the appstores.
Everyone should check out LimeJS. It is essentially functionally equivalent to what is being offered here, but without the shady license.
So I need to show your logo before my game starts in order to use this library ? Sorry, but that is a deal breaker. Everyone should check out LimeJS. It is essentially functionally equivalent to what is being offered here, but without the shady license.
So I need to show your logo before my game starts in order to use this library ? Sorry, but that is a deal breaker. Everyone should check out LimeJS. It is essentially functionally equivalent to what is being offered here, but without the shady license.
I should add a stipulation that LimeJS doesn't have a fancy marketing video, sorry.
Michael Carter here from Game Closure, I'd like to clear up some of the licensing questions. For background, before GC I founded a non-profit that helped open source projects deal with licensing issues, CLAs, and IP around software in general. I've been involved in 3-4 large OSS projects, and I've spoken at OSCON and Pycon multiple times. I very strongly believe in the GPL, though we also wanted to let businesses use…
I understand that, but you maybe you should consider charging some money to get the splash screen removed ? else its a deal breaker indeed.
I'd try it out especially since I am having some hard time with cocoonjs (making it work in android and some features failing to work in ios5).
Michael Carter here from Game Closure, I'd like to clear up some of the licensing questions. For background, before GC I founded a non-profit that helped open source projects deal with licensing issues, CLAs, and IP around software in general. I've been involved in 3-4 large OSS projects, and I've spoken at OSCON and Pycon multiple times. I very strongly believe in the GPL, though we also wanted to let businesses use…
The GPL is a hard sell to anyone. But with your commercial license, where do you draw the line between building functionality for your game on top of an engine versus extending the engine? It seems fuzzy. Besides, not having an option to build a game without either making it open source or publicly evangelizing your product will make adoption a non-starter for many serious developers. Licensing aside, it seems strang…
Great feedback on the fuzziness of the license WRT contributions! Overall our intention is to let people keep their source code proprietary, but protect clear bug fixes and enhancements to the core engine. We never, ever intend to come up with some "gotcha" and start charging money. Any suggestions on changes or clarifications to our license that let us accomplish that are very welcome! (Though please read our first attempt in Exhibit A "Modifications" first)
The good news is that the core native engine (c/c++/java/obj-c) is very obviously separated from the game code and so that's easy; it's just the JS libraries that we have to be precise about. Perhaps the MPL has the right wording and guidelines around that?
("The MPL is a simple, file-level copyleft license. The MPL’s “weak” copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions.")
Earlier quoted context omitted.
The GPL is a hard sell to anyone. But with your commercial license, where do you draw the line between building functionality for your game on top of an engine versus extending the engine? It seems fuzzy. Besides, not having an option to build a game without either making it open source or publicly evangelizing your product will make adoption a non-starter for many serious developers. Licensing aside, it seems strang…
I get your concern about supporting the web; I think it's because a lot of people really want us to be a web game engine, but we aren't. We're a mobile game engine. We simply chose "HTML5" as an API layer because of the excellent tooling around the ecosystem. It just so happens we support the web as a side-product, and that's pretty cool I think, but not really the point of the GC DevKit. Great feedback on the fuzzin…
Will the engine become a monolith with support for pretty much everything, and all games using the engine will only need 10% of it? Or something else?
I think you need to state very clearly what the goal of the engine is (best 2d engine, best tile game engine, best ??? engine, general purpose engine, etc?), which can help define exactly what kinds of contributions are actually useful.
Others I can think of, Construct2, ImpactJS, Crafy, Collie. Some of them are made for different things. For example Construct2 provides a visual interface, easier to build at the cost of having more limitations. ImpactJS has a level editor, based on blocks, physics are not hard to implement, and they document building for mobile app stores. Crafy is very light, an abstraction for the canvas, similar to Collie. Game c…
I think you probably mean Crafty, not Crafy. I found I enjoyed working with it the most -- it handled exactly the parts I didn't want to think about (drawing sprites, collision detection) and left the interesting stuff with me. That said, in the end I did end up looking into their drawing/collision code to tweak the performance some! :D