JeuWeb - Crée ton jeu par navigateur
Choix technologiques - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Choix technologiques (/showthread.php?tid=3986)

Choix technologiques - lcfseth - 20-05-2009

Voila, j'ai un peu avancé dans la conception de l'univers du jeu. J'en arrive au point ou je dois choisir le langage de prog, l'SGBD éventuellement le framework...Histoire de limiter les délires qui prennent une éternité à coder et qui finalement n'ont pas grand intérêt.

Donc pour mon jeu, l'utilisateur devra gérer une ville :
  1. Une interface graphique sera utilisé ( Pas de lien textuels).
  2. Une vue monde sera disponible.
  3. La construction se fera de façon libre ( à la manière d'un César ou Civ ), donc pas de spot prédéfini.
  4. Les combats se feront en temps réel ou au tour par tour, en tout cas de manière dynamique et avec contrôle directe de l'utilisateur ( genre Warcraft ) avec un nombre limité d'unités ( une vingtaine grand max).
  5. Un système de messagerie, de technologie... ( les classiques ) sera dispo.

Donc voila, j'ai fait quelques recherches, principalement sur ce forum et voila mes conclusions :

  1. Aucun framework ne sera utilisé, certains modules pourrait être utilisés ponctuellement, pour des besoins très précis.
  2. MySql sera probablement l'SGBD utilisé. C'est plus une contrainte qu'un choix, mais ça devrait faire l'affaire.
  3. Un forum sera présent mais sera codé de façon indépendante, probablement en utilisant un CMS connu.
  4. Le PHP semble être l'idéale pour gérer la vue monde, la messagerie...
    De plus c'est le plus utilisé par ce genre de jeu. Cependant c'est assez inadéquat pour le combat en temps réel.
  5. Afin d'alléger les requêtes MySql, Un seul field sera utilisé pour sauvegarder l'état d'une ville. L'XML semble être la solution parfaite. Je dois encore trouver un moyen pour optimiser la sauvegarde ( ne pas avoir à réecrire tout le document XML alors que seule le niveau de la caserne à changé )
    L'XSLT sera utilisé pour dessiner la map. D'autant que d'après ce que j'ai compris, le traitement ce fais au niveau du client.
  6. Pour les phases de combats, je pense utiliser Flash. Cependant je dois trouver un moyen d'intégrer l'animation de façon propre dans le jeu.
    Les phases de chargements me dérange énormément, je dois trouver un moyen de limiter au maximum cette phase. L'idéale serait de charger l'animation, une fois pour toute (de préférence pendant les phases de gestion, c'est un procède largement utilisé par les jeux en locale, mais je sais pas si c'est applicable).
  7. L'utilisation de JS sera limité à l'affichage, et ceux pour limiter les risques de triches.
Voila, J'aimerais avoir vos avis/conseils, principalement autour de l'utilisation de Flash avec PHP. Si vous avez d'autres idées n'hesitez pas, même concernant le gameplay.
D'autant plus que je pense que ce post pourrait servir de reference à d'autres personnes.

RE: Choix technologiques - Rodrik - 20-05-2009

C'est un projet ambitieux que tu montes.

Pour l'aspect temps réel je te souhaite bon courage, car en dehors des problèmes purement techniques, j'avoue que j'ai du mal à voir comment intégrer des combats temps réels à un jeu web. J'ai envie de dire que ce n'est pas le bon support pour ça. En tout cas le flash semble s'imposer, les jeux en pseudo temps réel que j'ai testé (en fait du tour par tour en direct) utilisaient tous flash sans exception.
La remarque qui me vient est: quitte à faire du flash, pourquoi ne pas faire tout le jeu en flash? Tu t'éviterais les problèmes d'intégration Flash/PHP.

Différentes remarques/interrogations:
Citation :Afin d'alléger les requêtes MySql, Un seul field sera utilisé pour sauvegarder l'état d'une ville.
Tu as fait des tests de performance? Je me demande si le gain sera vraiment visible, car une fois que tu es parti pour faire une insertion, que ce soit un champ ou 10, ça ne change pas grand chose non? Ce qui est coûteux c'est la connexion à la base plutôt.

Citation :L'XSLT sera utilisé pour dessiner la map. D'autant que d'après ce que j'ai compris, le traitement ce fais au niveau du client.
Tu as repéré un outil particulier pour faire de l'XSLT sous PHP?
Autre question: n'y a-t-il pas un risque de piratage des données, vu que ça se fait côté client?

Tout ça est intéressant, je garde ton topic à l'œil, ça pourrait me servir sur mon projet Wink

RE: Choix technologiques - lcfseth - 20-05-2009

Citation :C'est un projet ambitieux que tu montes.
En .Net je pourrais faire ca en quelques mois ( je parle de la partie code bien sur, pas des graphismes ). Maintenant, il est vrai que tout est plus compliqué quant c'est une technologie que l'on maitrise pas.
Je pense qu'avec le temps je vais enlevé des trucs.

Citation :Pour l'aspect temps réel je te souhaite bon courage, car en dehors des problèmes purement techniques, j'avoue que j'ai du mal à voir comment intégrer des combats temps réels à un jeu web.
C'est la toute l'originalité de mon jeu. J'ai trouvé un moyen de faire du combat temps réel dans un jeu web.

Citation : quitte à faire du flash, pourquoi ne pas faire tout le jeu en flash?
Je suis pas un grand specialiste du flash, mais c'est generalement plus lourd à charger qu'une page PHP, meme si une fois l'etape de prechargement (Loading ) terminé, il reagit mieux que du PHP, niveau interactivité.
Bien sur, si je peux eviter cette étape ( en chargeant le jeu au fur et à mesure de la progression ), alors oui.

Citation :Tu as fait des tests de performance? Je me demande si le gain sera vraiment visible, car une fois que tu es parti pour faire une insertion, que ce soit un champ ou 10, ça ne change pas grand chose non? Ce qui est coûteux c'est la connexion à la base plutôt.

Je n'ai pas vraiment fais de tests, j'ai récuperer cette idée sur plusieurs autres postes traitant du meme sujet. Niveau taille j'imagine que ca se vaut,
niveau rapidité, t'a probablement raison, je vais faire des tests. Je pense tout de meme que faire une insertion doit etre sensiblement moins couteux que d'en faire une trentaine. Je sais pas. Sujet à discuter Smile

Citation :Tu as repéré un outil particulier pour faire de l'XSLT sous PHP?
Autre question: n'y a-t-il pas un risque de piratage des données, vu que ça se fait côté client?
PHP gere l'XSLT de maniére native.
Lien
Je comprend pas trop le sens de ta question.
Sinon d'apres ce que j'ai cru comprendre, XSLT sert de moteur de template.
Il affiche les données sans les modifier, un peu comme du javascript (en beaucoup moins puissant).
Apres si l'utilisateur veut afficher 10000$ alors qu'en réalité il n'en a que 100$, libre à lui. Le moteur du jeu sait qu'il n'a que 100$.

RE: Choix technologiques - Rodrik - 20-05-2009

Ok autant pour moi, tu ne fais que traiter le fichier xml côté client. J'avais mal compris, je pensais que tu comptais le renvoyer côté serveur après l'avoir modifié Wink

RE: Choix technologiques - Roworll - 20-05-2009

XSLT, y'a pas de mystère. C'est un nouveau langage avec des standards qui lui sont propres.

Si on veut l'utiliser coté client (et c'est le but pour économiser de la ressource serveur) il n'y a pas besoin d'utiliser les fonctions XSLT qui existent dans PHP. Il suffit de faire un fichier XML avec en entête une référence vers le XSL. Par exemple
Code :
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="xsl/feuillexsl.xsl"?>
<tagxml>
... blabla xml ...
</tagxml>

XSLT fait principalement de la mise en forme en se basant sur les fonctions XPATH pour parcourir les données et faire des agrégations.

En ce qui concerne les risques de piratage, il n'y en a pas plus que dans du HTML classique. Au final on se retrouve avec une page en XHTML et les seules intéractions allant vers le serveur sont des requêtes POST/GET