Nom du projet : dbark, débarque, des barques (pour le nom du jeu, on verra plus tard)
Url : localhost...
Style de jeu : RPG
Univers : non encore défini, je cible d’abord le système de jeu et les fonctionnalités d’interface. Le background se construire après (fonction de l’appétence de ceux que j’espère être mes testeurs/ premiers joueurs) Cela ne veut pas dire que je n y attache pas d'importance, j ai déjà quelques idées, simplement ce n'est pas le moment
Principe du jeu (quelques lignes) : Vous jouez un personnage qui débarque, sans espoir de retour, sur un continent/planète/autre poussé par une entité supérieur (empire galactique, crash d’avion, dieux, savants, royaume perdu, etc...)
Technologie : AJAX, JS, PHP 5, MySQL, CSS
Type de codage (Procédural, objet ou rien) : on dira objet
Framework : JS : prototype et scriptaculo
Moyen de communication (Courriel, MSN, ICQ, Forum, Wiki, ...) : pas trop compris la question. Pour me contacter, ben par jeuphp, pour les fonctionnalités du jeu, à voir rien de définitif, messagerie interne + forum probablement.
Charge en terme de jeu : 10 à 30 minutes par tour, avec en cible un tour par jour
Contrainte d'âge : très probablement un niveau de maturité sera exigé (comme si on pouvait « exiger » sur internet)
Volonté bénévole du jeu : ca dépend, si ça me permet de prendre ma retraite à 45 ans, il sera payant, sinon... Du plus ou moins bénévole (bizarre je pense devoir travailler encore longtemps... longtemps...)
Quelle est la complexité du jeu ? le système ne sera pas aisément accessible (les règles de gestion ne seront pas toutes divulgués. Les actions des joueurs, quant à elles seront je l’espère naturelles (mais c’est subjectif, à tester en cible)
Combien de joueurs vise le jeu ? de quoi prendre ma retraite, sinon au moins quelques dizaines, sans quoi le jeu perdra de son intérêt
Idées nouvelles du jeu pas la prétention d’avoir inventer le super nouveau truc. Je cherche la qualité plus que l’aspect novateur (même si, j’espère, avoir quelques idées nouvelles, mais les muses m’ont posé un lapin)

Compte test (pseudo et mot de passe) : d / 1 mais bon, sur mon poste à la maison, alors...

Bien, maintenant que la fiche analytique a été réalisée, un peu de « figure libre »

Inspirations
Côté règles de gestion, le système dbark s’inspire de différents jeux de rôle que j’ai pu croiser dans ma jeunesse (même si je ne jouais pas beaucoup, je rentrais bien dans les règles) A savoir en particulier les suites chaosium (runequest, hawkmonn, le monstre que j arrive pas à écrire chtulu) et whitewolf (vampire, loup garou…)

Côté interface, deux sources :
- wow (pas pour l’aspect temps réels avec des super décors) pour les manipulations (objets, etc…)
- fractal (je crois que le jeu n’existe plus) pour la navigation, la carte, etc… C’est d’ailleurs en jouant à ce jeu que m’ai venu l’idée d’en créer un, dans un premier temps simple défi technique puis pourquoi pas le mettre en vrai sur la toile (enfin… un jour dans dix ans hein)

Côté background….. hahaha pour ceux qui ont suivi, le monde n’est pas déterminé donc…
Même si ma préférence va plutôt au mythe celtique, quelque soit le choix cible, mes sources seront diverses (d’autres jeux, des romans, l’histoire, les religions, la politique)

Principe de base : Personnage

Le joueur incarne un personnage. Un personnage est défini par ses caractéristiques, ses compétences, ses … envies (pas encore fouillé trop ce côté là). Par contre, un personnage n’a pas :

Pas de classe (pas de guerrier, mage, au sens strict du terme) : un personnage peut avoir des fonctions de guerrier (il est spécialisé dans les armes), de mage (il est spécialisé dans l’utilisation de la magie, mais peut évoluer comme il l’entend dans ses compétences, etc…

Pas de niveau, pas de points d’expérience. Un personnage évolue en fonction de ses actions ( je n’augmente pas cuisine en tuant des monstres)

Evidemment, lors de la création du personnage, le joueur choisira son back ground (formation, etc…) qui lui permettront d’être meilleurs dans tels ou tels domaines.

Principe de base : Jeu
La vie que je modélise est la suivante :
1) la survie :
Pour ne pas mourir, il faut vivre, la vie est mouvement
Donc on bouge
Donc on s’épuise
Donc on se repose et on consomme
Donc on récolte

2) le progès
Pour améliorer son quotidien, ou pour passer du temps à autre chose que marcher manger dodo, l’homme doit améliorer sa condition
Donc on fabrique des outils
Donc on construit des bâtiments

