Petit à petit, les moteurs de jeu open source deviennent de plus en plus performants et de plus en plus complets. Parmi ceux qu'on surveille de près se trouve un certain Xenko. Anciennement connu sous le nom de Paradox, il est développé par Silicon Studio (3D Dot Games Heroes, Bravely Default...) et propose une liste de fonctionnalités impressionnante : éditeur complet, scripting en C# avec plugins pour Visual Studio, prefabs, PBR, DX12, Vulkan, support de la RV...

Il peut exporter des jeux sur Windows, iOS, Android, XO et Linux et bientôt PS4 et macOS. Il va même plus loin que Unity en proposant une application comme le Epic Games Launcher qui permet de télécharger et mettre à jour plusieurs versions du moteur ainsi que de choisir le projet qu'on veut ouvrir. Le seul bémol est la licence : GPL v3. Cela signifie que si vous compilez le moteur vous-même, vous devez publier le code source de votre jeu.

Une autre alternative à Unity est Godot. Sa licence MIT est nettement moins contraignante mais le moteur est techniquement moins avancé que Xenko. Il n'excelle ni en 2D ni en 3D et utilise son propre langage de script plutôt qu'un langage existant. Le fait qu'aucun jeu populaire n'utilise ce moteur n'est pas exactement bon signe. Pour un jeu purement 2D, on vous conseille plutôt Moai. Il est nettement plus brut de décoffrage mais propose du scripting en Lua et a fait ses preuves sur le terrain avec des jeux tels que Broken Age ou Invisible, inc. LÖVE est un autre moteur open source 2D avec scripting en Lua.

Enfin, si vous utilisez l'Unreal Engine, deux choses peuvent vous intéresser. Depuis la versions 4.15, il est désormais possible de transformer ses Blueprints en code natif afin de booster les perfs. Si les Blueprints vous sortent par les trous de nez, sachez que NC Soft a publié un plugin gratuit et open source qui permet de scripter en Javascript. C'est propulsé par la dernière version du moteur V8 qui est 100% ECMAScript 6 afin d'avoir des vraies classes. D'autres devs planchent sur du scripting en C#.

Lire la suite sur le site : Xenko : l'alternative à Unity ?.

Hum toujours rien qui soit facile comme un multimedia fusion porté pour la 3d.

Merci pour ces articles purement tech/moteur, ça m'intéresse toujours autant !

"Si les Blueprints vous sortent par les trous de nez, sachez que NC Soft a publié un plugin gratuit et open source qui permet de scripter en Javascript. C'est propulsé par la dernière version du moteur V8 qui est 100% ECMAScript 6 afin d'avoir des vraies classes. D'autres devs planchent sur du scripting en C#."

Ça va pas faire tout ramer ça ?
Tout ça parce qu'ils ne savent plus coder en C++ (ok c'est pas le langage du siècle) et gérer les pointeurs mémoires.

"Cela signifie que si vous compilez le moteur vous-même, vous devez publier le code source de votre jeu."
Certains ont l'air de dire que ce n'est que les modifs apportées au moteur qui doivent être sous GPL

Ha non rien dit, ils le disent eux même

but if you modify the code of engine, the GPL v3 License of Xenko Beta requires you to publish both your game code and changes made to Xenko.

paradiz a écrit :
"Cela signifie que si vous compilez le moteur vous-même, vous devez publier le code source de votre jeu."
Certains ont l'air de dire que ce n'est que les modifs apportées au moteur qui doivent être sous GPL

Ha non rien dit, ils le disent eux même

but if you modify the code of engine, the GPL v3 License of Xenko Beta requires you to publish both your game code and changes made to Xenko.

Nous serons d'accord pour dire que ce n'est pas la licence GPLv3 qui oblige ceci, mais plutôt Xenko.
La licence GPLv3 oblige effectivement que les modifications apportées au code source du logiciel (de Xenko) doivent être republiées sous cette même licence.

