En ce qui concerne la question "pourquoi ne pas utiliser un moteur de jeu pour se concentrer uniquement sur le contenu ?"

Tout simplement parce que certains programmeurs (j'en fais parti) prennent tout autant de plaisir à designer et implémenter un moteur, qu'à faire des outils ou bien programmer la partie gameplay. Alors quand tu as :
- la possibilité financière
- le temps
- les compétences techniques
- le désir
Bah tu y vas !

Le principe étant quand même qu'il prenne son pied pendant le développement de son jeu :)

Surtout qu'il compte probablement ne faire que des jeux simples graphiquement.
Donc une fois la techno en main, ça donne un truc redoutable en flexibilité. C'est pas forcément pété de fonctionnalités comme un Unity, mais ça peut être customisé facilement en fonction des besoins. Et pas besoin de perdre du temps avec du support externe.

Netaie a écrit :
certains programmeurs (j'en fais parti) prennent tout autant de plaisir à designer et implémenter un moteur, qu'à faire des outils ou bien programmer la partie gameplay

Ouai, ça c'est quand t'as pas de réalité économique, de deadline ou de qualité derrière, on est d'accord (enfin perso, je vois l’intérêt que si c'est pour programmer une archi ou une feature novatrice, sinon ça a autant d’intérêt qu'un exercice scolaire).

Netaie : disons surtout que le mec a des couilles en beton armé vu qu'il a claqué tout le pognon de Braid dans un Myst-like vendu $40. Je suis content pour lui que ca ait marché mais c'était un sacré pari :)

MrPapillon : ba non au contraire. Il a fait un moteur pour un besoin précis. Dès qu'il voudra ajouter une fonctionnalité ou une plateforme à son moteur, il va en reprendre pour des des mois de dev. Il veut supporter la RV ? Dev. Il veut ajouter du multi ? Dev. Il veut ajouter de la physique ? Dev. Il veut passer sur Vulkan/DX12 ? Dev.

divide a écrit :
Ouai, ça c'est quand t'as pas de réalité économique, de deadline ou de qualité derrière, on est d'accord (enfin perso, je vois l’intérêt que si c'est pour programmer une archi ou une feature novatrice, sinon ça a autant d’intérêt qu'un exercice scolaire).

L'intérêt ? Le plaisir, le souhait de travailler avec une archi adaptée à sa façon de travailler ou celui de ne pas être dépendant d'une autre compagnie.

Après si effectivement tu n'as pas les compétences techniques c'est un suicide financier c'est certain. Tout dépend encore une fois du contexte : Temps, budget, compétence de l'équipe, envies. Mais il n'y a pas une bonne réponse générique à la question : Moteur interne ou externe ? :)

EDIT:

CBL a écrit :
Netaie : disons surtout que le mec a des couilles en beton armé vu qu'il a claqué tout le pognon de Braid dans un Myst-like vendu $40. Je suis content pour lui que ca ait marché mais c'était un sacré pari :)

Vu le parcours du gars et de son équipe technique, j'ai l'impression que ça n'a pas du le faire tiquer tant que ça :)

Il y a encore tout un tas de studios qui ont leur propres moteurs, ce n'est pas une exception.

Pourquoi le faire ? Pour contrôler la technique in-house ? Pour ne pas avoir à payer une grosse somme d'argent ou avoir à payer des royalties sur la durée de vie du projet ? Même les licenciés d'Unreal Engine continuent à faire du développement in-house sur une base plus ancienne (certains ont acheté la licence du 2 comme base il y a longtemps et ont continué à ajouter des features par ex).

