Arborescence des pages jeu par navigateur

[fortz]

Bonjour à tous,
Je viens à vous afin de vous présenter l'arborescence de mon jeu par navigateur (plus de détails sur mon projet en cliquant ici) (qui est en pleine conception) et je voudrais récolter vos avis sur cette dernière voire même que vous m'en proposiez d'autres si vous avez des idées d'améliorations. Je pense que l'arborescence des pages d'un jeu est important pour son développement et son organisation voilà pourquoi je vous demande cela.
Voici l'arborescence de mon site :

• dev/ (ce dossier n'est accessible que par les admins)
  • sites/    
    • forum/
      
    • devblog/
      
    • wiki/
      
  • erreurs/
    
  • admin/
    
  • design/
    • styles/
      
    • images/
      
    • polices/
      
  • jeu/
    • includes/
      • js/
        
      • header.php
        
      • footer.php
        
      • config.php
        
      • url_rewriting.php
        
    • modules/
      • membres/ (contient les classes et vues concernant les membres (inscription, profils, ...))
        
      • batiments/ (contient les classes et vues concernant les batiments et leurs systèmes (monter le niveau, former des troupes, attaquer, ...))
        
      • carte/ (contient les classes et vues concernant la carte (création, mouvement, ...))
        
      • classement/ (contient les classes et vues concernant le classement)
        
      • quetes/ (contient les classes et vues concernant les quêtes (suivi des quêtes, récompenses, ...))
        
      • evenements/ (contient les classes et vues concernant les évènements)
        
  • index.php
    
• prod/ (même contenu que dev/ avec une version antérieure totalement finie et testée)
  
• versions/
  • v1.0.0/
    
  • v1.1.0/
    
  • v2.2.1/
    
  • ...
    

A savoir : On développe les nouvelles fonctionnalités et corrige les bugs dans un espace réservé aux administrateurs : le dossier dev/.
Une fois une/plusieurs fonctionnalité(s) totalement finie(s) et testée(s), on extrait tout le contenu du dossier dev/ ainsi que la base de données dans une archive qui fera office d’une nouvelle version qu’on pourra ensuite mettre en ligne dans le dossier prod/ qui est, lui, visible par tous les membres.

Merci de m'avoir lu

Cordialement

[Xenos]

Salut,

n'hésite pas à confronter tes arborescence avec celles qui existent, au travers des CMS (ie, Wordpress) ou Frameworks (ie y'en a un tas).

En règle générale, une arborescence est "bonne" si:
• Elle est efficace quand tu cherches un trucs c'est à dire que si tu cherches un truc dans l'arborescence, alors tu ne fais que descendre dedans: tu ne remontes jamais à un parent
• Elle est univoque, c'est à dire que si tu as un élément à ranger dans l'arborescence, alors il n'a qu'une et une seule place logique.