Si cette restriction était celle de la licence GPLv3 et donc portée à tous les documents créés par un logiciel libre, cela voudrait dire que tous les fichiers textes créés avec LibreOffice (en GPLv3 aussi) devraient être aussi publiés sous licence GPLv3 ! (ce qui n'est pas le cas)


La formulation de l'article est hasardeuse :
"Le seul bémol n'est pas la licence GPLv3, mais la volonté de Xenko".

Ce que je trouve très bizarre c'est que tout le code gameplay C# ajouté à xenko ne doive pas être lui aussi publié sous licence GPLv3. Dans ce genre de cas on utilise normalement la LGPL qui permet le linkage dynamique.

http://stackoverflow.com/questions/10130143/gpl-lgpl-and-static-linking

(rien à voir: petit bug javascript je présume, à chaque fois que j'ajoute une ligne à mon commentaire, la boite de dialogue s'agrandit d'une ligne. Elle est maintenant 4x plus grande que le commentaire que j'écris, ça me semble un peu foufou ^^)

Aisyk : ca depend beaucoup de la manière dont Xenko compile et de l'interconnection entre le code du moteur et le code du projet. Mais en général, la GPLv3 t'oblige dans de nombreux cas à publier le code de ton projet si tu modifies les sources. C'est pour cela que tout le monde la fuit comme la peste.

klownk : les Blueprints tournent 10 fois moins vite que le code natif selon Epic. Les moteurs Javascript sont devenu tellement optimisés qu'ils tournent largement plus vite que cela. Et C# encore plus.

Faut se méfier. J'ai fait quelques opérations super basiques sous Unity en C#, mais avec du gros volume, et les opérations Vector3 n'étaient pas inlinées (ça veut dire des appels de fonctions même sur les petites opérations) et tout un tas d'autres problèmes (j'imagine qu'Unity ne passe pas par SSE dans leur lib en interne, parce qu'au final ils pourraient peut-être vu qu'ils contrôlent l'interpréteur). J'ai pas essayé de faire des builds non dev avec, mais c'était beaucoup trop pénalisant pour pouvoir dev avec de toute façon. Du coup une boucle toute bête avec un calcul tout bête défonçait complètement les perfs (sans garbage collect, sans rien). J'ai passé ces calculs en plugin natif, et bam, gain massif en perfs (genre x10), avec du C++ et du SSE naïf, brute force. Je pense du coup que même si le C# arrive à s'optimiser assez loin en théorie quand on évite les conneries de base, il y a quand même de sacrés goulots d'étranglements qui ravagent assez vite dès qu'on fait un peu de volume.

Pareil une fois quand j'ai voulu générer quelques voxels à un moment, le simple fait d'avoir des millions d'objets alloués (objets C#, pas objets Unity), et même pas dynamiquement, ça faisait un coup de poing au framerate toutes les secondes. C'est le problème du garbage collect pas totalement ref counté, mais quand même, la limite arrive beaucoup trop vite. C'est très vite ennuyant parce que ça oblige à devoir s'organiser pas mal juste pour faire quelques tests. Avoir un langage qui bloque parce qu'on a quelques millions d'objets en mémoire c'est problématique pour beaucoup de problèmes. Du coup, même pour prototyper, on avance beaucoup plus vite en C++ dans ce genre de situations.

Après faut pas mal m'interpréter, pour des petits projets simples lambdas, tout ça c'est très fun et très bien. C'est juste qu'il faut bien rester dans les clous, même sur du prototypage.

