Paladin : un nouveau projet de moteur de jeux en JavaScript, par la communauté Mozilla.

Le 06/09/2011, par LittleWhite, Responsable 2D/3D/Jeux
« Paladin » est le nom d'un nouveau projet Open Source de moteur de jeux pour le Web crée par la communauté Mozilla.

Paladin permet de faciliter les interactions 3D, notamment pour les jeux, en fournissant une bibliothèque de développement JavaScript.

Les objectifs sont :
- De rendre le Web (et Firefox) une plateforme plus attractive pour les jeux sur ordinateur comme sur téléphone portable ;
- D'aider les développeurs à concevoir des jeux pour internet en concevant un moteur de jeu 3D facile à utiliser ;
- D'encourager un développement amusant en utilisant les avantages des méthodes Agiles et de programmation extrême (c'est à dire: le développement conduit par les tests, la programmation par paire et la collaboration par communication vidéo).

Le moteur utilise actuellement CubicVR pour le rendu 3D et "ammo.js" (une compilation de Bullet utilisant Emscripten) pour la physique. Le chargement se fait à l'aide de "require.js". Le son est aussi d'actualité dans Paladin.

Bien que le projet n'en soit qu'à ses balbutiements, vous pouvez déjà découvrir quelques petits jeux, qui sont aussi utilisés pour tester le moteur.

Il vous est possible de participer au projet, ou simplement de communiquer avec l'équipe à travers un chat IRC ou encore par le biais d'un groupe sur Google.

Sources :

Paladin :

La wiki officielle
Code source
Bug tracker du moteur

Quelques jeux :

Code source des petits jeux
Étapes et rapport d'utilisateurs


Et vous :

Que pensez-vous du projet Paladin?
Pensez-vous utiliser un jour ou l'autre Paladin?

Les rubriques (actu, forums, tutos) de Développez


Poster une réponse Retrouver la discussion sur le forum

Avatar de Emmanuel Deloget Emmanuel Deloget
Expert Confirmé
le 08/09/2011

Citation:





Envoyé par _skip
Voir le message

En même temps, on peut se poser la question de savoir si de nos jours on n'essaie pas, à n'importe quel prix, de faire de javascript ce qu'il n'est pas. Peut être qu'il est plus adapté pour faire un peu de DOM plutôt que des jeux et des RIA? Question ouverte.

Bonne question.

Javascript est (probablement) l'un des meilleurs langages existant - multiparadigme, ouvert, remarquable du point de vue conception, et jusqu'à il y a peu souffrant de sont image de langage interprété. Avec l'avènement des compilateurs JS, il s'est débarrassé d'un poids important qui pesait sur son évolution future.

Est-il possible de faire de la 3D en JS ? Oui - j'en veux pour preuve WebGL. Est-ce que ça sera suffisant pour faire des jeux complets et intéressants ? Oui, j'en veux pour preuve Entenglement et Angry Birds (version Chrome). En 3D ? Ca reste à prouver, mais il est fortement aidé par les avancées dans le domaine des technologies de compilation et des progrès en termes de puissance des machines cible.

A l'heure actuelle, la complexité du contenu des jeux vidéos et plus limitatives que les technos qui sont utilisées pour leur développement. Les téléphones portables récents sont capables de faire tourner des jeux en 3D complexes (cf. la démo Unreal sur iPhone, ou d'autres jeux 3D comme Nova ou Nova 2 pour iPhone ou Android).

Avoir des jeux 3D dignes d'intérêt dans un navigateur n'est absolument pas impossible. Maintenant, est-ce au "vendeur" de browser de proposer un moteur de jeu complet ? je ne pense pas. Le browser doit se comporter comme un OS : proposer un accès au hardware, et laisser le programmeur décider de la marche à suivre. Dans le cas contraire, on élimine quelque chose de fondamental dans toute entreprise de développement : la créativité des programmeurs qui sont capable de tirer d'une plateforme quelque chose que cette plateforme n'est pas censé pouvoir proposer (multiples exemples de ça : le mode X des premières cartes VGA, l'effet wobbler sur Amiga (? ou pas ; j'ai pas une mémoire infaillible), ...). Plus on propose un accès complet au hardware, moins on limite le programmeur - même si on lui complique la tâche.

