Modules

[Aedius]

Pour la petite histoire, nodejs c'est un serveur ( à la place d'apache ) sur lequel tu mets ton code qui est en javascript à la place de PHP.

Tu as 1 thread pour toute les requête au lieu de 1 thread par get/post mais ça te permet bien de gérer du GET et du POST

La principale différence c'est que c'est bien plus facile de gérer des websocket ( possible mais pas facile en PHP ) et surtout de déclencher facilement des actions coté serveur.

*fin de la parenthèse*

Pour en revenir au sujet de base ( à savoir un framework de jeu en PHP ).
Quels sont les fonctionnalités qu'ont tout les jeux par navigateur ( de stratégie gestion d'après ton exemple ) ?

- connexion
- forum
- système de guilde
- carte
- échange de ressource
- unité
- bâtiment
- ressource
- évènement
- administration

Pour moi, ton système doit être une collection des interfaces de ces 10 éléments.
Je considère que "class Batiment implements IBatiment" gérera l'ensemble des batiment du joueur qui aura fait l'appel au serveur.
Sinon on peut aller plus loin avec IBatimentCollection et IBatiment

tu parles du temps de construction donc reprenons ton exemple.
Qu'est ce qui peux influer sur la construction d'un bâtiment ?

- les ressources
- les unités
- les batiments

on peu d'après moi partir sur le principe suivant :
- coté client une construction c'est : un requète avec un id batiment et un nombre
- récupérer que le client a le droit de construire
- coté serveur, il faut d'abord vérifier si c'est possible
- si possible : calculer le temps et les cout temoraire et définitif
- soustraire le cout
- enregistrer la construction dans les évènements
- à la fin de l'evement : ajouter les constructions
- puis ajouter le cout temporaire

ce qui donne dans les interfaces par exemple :

Iconnection :
- peuConstruire( idBat, nbBat)

Ibatiment :
- peuConstruire(idBat, nbBat)
- getCouts( idBat, nbBat)
- ajouter(idBat, nb)

IUnite :
- peuConstruire( idBat, nbBat)
- getReductionCouts(couts)
- soustraire(idUnit, nb )
- ajouter(idUnit, nb)

Iressource :
- peuConstruire( idBat, nbBat)
- getReductionCouts(couts)
- soustraire(idRessource, nb )
- ajouter(idRessource, nb)

IEvenement :
- enregistrerEvent(callback,param)

Et c'est donc le travaille de ton framework d'appeler chacune de ces fonctions dans le bon ordre avec les bons paramètres. La classe Batiment qui implement IBatiment elle ne connait rien des ressources ni du reste, tu as donc ton principe de module interchangeable

ça en fait pas mal pour une "simple" construction d'un batiment.
Je pense que faire une roadmap et un versionnement des Interfaces serait efficace. Si dans la V1 on ne peut pas réduire le couts, libérer la population d'ouvrier ou ce genre de chose, ça ne me choque pas du tout. Au contraire

[Ter Rowan]

moi y a des trucs qui m'intéressent la dedans

je sais pas si faut aller jusqu'à CMS ou n'avoir "que" une collection de module / fonction / trouver le bon terme

typiquement en réfléchissant sur mes différents jeux (euh... idées de jeux) j'ai constaté qu'il y avait beaucoup de fonctionnalités communes, donc réutilisables, malgré des gameplays (euh... idées de gameplay) différents, jeu de rôle, d'élevage, de gestion de royaume, de gestion d'équipe de sport, etc...

donc si c'est bien fait fonctionnellement, pas dégueu techniquement, apportant assez de paramétrages, sécurisé, assez voire très indépendants les uns des autres, ca apportera des trucs

[Xenos]

J'ajouterai : sans faute d'orthographe dans les noms de classes ("peutConstruire" et pas "peuConstruire"...), bien documenté, complété d'exemples "clef en main", maintenu et rétrocompatible (en cas de MaJ, j'ai pas envie de me creuser la tête ni de reprendre le moindre code).

Après, avec de tels critères, on peut même faire du payant ou se rémunérer d'une façon ou d'une autre (en vendant certains modules avancés par exemple).

Tiens, je ne suis pas seul à préfixer d'un "I" mes noms d'interfaces?! ^^

[niahoo]

