10-11-2016, 10:48 PM
Le SVG est le HTML de l'image: c'est un langage d'imagerie vectorielle donc à base de formes géométriques (à l'inverse des images PNG, raster, à base de pixels). Ce sui est très pratique avec le SVG, c'est qu'il s'intègre très bien au HTML. C'est ce que j'utilise maintenant pour Eclerd.
Ca conserve un des l'un des inconvénients de canvas et des images: c'est un bloc, donc ce ne sera pas responsive. Mais cela a l'énorme avantage de manipuler des éléments DOM, et de pouvoir donc rendre des cases, des objets, des bâtiments etc cliquables comme des liens classiques. C'est également sympa pour permettre de l'animation fluide et à temps variable (ie: plus ou moins rapide [ralenti]). Ca a déjà été traité qq part sur le forum, et tu peux gratter un peu mon blog à ce sujet (dont l'exemple du brouillard de guerre, qui ne changera pas le caractère inadapté d'une telle carte isométrique).
Si tu n'es qu'à la phase de prototypage et d'amorce, ne t'encombre pas de trucs inutiles: j'ai tenté plusieurs fois de refaire ma v0 d'eclerd en plus propre, et chaque tentative a foirée parce que j'ai constamment tourné en rond et perdu du temps à chercher "et si je prends ce FW? Et pour plus tard, comment je ferai? Et après? Et si gnagna...?". A l'inverse, sur la v0, j'ai été pragmatique (mais sans expérience de code): c'est en ligne, et c'est (on va dire) jouable. Ce n'est que récemment, au dernier reboot d'Eclerd (cf lien précédent) que j'ai repris ce pragmatisme et que j'ai arrêté de tourner en rond à vouloir faire "le truc parfait pour plus tard". Et c'est le seul reboot qui, jusqu'ici, a démarré et est en ligne.
Et non, je n'ai pas dev ces sites en Java, simplement car l'hébergeur ne le propose pas (et je ne veux pas passer des semaines et des euros à migrer tout mon bordel sur un dédié, à installer un serveur Java, et à m'apercevoir finalement que cela ne sera pas mieux qu'un Apache+PHP). La raison de PHP est souvent la simplicité de démarrage des projets et du dev (c'est très abordable comme langage je trouve, bien qu'il y ait des incohérences avec le recul [genre "on s'appelle PHP alors on va faire array_map(callback, array) mais array_filter(array, callback); rien d'insurmontable]).
Le Full JS est hyper-récent, donc pas encore bien répandu. De mon point de vue, à moins d'avoir vraiment une équipe de dev, c'est un peu "la techno qui brille du moment". C'est sûrement amusant à découvrir et à utiliser, mais je doute de l'efficacité de la chose.
Ca conserve un des l'un des inconvénients de canvas et des images: c'est un bloc, donc ce ne sera pas responsive. Mais cela a l'énorme avantage de manipuler des éléments DOM, et de pouvoir donc rendre des cases, des objets, des bâtiments etc cliquables comme des liens classiques. C'est également sympa pour permettre de l'animation fluide et à temps variable (ie: plus ou moins rapide [ralenti]). Ca a déjà été traité qq part sur le forum, et tu peux gratter un peu mon blog à ce sujet (dont l'exemple du brouillard de guerre, qui ne changera pas le caractère inadapté d'une telle carte isométrique).
Si tu n'es qu'à la phase de prototypage et d'amorce, ne t'encombre pas de trucs inutiles: j'ai tenté plusieurs fois de refaire ma v0 d'eclerd en plus propre, et chaque tentative a foirée parce que j'ai constamment tourné en rond et perdu du temps à chercher "et si je prends ce FW? Et pour plus tard, comment je ferai? Et après? Et si gnagna...?". A l'inverse, sur la v0, j'ai été pragmatique (mais sans expérience de code): c'est en ligne, et c'est (on va dire) jouable. Ce n'est que récemment, au dernier reboot d'Eclerd (cf lien précédent) que j'ai repris ce pragmatisme et que j'ai arrêté de tourner en rond à vouloir faire "le truc parfait pour plus tard". Et c'est le seul reboot qui, jusqu'ici, a démarré et est en ligne.
Et non, je n'ai pas dev ces sites en Java, simplement car l'hébergeur ne le propose pas (et je ne veux pas passer des semaines et des euros à migrer tout mon bordel sur un dédié, à installer un serveur Java, et à m'apercevoir finalement que cela ne sera pas mieux qu'un Apache+PHP). La raison de PHP est souvent la simplicité de démarrage des projets et du dev (c'est très abordable comme langage je trouve, bien qu'il y ait des incohérences avec le recul [genre "on s'appelle PHP alors on va faire array_map(callback, array) mais array_filter(array, callback); rien d'insurmontable]).
Le Full JS est hyper-récent, donc pas encore bien répandu. De mon point de vue, à moins d'avoir vraiment une équipe de dev, c'est un peu "la techno qui brille du moment". C'est sûrement amusant à découvrir et à utiliser, mais je doute de l'efficacité de la chose.