Un autre problème du JS (et des jeux via browser interposé) est qu'il doit être sur la machine client pour s'exécuter. Du coup, une fois tous les scripts récupérés, un "pirate" peut proposer le même jeu sur son site web. Il devient difficile de monétiser les jeux écrits en HTML5, à moins de trouver une solution pour que le jeux ne soit jamais complet sur la machine du joueur. Chrome NaCL permet probablement de limiter la casse à ce niveau, au prix d'une incompatibilité avec les autres browsers (ce qui est quand même ardu, vu le principe des technos web).
Avatar de LittleWhite LittleWhite
Responsable 2D/3D/Jeux
le 08/09/2011
Alors, j'ai fait un test.
Pour récupérer les fichiers du moteur:

Citation:




git clone git://github.com/alankligman/paladin.git

Du jeu:

Citation:




git clone git://github.com/mozilla/rescuefox.git

(Ok, je suis sous GNU/Linux Firefox 6)

Il y a des makefile, donc je lance make.
Comme premier résultat il m'indique

Citation:




Creating ./dist
Creating ./external/CubicVR.js/dist/CubicVR.js
make[1]: entrant dans le répertoire « /tmp/paladin/external/CubicVR.js »
make[1]: *** Pas de cibles spécifiées et aucun makefile n'a été trouvé. Arrêt.
make[1]: quittant le répertoire « /tmp/paladin/external/CubicVR.js »
make: *** [external/CubicVR.js/dist/CubicVR.js] Erreur 2

Bon, ok, il me manque CubicVR qui est un projet lié (je ne sais pas utilisais git, donc il peut y avoir plus simple pour faire ça).
Je vais donc dans le répertoire external et je récupère CubicVR

Citation:




cd external
git clone git://github.com/cjcliffe/CubicVR.js.git

Comme je suis prévoyant, je récupère qunit qui est aussi lié par le projet Paladin.

Citation:




git clone git://github.com/jquery/qunit.git

Je suis prêt à faire la compilation

Citation:




cd ..
make

Nouvelle erreur:

Citation:




Creating ./external/CubicVR.js/dist/CubicVR.js
make[1]: entrant dans le répertoire « /tmp/paladin/external/CubicVR.js »
Building ./dist/CubicVR.js
Building ./dist/CubicVR.min.js
Finished, see ./dist
make[1]: quittant le répertoire « /tmp/paladin/external/CubicVR.js »
Building ./dist/paladin.js
/bin/sh: node: not found

(On avance )

Il me faut installer 'node'

Citation:




aptitude install node

Puis je passe à l'erreur:

Citation:




axconfig: port 1 not active
axconfig: port 2 not active

Il semble que la compilation/build ne soit pas nécessaire pour faire tourner les tests. Mon navigateur les passent tous. Ok. Maintenant, le jeu
Je copie le dossier "paladin" dans le dossier "external" du jeu.

La compilation du jeu échoue immédiatement:

Citation:




/bin/sh: f: not found
make: [check-lint] Erreur 127 (ignorée)

Et lorsque je tente le lancement du jeu comme cela (par la page index), j'ai une page blanche.
Chrome dit qu'il plante.

Donc, voilà, ce n'est pas très concluant pour le moment.
Avatar de Flaburgan Flaburgan
Modérateur
le 09/09/2011

Citation:





Envoyé par Emmanuel Deloget
Voir le message

Javascript est (probablement) l'un des meilleurs langages existant

Quand j'ai lu ça, j'ai pleuré.

Et puis finalement, la suite n'est pas tellement vide de sens. Mais j'aimerais bien des détails quand même. JavaScript reste interprété, non ? Donc niveau performance, avant d'atteindre celles d'un langage compilé, il y a un gouffre.
Les compilateurs JS dont on parle sont donc intégrés dans les navigateurs, qui commencent par compiler les scripts avant de les exécuter pour palier à ça ?

Mais tout cela ne profite pas de l'accélération matériel ? Rien ne passe par le GPU ? Comment alors faire des jeux 3D à la fois réalistes et fluides ?

