Pour revenir à la 3D (désolé si c'est HS), excusez moi d'avoir parlé sans vraiment savoir (pour moi c'était 3D + C++ = Trop compliqué).

Cependant je me demande quels sont les intérêts de ne pas choisir la facilité (donc les moteurs) si elle est disponible? Le C++ fera en effet meilleur effet auprès des autres dev, mais le joueur, lui, s'en fout que son jeu soit fait avec Unity3D ou en C++, tant qu'il est divertissant et bien fait.

Je ne dis pas qu'il est mieux d'utiliser les moteurs, mais je demande aux gens qui préfèrent faire leurs jeux 3D en C++ les avantages de cette pratique pour le confort du développeur, et pour le joueur qui achètera/téléchargera le jeu.

Car étant peu expérimenté, de mon point de vue, je n'y vois pas vraiment d'avantages.

le développer maitrise son moteur si il le dev lui même ainsi il peut faire tout ce qu'il désire dans son jeu (si il en a les compétence), la seul chose qui empêche une personnes de faire un jeu 3d plus beau que n'importe quel moteur graphique et avec la richesse d'un dwarf fortress sont ses compétences

J'aime coder, j'aime les performances et je n'aime pas cette sensation désagréable d'être aux commandes d'une usine a gaz pleine de machines virtuelles qui est propre a ce que pond un moteur du genre d'unity. C'est comme minecraft java vs minetest en C++. Quand a dwarf fortress, je ne pense pas qu'il serait très performant sous unity. Et l'executable d'un programme vide qui pèse un poids conséquent car y a tout le moteur a embarquer derrière, non, je préfère souvent coder certaines choses en C. Après oui, c'est pas des jeux en 3D sur mobile, c'est sûr.

Je faisais du c++ avant mais après avoir été d'astreinte sur yoonity pendant quelques mois/années, je ne sais plus coder en c++, le c# m'a ramolli le cerveau.

Bah, ça aurait pu être pire... Genre, de l'objective-C.

Si tu fais un jeu directement en c++ avec opengl il sera plus portable que si t'utilise un moteur aussi.

Du moins a condition d'essayer de faire un trou portable hap

Ca encore, ça dépend des capacités du moteur, mais je n'aime pas du tout cette sensation de se trainer un énorme boulet au pied pour faire des petites applications. unity c'est bien quand on peut l'alimenter mais sinon ça vaut pas la peine, je préfère un environnement léger, un contrôle suffisant sur ce que je fais et un résultat avec lequel je n'ai pas besoin de rendre compte à des gens.

(Weeeeeee un premier débat sur mon sujet \o/)

Alors je viens apporter ma pierre à l'édifice et répondre à la question d'hexabeast (qui est "choisir la facilité").
L'idée de coder son propre moteur répond surtout à la problématique "faire moins pour faire mieux". En effet, un moteur fait maison ne sera jamais à la hauteur d'un moteur "Lourd" (on dirais que parle d'un char d'assaut) tel que Unreal/UDK, Unity, Cry Engine ou encore le nouvel arrivant, Snow Drop (si, si, vous savez, le truc qui vous a décollé la rétine quand vous avez regardé le trailer de The Division) mais dans la mesure où il sera codé avec amour avec nos petites patounes, ont en maîtrisera forcement toute les arcanes.

La maîtrise des arcanes des moteurs commerciaux étant forcément plus longue, on mettra plus de temps à sortir quelque chose de fonctionnel (ou tout du moins jouable). Au risque d'être narcissique je vais me prendre en contre-exemple. Je travaille depuis 1 semaine sur mon moteur maison, avec comme base la SFML. En 7/8 jour de travail j'ai déjà un asset manager, un layer manager, la gestion de plusieurs fenêtre et une architecture permettant de mettre en place un gameflow (le code est sur mon github, servez vous c'est open-bar). Tout ça, même si c'est très rudimentaire, marche comme je l'attend et mieux encore, je sais comment l'améliorer. En 7/8 jours sur Unity, je ne suis même pas sur que j'en serais au même point. Pire encore, je pense que j'ignorerais quel code à produit Unity pour que cela fonctionne (et je ne suis pas sûr de vouloir le savoir, ne serais-ce que pour éviter de les insulter en Allemand).

Et c'est là un de mes principaux arguments contre les moteurs qui se disent clé en main (je vise tout particulièrement UDK et Unity). Ne pas savoir comment fonctionne un moteur de jeu quand on est graphiste ou scénariste ça passe. C'est déjà limite-limite quand on est GD et c'est du foutage de gueule quand on se dit programmeur.

Ensuite tu parle d'avantage envers le joueur. Ce qu'il faut savoir c'est que même en maîtrisant bien le coté WYSIWYG de UDK/Unity, tu va certes arriver à un résultat graphiquement potable mais le gameplay risque de manquer singulièrement de profondeur car avoir une idée de gameplay c'est bien, savoir l'intégrer c'est un autre combat. Alors que, et je pense ne me contredira, si tu fait tout à la main, graphiquement ça sera moche mais ton gameplay sera au p'tits-oignons-frisou (comme on dit par chez moi).

Pour enfin rebondir sur, je te cite, "3D + C++ = Trop compliqué". Oui et non. Non car dessiné en OpenGL est relativement simple. Et Oui car pour arriver à un joli résultat, ça demande de bonne connaisse en mathématique dans l'espace.

Pavé terminé, j'attend vos réactions.

Merci pour la réponse c'est très clair et ça m'a permis de mieux comprendre le réelle utilité du C++ sans moteur.

Par contre je suis pas d'accord sur le gameplay, c'est pas très compliqué en général de changer le gameplay d'un jeu Unity selon ses envies (par rapport à juste du code C++ sans aucune interface pour voir les changements en live).

Sinon en quoi ne pas savoir comment un moteur fonctionne est problématique tant que ça fonctionne? quand tu fais du C++ tu sais pas comment le binaire créé par la suite fonctionne et pourtant c'est pas dérangeant (je sais pas si c'est un très bon exemple).

Bref sinon merci pour les infos!

Ne pas savoir comment ça fonctionne pose problème quand tu veux aller plus loin. Si tu n'a qu'une vision globale du fonctionnement d'un objet, le jour où tu veux faire mieux tu est rapidement bloqué par tout un tas de petits problèmes inhérent au fonctionnement dudit objet. Et si, je sais comment fonctionne un binaire (c'est pas très dur, ils fonctionnent tous pareil) =)

