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

[monsieur tintin]

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'un fond et 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 un "fichier plat" sécurisé à la place du Sql ?);
- et aussi 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 pas la même chose que les 40 valeurs puisque au moins 100 scènes existent, les 40 valeurs étant juste un attribut de droit pour ce qu'on peut voir dans chaque scène). Alors il faut bien que ces "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...
Ce projet n'aurait-il pas é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...).

Un objet-cliquable.
Selon les 40 valeurs du compte qui clique, chacune des 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);
- peut ne pas apparaître dans une scène (alors qu'elle apparaît pour d'autres comptes).
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 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 choisissant cette direction par un "petit menu-à-3-flèches qui apparait, soit parce qu'une des 3 directions est programmée d'office dans "l'action" pour cette valeur) (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 bien les 7 images appelées qui devraient "vérifier" les variables du compte (mises en RAM du navigateur si possible). Ainsi, malgré les 300 scripts associés aux 300 images (ou peut-être à un groupe d'images) cela permettrait d'exploiter le navigateur plutôt qu'un gros script systématiquement sollicité sur le serveur.
Cependant, j'ignore ce qui alerte le plus un hébergeur : le nombre d'appels ? ou la charge du serveur...


J'arrête ici mes supputations, puisque je ne suis absolument pas informaticien.
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".

Scénario concret :
j'avoue que c'est encore confus; il faudrait que j'avance pour savoir où j'en suis.
Mais en termes de fonctions, ce serait comme :
- un script de connexion connecte 1 des 5 TYPES de comptes de BASE (défini par quelques variables de session);
- une scène générale apparait (disons la i000-AA-T2) et comporte les objets n° 011,021,022,023,024,349,407.
- Le type clique sur l'objet 023, alors un script envoie une autre scène (la i023-AB-T2) selon le type de compte-de-base; (donc un 1er niveau de 5 différences selon les 5 TYPES de compte ?);
- Mais le script a surtout défini quels objets sont envoyés avec la scène i023-AB-T2 (c'est à dire les 021,026,027,032,145, qui eux, sonderont précisément les 40 valeurs pour savoir s'ils s'affichent vraiment.

Donc, un objet-cliquable comporterait à la fois : un script d'action afin d'appeler une scène suivante, mais comme l'objet peut être appelé par d'autres scènes : il comporte aussi le "sondeur" des 40 valeurs; (à moins qu'un script global pour chaque scène gère tout ce qui s'y trouve, les objets ne comportant plus qu'un numéro) (c'est alors chaque script-de-scène qui sonde les 40 valeurs et gère le droit aux objets).

Y'a encore de la confusion dans le plan, car :
- des objets sondent aussi les valeurs pour savoir si il se REMPLACE PAR UN AUTRE objet, c'est à dire qu'au lieu d'apparaitre : l'objet lance un script sur lui-même en substituant à sa place un autre objet plus adapté à la valeur sondée (mais heureusement pas ainsi pour les 40 valeurs (ni les 300 objets).
Pour ces objets, mieux vaudrait peut-être qu'ils emportent leur propre script au-delà de la gestion par le script-de-scène ?

3 scènes possibles, (voir aussi le début du paragraphe "Un objet-cliquable").
Par exemple, le script 023 peut renvoyer une scène différente selon le choix de l'utilisateur (scènes i023-AB-T2 ou i023-AC-T2 ou 023-AD-T2) mais en fonction du type de base T1 à T5; et là, y'a un problème... Car je devrais alors instituer 3 scènes x 5 types de comptes ? (15 scènes ?)... (x les 100 générales ?)...
Si, ça va, finalement... car une scène n'est pas obligé de tenir compte de la variable T, et une même scène peut être affectée à plusieurs valeur de T.

L'idée était de faire :
- d'une côté les 5 types de base (par exemple le choix d'un rôle, d'un avatar, d'un pouvoir GéNéRAL qui s'applique en toute situation plus facilement qu'un sondage répétitif des valeurs);
- d'un autre côté : les 40 valeurs plus changeantes (car un même type acquière des droits différents, des facultés, ou ce que vous voulez).
Et dans un autre contexte : cette idée se justifie, peut-être, encore plus (compte-professionnel, compte-particulier, compte-abonné)... J'ignore comment les portails gèrent ce genre de différences, alors qu'un type de compte a lui-même des différences (qui toutefois ne sont pas forcément les nôtres ici).

Quoi qu'il en soit, les 40 valeurs (ou 50) sont seulement dans 4 ou 3 variables : car c'est très intéressant de voir ce qu'on peut faire avec des suites-de-valeurs dans une même variable plutôt que 40 variables, j'insiste sur ce point, y compris sur des suites-de-valeurs qui pourraient (dans d'autres contextes) subir des recherches SQL ou en fichier plat.
D'autres variables par ailleurs, bien-sûr, peuvent être gérées séparément.

---

Je suis désolé de vous avoir embrouillé en essayant de programmer à votre place, mais globalement vous voyez la chose.

Encore une fois : ne serait-ce pas 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...

Pour un mécanisme de base : je laisse de côté des aspects comme la RAM du navigateur (vu les quantités largement supérieures de vidéos qu'on charrie) mais quand même : se pose peut-être des soucis de "discrétion" dans le "cache"... On trouvera bien une autre personne qui peut nous aider si besoin.

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.