Cherche Codeur de variables (genre jeu) JScript, Php, Maria-Sql...

monsieur tintin · Message par **monsieur tintin** » Hier, 22:14

Salut;
Dans le cadre d'un petit site artistique, j'aimerais mettre à l'écran une scène très visuelle (par exemple une représentation de la nature, ou autre) composée d'images-JavaScript cliquables, lesquelles appellent d'autres scènes suivantes.

Difficulté :
les images doivent appeler des scènes différentes selon l'état du compte d'inscrit qui clique... (état défini par 4 variables sur chaque compte d'inscrit).

N'étant pas informaticien, je cherche quelqu'un qui bricole un tel modèle, un petit dédommagement étant même possible.
Mon but est d'obtenir au moins les mécanismes adaptés à cette situation, sur quelques comptes et quelques scènes, tant qu'il s'agit de la bonne architecture, car il y aurait quand même une 40aine de valeurs possibles pour les variables, et environ 500 images en finalité.

imaginez par exemple : une sorte de jeux-vidéo dans lequel vous êtes un aventurier face à une scène de jungle et de pygmés... (Cela pourrait être aussi des martiens dans l'espace, ou une caverne-au-trésor, ou n'importe quoi d'autre).
Sur cette scène : 7 images remarquables sont cliquables.
Vous allez cliquer sur celle d'un petit "pont-de-bois" et ainsi changer de point-de-vue (changer de scène de fond) avec des nouveaux objets autour de vous, SAUF QUE ces nouveaux objets seront différents selon l'état de votre compte (et du type de compte); certains seront même absents, d'autres floutés.
Pareil avec la scène suivante; et ainsi de suite, de scène en scène.

Même si le JavaScript était capable d'avoir une sorte de base-de-données (ce que j'ignore) même au coup-par-coup (en RAM du navigateur) à mon avis la gestion serait plutôt par le SQL et le PHP :
- à la fois pour le grand nombre d'objets;
- forcément pour les comptes (ou alors "fichier plat" sécurisé à la place du Sql ?);
- et justement : pour les multiples "constantes" (les actions) qui définissent ce que telle valeur de variable de compte doit appeler comme scène (ces actions n'étant à priori pas la même chose que les 40 valeurs puisqu'au moins 100 scènes existent, les 40 valeurs étant juste un attribut de droit) alors il faut bien que les "actions" qui mènent aux scènes soient définies qlq-part (?) (actions en cliquant sur un des objets de la scène précédente).

Concernant les images (les objets-cliquables), ma vision première était un simple répertoire appelé par ces actions;
mais j'ai pensé ensuite à une table txt en "fichier plat", ce qui m'aurait permis d'ajouter quelques "colonnes" pour une gestion des images - et ce projet aurait vraiment été l'occasion fructueuse pour cet exercice de "fichier plat";
car même si un SGBD parait plus "facile" c'est en faits un moyen supplémentaire lourd et coûteux (serveur, langage à connaitre, options d'hébergement...).