Là, je peux te dire plusieurs choses pour ton arbo:
• "include", "admin", "header", "url_rewriting" vs "erreurs", "jeu": choisie une seule nomenclature de noms de fichiers/dossiers, et respecte-la. Par exemple, tu peux dire "je mets tous les noms en français, sans accent, et avec des "_" (snake_case). Ou alors, tu peux te dire "je mets tout en anglais, avec des Majuscules façon CamelCase". Choisis.
• Pas de section dédié aux fichiers accessibles depuis le web. Cela va te jouer des tours et de poser des difficultés pour les droits d'accès. N'hésite pas à séparer la section "ceci est accessible par le web (css, images, php recevant la requête entrante, etc)" de "ceci n'est pas accessible du web (fichiers sql de BDD, fichiers PHP du core du jeu, scripts bash, etc".
• Où sont les logs? "erreurs" va probablement les contenir, mais je pencherai pour un "logs/errors" + "logs/access" etc, bref un dossier dédié aux logs dans lequel se trouvera le dossier des erreurs (d'ailleurs, pourquoi un tel dossier?).
• Tes fichiers PHP ne sont pas dans un dossier dédié ("vendor namespace"), aka comment tu vas faire si tu veux ajouter des fichiers PHP issus d'un framework?


Pour info, j'ai cette arbo (je m'aperçois que j'ai des noms et des verbes dans mon arbo, c'est un peu dommage):
→ config/ (configurations de l'environnement, pas les configs du jeu, aka Apache, phpunit, Netbeans, etc)
→ data/ (données générées par les utilisateurs du jeu)
→ deploy/ (scripts de déploiement, mais je le trouve mal placé...)
→ php/ (codes du jeu)
→ resources/ (ressources internes, aka XSL, XML, etc)
→ sql/ (fichiers SQL, créant les procédures SQL ou générant les données pour la BDD; donc 2 sous-dossiers: procedures/ et initialize/)
→ www/ (fichiers accessibles du web, aka interface du jeu avec le web; 2 sous dossiers handler/ et resources/ contenant pour le 1er les PHP réceptionnant les requêtes et pour le 2nd, les fichiers CSS, JS etc)


PS: Il y a des remarques qui sont peut-être en "anticipation", donc tu peux éventuellement les ignorer.


PSS: ton cycle de "on copie de dev/ dans un dossier dédié avec un dump BDD blabla" s'appelle une "mise en prod", ou "deploy" ("déploiement"). Des scripts déjà faits existent, des outils puissants aussi (façon Jenkins, totalement surdimensionné dans ton cas je pense mais à essayer pour la culture). Alors je te conseillerai de laisser tomber le déploiement manuel (avec une gestion des numéro de version totalement à la mano ) au profit d'un outil existant, dont tu n'auras pas à assurer la maintenance et qui t'obligera à bien séparer les choses (aka, séparer la phase "je développe des trucs", la phase "je partage mes modifs" et la phase "je publie la nouvelle version").

[fortz]

Merci pour ta réponse Xenos

Alors je me doutais que mon arborescence n'était pas forcément bien pensée car je débute totalement dans la conception de ce genre de choses. A vrai dire j'ai conçu une arborescence qui me semblait logique; mais logique ne rime pas forcément avec performant bien-sûr. Alors je ne m'y connais absolument pas là-dedans donc beaucoup des choses dont tu as parlé sont peu compréhensible pour moi. Merci pour ton conseil, je mettrais tout en anglais en mode CamelCase.
Tout d'abord, qu'entends-tu par les logs ? (j'en entends parler mais je ne vois pas réellement ce qu'il doit y avoir dedans)
Dans ton arbo, je vais te demander quelques petits détails si ça ne te dérange pas :
- le dossier config pour moi c'est juste tes paramètres de connexion à la bd et deux trois petites choses, mais le reste aucune idée de ce que j'y met
- les dossiers php, data et sql je le confonds. Dans sql/ tu déclares les fonctions qui auront une interaction avec la bd ? Dans data/ je vois pas du tout quoi y mettre et dans php en fait il y a tout selon moi...
- le dossier www lui reçoit les requêtes du client et les envoies se faire traiter par le php/ et sql/ ?
- le dossier resources je sais pas non plus ce qu'il y aurait dedans

Bon voilà tu comprends bien que je suis un peu désespéré quoi.
Je me renseignerai sur Jenkins merci

Ayant commencé à faire quelques petits avancements sur mon projet, j'ai remarqué que j'avais du mal avec l'arborescence à cause de 2 raisons :
- la première c'est qu'en fait mon jeu est totalement géré en Ajax avec un mécanisme de popup donc très peu de rechargement de pages. Ceci m'apporte un problème : je n'ai plus réellement de page (hormis index.php), car tout n'est que popup donc pas une page entière. Je ne sais donc pas comment gérer ça, où mettre le contenu de mes popup ? où mettre mes page ajax qui servent au final à faire tourner le jeu ?
- la deuxième c'est qu'avec cette arborescence j'ai du mal à gérer les appels aux classes car en fonction d'où je les appel, leur chemin d'accès change totalement. Par exemple, d'un côté j'appel ma classe Membre.php dans ma page index.php qui est donc à la racine de mon arbo, et de l'autre je l'appel depuis une page traitementInscription.php qui est appelée via Ajax et qui est dans un dossier bien enfouit.

Je ne sais pas si j'ai été très clair, mais j'ai quelques difficultés à l'expliquer, n'hésite pas à me demander davantage d'explication.

Cordialement

[Xenos]

Un dossier "logs" est un dossier qui contiendra toutes les informations de journalisation du jeu. Par exemple, sur mes projets, j'ai un dossier "logs" dans lequel atterrissent les journaux de déploiement, les logs Apache ou (plus intéressant dans ton cas), les exceptions non-catchés du jeu (aka, quand une exception throw new ... n'est pas catch(ExceptionClass $ex), alors je la catch pour la journaliser dans logs/bugs/*.txt)

Bref, c'est un dossier où ranger les données générées par le code lui-même (on pourrait agrandir le principe à un dossier "codegen/", contenant "logs/" avec les journalisations, mais contenant aussi "cache/" où se trouvent des fichiers de cache).


Non, dans "config/", je n'ai pas les infos de connexion à la BDD. Ca, c'est la configuration liée au jeu. Et comme c'est celle utilisée par PHP, elle se trouve dans "php/eclerd/config/*.php". Dans config/, j'ai "apache/eclerd.vhost.conf" par exemple, qui est la configuration de mon hôte virtuel Apache (histoire d'avoir mon Eclerd en local à l'adresse 'eclerd.localhost'). J'ai la configuration pour Doxygen (génération de la documentation). Pour PHPUnit (tests unitaires, 'm'en suis pas trop servi... ^^ ) ou encore, des configurations pour d'autres scripts bash/batch.

Dans "sql/", j'ai mes fichiers SQL à exécuter sur la BDD pour l'initialiser (créer les tables et en rajouter ensuite; puis pour y mettre les données) et j'ai les fichiers SQL qui créent les procédures stockées utilisées ensuite par le jeu (je n'ai plus envie d'avoir des "SELECT ... FROM ..." et autres requêtes SQL chiantes dans mes codes PHP, je passe donc tout par des procédures; si c'est pas ton cas, tu n'auras pas ces fichiers de procédure, juste les fichier SQL d'initialisation de la BDD).

data/, je le réserve pour les fichiers générés par les utilisateurs. Par exemple, pour stocker leurs éventuels avatars. J'y mettrai aussi les données générées par le jeu, comme les cartes (Eclerd génère une carte du monde avec une info, comme la densité de population, et stocke cette image dans ce dossier, dans un sous-dossier "gen/map/*.png" par exemple).

C'est cela, www/handler contient les pages PHP qui vont aller appeler les codes PHP de php/eclerd/* qui eux, feront les vrais traitements. Et www/resources contient tous les fichiers statiques du site (css, js, images des batiments, etc).

resources/, t'en n'as peut-être simplement pas.



Perso, j'ai trouvé Mage (Magallanes) plus pratique que Jenkins (mais nécessitant Linux ou Cygwin). C'est plus léger à gérer.

Si tout n'est que popup, d'un avis personnel, je dirai que t'es dans la merde car tu n'auras aucune évolutivité et que "ça merde" sur les supports autres que ton écran 1920x1080 avec 1 barre d'outils en haut et 1 barre de favoris, en plein écran avec un clavier et ta souris. Bref, le navigateur est normalement là pour t'abstraire du support et tu perds cet avantage si tu fais des popup (on s'en contre-br*nle des "ouais mais Ajax ça évite de recharger la page, c'est plus performant" car c'est parfois faux, et surtout, gagner 1ms de temps réseau face à 100h de boulot de dev et une maintenance à s'arracher les cheveux, cela ne vaut pas le coup).
D'un point de vue moins personnel, le contenu de ta pop-up constitue une page. Ta page est l'URL appelée par ta requête Ajax. Popup ou pas, tu as donc toujours autant de pages Donc, les pop-ups devraient appeler une page de ton "www/php/" (l'équivalent de mon "www/handler/") qui répercutera la demande au code php correspondant.


Le problème des chemins d'accès aux classes vient d'une mauvais configuration PHP. Pour ma part, j'ai ajouté à l'include_path (via ini_set ou set_include_path, je ne sais plus) le dossier "php/". Ensuite, SPL et son autoload (cherche sur duckduckgo tu trouveras) se démerde tout seul pour chercher les classes qui n'existent pas quand le code PHP en a besoin. Bilan: 0 require_once dans mes codes, 0 soucis avec ces histoires de chemins relatifs.

[fortz]

Merci pour toutes ces précisions !

Donc en gros dans logs c'est tout ce qui n'est pas stocké dans la bd concernant des actions non prévues ?!
D'accord donc data/ c'est tout ce que l'utilisateur dépose sur mon serveur, donc par exemple si je propose de télécharger des photos (sur mon forum par exemple) alors ca irait là dedans ?!
Le dossier resources/ je suis un peu obligé d'en avoir, je vais avoir des styles différents, des pages js, des images (trop même :p) donc je pense que je m'en servirai :p

Je suis sur windows en local donc je ne vais pas pouvoir me servir de Mage

Alors pour les popup en fait ça part de l'observation que je fais sur l'existant : les jeux modernes fonctionnent comme ça désormais et en effet ça donne à l'utilisateur une impression de fluidité et c'est plus agréable à la navigation, tout reste sur la même page, tu n'as qu'à fermer des morceaux de fenêtres (popup). Qu'entends-tu par "aucune évolutivité" ? Quant aux supports, j'ai regardé un des jeux dont je te parle et sur mobile ou tablette ça rend tout aussi bien que sur mon écran 1920x1080. Je n'utiliserai pas ajax et les popup pour le gain de performance mais plus pour la facilité de prise en main de ce système et son ergonomie.

Alors concernant les chemins d'accès, je me suis renseigné sur include_path mais je comprends pas trop le truc en fait. Ca change le répertoire où tes fichiers includes vont être recherchés ? donc si on prend ton arbo, ton php/ étant à la racine de ton site, il suffira de faire set_include_path('php'); depuis ton index.php (qui serait à la racine aussi) et le tour est joué ? où alors il faut fonctionner avec un chemin absolu ? (car si c'est du absolu, ca risque d'être embettant car si tu es en local il faut partir de C:/wamp/www/... alors que la version hébergée, tous les dossiers sont directs à la racine )
Donc cela suppose que tous fichiers includes sont dans /php, donc les fichiers js/ qu'il faut que tu inclues aussi tu fais la bonne vieille méthode du require_once ?

Cordialement, merci pour ton aide

[Xenos]

logs -> oui, mais tu peux aussi logger les actions prévues (c'est pas recommandé de le faire soi-même, à la "mano": y'a des softs qui le font déjà très bien)
data/ -> oui
resources/ -> je distingue celles utilisées par le serveurs (/resources/, à la racine) et celles utilisées par les clients (/www/resources/); le 1er, tu n'en n'as peut-être pas (perso, j'y ai mes XSL), mais le 2nd, oui, tu en auras toi aussi (CSS, JS, images)

Tu peux bricoler Mage sous Windows mais j'ai pas trouvé cela pratique (mieux vaut simplement installer Cygwin puis installer Mage dans Cygwin).


Je ne critique pas le concept de pop-in (je-ne-sais-plus-qui m'avait suggéré ce nom, pour les distinguer des vraies pop-ups). Ce qui va te coincer, c'est de les "bricoler" à coup de JS et d'ajax. Si possible (et c'est très souvent le cas puisqu'une bonne partie des pop-up est en fait une page dans une page), essaie d'utiliser des iframes: tu ne seras pas coincé par des ids qui se chevauchent (le contenu de ta pop-in ne doit pas utiliser un #id déjà présent dans la page), tu verras plus clairement les I/O du serveur (tu ne te diras plus "j'ai 1 seule page", mais bien "j'ai N pages, certaines sont dans des pop-in et pas d'autres") et tu devrais avoir plus de facilité à long terme puisque tu t'appuies sur HTML et non sur du JS (maison ou pas).
Donc, oui, je suis d'accord sur le but, mais je ne partirai pas sur cette implémentation-là (je peux te dire qu'ici, au taff, "on" a fait que des pop-in à grands coups de JS, et maintenant, ça merdoie partout à cause de leurs effets collatéraux).

include_path -> c'est l'idée. Il me semble que je fait un set_include_path(realname($_SERVER['SCRIPT'])); ou quelque chose de ce style... Cela me permet de faire de l'absolu sans être coincé par les changements d'environnement dont tu parles (mais du relatif, ça peut se faire aussi je dirai... je ne sais plus exactement >.< )
Oui, tous mes fichiers inclus par PHP (ils s'auto-incluent d'ailleurs, via spl_autoload) sont dans /php/

Y'a pas d'inclusion à faire pour les JS (t'inclus pas un JS dans un PHP, si c'est ce que tu fais, tu t'es loupé: ton PHP renvoie ta page HTML qui utilise une balise script + attribut src et le client va aller chercher ce fichier JS à l'adresse web donnée par le src).

[fortz]

Je gère mes popups avec le widget "dialog" de jquery-ui, avec un peu de méthode on peut s'en sortir avec les id non ? après je suis d'accord que c'est discutable tu me conseillerais quel iframe pour les popups ? celui de jquery ?

Ben pour inclure le js, je fais des : <script src="includes/js/jquery.js"></script> sur mon index.php. C'est pas une bonne méthode ?

Pour le chemin le include_path je crois voir ce que tu veux dire, arrête moi si je me trompe :
- tu te mets sur ta page index.php, tu fais ton realpath(php);
- tu obtiens quelque chose du style : C:\wamp\...\php si tu en local
- tu mets le résultat dans set_include_path(); et voila ?
Après pour le spl_autoload() par contre, je ne peux pas différencier mes classes de mes autres fichiers php à moins que je les sépare dans un sous-dossier non ? Enfin, je pourrais aussi leur mettre une extension .class.php et faire un spl_autoload_extensions('.class.php'); non ?

Merci pour ton aide !

[Xenos]

avec un peu de méthode on peut s'en sortir avec les id non

Chez Alstom, ça débouche sur des trucs magiques du type "ah ben je peux pas prendre l'ID 'document-form' parcequ'il est déjà pris dans la pop-in qui apparaitrait quand t'auras cliqué sur tel, tel puis tel bouton". Je trouve ça affreux à maintenir, mais si tu préfères du jQuery, t'es le chef chez toi.

Hum... "quelle iframe"... ben, le balisage HTML... Oui, le truc que si peu de "dev web" connaissent en fait (c'est pas contre toi, c'est juste chiant de voir tant de gens au taff qui disent faire du web mais qui n'ont jamais foutu le nez dans les specs du W3C/WHATWG...


Si, c'est bien la bonne méthode, mais là, je crois que tu as manqué de compréhension dans ce que t'as fait (t'as fait juste, mais t'as soit pas eu les bons mots, soit pas compris ce que t'as fait). Les includes de PHP sont fait coté serveur, et utiliseront le include_path de PHP. En revanche, les balises HTML sont interprétés par le navigateur du client (pas par le serveur, qui s'en fiche royalement), donc, elles n'auront rien à voir avec l'include_path de PHP.


C'est ça pour le include path. Plus précisément:

preg_match('~^(.*[/\\\\])www[/\\\\]~i', realpath(__DIR__), $matches);

set_include_path($matches[1] . 'php/');

Okay, c'est un peu crade, mais c'est du code dans se trouvant dans /www/handler/*/handler.php (= le point d'entrée des requêtes web traitées par PHP): chaque environnement a son propre dossier (/www/handler/prod ; /www/handler/local-dev ; /www/handler/staging etc). Un lien symbolique (/www/handler/current) se charge de pointer sur le bon environnement (et Mage se charge de créer ce lien symbolique lors du déploiement vers tel ou tel environnement).

Tu peux faire comme tu le dis (.class.php), mais si tu fais de l'OO, je te conseillerai de rester sur 1 classe = 1 fichier PHP et inversement 1 fichier PHP = 1 classe. Si tu commences à mixer de l'OO et du procédural, tu vas en chier (dans mon cas, ce "mix" a été contourné en mettant le procédural, le handler.php, dans le point d'entrée du serveur web PHP /www/handler/* et les classes sont dans /php/*, les deux sont donc bien séparés). Si tu veux malgré tout mélanger OO et procédural, fais de même: 1 dossier pour les classes, 1 dossier pour le procédural (ie: /php/class/ et /php/procedural/)

---

Tiens, cas typique des merdailles dues aux IDs: supposons qu'un pop-in contienne les plans des usines du jeu. Le joueur l'ouvre, et regarde les usines qui sont dedans, avec leurs infos. Maintenant, il voudrait ouvrir une seconde pop-in, identique (avec elle aussi les plans des usines), pour pouvoir faire des comparaisons (ou pour avoir le plan d'une usine dans un coin, pour se rappeler de la construire demain). Si cette pop-in a des IDs, tu vas en chier. Si cette pop-in est une iframe, t'auras aucun soucis (tu pourras en créer autant que tu veux; cette création, qui revient juste à insérer un <iframe src=".../.../*.php"></iframe>, peut se faire via javascript).

Les pop-ins en JS pur équivalentes à des alert() ou à des confirm() ou input(), okay. Pour le reste, je te le déconseille (tout ton jeu va se retrouver dans 1 et 1 seule page web, dans 1 et 1 seul contexte, et tu vas avoir plein d'effets colatéraux partout).

[fortz]

Oui je vois le problème avec les popups en effet, après pour palier au problème, il suffit de faire une vérification avant l'ouverture du popup afin de savoir s'il est déjà ouvert ou non mais je comprends le principe du problème. Pour les iframes c'est plutôt pratique en effet, cependant il n'ont pas l'apparence de popup et je doute arriver à un résultat qui soit comme je le souhaite, je me trompe ? (je peux très bien me tromper donc je demande :p). Ce que j'aime avec le système actuel c'est que le style est très personnalisable et puis je peux rajouter des effets quand le popup apparaît et disparaît.

Je ne me prétends pas dev web encore, je sais que je suis un débutant et je n'aimerais qu'une chose : apprendre tout ce qui existe sur le web (irréalisable dis-tu ? ohhhh :p)

Merci pour la précision du code

Okay, c'est un peu crade, mais c'est du code dans se trouvant dans /www/handler/*/handler.php (= le point d'entrée des requêtes web traitées par PHP): chaque environnement a son propre dossier (/www/handler/prod ; /www/handler/local-dev ; /www/handler/staging etc). Un lien symbolique (/www/handler/current) se charge de pointer sur le bon environnement (et Mage se charge de créer ce lien symbolique lors du déploiement vers tel ou tel environnement).

Donc tu dois avoir ce système de partage entre dev, prod et staging (qui veut dire ?) sur chacun des dossiers général ? par exemple tu dois aussi l'avoir sur ton /php/ afin de ne pas mélanger les classes dev des classes prod par exemple non ?

Non je pense conserver ce système de classes d'un côté qui me serviront à traiter les données du handler.php et à renvoyer des résultats à cette même page. Donc dans handler.php au final tu centralises tous les envoies et réceptions de données aux classes ou aux autres handlers ?
Prenons mon usine, qui est dans handlerFactory.php, j'affiche les données du bâtiment aux utilisateurs et s'ils cliquent sur "Augmenter le niveau" par exemple, alors je fais quoi ? puisque cette page ne dispose pas du include_path, il ne connait pas les classes... comment puis-je alors faire appel à la classe /php/batiment.class.php pour monter le niveau du bâtiment ?

Désolé pour toutes ces questions j'ai l'impression d'être stupide

[Xenos]