Discussion :

[Kearz]

Bon, je savais pas où poster mais comme mon problème actuel est en PHP, je pense que c'est le bonne endroit.

J'ai un problème avec le concept de POO et BDD en PHP.

Je m'explique, je comprends très bien le concept de POO, j'en fais beaucoup en JAVA. Cependant quand je fais ça je n'ai pas vraiment besoin de BDD. (Sauf à la limite pour stocker des résultats, des scores. En gros pour stocker une fois que l'application à "fini de tourner")
De même, la notion de BDD pour stocker des données pour un site web, je comprends bien. Ça permet de sauvegarder, de vérifier, etc. (Bref, pas vraiment de problème en PHP4)

Maintenant, le mélange des deux est un peu obscur. Je suis en train de créer deux sites, le premier étant un jeux (multijoueur).
Pour faire simple, les joueurs auront leurs personnages et pourront faire divers actions. Le problème c'est que si je stocke le joueur en POO, exemple la vie du joueur, si le joueur perds de la vie (variable $_vie) les autres joueurs ne le verront pas...Et pire en encore, si je change des variables et que le joueur quitte, les données seront perdu.
Mais si je stocke dans la BDD, j'ai du mal a voir l'intérêt d'utiliser la POO. Je stocke les données et puis c'est tout. (J'vois pas trop l’intérêt à par peut-être pour utiliser des méthodes? Après les méthodes il me suffit de les dispatcher dans divers fichier .php et basta)

Donc la question qui se pose c'est: Quand stocker les données dans la BDD. Quand les stocker dans des variables POO.

La seule solution que je vois pour utiliser la puissance (enfin, l'organisation plus propre, les méthodes, etc.) de la POO et une BDD, serait qu'à chaque modification j'actualise les deux: l'objet et la BDD.

Hum..Bref, j'ai loupé un concept? Ou il faut vraiment faire comme ça?
J'ai l'impression de passer à côté d'un truc gros comme une montagne. :/

[grunk]

La seule solution que je vois pour utiliser la puissance (enfin, l'organisation plus propre, les méthodes, etc.) de la POO et une BDD, serait qu'à chaque modification j'actualise les deux: l'objet et la BDD.

Tu ne rate rien c'est bien le cas.

Dans ton cas tu vas avoir une table Joueur qui aura différentes colonnes. Très souvent à chaque table est associé une classe php.

Donc tu aura une classe Joueur avec comme attributs les différents champs de ta table.

On peut imaginer une méthode statique get() qui te permettra d'obtenir une instance de Joueur depuis la bdd et une methode (non statique cette fois) save() qui te permettra de mettre à jour la base.

En JAVA la problématique aurait été identique. Tu aurais eu une classe Joueurs , sauf qu'au lieu d'une bdd tu aurais sans doute eu une communication vers ton serveur de jeu qui aurait propager les mise à jour à tous les clients.

[Alcide_]

T'es explications sont assez obscures... et je penses que tu rates certaines étapes.
Je crois que certains concepts objet et surtout PHP te manquent vu le discours confus que tu as :

des variables POO

si je stocke le joueur en POO

si je stocke dans la BDD, j'ai du mal a voir l'intérêt d'utiliser la POO

j'actualise les deux: l'objet et la BDD

si je change des variables et que le joueur quitte, les données seront perdu

Faire du Java ne veut pas forcement dire maîtriser la POO.

Alors, PHP c'est quoi... Un langage de scripts interprété par un serveur web à chaque requête HTTP.
Donc il n'existe pas (je simplifie) de contexte d'exécution persistant en mémoire vive comme en JAVA, une requête http va déclencher l'exécution complète de ton appli ou de ton script php, du début à la fin.
Après que le serveur web ai renvoyé une page html (ou autre) au navigateur, ton contexte d'exécution disparaît et on recommence à 0 à la prochaine requête. Tous tes objets ont une durée de vie au maximum égale au temps d’exécution de la requête (quelques secondes max ).
Pour faire persister des objets ou, plus globalement, des données entre chaque exécution, plusieurs mécanismes existent, comme la session, le cache ou la BDD.

Alors, la BDD, c'est quoi... c'est comme je viens de le dire, le moyen le plus courant pour stocker des données. Donc, en PHP, si tu dois enregistrer des données de l'utilisateur (et surtout pour un jeux en ligne) tu dois forcément sauvegarder les données en bdd après chaque action (requete http) de l'utilisateur.

Alors le principe de base en php, que ce soit en POO ou en procédural, est le suivant :

• j'initialise mon contexte (configuration, test de la connexion, etc)
• je regarde la demande utilisateur
• je récupère les données souhaitées (en BDD ou autre)
• je modifie ou traite (si besoins) les données
• j'enregistre (si besoins) les données modifiées
• je formate (si besoins) les données
• je renvoi une réponse (html ou autre) à l’utilisateur

Maintenant, dans cette liste, où se situ réellement ton problème?
Que l'on puisse t'aider plus facilement sur l'aspect "POO" et sur l'aspect "persistance".

[gene69]

l'exposé initial est biaisé par le pt de vue du développeur. Une app php passe 99% du temps au repos, l’exécution est instantanée (ou presque), apres l'execution on détruit tous les objets. Donc on a toujours besoin de la base de données pour faire la persistance des données... pour les 99% du temps restant.
C'est vrai que la bd n'est pas le seul moyen de faire persister les données, il y a aussi la sérialisation. Mais sur une appli multijoueur, une bd toute faite c'est plus sur/performant qu'un fichier plat et 3 scripts maisons. c'est un avis.

Notons qu'une session peut être configurée pour s'appuyer sur une vraie BD au lieu d'un systeme de fichiers plats. J'y vois quelques avantages dans le cas d'un jeu multijoueur.

[Kearz]

D'abord merci pour les réponses.

Je dirais que le problème se situe plutôt la:

je récupère les données souhaitées

j'enregistre (si besoins) les données modifiées

Prenons un exemple simple pour voir si j'ai -un peu- mieux compris:
Un joueur décide de frapper un monstre. Il clic, change de page, exemple frappeMonstre.php.
Cette page est donc un objet qui prend un joueur et un monstre. Au chargement de la page je vais donc avec la clé primaire du joueur et du monstre initialiser les variables de l’objet frappeMonstre. Si le joueur attaque, je vais donc prendre en compte une méthode du joueur (ex: attaque()) et faire perdre des point de vie au monstre.
Une fois fait, je dois save les données par une méthode qui va mettre a jour la BDD.
L'action a été faite, la page se réactualise. Donc je perds mes objets et qui vont se réinitialisé. (puisqu'on retombe sur frappeMonstre.php)


L'idée est donc je chopper les données aux bons moments et de la sauvegarder aux bons moment, sachant que les objets ne sont pas persistant du tout?


PS: Je pense que les concepts qui me manque sont plus dans l'association des concepts justement. (Quand on apprend a faire du JAVA pour faire de la POO sans BDD, puis faire du PHP(4) pour apprendre faire des applications pour avec SQL, etc. On associe jamais rien et voilà le résultat. La joie des cours différents qui ne s’entremêlent jamais.)

[Golgotha]

Bonjour,

Pour le web il y à plusieurs style de jeux et le développement n'est pas du tout le même suivant le cas.

- Jeu solo type flash game : le joueur ouvre la page, le jeu se charge en mémoire et on y joue comme si c'était sur ça machine, le jeu est remis à zéro à chaque rechargement.

- Jeu multijoueur non persistent, ça reprends les base du jeu solo, avec un connexion entre les différents joueur connecté à ce moment là, techniquement je ne serais pas dire comment c'est géré, ça dois se faire à base de tunel qui reste ouvert sur la page pour avoir un rafraîchissement en temps réèl, c'est équivalent à un chat pour ainsi dire, mais nettement plus complexe.

- Jeu multijoueur persistent (type mmorpg, text based) : On entre dans le cas ou le jeu garde toutes les données du monde (ou de l'univers) en mémoire, donc en base de données, les joueurs se connecte à un compte et peuvent y faire évoluer des villages, des planètes.. ce type de jeu se joue avec un navigateur standard, la page est statique un fois ouverte et les actions sont fait avec des boutons sur la page (type formulaire html). Ce type de jeu nécessite de simuler le temps réel avec des algorithmes temporel, le serveur n'est pas constamment en train de faire évoluer le monde, ça serais trop coûteux en terme de performance.

- Jeu multijoueur persistent et temps réel (type wow) : Le plus complexe des jeux, il dois persister les données et faire un rendu temps réèl du monde, le joueur à besoin le plus souvent d'un programme client sur la machine en plus du serveur. Surement très complexe à réaliser.

Donc, la question c'est qu'est ce que tu développe comme jeu ?

[Kearz]

Je suis dans ce cas là:

Jeu multijoueur persistent (type mmorpg, text based) : [...]

Après je suis déjà fixé niveau technologie, etc: PHP + JS + BDD.
C'est juste qu'il me faut assimilé le PHP5. (ça serait bête de partir sur du PHP4 même si le PHP4 j'en ai déjà fait et donc serait un peu plus simple )

[gene69]

monstre initialiser les variables de l’objet frappeMonstre. Si le joueur attaque, je vais donc prendre en compte une méthode du joueur (ex: attaque()) et faire perdre des point de vie au monstre.

mauvaise idée, une page par action dans un jeu, ça fait bcccppppppppp de pagesssssssss.

Une fois fait, je dois save les données par une méthode qui va mettre a jour la BDD.
L'action a été faite, la page se réactualise.

en théorie oui, mais si tu utilise de l'ajax et l'objet XMLHttpRequest (pas directement, via prototype/Jquery hein ! ) tu peux discuter avec ton serveur en tache de fond.

Donc je perds mes objets et qui vont se réinitialisé. (puisqu'on retombe sur frappeMonstre.php)

OUI. il te faut des sessions pour te simplifier la vie.

L'idée est donc je chopper les données aux bons moments et de la sauvegarder aux bons moment, sachant que les objets ne sont pas persistant du tout?

il te faut des sessions. Ton monstre, tu peux le précharger dans une session utilisateur ainsi que l'identité de ton joueur. Et son pseudo et sa place sur la carte. Ce qu'il faut éviter de faire c'est que cette mise en cache via les sessions ne soit pas une faille qui permette de tricher (donc réfléchir à l'ordre de chargement).

[Alcide_]

Le projet est ambitieux, peut-être trop vu le manque de pratique que tu semble avoir dans les techno. web...
Comme le dit très justement gene69, le fait d'avoir une page par action est juste impensable pour ce type d'application.

Tes réflexes et ta terminologie Objet sont encore très balbutiant, tu parles de page comme d'un objet, qui de plus prend des paramètres :

Cette page est donc un objet qui prend un joueur et un monstre

L'appel à un script est une chose, les paramètres d'une requête en son une autre et les objets que tu manipules dans ton script, c'est encore différent.

mes objets [...] qui vont se réinitialiser

Non non non, rien ne se "réinitialise", les objets que tu obtiendras à la prochaine action (requête http) seront de nouvelles instances de tes classes.

Bon, si on part de ton petit exemple de joueur et de monstre, ça pourrait donner un truc comme çà :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<?php
//[...]
// ne pas oublier l'importance de la gestion des erreurs
if (!isset($_SESSION['player_id']) || !isset($_POST['monster_id'])) {
    throw InvalidArgumentException("your error message");
}
//on récupère nos paramètres en session ou à partir de la requête (ici POST)
$playerId = $_SESSION['player_id'];
$monsterId = $_POST['monster_id'];
 
/*
 * Construction et initialisation des objets que l'on veut manipuler via les ID.
 * L'id permettant de faire une requête en BDD, de récupérer les données brutes
 * en vu de peupler l'objet désiré.
 */
$player = new Player($playerId);
$monster = new Monster($monsterId);
 
 // Juste pour encore appuyer sur l'importance de la gestion des erreurs
if (!$player || !$monster) {
    throw InvalidArgumentException("your error message");
}
/*
 * Ici ce serait l'objet player qui mettrait à jour 
 * ses données et celles du monstre pour un combat
 */
$player->fight($monster);
 
//Sauvegarde des données en BDD
$player->save();
$monster->save();
 
//ensuite... plein d'autres trucs comme la gestion des exceptions,etc
//envoi d'une réponse à l'utilsateur ?
//redirection ?

Cet exemple est plus que grossier (je serais le premier à le critiquer vivement!) mais il a le mérite d'être très simple et d'imager ton propos. Peut-être éclaircira t-il certains points.

Je ne peux que t'encourager à te documenter sur la POO, les design-patterns et sur les différents frameworks web comme ZendFramework ou Symfony.
Un framework pourrait t'amener un cadre d'apprentissage et de développement intéressant.

Bon courage à toi !

[Kearz]

Merci, j'crois que j'ai compris avec ton exemple.

Oui, enfin c'est pas non plus super ambitieux. C'est vraiment histoire de s’entraîner parce que les technos webs à la fac on voit rien c'est du very light.

Si j'me foire le projet j'aurais surement appris des trucs en route. C'est le plus important.

Pour ce qui est framework j'y ai pensé mais pour un autre projet. Si je me met a faire de l'apprentissage de partout sur le même projet ça risque de capoter.