Consider integrating/extending an existing game engine in GDevelop?

[brylie]

What are your thoughts regarding integrating and extending an existing game engine in GDevelop? Some examples could include:

• Kiwi.js - has entity/component system, canvas/WebGL rendering, plugins, animation, touch input, audio, etc
• Cocos2d-x - extensive features inluding audio, sprites, scenes, events, physics, actions, multi-platform support, scripting (C++, JavaScript, and Lua), etc

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.

[4ian]

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) :)

[4ian]

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.

[brylie]

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:

• Pixi.js is a "rendering engine"
• SFML is a "multimedia API" or "Multimedia Library"

A true game engine would bring higher level semantics and libraries into the GDevelop IDE.

[4ian]

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).

[brylie]

Great news @4ian. Is there any way I can help with testing, etc?

[4ian]

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.

[desk467]

Have you taken a look at Haxe ?
It seems to be very interesting and maybe a little easier to integrate with GDevelop .
The Stencyl uses it.

[4ian]

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:

• It would require the rewrite the entire game engine in Haxe, including behaviors, objects, events, actions, conditions, expressions, renderers of objects and also write a new events compiler in the software to output Haxe code instead of JS or C++ like now.
• The goal is to be able to export to mobile (iOS/Android), desktop and web (HTML5 with WebGL). I don't know if Haxe has support for more platforms, but as long as Cocos2d can do this, it's ok for me :)
• Javascript is a really popular language nowadays and I'm not sure it would be a good idea to drop the current game engine based on it.

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 😄 ).

[desk467]

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.
Actually I think if you use SDL instead of SFML it would be better, because SDL has versions for all three mobile platforms and for web, via emscripten, and it's a C/C++ library. However, I don't know how much work would be to make this change.

[victorlevasseur]

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.

[victorlevasseur]

Where is linux in the runtime requirement of Cocos2d ?

Runtime Requirements

iOS 5.0+ for iPhone / iPad games
Android 2.3+ for Android games
Windows Phone 8+ for Windows Phone games
OS X v10.6+ for Mac games
Windows 7+ for Win games

[4ian]

SDL instead of SFML

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. ;)

runs faster than those using the Pixi.js, because asm.js

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 :)

Where is linux in the runtime requirement of Cocos2d ?

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!

We can also almost make the native games work on Android with SFML.

That's true, so the current plan is:

• Check if we can make most of the native games work on Android with SFML. (we made good progress, see here: [Experimental] Native android export #246 (comment)).
• Modularize the HTML5 game engine (it's done!) and add Cocos2d renderers for objects (I'm making good progress on it too).

In both case, there is a third point that we need to address :

• Make it easy for users that want to compile to a native Android or iOS app to download and install the needed SDK and any developer tool needed.

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 not sure what you need for building Cocos2d games on Windows - I guess some kind of Visual Studio installation :/ But once you have it, games can be compiled for the Windows store too :)
This last point is a pain, but if we properly help the user to install the required tools I guess it will be ok! For previews and quick exports, it will be as fast as now using HTML5. If users then want to export to native Android/iOS/Win/Linux/Mac games, then I think it's fair to ask them to install a few things.

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).

[desk467]

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.

[zatsme]

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!

[4ian]

Quick heads up: I've modularized almost all the engine and objects to be rendered with Cocos2d.
I'll release soon a version of GDevelop with a Cocos2d export.

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.
Exporting the game for native platforms is more complex as it needs a lot of tools to be installed (depending on the platform): I've started the explanations in the wiki page. I'll also need testers and writers to complete the steps for each platform. :)

[victorlevasseur]

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
écrit :

Quick heads up: I've modularized almost all the engine and objects to be
rendered with Cocos2d.
I'll release soon a version of GDevelop with a Cocos2d export.

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.
Exporting the game for native platforms is more complex as it needs a lot
of tools to be installed (depending on the platform): I've started the
explanations in the wiki page. I'll also need testers and writers to
complete the steps for each platform. :)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#238 (comment)

[4ian]

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.
Also, same thing here: we would need a wiki page with explanation on how to compile for Android - for now users will need to do it manually.

[brylie]

Great work! I am glad to help test the new exporter.

[4ian]

Cool! Feel free to try the new exporters and complete the wiki pages if you have some time or something is not clear. :)

[brylie]

@4ian which version of GDevelop should I use?

[4ian]

Use version 4.0.91, that you can download here: https://github.com/4ian/GD/releases
I also made threads about it on the forum :)

[blurymind]

I am glad you decided to go with cocos. Its still quite complicated to set up.
You know, perhaps you can go the Godot way - where they offer the exporter templates as a separate file that can be added to the engine.

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.
Will sfml be phased out if cocos becomes more integrated?

[4ian]

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!

[blurymind]

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> .