Mais non le code serveur ce n'est pas du back office ! On dirait que tu considères ton code uniquement en matière d'interface utilisateur, comme si tu ne voyais que l'ui quand tu regardes un logiciel. Le code serveur est bien plus que ça, et ce que je voulais dire c'est que si les jeux web s'appuyaient un peu plus sur le code serveur de jeux client/serveur desktop on aurait des interactions plus sympa que les jeux uniquement formulaires.

Le fait que ce code serveur soit uniquement serveur permet effectivement de tirer parti du web, de faire différentes interfaces pour différentes plateformes, etc.

Mais il ne faut pas qu'une technologie force les jeux dans un moule particulier. Or c'est ce qu'il se passe.

Sinon je m'aperçois que créer des modules indépendants s'avère très compliqué si l'on veut garder certains liens entre les modules, et pas juste un lien vers ceux-ci..

Ben à la limite, commences par faire un jeu, même un jeu nul tu t'en fous puisque le but c'est d'en tirer des composants. Une fois le jeu fini, tu en extrais ton framework.

[Aedius]

J'ajouterai : sans faute d'orthographe dans les noms de classes ("peutConstruire" et pas "peuConstruire"...), bien documenté, complété d'exemples "clef en main", maintenu et rétrocompatible (en cas de MaJ, j'ai pas envie de me creuser la tête ni de reprendre le moindre code).

Après, avec de tels critères, on peut même faire du payant ou se rémunérer d'une façon ou d'une autre (en vendant certains modules avancés par exemple).

Tiens, je ne suis pas seul à préfixer d'un "I" mes noms d'interfaces?! ^^

Ah ça l'orthographe ... C'est vraiment un truc qu'on perd bien trop facilement ...
Enfin en anglais c'plus simple : canBuild

I pour Interface
A pour Abstract
Tant qu'à faire parlant

[rachids]

Et la notation hongroise pour les variable (sMavariable = string, aMavar = array, o = Objet ...) ? :p

[Xenos]

Pareil @Aedius ^^ Ca aide ces petites abréviations

Le code serveur, c'est carrément du back-office... Enfin, j'espère que tes joueurs n'y ont pas accès :o Pour le joueur, ce qui compte, c'est l'expérience utilisateur, au fond, peu importe "comment ça marche" pour le joueur, faut juste que cela marche et bien
Au fond, que la machine du client fasse des requêtes "GET" en boucle chaque 10ms, ou que le serveur utilise un système d'évènements et de push, le joueur s'en fiche, il veut juste un jeu qui "s'actualise tout seul".

En revanche, oui, il faut éviter de se "brider" le gameplay à cause de difficultés techniques ou de manque de savoir-faire (c'est vieux, mais cela m'a marqué: "En informatique, tout est possible, mais ce n'est pas toujours évident!", BellamyJC).

Pour la méthode "jeu en premier, framework après", je suis d'accord C'est pragmatique, et cela évite "l'effet chercheur", c'est à dire faire un framework sans savoir s'il sera vraiment utile / comment il sera utilisé (comme un chercheur qui fait ses travaux sans véritablement se préoccuper de comment appliquer ses résultats à l'industrie).

La notation hongroise pour les variables ne m'était pas venue à l'idée

[niahoo]

le fait que le marché génère des offres aux joueurs, le fait qu'un world boss attaque une base d'un joueur, le fait qu'une base d'une faction PNJ attaque une base d'une autre faction PNJ, le fait qu'une équipe de foot PNJ défie celle d'un joueur, le traitement des évènements mis en queue lors d'une requête client, l'envoi de mail automatiques aux joueurs pour les informer d'un évènement en jeu, la résolution des tournois dans LeekWars, la gestion des boucliers de POS sur Eve Online, la gestion du classement PVP dans WOW (vanilla), la gestion de l'IA des PNJ dans DotA, les énigmes dans The Secret World, les PNJ dans GTA Online, l'avancement des prods dans Age Of Pyramids, le serveur websocket, le chat sur N jeux, les PNJ dans Browser Quest, c'est de ça dont je parle.

C'est ça le code serveur dont je parle, qui rend ton jeu plus intéressant que du remplissage de formulaire. Là on est en plein l'expérience utilisateur.

Je ne comprends pas ce que vient faire le back office dans cette histoire. Encore une fois tu n'envisages un jeu que via des div ou des span. C'est bien plus que ça.

[Max72]

Je vais écouter vos conseils avisés et prendre le problème dans l'autre sens : Je vais m'atteler à la création d'un jeu, et j'en sortirai le framework à la fin.
Mais bon, quitte à passer du temps dessus, autant essayer de faire un truc pas mal