L’univers du développement de jeux à besoin d’innovation.

Publié le par

Je l’avais déjà dit à l’époque du Gamescamp à Paris, le monde du jeu vidéo est très indulgent avec lui même concernant l’innovation. Nous avons tendance à penser que nous sommes très innovant alors que ce n’est pas nécessairement le cas. Certes nous avons pas mal de gens qui repoussent les limites du réalisme graphique, d’autres qui expérimentent de nouveaux modèles de narration mais dans l’absolu il y a un différentiel important entre l’innovation et notre sentiment d’innovation. Une preuve simple consiste à regarder la façon dont nous construisons les jeux, et plus précisément le langage d’application utilisé : c’est du C/C++ et ça fait bien 20 ans que cela dure.

Pourtant ces derniers temps le C++ a la vie dure, il suffit de voir le nombre de gens qui s’attaquent au C++ en lui même, une petite recherche vous confirmera que c’est récurent sans compter ceux qui voient dans la programmation objet un paradigme inadapté à l’architecture des ordinateurs modernes. Il faut dire que le C++ cumule pas mal de tares : langage difficile à compiler il propose une syntaxe très complexe quand on commence à regarder cela de plus près. Je pense que nous avons tous des cas de bugs tordus du à un cast implicite ou des séances de décryptage de message d’erreurs du compilateur parce qu’on avait utilisé des templates. En gros il serait peut être temps de passer à autre chose.

La question est bien entendu quoi ? Idéalement il devrait s’agir d’un langage compilé vu que nous sommes dans un domaine qui extrait la moindre goutte de performance de la machine. Cela écarte d’emblée les C# et autres Java sans parler des Ruby et Python. Il devrait s’agit d’un langage impératif, à la syntaxe claire, si possible « C Like » avec des facilités pour faire de la programmation multithreadée. J’aimerais bien aussi qu’il soit orienté objet tout en permettant de vraiment contrôler à bas niveau ce qu’on fait.

Parmis les noms qui reviennent après discussion avec un ami, le D et Go serait des candidats potentiels. Pour le Go j’ai juste peur que son approche limité de l’objet me révulse mais je suis près à étudier toute alternative. Bien entendu ce langage devrait être supporté sur un maximum de plateformes ce qui inclus dans notre cas les consoles de jeux. Or quand on voit la difficulté à produire des outils de développement par certains constructeurs de consoles on se dit que ce n’est pas gagné… même si la complexité du C++ n’est peut être pas étrangère à ça.

