Salut,

Depuis un moment j'ai vu des personnes définir le BGE comme limité, ce qui n'est pas vraiment faux si on le compare aux autres gros moteurs. Mais les "limites" évoqué sont souvent liées aux gameplay, ce qui étrange puisque c'est le point le moins limité ...

Après 5 ans à tester de long en large le moteur je n'ai jamais été limité par la logic sauf en surchargeant le processeur avec des codes beaucoup trop lourd (ce qui est rare).

Comme je vais allez mettre mon nez dans le code source du moteur et essayer d'y ajouter quelques fonctions, j'aimerais bien savoir qu'est-ce qui vous limite ?
Et si vous vous êtes mis à utiliser un autre moteur comme unity ou UDK, qu'est-ce qui a motivé votre choix ? Qu'est-ce qui vous limitait sur blender ?


Et si vous avez des idées d'amélioration pour le BGE, n'hésitez pas.

@+

Les limites selon moi, qui ne sont pas forcément celle "absolues":
- perfs trop mauvaises passé un certain stade.
- ce n'est pas vraiment une limite à proprement parler, mais le manque d'outil prédéfinis/facile à mettre en place, pour par exemple du pathfinding, fait perdre du temps.
- peu de filtre graphiques sans passer par du GLSL.

Tout ceci est discutable bien sûr, mais puisque tu demande

Avec une bonne optimisation on peut faire beaucoup de choses je pense, la seule limite c'est de savoir bien coder.
Moi je suis passé sur unity parce qu'il avais besoin de moins d'optimisation, mais blender à ces avantages parce que de modeliser puis importer tout les assets entre plusieurs logiciels avec unity c'est chiant..
Un système de particule serait bien car ça peut être assez chiant de faire soit même son système.

Je ne sais pas si on peut parler de limites, mais il y 3 points qui me gênent pour l'instant:

1. Pas de support réseau pour le multiplayer (et les tentatives actuelles me semblent bien insuffisante, ne serait-ce que pour un jeu de type FPS limité à 16 joueurs). Pour l'instant, on bricole de ce coté là.
2. Pas de portabilité digne de ce nom pour les exports vers les mobiles ou les consoles. Rien de très concluant non plus coté web.
3. Impossibilité de créer de véritables tâches qui sont exécutées en //. Et quand on fork le process, on se retrouve avec le player complet qui est forké !

Donc, si je devais bosser sur des améliorations du BGE, c'est surtout vers ces 3 points que je me tournerai. Pour le reste, je pense qu'on arrive toujours à contourner les limites par un code python ou un shader...

Je rejoins ce qui a été dit, il y a peu de choses vraiment bloquantes avec ce moteur. La seule grosse barrière technique insurmontable était le LOD, mais comme tu le sais c'est réglé.

Je dirais qu'il manque d'optimisation et surtout de fraîcheur dans la partie affichage. Je crois qu'il y avait un SoC sur le Viewport à ce propos.

Et puis comme le module présente peu d'intérêt général, quelques vieux bugs s'empilent.

Sinon je n'ai pas été arrêté par Blender, l'API Python étant complète à ce niveau, et permet de tout faire. Maintenant ce qui lui manque c'est énormément de facilité d'accès à toutes ces fonctionnalités avancées. C'est un peu comme Cycles, un moteur super efficace mais qui demande encore quelques contorsions pour son plein potentiel. C'est dommage parce que ça permettrait de développer plus en moins de temps. Et d'éviter d'avoir des scripts qui ne fonctionnent plus et qu'on ne sait pas corriger, parce qu'on n'a fait copier/coller vu qu'on n'y connaît rien en Python .
C'est un peu devenu un problème je trouve, de DEVOIR utiliser Python pour la moindre chose. C'est vraiment super et souple, et il est pas vraiment question de s'en séparer, mais bon vous voyez ce que je veux dire.

Un truc en passant aussi : les Nodes dans le Logic BGE, je vote pour ! Parce qu'en l'état, n'importe quel gars va trouver que du Python est bien plus lisible que n'importe quel amas de briques logiques connectées dans tous les sens, moi y compris. C'est un problème encore une fois, et les Nodes donneraient donc cette clarté supérieure d'organisation.

Sinon, pourquoi ne pas intégrer en dur des choses qu'une grande partie des gens utiliseront. Genre le script FPS Mouse, qu'on remplacerait par une option quelconque. L'inventaire aussi, et pourquoi pas un éditeur d'interface/HUD parce que là c'est vraiment archaïque. Et puis comme Lapineige le disait, des filtres graphiques ! Du Bloom / Correction RGB & HSL / DoF / Dispersion Colorimétrique / Vignettage / SSAO ou HBAO / FXAA & MSAA. A ce propos, quelqu'un m'explique pourquoi ils sont en brique logique et pas en param global du jeu ?