Et la question finale : Est-ce que, au final, le seul logiciel ouvert dans notre ordinateur sera le navigateur ? On jouera avec, on ira voir ses mails, on aura ses photos en ligne, notre suite bureautique aussi...
Est-ce que google et Chrome OS avait raison ?!
Avatar de LittleWhite LittleWhite
Responsable 2D/3D/Jeux
le 09/09/2011

Citation:





Envoyé par Flaburgan
Voir le message

Mais tout cela ne profite pas de l'accélération matériel ? Rien ne passe par le GPU ? Comment alors faire des jeux 3D à la fois réalistes et fluides ?

C'est là que WebGL et WebCL intervenaient, en donnant accès au GPU pour la 3D et le calcul parallèle. Donc si, il y a accélération matérielle, et cela peut aller assez loin


Citation:




Et la question finale : Est-ce que, au final, le seul logiciel ouvert dans notre ordinateur sera le navigateur ? On jouera avec, on ira voir ses mails, on aura ses photos en ligne, notre suite bureautique aussi...
Est-ce que google et Chrome OS avait raison ?!


Sachant que Google est un grand acteur d'internet (et qu'il participe aux discussions sur les évolutions du web), c'est l'idée qu'ils vont vouloir faire passer. De plus, c'est l'idée du web futur (et ça se voit) que tout sera sur Internet, et que nos PCs ne seront plus que des terminaux intégrants un client HTTP.
Avatar de Flaburgan Flaburgan
Modérateur
le 09/09/2011
Personnellement, ça me fait vraiment peur que les navigateurs arrivent à accéder au hardware. Déjà jusqu'à maintenant c'était un bazar pour expliquer à l'utilisateur lambda de pas cliquer et installer du bordel n'importe où, mais s'il suffit d'un simple bout de javascript pour accéder au coeur de l'ordinateur, j'imagine déjà les abus. Enfin, il faut se rassurer en se disant que de toute manière, puisque l'ordinateur ne sera qu'une interface et que tout sera sur Internet, le lambda ne se fera pas effacer ses photos de vacances.
Et là arrive le problème de la vie privée.
Avatar de LittleWhite LittleWhite
Responsable 2D/3D/Jeux
le 09/09/2011

Citation:





Envoyé par Flaburgan
Voir le message

Personnellement, ça me fait vraiment peur que les navigateurs arrivent à accéder au hardware. Déjà jusqu'à maintenant c'était un bazar pour expliquer à l'utilisateur lambda de pas cliquer et installer du bordel n'importe où, mais s'il suffit d'un simple bout de javascript pour accéder au coeur de l'ordinateur, j'imagine déjà les abus. Enfin, il faut se rassurer en se disant que de toute manière, puisque l'ordinateur ne sera qu'une interface et que tout sera sur Internet, le lambda ne se fera pas effacer ses photos de vacances.
Et là arrive le problème de la vie privée.

