Modules

[Xenos]

avec sa possibilité de développer en ruby

On finit toujours par retomber sur ce genre de phrase Alors, est-ce bien utile de se farcir du code d'interface, si 90% des bons jeux devront s'en affranchir? Perso, je pense qu'un CMS pour créer des jeux innovants et originaux n'est pas la meilleure solution (niveau gameplay! on peut très bien faire un bon jeu original niveau histoire mais plan plan et classique niveau gameplay). En revanche, un "paquet" de classes type framework qui sont ou non réutilisées, pourquoi pas (mais je m'en servirai pas car j'ai envie de farfouiller, par plaisir dans les tréfonds des codes :p).

[rachids]

Pas faux.

J'avoue que des modules de frameworks purement orienté jeu web ça ferait rêver.

[niahoo]

Le problème c'est que qu'on voit pas mal de jeux web ou en gros on a un site web vaguement interactif et ça s'arrête là. Des frameworks orienté jeu ça n'existe quasiment que pour la création visuelle. Donc pour nous ça sera du javascript. Le site en lui même ne fait pas grand chose, il se contente de faire transiter les données entre les clients et le serveur.

Si tu veux une vraie interaction entre les joueurs, le code serveur n'a pas besoin d'être orienté "jeu web". Il faut du code serveur orienté jeu tout court, voire multijoueur. Et ça il y en a plein.

Le vrai problème c'est qu'il y a trop de jeux qui consistent en "Formulaire HTML > requête POST > traitement PHP > base de données" ad libitum.

Donc je ne vois pas trop ce que tu voudrais comme framework « purement orienté jeu web ».

[rachids]

Donc je ne vois pas trop ce que tu voudrais comme framework « purement orienté jeu web ».

Je pensais à certaines choses que l'on retrouve dans de nombreux jeu web. Gestion d'alliances, de caractéristiques, module de succès, parrainage etc.

Des choses qui ne sont pas vraiment propre qu'à un seul jeu.

Le vrai problème c'est qu'il y a trop de jeux qui consistent en "Formulaire HTML > requête POST > traitement PHP > base de données" [i] ad libitum.[/i]

Hum... Ca ressemble pas mal à ce que je fais :$

[niahoo]

Oui bon après y a de très bon jeux aussi qui utilisent ce schéma là. C'est pas forcément un mauvais schéma. C'est juste que PHP tend à faire entrer le programmeur dans ce moule alors que ce n'est pas forcément la meilleure manière de concevoir un jeu, c'est à dire du gameplay et du fun.

Ensuite si le jeu repose avant tout sur un scénar et des énigmes par exemple, de la réflexion plus que de l'action, ça ne pose pas forcément problème. C'est d'ailleurs pour ça je pense qu'on fait surtout des jeux de gestion. Mais les RPG en PHP c'est pas très fun.

Gestion d'alliances, de caractéristiques, module de succès, parrainage etc.

Comme je le disais ceci n'est pas spécifique à du jeu web mais à du multi. Tu dois pouvoir trouver des librairies dans ce domaine. Pas forcément en PHP mais par exemple en Lua, que tu peux faire tourner dans PHP ou du moins t'en inspirer.

[Xenos]

HTTP n'étant pas étudié pour faire, de base, de l'interaction client-client, c'est assez normal d'avoir du client-serveur, des formulaires webs et du PHP... A mon sens, si c'est pour faire du client-client (et de la 3D car généralement, hein, faisons les deux puisqu'on a webGL... >.>), il ne faut pas aller voir les jeux webs, mais les jeux tout courts. Les SDK font déjà tout le travail pour ce qui est du réseau, de la 3D, et fournissent même généralement des classes pour n'avoir plus qu'à créer l'univers lui-même.

On me propose un "Formulaire HTML > requête POST > traitement PHP > base de données" avec une idée originale et une bonne réalisation, j'adhère de suite.
On me propose un jeu web hyper 3D en temps réel type FPS ou MMO qui charge pendant 20 minutes (parce qu'il faut re-transférer tout le jeu chaque fois) avec 3 plugins nécessaires (Adobe, Unity et allez, mettons du Java pour le chat), du javascript partout (parce que hein, le site, y sait surement tout mieux faire que le navigateur parce que le navigateur est surement mal fichu, très bête et pas du tout adapté à la machine sur laquelle on navigue) et où toutes les interactions se font de client à client (donc passé 8 joueurs en même temps on se retrouve avec 56 connexions au total), et bien je me tire très vite

[niahoo]

Tu n'a pas compris mon message. Je n'ai jamais parlé de connexions client-client.

Remplir des formulaires à la longue ça lasse. Bien sur c'est presque indispensable. Mais il faut proposer plus que ça : des interfaces plus riches (pas forcément en 3D) et un monde cóté serveur ou tout n'est pas régi par les requêtes client.

[Aedius]

Tu n'a pas compris mon message. Je n'ai jamais parlé de connexions client-client.

Remplir des formulaires à la longue ça lasse. Bien sur c'est presque indispensable. Mais il faut proposer plus que ça : des interfaces plus riches (pas forcément en 3D) et un monde cóté serveur ou tout n'est pas régi par les requêtes client.

Je suis entièrement d'accord.
J'ai toujours abandonné mes projets à cause de ce genre de soucis et finalement, nodejs me permet de faire des choses beaucoup plus riches.

Je suis en train de faire des test sur un petit jeu simple et basique (une reprise d'un jeu auquel j'ai joué en 2004 ) pour en tester les capacités et surtout apprendre la technos.

[Max72]

Bonjour.

Je vois que la conversation dévie, mais le sujet est très intéressant
Malheureusement, je ne connais pas nodejs etc, donc je reste cantonné à mes requêtes POST et GET ^^

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..

[Xenos]

Okay, j'ai mal généralisé. D'accord pour "l'habillage" du formulaire, en revanche, si le jeu se prive de l'aspect cross-plateform du web, alors il n'y a plus d'intérêt à passer par le navigateur. Si a une idée hyper précise de ce à quoi le jeu doit ressembler quelque soit la machine sur laquelle il tourne (exemple typique d'un jeu qui serait 100% canvas), alors on est dans l'impératif et un SDK classique (Unity par ex) permettra d'aller bien plus vite, et de mieux profiter des composants de la machine.

Après, beaucoup de jeux se limitent à du formulaire car ce sont souvent des "essais" de programmation, ce ne sont pas des jeux destinés à ramasser de l'argent pour en vivre, alors forcément dans de tels cas, on se limite à des choses basiques (cf @Aedius), car "commencer par un petit jeu simple et basique" permet de prendre ses marques. Il faut croire que beaucoup abandonnent ensuite avant de se lancer vers "plus étoffé", et on croise au final énormément de jeux-formulaires.

En revanche, le monde coté serveur qui n'est pas dirigé par les requêtes client, c'est du back-office. Au fond, le client s'en fiche...

Oui, pour en revenir au sujet, faire des modules indépendants requiert une certaine vision d'esprit... Quand on réalise le module "A", difficile de se forcer à ignorer ce que contiennent les autres modules (pour éviter les dépendances). D'autant plus difficile d'ailleurs si on est seul à travailler sur tous les modules, car alors, on sait ce que les autres modules contiennent et comment ils fonctionnent, ce qui rend difficile le fait "d'ignorer" leur contenu pour éviter les dépendances (pas sûr d'être clair là...).