"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)"

Je sais pas ce que tu voulais dire pas là mais j'ai l'impression qu'il faudrait que tu redescendes sur terre.

Pour ce qui est du débat moteur maison ou moteur externe, il n'y a pas une seule réponse, la plupart des gens devraient utiliser un moteur externe si les royalties leur conviennent, tout simplement parce qu'il vaut mieux coder un jeu qu'un moteur. Maintenir une base de code d'un moteur de jeu c'est plus compliqué que ça en a l'air.

Avoir son propre moteur peut devenir avantageux quand une entreprise veut dans le désordre : Avoir des features que les autres n'ont pas (et donc avoir un avantage concurrentiel); Toucher des subventions pour R&D; ne pas payer de royalties; avoir la main sur l'essentiel du code (mais la plupart des moteurs ont une offre avec sources, on peut même avoir les sources de l'UE4 pour quelques euros par mois il me semble ?); etc...

PanzerKadaver>>"l'Unreal Engine, c'est plus compliqué vu que n'a pas le code source."

Au contraire, on a le code source à partir du moment ou on a payé les 20€ pour le moteur (et on peut ensuite résilier l'abonnement des 20€ par mois en ayant le droit d'utiliser sa version actuelle du moteur).
On a le droit de modifier le code du moteur, de recompiler le moteur, d'utiliser des librairies externes dedans.

En gros il y a les royalties qui reste comme inconvéniant mais 5% c'est vraiment pas énorme.

Paulop > J'entendais par là que, Unity (tout comme UDK), pour ne faire peur au "non-codeur" propose son propre langage "simplifié". Et c'est là que je grince des dents. Le code généré c'est en général du code qui n'est pas maîtrisé et qui pose des problèmes en terme de performance. De manière générale, je suis contre les outils qui brandissent la bannière du "code less, think more". Pour moi la programmation (et plus encore la programmation vidéo-ludique) ce n'est pas ça.

hexabeast > Sauf erreur de ma part, cette formule "Source code + moteur" n'est apparu qu'avec l'UE4. Comme quoi, les gens de chez Epic ont finis pas comprendre que cacher ce qu'il y a sous le capot, n'est pas la bonne solution.

"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."

Faut arrêter d'exagerer, ça sert a rien de vouloir faire de la micro-optimisation si c'est pour rendre le code moins lisible.

Si tu penses que ton bottleneck est sur le code généré tu te trompes.

Pour Unity, et sans doute UDK (mais UDK ça existe toujours ?), tout est écrit en c++, seule la partie scripting est en langage managé (sans doute transformé en c++ au moment de l'export).
La perte de performance ici est minime, a moins de taper un algo aberrant.

" Si tu penses que ton bottleneck est sur le code généré tu te trompes."

Ça veut dire quoi ça ? Hap

Que c'est la partie limitante du programme.

Je vois pas de quoi il parle la.

il dit "si tu pense que ton programme rame a cause de la partie code que t'as tapé tu te trompe".

C'était pour répondre à PanzerKadaver qui pense que le code généré par Unity ou autre est sale et mal optimisé.
Tu seras limité par bien d'autre choses avant que ça arrive.

C'est marrant j'ai une vision totalement à l'opposé de l'OP. Personnellement je ne travaille jamais sans m'appuyer sur des frameworks ou des outils qui me facilitent la tâche, et d'ailleurs dès que je développe je vérifie toujours si ça n'existe pas déjà quelque part. J'ai horreur de réinventer la roue et j'ai horreur du code maison. Genre quand je débarque chez un client et qu'ils m'expliquent qu'ils ont développé en interne leur propre framework alors qu'en gros ils ont réinventé un framework déjà existant (mais en moins bien forcément) j'ai envie de pleurer.

Maintenant mon avis est biaisé par le fait que :

(1) C'est mon métier, et en entreprise il faut savoir être efficace et rapide, tout en apportant des solutions pérennes et maintenables. En gros, n'importe qui doit pouvoir repasser derrière.

(2) La sécurité et la stabilité sont des facteurs bien plus importants que les performances car je développe des applications web et non des jeux

(3) Je suis un intrus sur ce topic, je fais du Java et je ne faisais que passer

Néanmoins quelque soit le langage ou les technologies utilisées, je pense que les problématiques sont les mêmes et que vouloir à tout prix faire du "beau code" en codant tout soi-même n'est pas forcément la bonne stratégie selon moi (avis purement personnel). Cela peut même devenir dangereux selon les deadlines de ton projet.

Tu as raison il vaut mieux coder et terminer son projet plutôt que passer 30ans sur le même bout de code.

Ah ok, désolé j'avais pas tilté.

Je pense qu'il faut intelligemment calculer le gain possible à utiliser un moteur/framework.

L'argument "oui mais c'est trop facile d'utiliser un truc tout fait" est un mauvais argument. Dans ce cas, il faut recoder un "windows" car c'est trop nul d'utiliser un OS tout fait ?
Pareil pour OpenGl, vaut mieux recoder les drivers et la couche basse soi même ? Recoder le moteur son aussi ?
Programmer son editeur 3D ?

Bref tout est possible et chacun est libre d'utiliser (ou recoder) les moteurs/outils.

Je pense qu'il faut réfléchir :
- Durée de développement (rentabilité)

Prendre un framework tout fait, c'est cool. Mais si il faut 2 ans pour le maitriser, cela ne fait rien gagner en temps.

- Portabilité

Quand on veut faire du web, de la console, du mobile ou du PC. Faut bien choisir ses outils/moteurs.

- Cout

Les moteurs deviennent abordables. Les indies prennent une grande place. Donc la question peut se poser maintenant (avant certains moteurs coutaient les yeux de la tête, la question ne se posait pas)

- Qualité

Faut que les outils utilisés (ou le code fait) permettent d'atteindre la qualité souhaitée.

Je pense qu'avec tout cela, chacun peut choisir sa techno.

Je rajouterais :

- Expérience
Mettre les mains dans le cambouis en montant son propre moteur est un plus indéniable pour l'expérience personnelle (et le CV). Toutefois, aujourd'hui, beaucoup de studio qui recrute demande une expérience minimum sur certains moteurs commerciaux.

Moi je code en java ( android oblige ), ceux qui font des jeux sur des wysiwyg sont des m**des

| https://www.jeuxvideo.com/forums/1-31-8678986-3-0-1-0-que-les-codeurs-c-levent-les-bras.htm#message_8679294
| Ecrit par « LeDictator », 27 mars 2014 à 19:37:12
| « Moi je code en java ( android oblige ), ceux qui font des jeux sur des wysiwyg sont des m**des »

En même temps,tu ne vaux pas mieux qu'eux étant donné que tu codes sur du Java au lieu de créer ton propre langage

OP : Il faut voir les moteurs de jeux comme des alternatives à ce qui se fait deja sur du "code pur" . Si un game designer,sound designer,concept artist ou environment artist veux créer son jeu,va-tu lui dire de faire son moteur de jeu ?

Je ne pense pas,et là c'est la même chose,le programmeur peut créer son propre moteur étant donné qu'il en a la possibilité,les autres vont utiliser des moteurs de jeux pour créer leur JEU . Et oui,dans ce débat de game engine VS code pur vous oubliez que nous voulons tous créer un jeu,qu'importe la technologie ou solution utilisé,parcequ'au final tout ce que vous aurez fait c'est crée un jeu,s'too

• L'important c'est juste de choisir une solution qui convient à vos attentes ainsi que vos compétences .

L'Unreal Engine 3 est un WYSIWYG, et a été utilisé par plusieurs des plus grosses entreprises en matière de création de jeux. Donc LeDictator pour toi ceux qui bossent dans ces entreprises sont tous des "m**des"?

Tout dépend de ce qu'on veut faire de son jeu. Ça sert a rien d'utiliser Unity pour un Snake par exemple