Selon les 40 valeurs du compte qui la clique, chacune de 300 images peut :
- être cliquable mais appeler une chose différente (c'est à dire une scène suivante, une autre image dans la même scène, ou un message);
- ne pas apparaître dans une scène (alors qu'elle apparaît pour d'autres valeurs du compte);
- apparaitre mais floutée (toujours selon le compte) ou envoyer une autre fonction (comme un lecteur).
Précision : une image n'appelle pas 40 scènes différentes selon les 40 valeurs. Souvent : l'image-cliquable n'aura que 3 directions de scènes différentes mais c'est les 4 variables aux 40 possibilités de valeurs qui devront être sondées pour voir si au moins une de ces valeurs autorise le compte à aller vers une des 3 directions (soit en la choisissant par un "petit menu-à-3-flèches qui apparait, soit parce qu'une des 3 directions est programmée d'office dans "l'action") (les 2 autres directions vers laquelle enverrait l'image étant pour une autre valeur venant d'une autre action).
Ces deux notions (d'une part l'appel d'une scène globale, et d'autre part : l'escamotage de certains de ses composants selon les variables) sont bien deux aspects qui doivent co-exister; (des comptes peuvent aller dans une scène mais ne pas avoir tous les droits).

Donc pour un codeur, je me demande ce qui doit comporter des attributs... Les comptes ? ou plutôt les images...
à mesure que j'élague mon plan : j'ai l'impression que c'est l'image qui devrait "vérifier" les variables du compte, donc en somme une 40aine de valeurs, et non 300 X plusieurs colonnes d'attributs d'images.
Cependant, me vient comme une peur sur le sens de cette facilité... Donc coder ce qu'un compte peut ou ne peut pas : devra sans doute exister aussi; (et où sont les "actions" (?)...

J'arrête ici mes supputations, puisque je ne suis absolument pas programmeur.
Toutefois, afin de motiver une personne à me répondre, je vous informe que les 40 valeurs sur les comptes viennent d'un besoin assez ingénieux qui peut reservir dans d'autres domaines, et dont vous ferez sans doute votre profit, peut-être, ça dépend de si j'ai envie de vous dévoiler ce genre de détails, suivant votre implication et le niveau de finition dans l'exercice.
En attendant : les valeurs sont 40 nombres de 4 chiffres, valeur attribuée à la "création d'un compte".

Plan concret :
j'avoue que c'est encore confus; il faudrait que j'étale tout ça dans un schéma pour voir où j'en suis, que fait quoi, et quelles fonctions en découlent.
En pratique : je pense que ce serait un script-PHP qui (après un 1er sondage sommaire sur le type de compte)(un autre type de variables) envoie une scène générale avec des objets-cliquables, qui eux, sonderont précisément les 40 valeurs.
Donc, un objet-cliquable comporterait à la fois : un script général d'action afin d'envoyer une scène, mais comme l'objet pourrait être appelé dans d'autres scènes : il comporte aussi le "sondeur" des 40 valeurs, (et quelques attributs en propre (là pour le coup x 500).
En faits, je ne sais pas.

Y'a encore une grande confusion dans ma tête, entre :
- d'une part : je clique sur un objet > (dont l'action différente selon 3 types de comptes) appelle quand même globalement une scène avec 7 objets-cliquables, (donc 1er niveau de différence de scènes selon 3 types de comptes);
- et d'autre part (2ième niveau de différences) : chacun des 7 objets qui arrivent avec cette scène sondent plus précisément les 40 valeurs possibles du compte pour savoir : 1- s'il s'affiche ou non, 2- s'il se REMPLACE PAR UN AUTRE objet, c'est à dire qu'au lieu d'apparaitre : un script sur l'objet lui-même institut à sa place un autre objet plus adapté à la valeur sondé (mais heureusement pas ainsi pour les 40 valeurs, peut-être simplement un "vrai ou faux").
Et donc, si vous avez bien suivi : les 6 premiers objets comportent aussi un script plus général d'action pour appeler une autre scène globale, laquelle comporte à nouveau 7 objets qui eux-mêmes sondent plus précisément les 40 valeurs pour savoir comment ils s'affichent, etcetera.

Je suis désolé de vous avoir embrouillé en "programmant" à votre place, mais globalement vous voyez la chose.
Je fournirai des exemples plus concrets.

Encore une fois, ce serait l'occasion de comparer les deux systèmes de base-de-données.
Je ne sais pas ce qui m'y pousse : mais j'ai envie de ce "fichier plat" avec quelques explications, parallèlement au SGBD... Alors évidemment c'est peut-être beaucoup demander à un jeune qui veut des résultats très vite, et pour un exercice qui sort peut-être de son propre projet personnel.
Et du reste (tant qu'on y était) je trouve dommage de ne pas pousser cet exercice dans le sens où chacune des 300 images puisse envoyer vers 40 directions différentes selon les 40 valeurs (au lieu de 3 directions); y'a peut-être un intérêt mieux ré-exploitable en terme de structure ?

Merci de vous présenter un peu en privé pour celui qui voudra vraiment répondre (votre niveau sincère, situation, âge, même en plus court) car il est toujours difficile de re-répondre à quelqu'un qui n'indique pas sous quel angle lui parler... Et si vous savez lire, le téléphone sera peut-être plutôt encombrant... (en tout cas pour moi).
L'orthographe n'a pas d'importance;
rien ne presse.
Salutations.