3) le tissu social
Ces tâches sont parfois complexes et nécessitent la confrontation de compétences pas toujours maîtrisées voir simplement pour aller plus vite, la mise en commun de ressources.

Donc on échange
Donc on fait des actions évoluées
Donc on combat

Principe de base : Moteurs du jeu

Le moteur principal est la progression :

J’agis donc je m’améliore.

L’amélioration se fait sur trois pans :

Je m’améliore parce que je suis en meilleur état (je suis moins faible, moins fatigué)
Je m’améliore parce que mes compétences progressent (je suis plus fort)
Je m’améliore parce que je suis plus heureux (les actions que je réalise correspondent à mes envies. Exemples je suis faignant, je dors je suis heureux. Je suis méchant, je fais souffrir, je suis heureux)

Le moteur secondaire est la diversité :
J’ai besoin de l’autre pour réaliser certaines tâches, je ne peux pas tout faire moi-même.

On aura donc le choix entre être moyen/médiocre partout ou être expert en quelque chose
Je peux survivre moi-même si je suis compétent
Je ne peux pas maximiser l’ensemble de mon état (bonheur, équipement, etc..) sans l’aide de compétence que je ne peux acquérir moi même

Le moteur tertiaire contrôle :
Mes actions ne doivent pas pourrir la vie des autres joueurs. Bien sûr on ne doit pas être dans le monde des bisnounours (sauf si je vire « combat ») mais un personnage trop fort, trop violent, trop empêcheur de jouer les autres est un danger pour le jeu lui-même. J’ai plusieurs idées pour ce faire mais encore rien mis en pratique.

bien sûr d’autres aspects comme le rôle play sont des moteurs pour jouer, mais ce n’est pas php qui va faire le rôle play

Risques majeurs du projet

- trop ambitieux question charge de « travail »
- trop ambitieux question performance (base de données, etc…) pour un jeu php/mysql sur serveur internet normal
- trop complexe pour toucher assez de joueurs


pour la suite.... plan d'action et où j'en suis

J'aime bien ta démarche de réflexion concernant les moteurs du jeu, je crois que je vais m'en inspirer !!!
Ca parlotte, ça parlotte, ça se dessine... mais ça reste quand même assez flou en tout cas ça promet, si je peux te donner un conseil essaye de concentrer tes idées sur une base solide (esprit volatile apparament comme le mien): énumère les compétences, les actions, les objets de tes persos, fait des arbres, pense à ta map, les couleurs de ton jeu...car là tu restes assez éloigné de la prog et le problème quand on a un esprit débordant d'idée c'est qu'arrivé devant la prog on se dit: "euh...finalement comment je vais gérer ça..." donc fait d'abord des bases et construit dessus

Pas forcément, on a une idée de base que l'on adapte par la suite, il ne faut pas penser aux deux à la fois, concept/programmation doivent restés séparés au début (enfin je veux dire par là que prog est inexistante au début).
Par exemple quand un ingénieur dit à sont technicien : "je veux, ça, ça, ça...", il a donc définit le concept, puis le technicien voit si le projet et réalisable (il se décarcasse jusqu'au bout de la nuit), et si certaines options sont irréalisables ou trop lourdes (c'est à dire trop longues à réaliser), les deux se concertent et adaptent.
Il ne faut donc pas mettre de limite (tout du moins au début) à son imagination, si elle est très productive, tant mieux.
Mais, c'est vrai qu'après la phase de rêverie, il faut défini clairement le projet, son but, son mode de fonctionnement.
Cordialement, emaia.

On a pas la même vision des choses emaia (enfin il faut de tout pour faire un monde), j'ai peut être une démarche trop "technicien" j'ai l'habitude de créér d'abord une base solide avec un noyau précis et ensuite je travaille l'imagination pour agrandir le projet, de toute façon en entreprise (quelques expériences) on dit de faire ça ça ça...finalement quand c'est fait, on dit finalement ça aurait été mieux comme ça ah! et si on rajouté ça aussi...alors que pourtant le cahier des charges est fait et l'analyse également, donc bon c'est peut-être des hasards...enfin après le "developpement de SON PROPRE jeu" c'est un peu personnel, l'essentiel c'est que ça marche et que l'on prenne du plaisir donc soit, enjoy your game!!!

ah mais ma base (mon noyau) est extrêmement (un peu pompeux quand même ) solide