Voilà on a fait grosso modo le tour Map. Tu vas regretter d'avoir posé la question haha . Ah oui au fait, au risque de passer par le gros relou de service, mais est-ce que tu as bien regardé tout ce qui concerne l'implication des développeurs dans Blender ? Parce que ça serait bête de faire un truc dans ton coin et que cela ne soit pas accepté par les responsables pour une cause ou une autre. Le code est complexe et il y a pas mal de standards à respecter à ce que j'ai compris. Je te souhaite de réussir en tous cas .

Bonjour.

Je suis assez d'accord avec la plupart des choses qui ont été dites.

- Sur le pathfinding, on est très limité parce qu'il manque quelques steering behaviours (http://www.red3d.com/cwr/steer/). De plus, je ne sais pas s'il est possible le système des navmeshes pour ajouter des obstacles en cours de partie. Enfin, le système d'obstacle avoidance (RVO (reciprocal velocity obstacles)) produit des effets bizarres (je n'ai pas trop regardé le code source (blender KX_ObstacleSimulation.cpp, mais il me semble qu'il n'utilise pas la dernière version de la librairie RVO (Je suis pas sûr). Perso je travaille sur un autre système de pathfinding (Bon il sera sûrement pas aussi bien que celui de Blender, et il est en Python, mais il aura l'avantage de permettre l'ajout d'obstacles en temps réel... Enfin, je suis pas sûr que ça ne soit pas déjà possible avec une astuce dans le système de Blender). Donc si tu veux essayer de traduire mon système de pathfinding (qui utilise un algorithme très récent (jump point search) dans le code source de Blender, ça peut être rigolo.

- Sur les filtres GLSL, c'est vrai que ça serait bien d'avoir un set de filtres (et de shaders) un peu plus important à disposition dans Blender. Sinon, je ne sais pas trop où en est le projet Harmony (de Moguri je crois), mais il me semble avoir vu passer un message sur BA il y a pas longtemps, et je crois que ça avance. On attend toujours aussi avec impatience l'intégration shader water/underwater de Martins Upitis, mais si tu veux essayer de l'intégrer dans Blender, ça peut être un travail intéressant, bien que compliqué. Perso, j'ai laissé tomber le GLSL pour le moment par manque de doc compréhensible pour un noob. Il y a aussi le shader sky de Simon Wallner (inclus dans le .blend de démo du shader water/underwater de Martins Upitis), qui peut être bien intéressant à intégrer dans le code source pour de beaux cycles jour/nuit, et sûrement plus facile à implémenter que le shader water/underwater (dans le menu world par exemple :).

- Je suis d'accord avec Hooker95 sur un système de particules qui devrait être intégré à l'interface de Blender. Panzergame a fait un gros travail et une belle démo. J'espère que son travail sera intégré à Blender.
Sinon, le Xemitter de Solarlune (http://blenderartists.org/forum/showthread.php?204644-X-Emitter-V1-10-2-11-1-11-BGE-Particle-System-Bugfix) est vraiment sympa et facile d'usage, mais en python, donc peut-être moins performant qu'une solution intégrée au code source (enfin je sais pas). L'idéal serait de faire marcher la carte graphique pour gérer les particules mais bon, ça doit être sacrément compliqué.

- Sur le support du réseau, Agoose77 travaille en ce moment sur un addon multiplayer. Je ne l'ai jamais testé, mais je lui fait confiance pour pondre un truc intéressant. Sinon, il reste toujours la possibilité de jouer avec le module socket en python, et ça marche plutôt bien d'après les quelques exemples que j'ai vus. Mais bon, c'est vrai que l'implémentation d'une solution vraiment intégrée au code source de Blender peut être un travail intéressant.

- Sur le threading, je m'en suis déjà servi à plusieurs reprises et je n'ai jamais eu de problème. Pas le module multiprocessing, hein, le module threading. Couplé au module Queue, on peut faire du multitask sans problème (enfin je dis ça parce que je n'ai jamais eu de problème mais je ne dis pas qu'il ne peut pas y en avoir ). Par contre, là, je ne vois pas ce qu'on peut faire dans le code source de Blender.? (A quoi penses-tu Bénicourt?)

- Sur la portabilité vers les consoles et les téléphones, c'est vrai que c'est une lacune. Il faudrait trouver quelques développeurs qui connaissent bien à la fois Blender et le fonctionnement de ces machines... Je me demande si pour Unity, ils n'ont pas payé des développeurs professionnels PS3, XBOX, Android, Windows Phone etc... avec les sous qu'ils ont gagné en vendant la version pro d'Unity) pour implémenter l'export des fichiers créés dans Unity vers ces appareils...

Conclusion: Je me rappelle que Matpi disait que quand on commence à toucher au code source de Blender, c'est assez simple d'essayer de faire un filtre 2D. Ca pourrait être un bon départ, j'imagine. Sinon, l'implémentation du shader sky de Simon Wallner pour les cycles jour/nuit (qui peut peut-être être intégré comme un filtre 2D (?) ou dans le menu world (ça serait génial ça) peut être un travail super intéressant et stimulant j'imagine. Mais bon, je n'y connais rien au code source de Blender.

Bonne journée.

EDIT: J'avais pas vu que tu étais en train d'écrire un pavé aussi ebrain. Si j'avais su, j'aurais essayé de faire plus court

Personnellement, en tant qu'utilisateur occasionnel duBGE, (et non pas en tant que monstre comme vous :D), je dirais que ce qui m'a déjà le plus manqué, c'est principalement la gestion simple du multijoueur, ainsi que la portabilité vers mobile.

Salut,

Je ne connais pas réellement les limites du bge, mais je rejoins certaines choses qui ont été dites.

Implémenter freestyle ou quelque chose de similaire serait une bonne chose selon moi mais aussi permettre au débutant de faire un système de sauvegarde via les briques logiques, car là, on est obligé de passer par python.

C'est déjà dit, mais il manque aussi des filtres et des shaders, cela semblent complexes à coder en python, et ça rajoute un vrai plus graphiquement.

Salut

Il y a déjà eu beaucoup d'écriture( bon courage pour tout lire :D ), et je vais rajouter ma couche:
-Il faudrait à tout prix le support des textures procédurales, parce que ça serait énormément utile et beaucoup moins lourd dans les fichiers que un tas d’images packés dans les blend.
-Pour le système de sauvegarde je crois qu'il y a un truc dans les briques logiques mais j'ai jamais essayé.
-Ca serait bien que pour le ciel, on ne soit pas obligé de passer par une skydome et que ça soit vraiment en background( je sais pas si c'est vraiment possible).
-Il faudrait je pense un système de particule, avec une bonne interface de préférence.
-Je rejoint l'avis sur un éditeur d'HUD intégrées.
-Les nodes serait bien aussi, que ça soit pour les animations que pour les comportements, ça serait beaucoup plus lisibles je pense que des briques logiques ou plein de script packés eux aussi, et offrirait une plus grande lisibilité pour les débutant.
-En parlant de systèmes de particules, ça serait bien qu'il y ai un outil de level design permettant de placer aléatoirement, avec des paramètres, des objets à la manière d'un système de particules ( en pouvant faire varier la taille et l'inclinaison, voire des paramètres dans le matériaux)
-L'intégration d'une bibliothèque de matériaux serait bien, mais il serait mieux qu'elle fonctionne avec des textures procédurales.
-Il serait bien qu'ils y ait une bibliothèque de base pour les IA, avec des comportements comme suivre, patrouiller, etc...
-Au niveau du personnage, ça serait bien que quand on prenne la physics character, qu'ils y ait plus de paramètres comme: choisir entre un déplacement basés sur wasd ou zqsd, une caméra FPS ou TPS ou autre comme MOBA ou str, en plus des paramètres de saut, il faudrait des paramètres pour le mode furtif et course, genre la vitesse ...
-Un outil d'éditions de terrains puissant avec la possibilité de le sculpté pour en changer la forme et de peindre sur le terrains les différentes textures que l'on veut en suivant des courbes ou en freestyle ( à la manière de l'éditeur de map de Starcraft 2). Tout cela sans avoir besoin de passer par le sculpt mode ou le paint mode.
-Un système de ragdoll intégrées au code source( je crois pas qu'il y en ai, rectifiez moi si je me trompe)
-Pour en revenir aux animations, dans les nodes il faudrait pouvoir mixer des animations, avec en "fac" des paramétres comme des random ou des trucs comme ça ce qui permettrait d'avoir des animations comme trébucher de temps en temps par exemple.

Voila voila jpense que j'ai pas mis grand chose ...
Jpense qu'il y a beaucoup d'idées assez utopiques, mais quitte à donner des idées autant tout donner :)

A+ et bon lecture.

P.S: Si on touche au code source, c'est en python ou en C?

Salut!

Ce que j'ai toujours regretté chez le BGE, c'est le manque de performances. Jai toujours travaillé sur des ordinateurs peu puissants, et les jeux blender rament rapidement là où unity par exemple affiche 10× plus sans problème.
Python c'est cool, mais chez unity, le code est (à peu près) compilé, et il est exécuté 20 fois plus rapidement.
J'ai une fois essayé de travailler dans une équipe sur un jeu blender. Les graphismes étaient simples, mais le code s'exécutait mal sans raison. Certaines touches ne répondaient qu'une fois sur deux. Quand on a l'habitude de moteurs qui fonctionnent, ça rebute (énerve) très rapidement.