MANU est un nouveau moteur de jeux vidéo dont le principe est d'être intégralement visuel et de ne pas nécessiter de code. Pour l'instant, le moteur n'est qu'en alpha.
Vous pouvez obtenir le moteur en vous inscrivant sur cette page. Aussi, vous trouverez trois projets de démonstration des capacités du moteur :
deux exemples de jeux de plateformes 3D ;
un monde en voxel.
Le moteur est accessible sur Windows et MacOS (application non signée). Le moteur est développé en C++, C# et l'interface utilise Qt. Le rendu repose sur OpenGL 3.3. Sachant que c'est une version alpha, le moteur est principalement orienté sur la création de jeux de plateforme.
Les développeurs indiquent aussi que de nombreuses fonctionnalités prévues ne sont pas présentes dans le moteur (un éditeur de niveau, un éditeur d'interface utilisateur...). Le but de cet alpha est de recevoir les premiers retours de la communauté. D'ailleurs, avec cette version, il n'est pas possible de publier un jeu (mais il est toujours possible de partager son projet).
Est-ce qu'un nouveau moteur de jeux vidéo a sa place sur le marché ? Pensez-vous que l'approche no-code soit intéressante ? Croyez-vous qu'il est possible de faire tout type de jeu avec une approche no-code ?
Apple veut pousser sa propre API Metal au détriment de l'API Vulkan, mais le projet MoltenVK permet de traduire tous les appels Vulkan en Metal. Et l'API Vulkan fonctionne en native sur GNU/Linux et Windows.
Il serait intéressant de le comparer MANU avec Godot. Godot a déjà deux avantages de poids, sa licence libre et open source MIT et Gotdot fonctionne sur Windows, macOS, Linux, FreeBSD, OpenBSD et Haiku, alors que MANU est uniquement disponible sous Windows et macOS.
J'ai appris à mes dépens qu'ajouter une API graphique supplémentaire tardivement ça pouvait poser probème, souvent parce qu'on calque plus ou moins l'interface vers l'API graphique sur la 1ère API qu'on supporte; et c'était dans un cas assez similaire: j'avais un moteur OpenGL3.0-only, j'ai ajouté DirectX12; non seulement le fait que l'API soit plus moderne demande de gérer plein de choses différemment (le concept de Command List qui change la façon dont on soumet les commandes, le fait qu'il faille gérer l'upload asynchrone des ressources côté application plutôt qu'espérer que l'API va s'en charger...), mais aussi le fait que les API soient faites par des gens/entreprises différentes qui ont trouvé des solutions différentes à leurs problèmes (par exemple, activer/désactiver le depth test c'est global au contexte dans OpenGL, alors que dans DirectX12 on a une version différente du shader selon qu'il est activé ou non Je devrais dire le Pipeline State Object plutôt que "Shader" si je veux être strict mais bref)
Je pourrais aussi m'énerver et parler d'Unity qui a foiré l'intégration de l'API graphique spécifique à la Switch, qui fait qu'on se retrouve avec un rendu tout pété dans certains cas, et qui n'autorise pas à utiliser OpenGL4.5 ou Vulkan sur cette plate-forme pour contourner ces bugs (alors qu'ils ont été obligés d'intégrer ces APIs pour d'autres plate-formes et qu'ils ont pu les tester pendant des années. Et puis c'est un driver nVIDIA, donc on peut s'attendre à ce que ça fonctionne aussi bien).
Je ne sais pas quelles plate-formes MANU prévoit de supporter dans le futur, mais si c'est juste Windows et Mac, en effet supporter 2 APIs (DX11 et Metal) pour s'adapter au mieux à la plate-forme c'est pas la mort.
Le choix d'OpenGL 3.3 ne me choque pas tellement, du moins dans le cas de Windows, aujourd'hui OpenGL 3.2 est tellement supporté par les drivers que c'est presque aussi fiable de baser son renderer dessus que sur DirectX 9, en un poil plus moderne. Et quand on fait des jeux de plate-forme, pas forcément besoin d'avoir une API dernier cri. À l'inverse, la beta de The Machinery ne supporte que Vulkan pour l'instant, pour lequel on sait que les drivers ne sont pas tous au point (et là, pas de MacOS du tout :p )
Bof , c'est un peu le but d'un moteur de justement d'utiliser plusieurs API suivant la plateforme pour maximiser les performances.
Et le choix d'OpenGL 3.3 comme seul API gérer pour un moteur 2020 fait super tache.
Il faudrait qu'il gère Vulkan , voir DirextX pour la version Windows (et Metal pour la version MAC OS ).
il n'y a aucun intérêt qu'un moteur en alpha gère plusieurs api graphiques, il y a tellement de travail à faire au niveau du concept du moteur et de sa validité que faire du multi-plateforme et/ou multi-api c'est juste une pure perte d'énergie et de temps.
surtout que de nos jours, les api graphiques, c'est bonnet blanc et blanc bonnet, donc ajouter une api tardivement dans le projet ne sera pas la chose la plus difficile à mettre en place.
le choix de la stabilité d'une api comme opengl 3.3 assure déjà un bon gros parc de machines compatibles, et même si apple dégage opengl, ce n'est de toute façon pas pour tout de suite.
bref, je ne comprends pas le besoin d'avoir plusieurs api graphique, surtout pour un produit si jeune.
j'ai pas rencontré les problèmes que tu mentionnes, donc je ne vais pas commenter dessus, ça serait débile de ma part.
par contre tu dis que selon ton expérience perso rajouter une api tardivement c'est chiant, parce que tu tends à calquer ton api sur la première api graphique que tu utilises, mais dans ce cas, c'est quoi la somme de travail de penser de base ton api comme suffisamment générique pour supporter plusieurs api de base?
perso, pour l'avoir déjà fait, c'est chiant à crever, déjà que tu te tapes les différences entre les apis, tu te tapes aussi les différences entre les apis entre les différents systèmes d'exploitation. faire correctement de l'opengl 3.3 sur différents systèmes avec différentes cartes graphiques c'est chiant, et je ne souhaites cette expérience à personne, donc que ce produit ne gère qu'une api, pour moi, pour de l'alpha, c'est déjà suffisant pour tester le produit.
et point supplémentaire, tu n'utilises en général pas un moteur pour qu'il gère plusieurs apis graphiques, tu utilises un moteur pour qu'il gère le coté affichage (entre autre) à ta place et que de ton coté tu n'en ait pas à t'en soucier.
c'est quoi la somme de travail de penser de base ton api comme suffisamment générique pour supporter plusieurs api de base?
Bonne question, je vois mal comment évaluer ça sans d'abord connaître sur le bout des doigts toutes les APIs que tu voudras intégrer :p Sans compter que, au fil de la vie de ton moteur, les APIs seront peut-être mises à jours, ou que de nouvelles APIs incontournables apparaîtront...
Envoyé par Mat.M
attention l'intérêt d'un outil de dévélopement de jeux multi-plateformes ce n'est pas seulement que pour maximiser les performances c'est surtout dans une optique commerciale.
Bref ce genre d'outiil est destiné à être utilisé par le plus grand nombre et par le maximum de plateformes possibles.
Je suis d'accord que dans le cas de MANU, optimiser les perfs ne semble pas être la priorité et le style de jeux mis en avant (les platformers) n'est pas réputé comme étant celui qui pompe le plus les ressources, donc ils pourraient rester avec OpenGL3.3 pendant plusieurs années sans que les joueurs s'en rendent compte.
Envoyé par Mat.M
Unity pour des gros projets solides et commerciaux c'est un truc à ne pas recommander.
C'est pas que ça soit un mauvais outil mais on sera limité un jour ou l'autre pour étendre les fonctionnalités de cet outil.
Et en plus il faut payer des royalties à l'éditeur
Je suis complètement d'accord, malheureusement des clients RÉCLAMENT que leurs studios utilisent Unity quand ils commandent un jeu pour des raisons douteuses, du coup on se retrouve avec tous ces problèmes :'( Par contre Unity ne fait pas payer de royalties mais un prix fixe, c'est Unreal qui s'utilise gratuitement en échange de royalties...
Bof , c'est un peu le but d'un moteur de justement d'utiliser plusieurs API suivant la plateforme pour maximiser les performances.
attention l'intérêt d'un outil de dévélopement de jeux multi-plateformes ce n'est pas seulement que pour maximiser les performances c'est surtout dans une optique commerciale.
Bref ce genre d'outiil est destiné à être utilisé par le plus grand nombre et par le maximum de plateformes possibles.
Mettons que sur le marché il y ait 500 000 utilisateurs sous Linux, eh bien l'outil de conception de jeux doit se tourner vers ce marché
Envoyé par LittleWhite
Pensez-vous que l'approche no-code soit intéressante?
Croyez-vous qu'il est possible de faire tout type de jeu avec une approche no-code?
Catégoriquement non car si pour des petits projets ça peut être valable, pour des plus gros impossible d'ndustrialiser la production d'un jeu avec ce genre d'outil
Envoyé par Guntha
J'ai appris à mes dépens qu'ajouter une API graphique supplémentaire tardivement ça pouvait poser probème,
c'est pour ça qu'il est souhaitable de faire des couches d'abstraction mais pas trop non plus.
Déclarer un vecteur 3d ça se déclare d'une certaine manière avec Direct3d et de manière différente sous Open GL
Envoyé par Guntha
Je pourrais aussi m'énerver et parler d'Unity qui a foiré l'intégration de l'API graphique spécifique à la Switch.
Unity pour des gros projets solides et commerciaux c'est un truc à ne pas recommander.
C'est pas que ça soit un mauvais outil mais on sera limité un jour ou l'autre pour étendre les fonctionnalités de cet outil.
Et en plus il faut payer des royalties à l'éditeur
Quant au fait que MANU utilise une "vieille" version d'Open Gl ne pas perdre de vue que bon nombre de joueurs utilise des petites machines peu puissantes
pas de bol que certains exigent unity (c'est plutôt un bon produit, mais comme beaucoup pas pour tous les cas d'utilisation), en général on me demande "seulement" que ça ne coûte pas cher et que je vais devoir livrer pour l'année passée XD
Est-ce qu'un nouveau moteur de jeux vidéo a sa place sur le marché ?
Envoyé par stardeath