Flash ne le ferait-il pas depuis longtemps ?
Sinon, réponse un peu plus sérieuse, il y a eu un grand recule par rapport à WebGL, notamment du point de vue sécurité, ou des failles avaient été remarqué dans le modèle même de l'API. Du coup, on en parle plus (et puis le support était moyen). C'est pour cela que je pense que Paladin repose sur "CubicVR" (Je ne sais pas ce qu'il y a derrière).
Vie privée ... hum, beaucoup sont sur Facebook ...
Avatar de Emmanuel Deloget Emmanuel Deloget
Expert Confirmé
le 09/09/2011

Citation:





Envoyé par Flaburgan
Voir le message

Quand j'ai lu ça, j'ai pleuré.

Faut pas Je n'ai pas dis ça au hasard non plus

JS est un langage multiparadigme (impératif, objet, dynamique, fonctionnel) supportant la méta-programmation au run-time (JS peut produire du JS au runtime, et l'exécuter via eval()), le lambda calcul et les fonctions / méthodes / objets anonymes, etc. Il est extensible, syntaxiquement bien conçu, relativement facile à lire, et supporté partout. Les récentes recherches ont montré qu'il était compilable (cf. le v8 engine de Google, ou l'équivalent dans Firefox).

Cite un seul langage qui supporte tout ça, tout en restant simple d'utilisation


Citation:





Envoyé par Flaburgan
Voir le message

Et puis finalement, la suite n'est pas tellement vide de sens. Mais j'aimerais bien des détails quand même. JavaScript reste interprété, non ? Donc niveau performance, avant d'atteindre celles d'un langage compilé, il y a un gouffre.

Et bien, plus tout à fait. JS peut être compilé nativement (c'est ce que fait v8).


Citation:





Envoyé par Flaburgan
Voir le message

Les compilateurs JS dont on parle sont donc intégrés dans les navigateurs, qui commencent par compiler les scripts avant de les exécuter pour palier à ça ?

Exact. Sans ça, un produit comme Gmail ou Zimbra serait difficile utilisable sur les ordinateurs récents.


Citation:





Envoyé par Flaburgan
Voir le message

Mais tout cela ne profite pas de l'accélération matériel ? Rien ne passe par le GPU ? Comment alors faire des jeux 3D à la fois réalistes et fluides ?

L'accélération matérielle est possible via des API spécifiques - comme WebGL, qui va être retravaillé.

Histoire d'être clair : ça ne pose pas de problème de sécurité majeure (à moins d'une faille, qui peut être au niveau du concept ou au niveau de l'implémentation). La sécurité est assurée par le navigateur, qui ne propose que des API qui sont censées ne pas permettre à une application tierce de faire ce qu'elle veux. Pour simplifier, le code est exécuté dans une sandbox, et les E/S de cette sandbox sont contrôlés de manière drastique.

Après, si une faille est présente, c'est une autre histoire. Mais dans l'esprit, le fait d'accéder au hardware n'est pas un problème (après tout, on accède déjà au clavier, à l'écran (via la page web), à la souris, etc).


Citation:





Envoyé par Flaburgan
Voir le message

Et la question finale : Est-ce que, au final, le seul logiciel ouvert dans notre ordinateur sera le navigateur ? On jouera avec, on ira voir ses mails, on aura ses photos en ligne, notre suite bureautique aussi...
Est-ce que google et Chrome OS avait raison ?!



C'est le principe de ChromeOS et des clients dit légers. Ils ne sont quand même pas prêt de s'imposer (c'est plus un retour en arrière qu'autre chose : après tout, c'est le principe d'un terminal X).
Avatar de jeroy jeroy
Membre régulier
le 09/09/2011

Citation:




Javascript est (probablement) l'un des meilleurs langages existant

Sur le papier, quand on liste les fonctionnalités, effectivement ça parait être le cas. Le problème c'est que justement, il n'y a pas que la liste des fonctionnalités et des API qui compte.

Particuliérement pour faire un jeu. Un vrai jeu c'est de la programmation "in the large" : http://en.wikipedia.org/wiki/Program...g_in_the_small

Ce qui compte avant tout c'est la possibilité de mettre en place une architecture, et que cette architecture soit solide. Solide ça veut dire débuggable: ça veut dire typage fort (et son corollaire, les templates), gestion de la visibilité des membres de classes, classes abstraites, et interfaces.

Et pour l'instant JS c'est plutôt "in the small", puisque ces fonctionnalités-là ne sont pas au programme.

Javascript est un langage certes riche et plaisant, mais pas un langage "in the large". Ce n'est pas le meilleur langage pour faire des jeux vidéos. Unity a lâché le support de leur ECMAscript pour forcer le C#, Google fait tout via GWT (Java). Pour de petits jeux oui, pour de gros jeux, des solutions comme Flash, NaCL, Unity/C# tiennent mieux la route IMHO.

Donc Paladin c'est probablement génial, mais pour des petits jeux.
Avatar de LittleWhite LittleWhite
Responsable 2D/3D/Jeux
le 09/09/2011
De plus, si j'en crois les propos d'un prof que j'ai eu (je n'ai pas de raison de croire le contraire), le JavaScript existe en plusieurs versions, et les navigateurs ont tendance à supporter chacun leurs propres versions. Nous avons plus de 4 moteurs JavaScript, ce qui veut dire que la compatibilité peut être dur à avoir avec un code simple.
C'est un peu dommage. Et c'est peut être aussi pour cela (ou qu'ils utilisent des features uniquement sous Firefox aussi) que Paladin fait crasher Chrome.
Avatar de Emmanuel Deloget Emmanuel Deloget
Expert Confirmé
le 09/09/2011

Citation:





Envoyé par jeroy
Voir le message

Sur le papier, quand on liste les fonctionnalités, effectivement ça parait être le cas. Le problème c'est que justement, il n'y a pas que la liste des fonctionnalités et des API qui compte.

Particuliérement pour faire un jeu. Un vrai jeu c'est de la programmation "in the large" : http://en.wikipedia.org/wiki/Program...g_in_the_small

Ce qui compte avant tout c'est la possibilité de mettre en place une architecture, et que cette architecture soit solide. Solide ça veut dire débuggable: ça veut dire typage fort (et son corollaire, les templates), gestion de la visibilité des membres de classes, classes abstraites, et interfaces.

Et pour l'instant JS c'est plutôt "in the small", puisque ces fonctionnalités-là ne sont pas au programme.

Javascript est un langage certes riche et plaisant, mais pas un langage "in the large". Ce n'est pas le meilleur langage pour faire des jeux vidéos. Unity a lâché le support de leur ECMAscript pour forcer le C#, Google fait tout via GWT (Java). Pour de petits jeux oui, pour de gros jeux, des solutions comme Flash, NaCL, Unity/C# tiennent mieux la route IMHO.

Donc Paladin c'est probablement génial, mais pour des petits jeux.

C'est un autre débat qu'on commence là

JS a été (et est toujours) utilisé pour réaliser des produits de taille conséquente (le tar.gz de Zimbra fait 413 Mo - une fois décompressé, on se retrouve avec ; il y a quantité de gros projets qui utilisent JS dans une large mesure, avec plusieurs développeurs travaillant en parallèle sur les corrections de bug et les évolutions : les Google Docs et autres Etherpad, , etc).

Je ne suis pas trop d'accord avec toi lorsque tu donnes les caractéristiques d'un langage adapté à la programmation ITL. Un typage fort n'est pas utile au développement - c'est utile au compilateur, principalement. De plus, il existe plusieurs types de typage fort : statique (comme en C++) ou dynamique (comme en Python), explicite (pareil, C++) ou implicite (Lisp). Ce n'est pas ça qui importe vraiment, même si c'est une aide appréciable. En ce qui concerne la gestion du contrôle d'accès aux membres d'une classe, je ne pense pas que ça soit vraiment quelque chose de fondamental. Il y a l'interface, et rien en dehors de l'interface n'est accessible. Que ce contrôle soit explicite (auquel cas celà demande un effort supplémentaire pour le programmeur, ce qui est une source de bugs) ou implicite (de part la structure du langage) ne change pas vraiment grand chose. Je pense (mais je me trompe peut-être) que tu te bases trop sur ton expérience avec les langages objets pour affirmer que la programmation ITL n'est possible qu'avec un langage dont tu définis les caractéristiques. Pour ma part, j'ai travaillé sur tant de projets différents, avec tant de langages différents (je suis même intervenu en tant que consultant sur un projet en fortran 66, fort de plusieurs dizaines de millions de lignes, écrites sur une durée de 30 ans par une équipe internationale ; si c'est pas de la prog ITL, ça...) que je n'oserais pas m'avancer.

JS offre des caractéristiques qui font qu'il est adapté aux développement lourds. Après, personne n'a encore osé penser réaliser un jeu AAA en JS, dans le navigateur. Il y a d'autres contraintes pour réaliser ce type de jeux, et la plateforme navigateur + JS ne me semble pas adaptée. Mais voir survenir des shooters de taille modeste, ou des CRPG épisodiques en 3D ne me parait pas impossible - loin de là.

Pour finir, j'oserais ajouter que si Unity a abandonné le support JS, c'est en grande partie pour pouvoir être en accord avec la licence de l'AppStore - ça n'a pas grand chose à voir avec des considérations techniques. Un programme sur l'AppStore n'a pas le droit d'embarquer un interpréteur de script. Sans cette restriction, Unity supporterait encore JS (C# n'apportant pas grand chose à ce niveau).
Poster une réponse Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum d'entraide

Blogs

Hébergement

 
Partenaires

Hébergement Web