Des gens qui développent l'Unreal Engine aujourd'hui ont fait leurs armes sur les moteurs maison (donc même Epic d'une certaine façon a besoin de ces compétences même si indirectement).

Disons que si on a vraiment des besoins particuliers pour un jeu, il est souvent plus intéressant de reprendre ce qui existe déjà, comme pour les mecs de Star Citizen qui ont adapté le CryEngine à leurs besoins. Par contre pour des jeux comme Elite:D qui ont certaines spécificités (aire de jeu de taille astronomique (même si les systèmes sont instanciés), énormément de procédural), vaut mieux en effet partir de zéro et créer un moteur adapté (et souvent on a pas le choix).

LeGreg a écrit :
Pour contrôler la technique in-house ? Pour ne pas avoir à payer une grosse somme d'argent ou avoir à payer des royalties sur la durée de vie du projet ?

Comme dit au-dessus, en montrant patte blanche, un studio motivé peux avoir accès au pipeline de rendu des principaux moteurs commerciaux. Y a donc moyen de les adapter (sauf besoins très spécifiques) et de les optimiser pour ton jeu.
Et les coûts des licences sont devenus très raisonnables, que ce soit pour des petits/moyens studios ou un pov'mec tout seul et fauché comme moi... Surtout par rapport au temps gagné sur les divers supports d'API et leurs màj, comme le dit CBL (par exemple sous Unity tu mets à jour le support de ton Rift en quelques clics).
EDIT: heureusement que le nombre d'édits n'est plus affiché :p

CBL a écrit :
MrPapillon : ba non au contraire. Il a fait un moteur pour un besoin précis. Dès qu'il voudra ajouter une fonctionnalité ou une plateforme à son moteur, il va en reprendre pour des des mois de dev. Il veut supporter la RV ? Dev. Il veut ajouter du multi ? Dev. Il veut ajouter de la physique ? Dev. Il veut passer sur Vulkan/DX12 ? Dev.

Oui, mais il n'y en a pas une infinité de ces devs. Et il pourra aussi faire une intégration minimaliste, contrairement à un gros middleware qui va devoir gérer tous les cas.
Carmack avait aussi cette approche sur ses id Tech, en gros tout faire en interne.
Avoir un gros moteur c'est aussi faire face à une grande complexité. Si le moteur custom est super minimaliste, c'est très facile de le modifier. Même avec les sources d'un gros middleware, et même dans un gros studio, c'est tendu de modifier. Déjà parce qu'on n'a pas l'expertise et qu'il faut gérer les conséquences court terme, et aussi devoir gérer la maintenance par rapport à toutes les futures mises à jour. Sans parler du support technique qui peut devenir complexe à cause des allers-retours pour expliquer les modifs customs.

Par contre un truc intéressant, c'est qu'il avait affirmé que si son langage custom avançait bien, il était pas contre démarrer la nouvelle prod' avec.

Carmack proposait un tas d'innovation graphiques que d'autres moteurs ne pouvaient pas faire, ça se justifiait. Et les id Tech avaient une valeur commerciale en eux-même.

Sauf qu'avec un bon middleware tu mets rarement les pieds dans le code du moteur. Ma boite utilise UE 4 et quand il fallait ajouter des fonctionnalités qui manquaient au moteur, on a codé des plugins. Et le middleware c'est pas juste un moteur. C'est des outils : éditeur de niveau, scripting, import des modèles 3D, intégration avec un soft de versionning...

Je comprends que pour des gros studios comme EA ou Ubisoft ca vaut le coup de faire sa propre sauce mais pour des petits indies c'est irréaliste. Des mecs comme Blow ou Carmack sont à part car c'est des dieux du code.

"Most of us would do well to remember that there is a reason Carmack is Carmack, and we are not Carmack.", Jonathan Blow, 2/1/2006

Pour ma part j'aurais fait aussi The Witness avec Unity. Je pense que le cas de Blow est un peu particulier parce qu'il a l'air de vouloir maîtriser de A à Z tout le contenu et la technique de ses jeux. Je pense que dans sa vision personnelle, le choix d'un moteur custom n'est pas forcément incohérent. Le chemin pour aller de rien à un truc minimaliste n'est pas forcément trop gigantesque.

Par contre le vrai soucis c'est les outils d'édition c'est clair. Pour le versioning c'est pas trop compliqué à son niveau, tout est en texte. Il a une approche minimaliste dans le genre Stingray. Les datas binaires peuvent se trouver sur un gestionnaire différent et gérées à la main. Le pipe d'import/export ça ne devrait pas être un gros problème parce qu'il ne gère qu'une toute petite équipe. Le script, j'imagine que Blow tape soit dans du C++, soit dans du Lua. Le visual scripting ça sert surtout dans des gros studios où tu embauches des gars sans bases de code. Mais c'est vrai que sur tous ces points, même s'il a un peu de flexibilité, la somme de travail est trop importante pour arriver à des outils aussi ergonomiques qu'un middleware dédié.

Pour moi, à part le cas de Blow et des moteurs avec des technos vraiment spécifiques, un moteur custom peut se justifier sur un jeu majoritairement procédural, mais ça reste encore assez rare.

MrPapillon a écrit :
Même avec les sources d'un gros middleware, et même dans un gros studio, c'est tendu de modifier. .

C'est sûrement vrai dans certains cas extrêmes, Star Citizen est encore un bon exemple, apparemment ils ont sué pour faire faire au CryEngine des trucs qu'il était pas censé faire (des phases FPS dans des vaisseaux en mouvement rapide.)

Le truc marrant, pour voir qu'utiliser un gros moteur de jeu style Unreal 4 d'Epic n'est pas anodin, c'est de mater les crédits section programmation d'un jeu utilisant cette techno. La liste est parfois assez impressionnante même pour des studios de taille moyenne et pour des projets techniquement pas complètement dingue. A côté de ça, tu as des studios, anciens certes, qui capitalise sur l'évolution de leur techno interne et leur pipe de production (10 ans d'itération tu commences à avoir un truc qui tourne bien sans aller chercher ailleurs pour certains).

Dans ma carrière pro, j'ai du utiliser deux fois un moteur externe : renderware pour un proto rapide d'un jeu sur PS2 qui n'est jamais sorti (le reste des projets de la boite étaient fait avec une techno interne) et unreal 4 (impressionnant et hyper touffu, mais on doit parfois toucher au code moteur pour corriger certains bugs, qui sont remontés à Epic mais forcément rapidement intégrés, ou pour des features qui peuvent manquer).

Un moteur perso, c'est aussi régulièrement associé à une plateforme dédiée, et ça permet d'optimiser bien mieux qu'avec un middleware. Naughty Dog n'aurait jamais pu faire The Last Of Us avec un moteur non-maison.

Je viens juste de tester le jeu dans un DK2, le support est pas tout à fait fini mais c'est jouable. Et c'est très chouette, je sens qu'en VR on va passer beaucoup de temps à flâner entre deux puzzles dans ce monde bariolé. Par contre c'est ultra-gourmand (apparemment même avec une 970, le jeu nécessite quelques optimisations), je vais donc mettre le jeu de coté en attendant un nouveau GPU (voire aussi l'arrivée du CV1, en espérant un support pas trop tardif du jeu)...

Jonathan Blow explique qu'il préférait avoir son propre moteur pour ne dépendre de personne lorsque les moteurs actuels ne seront plus maintenus : https://www.reddit.com/r/Games/comments/282l0k/jonathan_blow_on_using_his_own_engine_i_would/

Il y a plus de chances que le moteur unity ou UE4 tourne encore dans 20 ans que celui de the witness, maintenance ou pas.

Ze_PilOt a écrit :
Il y a plus de chances que le moteur unity ou UE4 tourne encore dans 20 ans que celui de the witness, maintenance ou pas.

C'est pas évident, regarde le RenderWare racheté par EA. Rien n'indique qu'il n'y aura pas un Bolloré qui va se saisir de tout ça et tout défoncer pour vendre des jeux sur mobiles. Un autre truc aussi, c'est que les licences peuvent changer, et ce qui est abordable maintenant pourrait devenir bloquant par la suite.

Ze_PilOt a écrit :
Il y a plus de chances que le moteur unity ou UE4 tourne encore dans 20 ans que celui de the witness, maintenance ou pas.

Mais si ce n'est pas le cas, il a plus de chance de réussir à faire évoluer son moteur plutôt qu'un moteur propriétaire.