simplement tu ne mets pas le curseur de la "base" au même niveau


Exemple : ma base dit :

j ai une action à réaliser

elle fait entrer en jeu :
- de l'énergie à dépenser (ex, on se fatigue)
- des outils nécessaires
- des matières premières
- des compétences
- un résultat

maintenant que ce soit un sabre laser, une robe de mariée, ou une hache en silex , cela revient au même, ça respectera ce modèle

conclusion, je n ai pas besoin de savoir quelles sont les compétences pour avancer sur le modèle de compétence

Passons maintenant à l’interface (ce sera plus concret). De plus l’angle « interface » est, vu mes compétences, le meilleur angle d’attaque pour mesurer l’avancée du projet. En effet, je mets énormément moins de temps à monter un système de règle de gestion qu’à l’afficher De plus, comme une grande majorité des règles sont déjà pensées voire modélisées, le point critique est la mise en œuvre de l’interface.

Les différentes fonctionnalités que j’ai identifiées :

1) la carte (fait)
2) l’inventaire (en cours)
3) l’équipement sur le personnage (en réflexion)
4) les actions de production (pas fait)
5) la fiche de personnage (pas fait)
6) le combat (pas fait)
7) l’exploration d’un lieu, et les actions associées (pas fait)
8) le récapitulatif des événements – vous croisez xxx…- (pas fait)
9) la messagerie interne (pas fait)
10) le forum (pas fait)
11) je ne sais pas comment appeler cela alors… les « gambits » de final fantasy (pas fait)

Rien qu’en regardant la liste, je me dis que je suis loin d’avoir fini….

Sur ce qui a été fait ou en cours :

1) la carte (v0).

La carte est une vue 2d hexagonale. Chaque hexagone est une image indiquant le type de lieu, grosso modo un hexagone correspond à un champ agricole (pour se donner un ordre d’idée sauf que…ça a quelle taille un champ ?). De fait il n’y a que deux dimensions de jeu pour les déplacements sur la carte (on peut être en l’air selon le véhicule, mais l’altitude n’a pas de dimension tactique)

On déplace le personnage grâce à une rose des vents (par choix, pas de clic sur la carte pour se déplacer)
Différents tests sont faits pour éventuellement interdire le déplacement :

Le personnage a-t-il un véhicule adapté au terrain ?
Le personnage a-t-il le temps pour se déplacer (fonction du véhicule, du terrain, etc…) ?
Le personnage a-t-il l’énergie nécessaire pour avancer ?

Quelques actions basiques : faire un campement, se reposer, etc…

En version ultérieure il faudra prévoir l’interaction avec les points 7 et 8 (exploration et événements) et peut être rendre plus sexy la carte (3d ?)

J’ai mis du temps sur la carte car c’est avec elle que j’ai appris l’AJAX, et que je me suis mis au CSS (beaucoup de difficultés d’un coup )
Concernant le rafraichissement de la carte, au départ j’étais parti sur un chargement partiel (les terrains que l’on découvre juste sont chargés en AJAX, le reste est juste déplacé par JS) Après différents tests de performance (biaisés certes car fait en local) et réflexions (le serveur me dit si le mouvement est possible donc je ne peux pas anticiper le déplacement en pur JS), je charge aujourd’hui à chaque déplacement toute la carte XML. A voir en « live » si cela pose de vrais soucis de performance, ce ne sera pas trop dur de revenir au partiel.

2) l’inventaire
Point simple a priori mais qui finalement me bloque et me démotive…

J’ai voulu travailler sur un inventaire poussé pour deux raisons :

+ il y a des joueurs qui peuvent apprécier de bien ranger leurs affaires, or il y aura probablement beaucoup d’item à prendre (pensons wow like) il faut donc pour ces joueurs avoir une fonctionnalité d’inventaire poussée

+ le pick pocket.. Je souhaite que les actions de vol à la tire puisse « stressé » le joueur (donc plus d’excitation, plus de plaisir). Si je n’ai pas un inventaire poussé cela me donne :

X veut voler Y
Il rate alors alerte
Il réussit alors il arrive à voler (tirage de dés) un machin

Pas super excitant comme système (mais au moins c’est un système qui marche pas comme le mien )

Là où je veux aller