Moi il me manque un truc basique et complet, genre Unity (sans tout le cirque qu'il y a dans un Unreal), mais avec un vrai pipe C++.

CBL a écrit :
Aisyk : ca depend beaucoup de la manière dont Xenko compile et de l'interconnection entre le code du moteur et le code du projet. Mais en général, la GPLv3 t'oblige dans de nombreux cas à publier le code de ton projet si tu modifies les sources. C'est pour cela que tout le monde la fuit comme la peste.

La licence GPLv3 n'oblige que de publier le code source du logiciel que tu as modifié, en l'occurrence le code du logiciel Xenko. La licence GPLv3 n'oblige pas à publier les projets de ce logiciel en GPLv3, c'est Xenko qui le mentionne et le souhaite, c'est son modèle de développement, il permet à Xenko de profiter des adaptations apportées par ses utilisateurs.
C'est un modèle critiquable, sans soucis, mais la formulation de ton article est imprécise.

La formule de ton article laisse à penser que dès qu'un outil est en GPLv3, tous les projets qui découlent de cet outil devront être publiés sous cette licence, ce qui est faux, relis la licence GPLv3.
As-tu une obligation de publier tous tes documents créés avec LibreOffice en GPLv3 ?!? Non évidemment. Tiens j'ai trouvé un autre logiciel avec une licence GPLv3, Blender. As-tu aussi l'obligation de publier aussi tes projets en GPLv3 ?!?
L'émulateur Mame aussi utilise la GPLv3... etc...

On parle de code source, pas d'assets. Et on parle de modifier les sources d'un projet GPL v3, pas d'utiliser les binaires.

Pour le reste, ce n'est pas Xenko qui impose ses propres règles. Tu ne peux pas modifier la GPL v3 à ta guise. Sinon ce n'est plus une license GPL v3.
Ils se contentent de décrire la réalité des choses et de mettre en garde les gens.

Ce ne sont pas les seuls. Ca dépend beaucoup de la manière dont est architecturé le code et de si tu compiles en statique ou en dynamique. Encore une fois, il y a une raison pour laquelle les gens fuient la GPL comme la peste et préfèrent des licences open source plus permissives type MIT, BSD ou Apache 2.0

CBLLe seul bémol est la licence : GPL v3. Cela signifie que si vous compilez le moteur vous-même, vous devez publier le code source de votre jeu.

Ta phrase est incomplète. Je peux très bien compiler les sources (pour avoir un logiciel adapté à mon système) et NE RIEN CHANGER au code tout en pouvant utiliser et publier mes travaux sous une autre licence. Là où ta formulation est inexacte c'est bien sur cette phrase.

Je connais les limites de la GPL, merci. Comme je te l'ai mentionné plus haut, c'est un modèle de développement critiquable mais qui a ses avantages.

La FAQ de la GPL en français : https://www.gnu.org/licenses/gpl-faq.fr.html#GPLAndPlugins

C'est sous-entendu. Pourquoi tu compilerais le moteur sans rien changer ? Par pur plaisir de perdre ton temps ?

Pour frimer dans les clubs de barbus.

CBL a écrit :
C'est sous-entendu. Pourquoi tu compilerais le moteur sans rien changer ? Par pur plaisir de perdre ton temps ?

Tu as déjà compilé un logiciel ? (tu plaisantes ?!?)

L'intérêt de la compilation d'un logiciel ? L'adapter à ton système.

Un exemple ? Les fonctionnalités spécifiques de certains processeurs, non prises en charge par défaut, certains logiciels sont compilés par défaut pour ne prendre en charge que 2 cores par exemple. Tu peux gagner en rendu sur des calculs importants. Demande à Pixar comment ils calculent leurs rendus sur leurs serveurs.

MrPapillon a écrit :
Pour frimer dans les clubs de barbus.

Tu n'es pas obligé de frimer dans les clubs de barbus :D

C'est un moteur de jeu. Tu ne veux pas qu'il soit adapté à ton système. Tu veux qu'il soit adapté à tous les systèmes si tu veux distribuer ton jeu. Si tu commences à modifier les options du compilateur pour tirer partie d'instructions spécifiques, tu te coupes d'une base potentielle de joueurs.

Oh et accessoirement :

"It means that if you use Xenko built from sources (either unmodified or modified), you must publish source of your game, as well as any changes to Xenko that you might have done (as per GPLv3 license)."

"certains logiciels sont compilés par défaut pour ne prendre en charge que 2 cores par exemple."
Le meilleur moyen d'utiliser plus de coeurs est de créer plus de threads. Si tu arrives à faire cela sans modifier le code, tu me fais signe.

CBL a écrit :
C'est un moteur de jeu. Tu ne veux pas qu'il soit adapté à ton système. Tu veux qu'il soit adapté à tous les systèmes si tu veux distribuer ton jeu. Si tu commences à modifier les options du compilateur pour tirer partie d'instructions spécifiques, tu te coupes d'une base potentielle de joueurs.

Tu peux avoir comme besoin d'économiser du temps de traitement de rendu pour tes scènes. Les options d'export de ton moteur de jeu te permettent de le rendre compatible avec les systèmes que tu souhaites.

Relis la licence GPLv3 (pas besoin du lien tu le retrouveras très facilement je pense).
Le code non modifié n'a pas besoin d'être redistribué, ni les projets tirant partie d'un logiciel construit à partir de ses sources.

CBL a écrit :
"certains logiciels sont compilés par défaut pour ne prendre en charge que 2 cores par exemple."
Le meilleur moyen d'utiliser plus de coeurs est de créer plus de threads. Si tu arrives à faire cela sans modifier le code, tu me fais signe.

Si les sources prennent en charge cette option, tu n'as pas à modifier le code.

Aisyk a écrit :Tu peux avoir comme besoin d'économiser du temps de traitement de rendu pour tes scènes. Les options d'export de ton moteur de jeu te permettent de le rendre compatible avec les systèmes que tu souhaites.

Encore une fois on parle d'un moteur de jeu. Le rendu est fait par la carte graphique. Modifier les options de compilation ne va pas changer grand chose. Quant à porter ton moteur sur differentes plateformes, modifier les options de compilation ne suffit pas. Il faut aussi modifier le code pour integrer le SDK.

Aisyk a écrit :
Si les sources prennent en charge cette option, tu n'as pas à modifier le code.

Yep et ce n'est surement pas en modifiant les options du compilateur que tu vas y arriver.

Pour le reste, je ne fais que citer Silicon Studio, un studio qui plus de 15 ans d'expérience et qui a été fondé par un ancien de Silicon Graphics.