Je vois pas le problème perso, tout ceux qui utilisent sfml savent pas exactement comment ça fonctionne, et savoir comment utiliser opengl te permet pas de deviner comme la sfml gère tout ça elle.

" Et si, je sais comment fonctionne un binaire (c'est pas très dur, ils fonctionnent tous pareil) =)"

Bah en principe je pense pas que tu sais exactement quel est le code assembleur généré.

Pour détailler un peu plus ce que j'ai dis avant, une personne qui utilise unity va se douter de comment tout ça peut être géré, tout comme toi tu peux te douter d'en gros d'à quoi ressemblera le code assembleur, mais au final tu seras jamais précisément ce qui se passera.

Il y a détail et détail. Non effectivement j'ignore au mot près quel est le code assembleur généré l'ors de la compilation. En revanche je sais comment à quoi ressemble un "block" de code et quel sont ses effets sur la mémoire et la pile d’exécution. Rien qu'avec ça, tu pense ton code autrement et comprend pourquoi for pue, pourquoi switch est dégueu, pourquoi goto c'est l'enfer dans ton code et pourquoi les globales sont des monstres à bannir.

Ca permet aussi de se poser des questions d'optimisation intéressantes et de se rendre compte que même si il y a plusieurs manières d'écrire un algorithme, elles ne sont pas forcément toutes bonnes.

Encore une question! (oui je suis chiant
Quelle est la différence entre utiliser l'UE4 avec du C++ et utiliser n'importe quelle librairie comme Ogre ou SFML avec du C++ ?
Dans tout les cas on sait pas exactement ce qui se passe à l'intérieur du moteur / de la librairie, si?

Ogre et SFML est opensource mais peu de gens lisent le code donc on peut dire que ça revient un tout petit peu au même mais UE4 est un peu plus présent et bonne chance pour faire un petit jeu qui ne pèse pas dix fois plus lourd qu'un équivalent C++.

Je dirais que la principale différence viens du fait que Orge/SFML sont Open Source, ce qui fait que si tu veux te renseigner sur le fonctionnement en interne, tu peut. Avec l'Unreal Engine, c'est plus compliqué vu que n'a pas le code source.

Sinon ils sont aussi gratuits et te fichent globalement la paix au niveau des licences, tandis que l'UE4 risque de se montrer assez tentaculaire.

Pas faux, y a l'coté commercial aussi. J'avais zappé ce "détail".

C'est surtout ça qui est emmerdant, + les projets UE3 ne sont pas compatibles UE4, pas moyen de faire de la maintenance soit-même sur le moteur, ça veut dire qu'on dépend directement du bon vouloir d'epic games. Ces questions de perennité me semblent intéressantes aussi.

C'est vrai que c'est un point intéressant. Aujourd'hui beaucoup de gens aujourd'hui se lancent à fond dans Unity. Si dans 5 ans, le moteur disparaît, pas mal de jeux vont "mourir" faute de maintenance. J'ai aussi tendance à penser qu'un moteur "fait main" aura une courbe d'évolution moins haché et plus durable.