X veut voler Y.
Y porte un sac à dos, X décide de fouiller ce sac à dos
Il rate alors alerte
Il réussit, il découvre dans le sac à dos deux sacs , une couverture, une corde, un poignard et une bourse ( ou du moins c’est ce qu’il a l’impression de trouver dans le sac à dos)
X doit choisir entre pousser plus loin son exploration (fouiller un des deux sacs ou la bourse) ou prendre ce qu’il a identifié (dommage la corde est un serpent, …)
A chaque action de X fouiller plus encore, il y a une chance que Y s’aperçoive de quelque chose…
Du coup grosse interface (c’est couillon je n’ai jamais joué de voleur alors pourquoi je m’embête avec ça) qui marche…. Sous firefox pas sous ie…

J’ai deux problèmes sous ie :
-1 il rame beaucoup (cf mon post la haut)
-2 il me fait des effets de bord d’affichage suite au CSS.

Donc je suis devant une situation dure :

Soit je réduis la voilure fortement (genre vous portez 4 sacs et chaque sac possède 12 emplacement, et c’est bien soyez heureux)

Soit j’abandonne les joueurs sous ie (genre z avez qu’à prendre FF bande de nuls)

Soit je trouve (par hasard, j ai rien trouvé avec google:/ ) un article quelque part qui me donne un retour d’expérience identique sauf qu’un gars aurait trouvé l’astuce

Soit je refais tout (c’est une possibilité, je passe du « essaie d’être puriste en CSS » au « je fais peut être pas propre mais ça marche »)

Je n’arrive pas a passer à la suite tant que je n’aurai pas lever ce problème, c’est bien malheureux

N’empêche ce module m’a fait découvrir :
Un css un peu plus avancé
Les librairies Prototype et Script aculo

Perso l'option suivante me semble la meilleur :

Citation :Soit je refais tout (c’est une possibilité, je passe du « essaie d’être puriste en CSS » au « je fais peut être pas propre mais ça marche »)

Je suis pas souvent voleur, mais tu me donnes des idées pour mon jeu . Bon je n'ai pas opté pour un système de sac à dos en case par case... je préfère la liste basique.

Bon courage.
Kéké.

Ton projet m'intéresse, je te contacte par le biais d'un MP

Ah deux semaines de vacances avec un portable, idéal pour avancer un projet qui stagne

sauf que.... les vacances avec madame, c'est plus des vacances sans php qu'avec


de fait

après l'épisode inventaire que j'ai laissé en stand by (merci les lag ie pour les drag and drop complexes)

j'ai travaillé sur trois axes :

1- technique de code HTML :
suite à diverses discussions qu'il y a eu ici, j'ai corrigé / amélioré mon code :
- basculer les javascript en fin de page plutôt qu'au début
- ne plus mettre de href=javascript mais des href="#..." et des addEvent
- réduire le nombre de addEvent
Exemple : J'avais un menu (ul / li) avec un addEvent par li, j ai mis un seul addEvent sur le ul, et tout marche pareil
- ne pas cacher les onglets directement par le css mais dans le javascript (une fois la page chargée), afin de permettre à ceux qui désactiveraient js d'accèder à tout (d'un autre côté je ne suis pas prêt à investir trop sur le site sans js, donc le gars verrait tout mais ne pourrait rien faire)

un petit peu de nettoyage donc à noter le javascript à la fin , je ne sais pas si je vais le garder. En effet, le portable que j'utilisais étant un vieux tromblon, je suis tombé dans une situation frustrante :

sous firefox, je charge la page, js se lance très vite, tout est parfait
sous ie, la page se charge (texte,image) mais le js est très long à se charger donc le "masquage" des onglets n'arrive pas tout de suite. Total l'utilisateur (moi même) a l'impression que la page est chargé, et tente de cliquer sur un bouton, s'acharne dessus, pour rien, puisque le système n'est pas encore prêt.

2- un "outil" générique en plus
je me suis développé une classe php (suivi d'un code js) pour mieux gérer certains de mes menus, sans avoir à me retaper tout le code à chaque fois. Elle est pas forcément terrible mais au moins, elle me permet d'avoir un comportement standard pour tous mes menus.

3- l'interface de l'onglet exploration
je suis dans un lieu, je cherche à trouver, de l'eau, des plantes, des gens, etc.... c'est ici que ca se passe.

pour le moment uniquement l'interface est construite, ni l'ajax, ni le calcul serveur. On pourrait croire, du coup, que l'onglet exploration est réalisé à 10%, mais au final, j'ai plus de difficulté à créer une IHM (css + js) qu'à construire la requête ajax ou le calcul des résultats php. Du coup le volet exploration est à plus de 60%

voilà, une légère avancée, qui m'a permis de reprendre du poil de la bête suite à la bonne claque dans la tête sur l'ihm de mon inventaire avec ie. Pas très content d'avoir fait 'si peu' mais content de m'être remis sur les rails.