search

4ian / GDevelop

🎮 Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.
https://gdevelop.io
Other
10.76k stars 847 forks source link

Consider integrating/extending an existing game engine in GDevelop? #238

Closed brylie closed 6 years ago

brylie commented 8 years ago

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.

4ian commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.

4ian commented 8 years ago

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 commented 8 years ago

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

4ian commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

desk467 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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 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! :smile: (and a lot better than when packaging HTML5 games to Android/iOS with Cordova or Crosswalk).

desk467 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/4ian/GD/issues/238#issuecomment-198993148

4ian commented 8 years ago

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 commented 8 years ago

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

4ian commented 8 years ago

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

brylie commented 8 years ago

@4ian which version of GDevelop should I use?

4ian commented 8 years ago

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 commented 8 years ago

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 commented 6 years ago

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 commented 6 years ago

It would actually be a better fit for godot than unity imo :)

On Sat, 26 May 2018 01:19 Florian Rival, notifications@github.com wrote:

Closed #238 https://github.com/4ian/GD/issues/238.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/238#event-1647672162, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVYbrBUttZEokEXPT_BKqMdHHaJxqks5t2J-agaJpZM4HDA_f .