Dans tous les cas si l’on veut que cela progresse à ce niveau là il nous faudra du résultat scientifique, il nous faudra du middleware qui va avec, et plein d’autres choses. D’ailleurs cela me fait penser qu’il existe peut être déjà des retour sur l’UDK depuis sa sortie et sur les différences au niveau du développement constaté quand on utilise l’Unreal Script. Dans tous les cas, j’aimerais bien expérimenter.

  • http://www.alexandrefranke.com/ Alexandre Franke

    Je sais que ça va en faire rire ou sourire certains, mais tu as jeté un œil à Lisaac ?

  • http://www.puupuu.org Mokona

    Oui pour le D. Son nom est explicite : c’est le C++ tel qu’il devrait être.

    Après tout, Digital Mars fourni un compilateur C++ assez pointu. Je ne connais pas l’historique, mais j’ai l’impression que D est né de cette expérience.

    Et quand on voit que certains guru du C++ comme Alexandrescu trainent dans les parages du D (son livre vient de sortir), on est rassuré.

    Rassuré sur quoi ? Sur le fait de ne pas perdre plus de 20 ans de recherche sur le C++. Parce qu’on a beau dire (complexe, error prone,…), le C++ a généré une littérature abondante et pointue sur la manière d’architecturer un programme, comme le rendre efficace, le rendre lisible,…

    Et lorsqu’on regarde cette littérature, on s’aperçoit que si une partie ne s’applique qu’au C++ (pour justement gérer sa complexité) une autre très grande partie s’appliquerait à un langage similaire qui gommerait cette complexité…

    Google Go, j’ai essayé. Je pense que pour le moment, les problématiques qu’essaient de résoudre les contributeurs à ce langage sont très web-centered. J’y ai trouvé, au moment de mes essais (qui datent un peu), qu’il y avait derrière chaque chois le principe que le programme était freiné par des bases de données.

    C’est rarement ce qui nous freine en jeu vidéo (hors web).

    Go est aussi balbutiant sur ce dont je parle à propos du C++ qui ait : quelles sont les bonnes pratiques. Normal, le langage est neuf.

    C’est accessoirement ce que je reproche à Java et C# plus que leur nature de langage non compilé (dans leur natural flavor en tout cas). Quelques personnes se sont penchées sur ces problématiques en Java. En C#, je n’ai peut être pas trouvé le bon point d’entré, mais je n’ai trouvé que très peu de choses.

    Pour C#, on va dire que c’est normal : c’est le plus jeune. Mais aussi, Microsoft perturbe le langage en ajoutant et modifiant des features tous les 6 mois.

    Ça commence à être long, je vais peut-être songer à continuer sur mon blog :)

    Et on en reparle au prochain Gamecamp.

  • http://www.puupuu.org Mokona

    Ah si, j’ajoute un truc : ce qui me fait le plus peur sur D, c’est qu’après tant d’années d’existences, il soit accompagné de si peu de bibliothèques.

    C’est comme tout système de poule et d’œuf, il faut un déclencheur. Mais il n’est toujours pas là.

    Autre frein à mon avis, l’existence actuellement de deux branches du langage, dont la plus récente est beaucoup mieux, mais toujours annoncée béta.

  • http://www.fabienschwob.com Fabien

    Ça bouge pas mal autour de LLVM en moment, est-ce qu’il n’existe pas des trucs sympa de ce coté ? Où est-ce que l’aspect VM rend le trop lent ?

    Clang, le compilateur C (C++ ?) qui utilise LLVM semble avec des performances à l’exécution pas trop gênante pour ce que j’en ai lu.

  • Laurent

    Je suis tout à fait d’accord avec le titre même s’il enfonce une porte ouverte, pourquoi parler d’innovation en se bridant aux « compilé », « impératif », « orienté objet » ? Pas du C++ mais du C++-like, c’est carrément frileux comme démarche de recherche.

    Les langages non compilés capable de se transformer en runtime, les paradigmes comme le fonctionnel et la POA. Pourquoi ne pas commencer par s’intéresser à ces technos avant de limiter le panel de langages ?

  • http://www.bretzelsandgames.com Whirly

    On est en train de parler d’utilisation industrielle, pas d’une expérience à l’université. Sur les différents points :
    - « Non compilé », on est dans l’univers du jeu, il faut donc des performances donc on écarte de suite le non compilé.
    - Le fonctionnel, on a déjà essayé dans le monde du jeu et l’expérience n’a pas été très concluante, visiblement ça coince au niveau du recrutement où très peu de gens sont apte à coder en fonctionnel. De plus je ne suis pas convaincu que cela soit la formule miracle.
    - Pour l’orienté aspect, il me semble que ce truc n’a jamais décollé, pourquoi ? Actuellement on est plus dans une approche data centric au niveau des jeux que code centric.

  • Laurent

    Quelle genre d’innovation peuvent être apportées avec un changement d’outil ?

    J’arrive pas à voir où ce situe la marge de manœuvre dans le fait de reprendre les même paradigmes en fait. Changer une techno par sa cousine pour réduire les coûts et les temps de dev, ok, mais l’outil n’a pas ouvert de nouvelles portes il a juste réduit l’entrave au mouvement.

    Sur le fond je suis d’accord avec l’article, en parlant de productivité. Qui pourrait même rentrer en opposition avec l’innovation : on avance tête baissé dans ce qu’on connais.

    Je pense au temps libre chez Google, ça implique une perte brute en productivité assez énorme, pourtant niveau créativité et résultats net… j’admire ce genre de démarche, dans la culture d’entreprise plus que dans les outils.

    Pour répondre aux différents points vu que ça m’intéresse aussi :

    - Bosser avec un langage haut niveau et remplacer les bottleneck par du bas niveau c’est pas une solution viable pour un studio avec des moyens plus limités qu’un Ubisoft ou un Blizzard ?

    - Pour le fonctionnel, c’est un problème de recrutement et de formation plus que propre à la technologie en elle même, c’est pas en poussant par là qu’on peut innover plutôt que suivre ?
    Sans R&D je suis d’accord, c’est difficilement industrialisable, et le R&D c’est cher. Mais on le vois depuis la vague indé, les compromis qui sont fait jusqu’à présent ne sont peut être pas au bon endroit.
    Ma remarque est valable pour d’autres paradigmes et d’autres technos, j’en parlais en pensant à Naughty et Unchartred et parcque je trouve que le fonctionnel c’est quand même super élégant et inventif. J’ai aussi vu passer du code CAML chez MotionTwin et F# commence vraiment à faire parler de lui dans l’environnement .Net, donc il y a bien des solutions plus avancées que des publication dans Nature.

    - La POA est super jeune. De ce que j’ai vu dans wikipédia on parle d’une techno qui date des années 2000, dur face a la POO des années 70.
    Data/Code oriented, POA, POO aucun de ces concepts n’est exclusif, j’ai fait des expériences de moteur de jeu orienté données et les premiers concepts que j’ai voulu, sur papier, c’était du code qui se transforme (suivant les données justement) et des systèmes d’interceptions, c’est ce qui m’a fait rester sur un langage haut niveau et découvrir la POA.

  • http://www.bretzelsandgames.com Whirly

    L’idée c’était déjà d’avoir un langage bas niveau qui nous épargne pas mal des merdes habituelles qu’on a en C++ avec la syntaxe imbitable, les mecs qui se prennent pour les chevaliers Jedi du template et autre.

    Après par dessus rien n’empêche de construire autre chose, comme par exemple écrire le gros du code avec un langage dynamique et bénéficier des trucs genre duck typing.

    Pour le fonctionnel comme dit, nous sommes dans une logique industrielle et l’exemple de Google n’est pas vraiment en ligne, quand on a une cash cow qui fait qu’on se fait pas trop de soucis à court terme on envisage pas l’avenir de la même façon.

    Chez Naughty, c’est un gus qui a tapé un délire et fait leur script à base de Lisp. Au final ça a été une polémique en interne car il était le seul gus à vraiment comprendre les tenant et aboutissant du truc, et surtout au final l’aspect fonctionnel était pas très poussé c’était plus le langage qui servait à basculer trois flags et pour lequel il fallait 12 ans de formation pour faire un truc (j’exagère là, mais vous avez l’idée). Je pense que si on leur demandait, ils retenteraient pas l’expérience.

    Mais surtout à ce niveau là se pose la question des outils. J’ai moi même participé à un effort de développement de notre propre langage custom pour un jeu et au final c’est beaucoup de temps pour avoir au final une expérience en dessous de ce que l’on aurait eu en utilisant cash un standard du marché. Genre n’importe quel éditeur te fait de la coloration syntaxique du python, mais pas de notre langage Zyklag12.

    Pour la POA c’est un peu ce qu’on pourrait attendre des chercheurs : qu’ils se bougent le cul à tester les gains de productivités avec d’autres méthodes de programmation.