-
Notifications
You must be signed in to change notification settings - Fork 787
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
Consider integrating/extending an existing game engine in GDevelop? #238
Comments
GDevelop is already based on existing game engines: Pixi.js and SFML. (They are not exactly complete game engine though but still are very powerful). A change toward another library can be done, but it should be motivated by the need to benefit from a new (set of) feature or any substantial improvement, as it also involves a lots of changes in the source code of the native or HTML5 game engines of GDevelop (including a potential breaking of backward compatibility or the need to remove features that can't be easily reproduced with the new library, in favor of new features) :) |
I've looked a bit at Cocos2d-x not so long ago. It looks rather solid (even if the API is not as pretty as the one from SFML) and the support of mobile devices is better, but looks more difficult to integrate into GD. |
Good thoughts about backwards compatibility, and hopefully there is a migration path for and/or option to disable engine changes. The Pixi.js and SFML projects do not present themselves as 'game engines', per se:
A true game engine would bring higher level semantics and libraries into the GDevelop IDE. |
I'm doing some experiments with Cocos2d-JS, which would allow to still have HTML5 games but also support making Android/iOS/Windows/Mac/Linux games with native rendering and JS as the scripting language (so there would be only one game engine to maintain in GD for both native and HTML5 - and JS events could be used even in native games!). :) Still have to see what the performance of Cocos2d are, and how I could integrate their tools so that you can export native games directly from GDevelop (for previewing, it's easy to export in HTML5 like now. For native exports, it can be a bit more difficult and long because you need to have Cocos2d command line tools and some SDKs installed). |
Great news @4ian. Is there any way I can help with testing, etc? |
Thanks for asking! :) For now nothing much to do, I'm still implementing it. I guess there will be some testing to do: first to check that HTML5 games powered by the engine using Cocos2d are working (compatibility with exisiting games should be good - as the engine stays the same but the rendering is abstracted to use Cocos2d). Then, check that you're able to compile to a native game using Cocos2d tools. This could be a bit more tricky but we'll see. I'll post update here in case there is something interesting to see. |
Have you taken a look at Haxe ? |
Good point, I've taken a look at it but I'm not sure it would be the best bet to use Haxe for now, because of these points:
What I'm doing now is "just" reworking the rendering of objects and a few specific things to use Cocos2d. It's a bit of work but far less compared to switching to a different language. Also, I want to do it as fast as possible to validate that the result is good :) (That being said, feel free to let me know if you think about interesting points when comparing Haxe to Cocos2d/Pixi/other game/rendering engine 😄 ). |
About Haxe, you can generate an executable for basically any platform, technically speaking (there are frontends to consoles, for instance). Also, Haxe uses Emscripten to run in the browser, which, as far as I know, generates a game that runs faster than those using the Pixi.js, because asm.js (I don't know about cocos-2d-x). However you would have to rewrite much of GDevelop and would be much work to do. |
This would require a lot of work for using a C library which look pretty horrible in a modern C++ code... We can also almost make the native games work on Android with SFML. |
Where is linux in the runtime requirement of Cocos2d ?
|
SDL is definitely a no-go, it's really a low-level library, and basically requires you to use OpenGL as soon as you want to do something complex. Switching to SDL would means putting a lot of efforts and time to get something that will probably be less efficient than what me have with Pixi, SFML or Cocos. ;)
That's not true, it's not because you're compiling a library to asm.js that it will faster than a vanilla JS library : in most cases, it depends of your usage, of the performance of the library itself and if your browser is able to handle asm.js or not. Basically, you're comparing here pixi.js - a library - with a language Haxe, which does not make a lot of sense. What you should compare instead is Pixi.js with OpenFL (http://www.openfl.org/) which is the de-facto Haxe library for building games it seems ;) Note that as explained in my other message, the rationale about not trying Haxe now is that it would implies a full rewrite of the game engine and extensions, so better stick with JS game engines for now - I hope it makes sense :)
I'm not sure, there is a for sure a linux target for Cocos2d. Games are mainly using OpenGL and powered by Mozilla SpiderMonkey JS engine, so most recent linux distro should be compatible!
That's true, so the current plan is:
In both case, there is a third point that we need to address :
For this last point, we need : Android SDK and Android NDK (for making android apk, both for Cocos and SFML), XCode (for making iOS/Mac games, both for iOS and SFML - only on OS X), Python (for Cocos2d, it's already installed on Linux/OS X but not on Windows). I'm trying to finish to add Cocos2d renderers to the game engine and then update GDevelop to be able to launch preview and/or export HTML5 games using Cocos2d. That will be a good start to see how things are working. So far performance are good! 😄 (and a lot better than when packaging HTML5 games to Android/iOS with Cordova or Crosswalk). |
Good explanation :) It's nice to know that GDevelop at some point will generate games with good performance for mobile (thanks to cocos-2d). This will make the GDev much more competitive. |
Great to see potential native android builds, and if you can use Cocos2d then a revolution could be started ;) Willing tester here, primed and ready :) Great work! |
Quick heads up: I've modularized almost all the engine and objects to be rendered with Cocos2d. I've started to write a page explaining how to export to native platforms : http://wiki.compilgames.net/doku.php/gdevelop/tutorials/howtoexportwithcocos2dx I'll need you to check that the export with Cocos2d is working (there will probably be some glitches or a few things to fix). Basically, exporting the game for browser is the same as now: it's an easy and quick process and most games should work properly. |
And what is the status of native games compiled to Android with SFML ? Le dim. 20 mars 2016 à 20:04, Florian Rival notifications@github.com a
|
It will also be included in the next version, also flagged as experimental :) I'm not actively working on it right now - as it does not support iOS :/ But it's still a great improvement and this is why it should be included for sure in next version. |
Great work! I am glad to help test the new exporter. |
Cool! Feel free to try the new exporters and complete the wiki pages if you have some time or something is not clear. :) |
@4ian which version of GDevelop should I use? |
Use version 4.0.91, that you can download here: https://github.com/4ian/GD/releases |
I am glad you decided to go with cocos. Its still quite complicated to set up. Just put cocos in a zip file, along with an install script that sets it up and for the user it would be a matter of selecting it from a menu in gdevelop. Whatever you decide to do, I wholly support the idea of getting cocos more closely integrated with gdevelop - where gdevelop is the editor and cocos is the underlying engine. I dont mind the increase in file size either. Gdevelop visual scripting/level editor --> cocos engine GD core engine package (vanilla cocos engine+gdevelop interpreter) --> export game Actually I am not sure why both sfml and cocos are supported. They both export to the same platforms, while cocos is obviously more mature and performant. |
Closing this as it's getting old and there is actually a Cocos2d-JS export. But any help to integrate native games or support something like export to Unity in GDevelop 5 is welcome! |
It would actually be a better fit for godot than unity imo :)
…On Sat, 26 May 2018 01:19 Florian Rival, ***@***.***> wrote:
Closed #238 <#238>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#238 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AGMbVYbrBUttZEokEXPT_BKqMdHHaJxqks5t2J-agaJpZM4HDA_f>
.
|
What are your thoughts regarding integrating and extending an existing game engine in GDevelop? Some examples could include:
In effect, building on an existing game engine, with established community, could save a lot of time by allowing GDevelop to use a higher level framework.
The text was updated successfully, but these errors were encountered: