Que devrait contenir un framework pour les jeux ?

[Sephi-Chan]

Bonjour à tous,

Ces derniers mois, j'ai eu l'occasion de tester (plus ou moins longtemps) quelques Frameworks PHP : Jelix, CodeIgniter, Copix et CakePHP (et pas mal de temps sur ces deux derniers).

Mon avis final : C'est très bien pour développer des sites génériques vite et bien, mais ça n'est pas adapté à la création de jeu, notamment à cause de certaines lourdeurs telles que DAO et l'assistanat global.

Mais le débat n'est pas là. Je préviens d'ailleurs d'avance que tout ce qui déviera du sujet sera masqué.

Mon idée ? Écrire un Framework pour PHP 5 qui réponde aux besoins (classiques et spécifiques) des jeux grâce à une grande modularité.

Je cherche maintenant à déterminer ce que devrait gérer un tel Framework.

Voilà les éléments vraiment basiques qui doivent être incorporés :

• Gestion du MVC ;
  
• Gestion des utilisateurs et de leurs droits (des ACL, en somme) ;
  
• Gestion de la base de données MySQL ;
  
• La gestion des erreurs et des exceptions ;
  
• La gestion de flux basiques (redirection) ;
  
• La gestion de la journalisation ;
  

J'attends donc vos suggestions et vous en remercie d'avance ,


Sephi-Chan

[Tagu]

Comme toi Sephi j'ai testé les différents frameworks php sur le marché et aucun ne convient à mon projet de jeu. Au final, j'ai codé mon propre MVC.

Pour ton framework, je dirais qu'une gestion de configuration simple via création d'un array peut être utile. Sinon, pour faire un framework généraliste, la liste me semble complète.

[Melimelo]

Peut-être un système pour stocker chaque action dans le jeu, et l'idée du Svn me parait pas mal.

Puis gestion multi-langues / multi-design Et surtout etre bien fourni niveau doc.


Moi insomniaque mais non je juste sur les bord et au mileu ^^ ( 5:00 du math pour moi ) fin 4h ca depend quelle heure je prend

[pascal]

Mon avis final : C'est très bien pour développer des sites génériques vite et bien, mais ça n'est pas adapté à la création de jeu, notamment à cause de certaines lourdeurs telles que DAO et l'assistanat global.

peux-tu détailler un peu les lourdeurs de DAO et ce que tu veux dire par "assistanat global" ?

je vois aussi :
- la gestion de formulaires
- une architecture pour ajax
- une debug bar comme dans symfony
- une gestion du routage ( faire des URLs cool )
- une gestion simple et solide des modules
- de la documentation

A+

Pascal[/align]

[Sephi-Chan]

Et bien, que de choses ! Je vais revenir sur chaque proposition pour mieux les comprendre.

Concernant les propositions d'Oxman :

La gestion des tests unitaires
La gestion des tests de performances
La gestion de cache avancé
La gestion de centralisation de fonctions
La gestion d'externalisation du coeur du système
La gestion de SVN de manière transparent

Pour les tests unitaires, il faut que je réfléchisse à la manière d'implémenter ça.
Pour les tests de performance, l'idéal serait quoi ? De donner le temps d'exécution du script quand on est en mode debug ?
Pour la gestion du cache, que voudrais-tu rendre cachable concrètement ?
Au sujet de la centralisation de fonctions, je ne comprends pas de quelles fonctions tu parles… Peux-tu m'expliquer un peu s'il te plaît ?
Pour l'externalisation du noyau, est-ce vraiment utile ? J'en doute.
Et enfin, je ne comprends pas trop ce que tu veux dire par la gestion transparente du SVN ? Comment le Framework peut gérer ça ? Et sinon, là non plus je pense (à première vue) que ça risque d'apporter des lourdeurs en plus pour pas grand chose.


La proposition de Melimelo, le nocturne :

Peut-être un système pour stocker chaque action dans le jeu

Tu parles de journalisation (logging) ? Si oui, c'est déjà prévu. Si non, je ne comprends pas de quoi tu parles… :/


Les proposition de Pascal, enfin :

La gestion de formulaires
Une architecture pour ajax
Une debug bar comme dans symfony
Une gestion du routage ( faire des URLs cool )
Une gestion simple et solide des modules
De la documentation

Pour les formulaires, je pense inclure des Helpers.
Pour l'architecture Ajax, j'y reviens après car c'est un point particulier.
La réécriture d'URL est prévue, via le mod_rewrite d'Apache (pour les autres, ce sera du index.php?c=controller&a=action).
Pour la gestion des modules, là aussi c'est un point (difficile, à mon goût) qui me tient à cœur puisque je veux qu'on puisse gérer tout genre de jeu (si évidemment il y a des contributeurs).


Gestion d'Ajax

J'en reviens à Ajax, maintenant. Bien souvent, l'injection de contenus est fait salement (à coup de innerHTML, par exemple). J'aimerai que le Framework ne permette pas ça, qu'il impose d'envoyer un objet Javascript que l'on manipule ensuite. Pour cela, je me demande encore comment implémenter l'aide à l'Ajax.

De plus, j'aimerai permettre à chacun d'utiliser la librairie qu'il souhaite, je me demande donc comment permettre la souplesse à ce niveau là. Des idées ?

peux-tu détailler un peu les lourdeurs de DAO et ce que tu veux dire par "assistanat global" ?

La génération des requêtes de DAO n'est à mon sens pas optimisée. Je me rends souvent compte qu'en repassant derrière à la main, je ferais mieux.
Si l'on peut se permettre ça pour un site bateau, je trouve que ce n'est pas le cas pour un jeu, où les créateurs n'ont pas forcément les moyens de compenser la lourdeur de leur framework par l'achat de serveurs supplémentaires et/ou plus puissants.
Dans l'assasitnat global, je pense à tous les petits sucres qui rendent le développement très sympa, mais qui ajoutent de la lourdeur.
Les gens veulent faire une application conséquente et ils n'ont pas forcément besoin de développer vite, ils peuvent donc bien travailler un peu (se retirer les doigts iffle.



Sephi-Chan

[Plume]

Je donne un point pour ne pas intégrer la DAO. C'est pas comme si t'avais l'habitude de jongler avec les différents SGBD donc abstraction inutile. MySQL c'est suffisant. P'tet dans un avenir proche pourquoi pas ?

Je pense également que la gestion des formulaires c'est gadget aussi. J'suis pas particulièrement avancé avec symfony de ne pas les écrire moi même par exemple. J'suis pas conscient de l'avantage que j'y gagne.

Le SVN, c'est pareil. Dans l'immédiat et sûrement avant longtemps, j'pense pas que ce soit nécessaire. Je crois que symfony le fait mais j'l'utilise pas et ne sais pas en quoi ça consiste que le fw gère ce genre de chose.

Ensuite, comme on en parlait, la difficulté d'un fw pour les jeux, c'est qu'il est difficile d'en concevoir un qui correspond à tout le monde. Je pense donc que beaucoup de choses, voir presque tous les éléments du fw, pourraient être gérer via la gestion de modules.

En bref, il faut que le fw impose une architecture performante et un gestionnaire de module au poil. Ensuite, développer les modules comme :

• Gestionnaire MySQL
  
• Gestionnaire de routage
  
• Gestionnaire Multi-langage
  
• Gestionnaire de journalisation
  
• Gestionnaire ACL
  
• ...
  

Et dans le core :

• MVC
  
• Gestion des exceptions/erreurs
  
• Debug
  
• Gestion des modules
  
• Gestion de configuration adaptative ( e.g à savoir évolutive en fonction des modules présents )
  

Ensuite, grâce à la gestion des modules, tu peux indépendamment poser les briques que tu veux en restant libre.

[Edition]
J'oubliais d'appuyer sur une chose : la documentation. J'suis vraiment d'accord pour dire que c'est important !

@tchaOo°

[Melimelo]

Oui ctai bien la journalisation dont je parlais, mais plus poussé que des simple log de connexion.

Genre à chaque action qu'on veut enregistrer, ont fait appel à une fonction qui prend en paramètre le nom de l'évènement par exemple et celui-ci est stocké dans une bdd / fichier xml.

[pascal]

oxman, tu devrais te renseigner sur les formulaires en symfony 1.1, c'est sympa car :
- tout est centralisé dans une classe : label, règles de validation
- la validation de base est créée via la DB ( on analyse les champs de DB et on valide les types et longueurs ) ; cette validation de base est héritée pour ta configuration fine du formulaire

les urls doivent être libres dans leur forme, c'est plus joli
cf symfony again.

je reste sur mon idée de faire des plugins "spécial jeux" en utilisant symfony. l'orientation du framework va vers un coeur minimal, qui utilise des briques interchangeables pour l'accès à la DB, les formulaires, les tests unitaires ...

on ne réinvente pas la roue, on utilise la meilleure roue open source

je suis OK sur un point : le DAO customisé pour MySQL, pour améliorer les performances.

je ne suis pas d'accord sur un autre point : les outils qui font gagner du temps ne sont pas inutiles, ils permettent de se consacrer à des choses plus essentielles, à plus forte valeur ajoutée pour le projet.

voilà voilà

A+

Pascal

[pascal]

bonne lecture alors

A+

Pascal

[Hakushi]

Personnellement je vois pas l'interet de créer un framework pour les jeux, ceux existant comportent deja toutes les composantes nécessaires au développement d'un jeu.

Pascal évoque Symfony, je n'ai pas eu le loisir de l'essayer, mais par contre je bosse pas mal avec le Zend Framework, et je ne vois pas ce qu'on peut demander de plus a Framework que le Zend Framework ne fait pas deja (c'est a peu pret similaire pour Symfony, sur le papier).

Apres dans les ajouts que j'ai personnellement fait au Zend Framework, il y a juste un support facile de l'interaction avec Flash et de la gestion de celui-ci (une sorte de penchant PHP de SWFObject), une gestion de http://www.danga.com/memcached/ parce que dans un site a potentiel haut traffic comme peu l'etre un jeu PHP, passer par memcached pour les donnees peu evolutive, c'est un gain de perf sur le jeu, et une sauvegarde en terme de charge db (bon ca oblige a avoir un serveur memcached, mais bon... ) .

Et enfin un systeme de "static page" , c'est un petit truc tres simple qui permet egalement de menager la bdd et eventuellement ton master server si t'en a un : pour faire simple, chaque fois qu'un user va pointer sur une page, le framework verifie si celle-ci a deja ete genere en static, si oui, il affiche celle ci, si non il la genere et l'affiche, dans tout les cas une page n'est generee qu'un et une seule fois, sauf forcing (generate=true par exemple), ou alors si celle ci est perimee (base sur le temps). De plus il est possible de garder des dynamic parts dans une page static, ce qui est plutot pratique par exemple si on a une page massivement remplit d'infos qui changent peu, avec quelques infos dynamiques, on genere la page en gardant les dynamics parts, de ce fait l'user qui se verra rediriger sur la page, aura le contenu statique sans interroger la bdd, et le contenu dynamique sera lui mis a jours a chaque affichage, sans avoir a egalement redemander les infos statiques.

Je sais pas si je suis clair :heuuu: