Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

18/12/2009

Pitfalls of OOP par Tony Albrecht

A moins de vivre dans une cave (ou d’être un programmeur de jeu du Dimanche), il y a une grande vague de remise en cause des principes de la programmation orientée objet dans le contexte des moteur de jeu (au runtime hein, pas dans les outils).


Dernier exemple en date, cette présentation par Tony Albrecht (Sony) qui est littéralement en train de faire le tour du web en ce moment même :


http://research.scee.net/files/presentations/gcapaustrali...

 

Si vous êtes programmeur, rendez-vous service et prenez le temps de lire cette présentation: car même si vous n'êtes pas d'accord avec l'argument principal, vous comprendrez enfin pourquoi les codeurs moteurs passent leurs temps à raler :-)

10:50 Publié dans Code | Lien permanent | Commentaires (11)

Commentaires

Mouais. Un vieux sujet bien présent sur PS2 ressorti pour la PS3.

Ce qui me gène dans le discours, c'est qu'au final, il fait toujours de l'objet. Il passe juste d'un code objet naïf à un code objet muri. Pas besoin de taper sur l'objet lorsque l'on fait est juste changer de niveau d'abstraction.

Autrement dit : oui, je vois moi aussi passer une vague de remise en question de l'objet. Ce qu'elle a d'intéressant est plus dans la manière de voire le code gameplay, et les articles qui parlent de langages fonctionnels où de prolog-like pour faire tourner leurs IA donnent de bonnes pistes.

Par contre, les discussions interminables sur certaines mailing list ou forums (ou dans des conf) où le propos est globalement "l'objet, c'est mal, moi je préfère faire du C" révèlent généralement une mauvaise maitrise de l'architecture (ce n'est pas le cas de l'article ici, l'article ici a juste un titre accrocheur qui ne correspond pas au contenu).

Écrit par : Mokona | 19/12/2009

Plutôt d'une architecture naive vers une architecture pseudo-fonctionnelle. (le découplage dont il parle vers la fin est vraiment la marque de paradigme non-OOP)

@mokona : les avantages de la programmation fonctionnelle me semblent plus intéréssant sur le moteur et non sur le script. Pour le gameplay, je verrai plutôt des DSL.

Écrit par : Lionel Barret | 20/12/2009

Ce que j'ai pu voir (un rapport sur une conférence IA et la présentation de la programmation Gameplay de Uncharted 2), ce sont des DSL fonctionnels (des Lisp-like ou des Prolog-like dans la syntaxe, mais modifiées pour s'axer sur le jeu)

Écrit par : Mokona | 21/12/2009

@mokona : tu as un lien ou la référence de la conf ? ça m'intéresse. tiens, au passage, joyeux noel et bonne année.

Écrit par : Lionel Barret | 23/12/2009

Ouaip enfin c'est marrant tout ça, mais globalement une fois qu'on a monté le niveau de jeu du dev est ce qu'on ne risque pas d'être dans une situation merdique de "où est ce que je recrute les types". Genre les programmeurs en fonctionnels ça se trouve pas sous les sabots d'un cheval surtout à une époque où on a déjà du mal à trouver des gens capables de développer avec des ressources machines limités voir même d'arriver à allouer / désallouer de la mémoire correctement.

J'ai un copain qui a une boite qui fait du dev web en RoR, déjà à son niveau pour recruter c'est super chaud vu qu'en principe le truc qui tombe des arbres dans le monde web c'est des devs PHP ou Machin.Net. Et dans ces case là on trouve rarement du développeur pointu qui a capté des choses genre le MVC.

Mon but là c'est pas de vous dire que c'est une mauvaise idée, mais qu'il faut tenir compte de la facilité de recrutement / formation des gens quand on "design" la stratégie du futur en matière de dev.

Écrit par : Whirly | 26/12/2009

Tout à fait.
Le debug ne doit pas être aisé.
Autant que je m'en souvienne, empiler/dépiler des arbres récursifs pour comprendre ce qui n'a pas fonctionné, cela demande une certaine tournure d'esprit.

Écrit par : Serpico | 26/12/2009

@Whirly : c'est sûr que les ressources humaines sont le facteur limitant absolu. Ceci dit, la programmation fonctionnelle est assez bien adaptée à une représentation par graphe, ce qui peut permettre de créer certains tools très facilement utilisables. Tout dépend du pool de dev disponible, j'imagine que naughty dog (qui ont fait GOAL, IIRC) avait de bons devs fonctionnels sous la main.

@Serpico : après avoir un peu creusé le sujet, il me semble surtout que la prog. fonctionnelle est surtout très très mal enseignée, sa compléxité n'étant pas significativement supérieure à ce que doit maîtriser un dev c++. Reste la disponibilité des devs...(cf Whirly)

Écrit par : Lionel Barret | 26/12/2009

Pour avoir discuté avec des gens de chez Naughty justement le problème était que le mec qui avait introduit le fonctionnel était justement le seul à comprendre le bordel. D'ailleurs c'était résumé dans un billet de Gamasutra ou en gros ils expliquaient que l'usage de GOAL les avait coupé du monde extérieurs parce que non seuleument leur truc était fonctionnel mais en plus il était custom donc le marché contenait 0 gus avec de l'expérience sur leur langage.

Maintenant pour avoir fait pas mal de Lisp je dirais que c'est quand même un paradigme complètement différent sur lequel pas mal de gens plannent. Et c'était pas spécialement plus mal enseigné que la programmation orienté objet. Il faut dire quand même que le lisp avait un côté très académique avec un discours de type "de toute façon dans l'industrie ça sert à rien" et des outils qui sentaient le "vous ferez pas d'appli réel avec ça" à 3km, ça n'aide pas.

Après en C++ on ne maitrise bien entendu qu'un subset du langage, j'ai toujours à portée de main un pistolet avec tranquilisant si un dev veut m'écrire des typelists ou appliquer du Alexandrescu par le menu.

Écrit par : Whirly | 27/12/2009

Pourtant, ça marche :p

Je viens de passer un peu plus de deux ans à utiliser un moteur qui contient des typelists et des bouts d'Alexandrescu (du moins, fortement inspiré par).

Je n'en suis pas l'auteur, mais je n'ai eu aucun soucis à comprendre, le code était très clair. J'ai eu à modifier des bouts, et j'ai pu.

Mais ce n'étaient pas les couches gameplay, hein, c'étaient les couches les plus basses du moteur. Et ce n'est certainement pas ce que je pointerais comme "à améliorer" dans ce moteur.

Écrit par : Mokona | 29/12/2009

Le mot clef c'est "parcimonie".

Écrit par : Whirly | 30/12/2009

Et « pragmatisme ». Comme partout. Quand c'est une bonne réponse au problème, autant l'utiliser.

Il est vrai que quelqu'un qui vient de découvrir les templates a envie d'en mettre partout, juste parce que c'est neuf. Mais c'est vrai pour pas mal d'autres choses : quand cela vient d'être appris/découvert, ça ressemble à un Graal (cf. mes articles sur mon blog à propos des Graal).

Écrit par : Mokona | 01/01/2010

Les commentaires sont fermés.