Il y a quelques règles à respecter pour ne pas tomber dans certains pièges. Nous allons voir ça tout de suite.

Redirection simple

La redirection la plus simple consiste à faire la chose suivante :


header("Location: fichier_destination.php");


Cette ligne dans votre fichier PHP vous conduira vers le fichier « fichier_destination.php ».

Attention a ne pas envoyer au navigateur quoique ce soit avant cette ligne sinon, la redirection ne fonctionnera pas.

Redirection 301

Mais, dans l’exemple d’un annuaire où une fiche de jeu n’existe pas / plus, il est préférable de faire une redirection de type 301. Voilà comment s’y prendre :


header("Status: 301 Moved Permanently", false, 301);
header("Location: fichier_destination.php");


Et là, Google saura que la page n’existe plus et qu’il ne faut pas la référencer.

Piège à éviter

Juste un petit jeu pour finir. A votre avis, à la fin du code suivant, il y aura quoi dans le fichier « dummy.txt » ?

Soit il y aura « premier passage », soit « second passage ».


$file = "dummy.txt";
$a = "premier passage";
file_put_contents($file, $a);
header("Location: test.php");
$a = "second passage";
file_put_contents($file, $a);
echo "ok";


Disons-le tout de suite, vous ne verrez pas inscrire « ok » sur votre écran.

Par contre, dans le fichier, il y aura « second passage ».

Oui, une redirection n’empêche pas la continuité du code !

Erreur de débutant dirons certains. Erreur tout simplement.

La solution, mettre une fin après la redirection :


header("Location: test.php");
exit();


Et là, vous avez une jolie redirection et pas de problèmes.

L’idéal étant de faire une fonction avec possibilité de faire une redirection 301. Ça permet de mettre un test avant chaque redirection également. Utile pour débugger.

Pour commencer, voici donc le temps nécessaire pour remplir une base :

C’est indiscutable, InnoDB semble plus lent pour l’insertion des données. Et pourquoi donc ?! Il faut savoir que InnoDB est de type transactionnelle alors que MyISAM est (on s’en doute un peu) non-transactionnelle. Bon… Et ?! Ca veux dire quoi au juste ces termes barbares ?!

Les tables non-transactionnelles sont plus rapide, utilisent moins d’espace disque et moins de mémoire. Alors pourquoi choisir InnoDB ?! Car les tables transactionnelles sont plus sûr (en cas de crash de MySQL, vous pouvez tout de même récupérer vos données) et pour d’autres petits détails qui sortent un peu de cet article.

Les tables contiennent 4 champs :

Alors, nous voilà avec une table de 1 000 000 enregistrements (lignes) et nous allons pouvoir commencer les premiers tests. Juste pour info, voilà la place occupée par les différentes tables utilisées pour les tests (estimation de PhpMyAdmin, après optimisation) :

On constate que InnoDB ne prend pas forcément plus de place que MyISAM. Mais cela tient surtout aux choix de stockage des données si vous choisissez plutôt CHAR que VARCHAR par exemple. Il faut bien garder à l’esprit que CHAR va allouer la taille indiqué (ici 30) quelque soit la quantité d’information stockée alors que VARCHAR va allouer la taille de l’information stockée (plus un reliquat pour indiqué la fin).

CHAR peut s’avérer plus rapide sur des tailles importantes (à partir de 100), mais n’a pratiquement aucune incidence en dessous.

Dans tous les tests que nous avons fait, le terme recherché, que ce soit un chiffre ou des lettres, est changé à chaque itération afin de ne pas récupérer un résultat dans un cache. Car, en effet, si MySQL reçoit une requête déjà effectuée, cette seconde requête (et les suivantes) est nettement plus rapide. La recherche est lancée plusieurs fois et le temps affiché est une moyenne. Les tests ont été relancés plusieurs fois à différents moments pour être certain que rien ne pouvait interférer sur les résultats.

Les tests

SELECT * FROM MaTable WHERE Age>45

InnoDB est plus lent sur une requête simple.

SELECT * FROM MaTable WHERE Nom=’dummy’

SELECT * FROM MaTable WHERE Nom<>‘dummy’

La recherche par différence est plus longue que l’égalité.

SELECT * FROM MaTable WHERE Nom LIKE ‘xyz%’

Aussi étonnant que cela puisse sembler, ici le temps est pratiquement le même pour une égalité pour un LIKE. Notons également que le temps reste le même si les données sont du type CHAR(30) ou VARCHAR(30).

SELECT * FROM MaTable WHERE Nom LIKE ‘xyz%’ ORDER BY Age

Nous rajoutons un tri à la recherche. Du coup, InnoDB augmente un peu son temps alors que MyISAM le réduit.

Attention, maintenant, nous allons faire exactement la même requête, mais en ajoutant un index sur le champs Nom. Et là, vous allez voir que ce n’est pas négligeable d’y penser :

SELECT * FROM MaTable WHERE Nom LIKE ‘xyz%’ ORDER BY Age

Conclusion

Pas simple de conclure avec ces chiffres. Disons que si vous avez des informations importantes à stocker et que vous avez beaucoup d’utilisateurs qui vont faire des écritures simultanées dans votre base, il vaut peut-être mieux choisir InnoDB.

Si vous faites beaucoup de lecture de données et peu d’écriture, le choix doit se porter sur MyISAM.

Mettre un index sur un champs permet d’augmenter considérablement la vitesse lors d’une requête, mais augmente aussi la taille de la base. Faites donc attention surtout si vous êtes sur un serveur mutualisé.

Un dernier mot : il existe d’autres type de tables pour MySQL. Notamment les tables MEMORY. Mais ce type ne peut-être utilisé pour des tables de cette taille sans avoir une quantité de mémoire très importante. Nous effectuerons très certainement des tests dans un prochain article.

.page .menu li color: red;

body div.menu ul li color: blue;


Si les deux déclarations désignent bien le même élément, l’une est prioritaire sur l’autre et du style de la première déclaration dont va hériter l’élément de liste. La couleur bleue de la deuxième déclaration ne sera pas appliquée.

Si la première déclaration (.page .menu li) prend le pas sur la deuxième (body div.menu ul li) c’est que le calcul de spécificité lui donne plus d’importance.

La spécificité d’une déclaration est un calcul qui indique le « poids » d’une déclaration.

Ce « poids » est alors utilisé pour comparer les différentes déclarations entre-elles et savoir laquelle est prioritaire sur l’autre, laquelle a le plus de « poids ».

Le calcul se fait :
– en fonction de 3 types d’éléments qui composent une déclaration (ID, class, élément balise)
– sur 3 chiffres concaténés

Pour connaitre le premier des trois chiffres concaténés, il faut compter le nombre d’ID dans la déclaration (a).
Pour le deuxième chiffre, il faut compter le nombre de class (b).

Enfin, le troisième chiffre est donné par le nombre d’élément balise (c).

Le poids d’une déclaration est le nombre donné par ces trois résultats mis côte à côte (abc).

Dans notre exemple :

.page .menu li color: red;
Nombre d'ID : 0 (donc a=0)
Nombre de class : 2 (donc b=2)
Nombre d'élément : 1 (donc C=1)

Le poids de cette déclaration est donc de 21 (021).

body div.menu ul li color: blue;
Nombre d'ID : 0 (donc a=0)
Nombre de class : 1 (donc b=1)
Nombre d'élément : 4 (donc C=4)

Le poids de cette déclaration est donc de 14 (014).

La première déclaration est donc bien prioritaire sur la deuxième.

Quelques exemples :
#contenu #contenu-principal

La spécificité est de 200 (a=2 ; b=0 ; c=0)

div.informations #mentions p.important span

La spécificité est de 123 (a=1 ; b=2 ; c=3)

Et comme une image (ludique) vaut toujours mieux qu’un long discours :

http://www.stuffandnonsense.co.uk/…/specificitywars-05v2.jpg

Cela nous permet de comprendre pourquoi, dans certains cas « inexplicable » notre déclaration ne s’applique pas alors qu’elle ne contient aucune erreur. L’élément cible hérite en fait d’une déclaration ayant une spécificité plus forte.
Parfois, ces problèmes peuvent simplement se régler en « surchargeant » la déclaration afin de lui donner plus de poids. Attention néanmoins à ne pas avoir le reflexe de trop charger ses déclarations (pour éviter ce type de désagrément) au point d’avoir des déclarations très fortes et peu souples.

Aller plus loin :

Spécification CSS2 (traduction française) > Le calcul de la spécificité d’un sélecteur – http://www.yoyodesign.org/doc/w3c/css2/cascade.html#specificity

Notre but cette fois et de parcourir une implémentation (parmi tant d’autres) d’un moteur de gestion de carte. Notre moteur tentera de tirer parti d’Ajax en évitant au joueur de devoir supporter une période de loading.

Notre carte est volontairement simple : pas de support de layers, nous n’afficherons que le sol. Le but ici est de démontrer qu’Ajax peut être un outil fort intéressant dans le cadre du pré-loading d’une carte, rien d’autre. Evidemment si cette structure peut vous donner des idées c’est tant mieux…

Concept

Notre carte est composée de cases, toutes placées fort judicieusement les unes à côté des autres. Jusque là rien de bien nouveau.

Concept de la carte

Nous ne voulons pas de loading, il nous faudra donc :

1. Pouvoir faire le rendu de la carte de façon modulaire
2. Pouvoir gérer un ou plusieurs buffers, dont le rendu sera assuré par les méthodes du point 1.

Dans notre cas nous prendrons 4 buffers, en haut, en bas, à droite et à gauche. La dimension des buffers dépends de vous et de vos tests, ici je les prendrai de 1×5 (1 case de large sur 5 cases de long).

Base de données

Structure de la DB

Notre carte sera découpée en lignes et colonnes, ce qui nous permettra plus facilement de gérer un buffer de cases.

Chaque case dispose d’une image qui lui est propre, cette image peut être NULL. Si ce champ est NULL nous utiliserons l’image par défaut du type de terrain (type_terrain.type_img)

Pour le principe ajoutons une table joueur minimaliste. Elle ne retient qu’une chose : la position du joueur.

Dans la réalité le schéma de votre DB sera nettement plus complexe, on est tous d’accord, mais ça nous suffira pour l’instant.

Ecrire des queries pour cette structure est très simple : prenons un exemple : comment trouver le buffer de gauche de notre carte ?


SELECT C.case_id, C.type_terrain_id, C.case_ligne, C.case_col, C.case_img, T.type_img
FROM type_terrain T, cases C
WHERE T.type_terrain_id=C.type_terrain_id
AND C.case_col = 4
AND C.case_ligne BETWEEN 11 AND 15


Ce select renvoie donc le buffer gauche de notre carte. C’est à dire une colonne composée de 5 cases. Pour obtenir les autres buffers nous jouerons sur les deux dernières conditions, faisant varier soit les colonnes soit les lignes. Par exemple, pour trouver le buffer du bas


AND C.case_col BETWEEN 5 AND 9
AND C.case_ligne = 16


Nous allons essayer de faire aussi générique que possible. De quoi avons-nous besoin ? Tout d’abord d’un script capable de nous renvoyer le XML proprement dit. Nous appellerons ce script un module.

Notre structure, en sus de la carte, devra être capable d’accueillir bien d’autres modules, pour à peu près n’importe quoi. Puisque nous risquons d’avoir un nombre de modules importants il ne serait pas opportun de lier chaque appel Ajax à un module en particulier, ça nous obligerait à connaître à chaque fois l’URL de ce module, ce qui peut être contraignant (et ennuyeux niveau sécurité).

Pour éviter de coupler module et code côté client nous allons définir un point d’entrée. Ce script particulier sera chargé de dispatcher l’appel Ajax vers le module ad-hoc puis d’en renvoyer le code XML. Avantage supplémentaire, nous pourrons valider ce que le client nous envoi directement au niveau du point d’entrée.

Le code en dessous vous donne un aperçu de l’implémentation du point d’entrée et d’un module.

Le point d’entrée



die "action non définie!";
/**
Erreur mal gérée! Idéalement il faut logger les détails de la requête.
Il peut également être intéressant de renvoyer un XML contenant les détails de l'erreur
Ca simplifiera d'autant le debugging.
**/

else

switch($_REQUEST['action'])


// Renvoie le code XML généré
echo $str_xml;
?>


Un module

(ici la carte, donc)


//Cette fonction renvoie du HTML, pas du XML, ce n'est pas un appel AJAX

?>


Côté client

Mais qu’en est-il côté client ? Très simple : du javascript à foison ! Dans le chapitre précédent nous avions un simple « Moteur javascript », et bien c’est lui qui va se charger de tout :

1. Des appels pour récupérer le code XML
2. Des buffers
3. De l’affichage des informations recueillies

La solution la plus propre pour gérer l’affichage est d’utiliser des feuilles de style XSL. Mais ce n’est pas forcément la solution la plus simple. XSL fait appel à des technologies telles que XPath, qui ne sont pas toujours accessibles aux moins expérimentés.

En pseudo-code, voilà ce que donne notre moteur JS :

Vérifier si le buffer contient ce dont on a besoin
Si il ne le contient pas
Recupérer le handler (l'objet XMLHttpRequest)
Construire la requête en fonction de ce qu'on désire obtenir
Envoyer la requête et récupérer la réponse

On identifie la cible dans laquelle il faut insérer le contenu (avec son attribut ID)
On insère le code HTML obtenu grâce à la transformation XSL


Il existe des tas de très bon tutoriaux pour découvrir quelles sont les fonctions qui vont bien en JavaScript. Allez jeter un œil du côté de developpez.com par exemple pour un très bon papier dessus.

Avec ce que nous avons vu ici vous devriez être capable de construire une structure simple de gestion d’appels Ajax. Pour augmenter les possibilités de cette structure il ne vous reste qu’à développer de nouveaux modules, à choisir l’action qui y est liée (mod) et à effectuer l’appel javascript qui va bien.

Dans le cas qui nous intéresse, une carte, il est clair que nous gagnons en ergonomie ce qui nous perdons en complexité. Le joueur ne doit plus reloader la page à chaque mouvement de son personnage, mais seulement quand le besoin d’un scroll se fait sentir.

Implémenter le support du scrolling manuel (le joueur qui déplace la vue) est également un jeu d’enfant : c’est déjà supporté.

Soyons clair, la méthode décrite n’est pas parfaite et peut-être améliorée. Le code présenté n’est pas orienté objet, ce qui est très dommage. Point de vue performance, le switch sur l’action n’est sûrement pas la panacée. Avec de nombreuses actions différentes vous aurez vite un code horrible. Mais cet exemple a le mérite de montrer qu’il n’est pas forcément si complexe de concevoir « from scratch » le support d’une carte en Ajax.

Dans le prochain épisode nous verrons qu’il existe aussi des frameworks qui supportent déjà toutes ces fonctions, vous évitant donc de réinventer la roue à chaque fois. Stay tuned, et rendez-vous dans un petit mois!

Il n’est pas question dans cet article de faire l’inventaire de toutes les failles possibles de sécurité pour un site en PHP. Je conseille à ce sujet le très bon Guide Sécurité PHP du PHP Security Consortium, après avoir bien sûr parcouru la rubrique sécurité du manuel PHP.
Cet article a pour but de vous donner les bases qui vous permettront de développer l’esprit tranquille, le tout illustré d’exemples concrets applicables aux jeux web.

Configuration et utilisation des variables

La configuration de php, stockée dans le php.ini est importante puisqu’elle conditionne le comportement des variables prédéfinies. Utilisez une configuration par défaut, elle est le fruit de l’expérience de la communauté PHP. Evitez d’utiliser des fonctionnalités spécifiques, qui pourraient ne pas être disponibles sur n’importe quel serveur ! On peut citer register_globals, magic_quotes_gpc, short_open_tags, …
Et bien sûr, si vous êtes plusieurs à développer, utilisez tous la même configuration.

Voici les points vraiment très importants :

• register_globals doit être positionné à Off. Lorsque vous utilisez des variables de session, utilisez toujours $_SESSION, idem pour les cookies, variables passées en GET et POST : $_COOKIE, $_GET et $_POST.

• Positionnez error_reporting à E_ALL, afin d’afficher toutes les erreurs, warnings et notice. Un bon moyen est d’appeler error_reporting(E_ALL) au début de chaque script. Si vous avez le moindre avertissement, c’est potentiellement une faille de sécurité !

• Evitez d’utiliser le include($page), même si vous contrôlez avec une liste de pages autorisées.

• Si vous avez un espace d’administration, contrôlez son accès avec un mot de passe (.htaccess)

• Si vous offrez la possibilité d’uploader un fichier, contrôlez son contenu, cela pourrait être… un script php, qui pourrait être exécuté par le serveur !

• De manière générale, évitez de re-développer des fonctionnalités déjà existantes, comme la gestion des sessions. Sauf si vous êtes un véritable expert, il y a de fortes chances pour que vous laissiez passer certains aspects importants (la sécurité en est un), et cela pour un gain pas forcément réel.

• Sur la même note, si vous utilisez des outils externes (forum phpBB, punBB, …) assurez-vous de le maintenir à jour régulièrement afin de combler les failles de sécurité. Si vous décidez de gérer vous-même votre hébergement (serveur dédié), sachez que c’est un métier à part entière, et un métier complexe. Là encore, agissez prudemment, n’utilisez que des outils stables et sécurisés, et entourez-vous de personnes compétentes sur le sujet.

• Pour éviter les injections SQL, assurez-vous de toujours échapper les variables utilisées dans les requêtes, surtout si elles proviennent de l’utilisateur. La fonction addslashes est généralement utilisée, mais il est préférable d’utiliser celle correspondant à votre base de données : mysql_real_escape_string pour MySQL (qui échappe en plus le caractère 0)
  Attention aux magic quotes : les variables peuvent être déjà échappées ou non selon la configuration php.
  Le manuel PHP fournit une solution sécurisée les prenant en compte :
  

// Stripslashes
if (get_magic_quotes_gpc())
$value = stripslashes($value);

// Protection si ce n'est pas une valeur numérique ou une chaîne numérique
if (!is_numeric($value))
$value = "'" . mysql_real_escape_string($value) . "'";

return $value;


mysql_query($query);
?>


Il est généralement recommandé de désactiver les magic quotes, et de systématiquement
échapper les variables utilisées dans une requête SQL (cela simplifie également
leur sortie sur la page html). Pour désactiver les magic quotes quelle que soit
la configuration, on peut placer ce bout de code au début de chaque page :


set_magic_quotes_runtime(FALSE);
if(get_magic_quotes_gpc())
function remove_magic_quotes(&$var)
if(is_array($var))
array_walk($var, "remove_magic_quotes");
else if (is_string($var))
$var=stripslashes($var);



remove_magic_quotes($_POST);
remove_magic_quotes($_GET);
remove_magic_quotes($_REQUEST);
remove_magic_quotes($_COOKIE);



Pour éviter les problèmes d’injection SQL, on peut aussi se tourner vers les requêtes préparées, supportées entre autres dans la nouvelle extension PDO inclue dans PHP 5.1.

Contrôle des données fournies par l’utilisateur

Si vous n’en avez jamais entendu parler, c’est que vous n’avez lu aucun article sur la sécurité.
Les données fournies en provenance de l’utilisateur, qu’elle proviennent d’un formulaire de saisie (variable $_POST), ou qu’elles soient passées en paramètre de la requête HTTP ($_GET), peuvent aisément être falsifiées. Il faut donc impérativement contrôler TOUTE valeur que vous récupérez du navigateur web, et vérifier que ces valeurs sont bien fournies !

Une bonne pratique est de lister, pour chaque action, les variables nécessaires, ainsi que des contraintes sur leur contenu (ceux qui ont suivi des cours se remémoreront la notion de « pré-condition »). Si une valeur est facultative pour l’utilisateur, mais que vous en avez besoin pour un traitement, pensez à l’initialiser avec une valeur par défaut.

Exemple pour l’action « inscription d’un joueur » :

$_POST[‘nom_perso’] : texte, min 1 caractère, max 100 caractères, obligatoire
$_POST[‘description’] : texte, min 0 caractère, max 1000 caractères, obligatoire
$_POST[‘force’] : nombre, min 1, max 20, obligatoire
$_POST[‘endurance’] : nombre, min 1, max 20, obligatoire
force + endurance = 20

Toutes ces contraintes devront être vérifiées avant de pouvoir effectuer l’inscription. Si une contrainte n’est pas respectée, à vous de décider de renvoyer une erreur à l’utilisateur (« Nom du perso obligatoire ») ou bien de considérer cela comme une tentative de tricherie ! S’il n’est pas possible en navigant normalement de fournir une certaine valeur, alors c’est très probablement une tentative de triche. Exemple, vous avez sur une page 3 liens :

• avancer.php?direction=1
• avancer.php?direction=2
• avancer.php?direction=3

Il n’y a que 3 directions possibles, et il n’existe nulle part sur le site de lien avec une direction différente de 1, 2 ou 3. Si l’on vous fournit une valeur différente, alors c’est que l’utilisateur a modifié le lien manuellement !

Les contraintes listées précedemment pourraient se traduire ainsi :


function valider_inscription($variables)
if (!isset($variables['nom_perso'])) return array('TRICHE', 'nom_perso non défini');
if (!is_string($variables['nom_perso'])) return array('TRICHE', 'nom_perso non textuel');
if (strlen($variables['nom_perso'])<1 || strlen($variables['nom_perso'])>100) return array('VALID', 'Le nom du perso doit comprendre entre 1 et 100 caractères');

return array('OK', '');



Cette fonction pourra être utilisée ainsi :


list($erreur, $message)=valider_inscription($_POST);
if ($erreur=="TRICHE")
//selon votre politique, logger la tentative, afficher un message à l'utilisateur, etc
else if ($erreur=="VALID")
//Renvoyer le formulaire avec le message d'erreur $message à l'utilisateur
else
//OK, effectuer l'inscription en utilisant $_POST['nom_perso'], $_POST['force'], etc



A propos de la politique concernant la triche, il est utile d’enregistrer quelque part toutes les tentatives de triche. Lorsqu’une entrée ne correspond pas à ce qu’elle devrait être, on peut enregistrer cela sur le disque, avec la requête lancée, la page appelée, l’IP, ainsi que toutes les variables de session (numéro de compte). Ce fichier peut même entre envoyé à un administrateur par mail régulièrement. Cela permet de voir immédiatement une tentative de piratage, son auteur, et de prendre immédiatement les mesures qui s’imposent.
On peut faire la même chose pour les requêtes SQL ayant échoué. A chaque requête lancée, on va vérifier que l’exécution s’est déroulée correctement (mysql_query() renvoit false en cas d’échec). Si ce n’est pas le cas, alors on va envoyer un mail à l’administrateur avec toutes les infos citées précédemment. En plus de permettre de contrôler que toutes les requêtes sont bonnes, cela permet quelquefois de détecter une tentative de hack par injection SQL.

Voici deux exemples qui vous convaincront de la nécessité de bien contrôler ses variables.

1) Imaginons que vous ayez une fonctionnalité de don d’argent à un autre personnage.
L’utilisateur choisit un destinataire, puis saisit la somme qu’il veut lui céder dans un formulaire. Imaginez d’abord que vous contrôliez bien que la somme soit un nombre, mais que vous ne testiez pas les bornes. Votre traitement ressemble à :


UPDATE Perso set argent=argent-somme where id_perso=$donneur
UPDATE Perso set argent=argent+somme where id_perso=$destinataire


Imaginez qu’un joueur malin saisisse une somme négative… cela aura pour effet de retirer de l’argent au destinataire, et d’en ajouter au donneur !

2) Votre jeu se déroule sur une carte, chaque personnage se trouvant une case. Votre script d’attaque, attaquer.php, prend en paramètre un nombre correspondant au personnage visé, id_perso_vise. Lorsque l’utilisateur choisit d’attaquer, le site lui présente une liste de personnages qui sont à sa portée, c’est-à-dire à moins de 3 cases, accompagné d’un lien attaquer.php?id_perso_vise=xxxx
Si vous ne contrôlez pas que le personnage visé est bien à moins de 3 cases dans le script attaquer.php, alors un joueur pourrait modifier l’url, et attaquer n’importe quel perso où qu’il soit !

Il existe des cas très subtils, par exemple prenons si une variable $force contient la chaîne « 15+250 » (saisie par l’utilisateur) :

• Dans un calcul PHP, $force sera converti en nombre, la conversion récupère tous les chiffres jusqu’au premier caractère non numérique è if ($force<20) renverra true
• Si alors vous faites une requête : UPDATE Perso set force=$force, alors la valeur 265 sera insérée dans la table !
  è il faut vérifier l’utilisateur a bien saisi un nombre (is_numeric). Il est aussi possible de systématiquement convertir le nombre en entier avec intval() par exemple, mais cela ne permet pas de détecter la tentative de triche.

Concurrence d’accès aux données

Maintenant que les données en entrées des traitement sont bien contrôlées, nous allons nous intéresser aux traitements aux-mêmes.

Reprenons notre exemple de don d’argent. Cette action est effectuée par un script donner.php qui prend en paramètre le destinataire du don, ainsi que la somme – entier positif, qui doit être inférieur au montant disponible sur le compte bancaire du joueur. Le numéro du donateur (joueur connecté) est bien entendu conservé dans une variable de session.

La structure générale du script est la suivante :


//Validation : on vérifie que le joueur possède assez d'argent
$r=mysql_query("SELECT argent from Perso where id_perso=".$_SESSION["id_perso']);
list($argent_dispo)=mysql_fetch_row($r);
if ($somme > $argent_dispo)
// renvoyer un message d'erreur à l'utilisateur indiquant qu'il n'a pas assez d'argent

...

//Traitement : on transfert l'argent d'un perso à l'autre
mysql_query("UPDATE Perso set argent=argent-".$_POST['somme']." where id_perso=".$_SESSION['id_perso']);
mysql_query("UPDATE Perso set argent=argent+".$_POST['somme']." where id_perso=$destinataire");


Tout va bien jusqu’à présent, notre code fonctionne. Maintenant, imaginons qu’il survienne un délai notable entre la validation et le traitement. Les serveurs web gèrent plusieurs processus ou requêtes simultanément. Un script peut donc être interrompu provisoirement, avant de reprendre son exécution plus tard. Vous pourriez également avoir à effectuer des calculs longs et compliquées entre la validation et la mise à jour de la base de données.

Si un joueur envoie alors plusieurs fois de suite la même requête http (avec le même contenu), ce qui peut aisément être effectué en cliquant plusieurs fois de suite, très rapidement, sur le bouton de validation, alors nous avons plusieurs requêtes qui arrivent simultanément au serveur web. Notre serveur web sait exécuter plusieurs scripts (processus) simultanément, et leur exécution peut être effectuée simultanément – surtout si par exemple, le serveur dispose de plusieurs CPU ; mais aussi parce que le système peut décider de suspendre un processus pour en démarrer un autre.

Considérons donc le cas où 2 appels identiques (mêmes paramètres) à donner.php sont arrivés au serveur web simultanément. Nous allons les appeler A et B. Le donateur (joueur n°42) dispose de 50 pièces sur son compte. Il souhaite en donner 30 au joueur n°123, qui en possède initialement 20.
Le séquencement des opérations peut être le suivant :

Le système démarre l’appel A au script
A effectue la phase de validation è ok, le joueur veut donner 30 et dispose de 50
Le système interromps l’appel A et démarre l’appel B au script.
B effectue la phase de validation è ok, le joueur veut donner 30 et dispose de 50
B effectue le traitement, il retire 30 à A et les verse à B è joueur 42 dispose de 20, joueur 123 dispose de 50
B se termine
A reprend son exécution
B effectue le traitement, il retire 30 à A et les verse à B è joueur 42 dispose de -10, joueur 123 dispose de 80 !

C’est ce genre de problème qui a conduit des informaticiens, il y a quelques dizaines d’années, à inventer les bases de données et la notion de transaction. Je ne vais pas rentrer dans les détails ici (internet fournit une large documentation sur le sujet), sachez juste que les transactions ne sont pas supportées par le format de table par défaut de MySQL, MyISAM, mais qu’elles le sont avec InnoDB.
Les transactions permettent de verrouiller les données manipulées, et de s’assurer qu’elles n’ont pas été modifiées entre le début et la fin de la transaction. Si nous avions encapsulé toutes nos requêtes SQL dans une même transaction, nous aurions eu l’assurance que le 2ème appel n’aurait pas abouti.

Outre ce cas d’école, il existe de nombreuses situations où vous pourriez avoir des problèmes.

Prenons l’exemple d’une gestion des points d’action (PA). Le joueur gagne 1 PA par heure. Pour gérer ce système, on stocke la date/heure (timestamp) de dernière connexion pour chaque joueur. Lorsqu’il se connecte, on calcule le temps écoulé depuis le dernier gain de PA, et on lui redonne autant de PA que d’heures écoulées. Notre script pourrait ressembler à :


$r=mysql_query("SELECT timestamp_gain from Perso where id_perso=".$_SESSION['id_perso']);
list($timestamp_gain)=mysql_fetch_row($r));
if (time()-$timestamp_gain>3600) //si plus de 3600 secondes (1h) se sont écoulées depuis la dernière connexion
$gain = floor((time()-$timestamp_gain)/3600); //calculer le nombre d'heures écoulées
mysql_query("UPDATE Perso set PA=PA+$gain, timestamp_gain= timestamp_gain+3600*$gain_timestamp where id_perso=$id_perso");



Maintenant, imaginez si deux appels à ce script arrivent simultanément au serveur web… Quel est le risque ? Que le joueur perçoive 2 fois trop de PA !

Pour éviter cette situation délicate, il n’existe guère de salut en dehors des transactions. Vous pourriez effectuer toute l’opération en une seule requête (la requête est compliquée mais c’est parfaitement faisable), mais ce n’est valable que pour ce cas précis. Vous pourriez aussi gérer vous-même une section critique à l’aide de sémaphores UNIX, de la fonction flock() ou la fonction GET_LOCK() de MySQL. Oubliez tout de suite, c’est une très mauvaise idée. D’une part, parce que (hormis avec flock), vous devenez dépendant de fonctions qui ne seront pas forcément disponibles sur toute plate-forme, mais surtout parce que vous êtes en train de réinventer la roue ! La gestion des transactions est un problème compliqué, fiez-vous plutôt aux implémentations fiables et éprouvées qui existent déjà, vous gagnerez du temps et de la sueur ! 🙂

Pour clôre ce chapitre (et vous faire des frayeurs :p), appliquez le comportement que l’on vient de voir à une action d’attaque d’un adversaire : le joueur inflige des dommages à un adversaire. Si le nombre de Points de Vie de l’adversaire bascule en dessous de zéro, l’adversaire meurt. Plusieurs joueurs peuvent même attaquer un même adversaire simultanément. Que peut-il se passer en cas d’attaques simultanées sur un même perso ?

Multi-comptes

Vous avez maintenant toutes les cartes en main pour sécuriser votre site. Il reste cependant un problème potentiel : le multi-comptes. En effet, dans un jeu traditionnel, comme un jeu de carte, une personne ne peut jouer qu’un seul joueur. Dans un jeu sur internet, il en va autrement. Une même personne peut très facilement se créer plusieurs comptes sur votre jeu !
Selon le type de jeu, cela aura un impact plus ou moins important. Dans un jeu de guerre, où le nombre de joueurs influence les chances de victoire, cela peut être catastrophique. A moindre échelle, un autre compte peut être utiliser pour affaiblir l’ennemi avant de l’attaquer avec son vrai personnage, pour espionner ou même infiltrer son ennemi.

Il faut savoir qu’il est presque impossible, au niveau technique, d’empêcher le multi-comptes. Les principales techniques de détection, basées sur l’e-mail, l’adresse IP ou les cookies, peuvent être contournées par une personne suffisamment expérimentée. De même, il peut arriver que plusieurs personnes jouent réellement à partir du même poste (familles, écoles, cyber-cafés, …). Aucune technique de détection n’est donc véritablement fiable.

En conséquence, il est important d’évaluer les impacts et les risques provoqués par une personne gérant plusieurs comptes sur votre jeu. De là, vous devrez en déduire une politique à adapter face à ce problème.
Selon le type et les règles du jeu, cela pourrait être :

• autorisation explicite de faire du multi-comptes (aucun d’impact)
• autorisation implicite (très faible impact)
• interdiction explicite sans répression.
• interdiction explicite avec répression, ce qui suppose la mise en place d’un système de détection. On peut joueur sur le niveau de tolérance, sur l’éducation plutôt que la répression, s’aider de la dénonciation, etc. Le système de détection n’étant pas fiable, certains jeux mettent même en place des équipes chargées d’enquêter et juger les cas litigieux.

Le meilleur moyen de limiter le multi-comptes reste sans aucun doute de faire en sorte qu’il n’ait aucun impact sur le jeu… Ce qui n’est pas toujours forcément évident. C’est donc un aspect qui devrait être pris en compte dès la conception du jeu !

Pour conclure, retenez surtout qu’il n’y a pas de solution toute faite. Il faudra la choisir en fonction de votre jeu, de votre public et… de votre intuition ! 😉

Je remercie Merrick, VYS et DT pour leurs remarques et relecture de cet article 🙂

Voici quelques astuces et reflexes à avoir au moment de préparer ses pages et ses feuilles de style pour bien profiter des possibilité des styles d’impression.

L’appel à la feuille de style

De la même manière que vous appelez votre ou vos feuilles de style habituellement, vous pouvez ajouter des appels à d’autres feuilles en spécifiant bien le média auquel elles se destinent.

Exemple :

La typo

Certaines polices de caractères sont plus agréables à l’écran que d’autres. De la même manière, une police de caractère peut être désagréable ou moins « jolie » une fois imprimée. On peut donc utiliser la feuille de style d’impression pour changer de typo.
Les typo à empâtement, par exemple, sont très fréquentes sur support papier alors qu’elles le sont moins sur écran.
Il faut aussi penser à adapter la taille des caractères.

Exemple :
body
font: 10pt Times New Roman, serif;


Les liens

Les liens de navigation interne n’ont plus d’intérêt sur une feuille imprimée. On peut donc, dès le début, prévoir une classe spécifique à appliquer sur tous ces liens. Ainsi, on peut faire disparaître, par exemple, le sousligné sur les liens type « …que vous trouverez sur la page Recherche ».

Les liens externes, eux, sont certainement des liens qui continuent à avoir un sens hors du site.

CSS2 permet d’afficher l’adresse d’un lien après celui-ci. C’est très intéressant pour une feuille de style d’impression puisque, sur papier, impossible de cliquer. Sans cette possibilité, l’information principale du lien (l’adresse) est perdue.
Ne soyez pas déçus, néanmoins, si vous imprimez avec Internet Explorer : cette fonction n’est pas encore implémentée. Cela ne générera pas d’erreur … mais cela n’affichera pas l’adresse internet non plus !

Exemple :
a.navigationInterne
text-decoration: none;

a:after
content: " (" attr(href) ") ";
font-size: 0.9em;

a.navigationInterne:after
content: "";


Les couleurs et les images de fond

Les couleurs de fond peuvent avoir de gros inconvénients, une fois sur papier.
Elles peuvent, dans certains cas, gêner la lisibilité (plus que sur écran où le contraste n’est pas le même).

C’est encore plus vrai pour les images de fond qui peuvent être jolies et sans effet gênant sur un écran mais poser des problèmes de contraste à la lecture sur papier.

Couleurs de fond et images de fond peuvent aussi utiliser beaucoup d’encre pour un effet graphique mineur. L’internaute apprécierait qu’un site ait pensé à lui éviter le problème.
Cette fonctionnalité est d’ailleurs déjà implémentée par défaut dans certains navigateurs.

Attention, en enlevant les couleurs de fond, à ne pas se retrouver avec un texte illisible. Si un texte jaune, par exemple, était très lisible sur son fond noir, une fois la couleur de fond enlevée, le jaune sur le blanc de la feuille sera très difficile à lire. Il convient d’adapter la couleur du texte à tout changement de couleur de fond.

Exemple :
p
background: none;
color: #000;


Les marges, les espacements

L’aération d’une page imprimée n’est pas la même que pour une page web.
Il sera alors peut-être nécéssaire de revoir les marges, notamment horizontale, sur votre feuille d’impression.
Pensez que l’internaute sera déçu s’il doit imprimer sur 2 pages avec une marge de 4 cm un texte qui tiendrait sur 1 en utilisant simplement toute la largeur de la feuille.

Adaptez les espacements entre les éléments au média. Les titres n’ont pas forcément besoin d’être autant espacés de leur texte sur une version papier qu’à l’écran.

Les sauts de page

Rien de plus désagréable pour un internaute qu’une page sur laquelle n’a été imprimée qu’une seule ligne, qu’un paragraphe dont les derniers mots sont sur la page suivante, qu’un titre qui n’est pas immédiatement suivi par, au moins, la première ligne de son paragraphe, ou qu’une image dont la légende a été imprimée sur la page suivante, etc.
Les styles d’impression permettent de gérer tout ça. Analysez bien vos pages pour voir quels sont les coupures à éviter. Attention à ne pas tomber dans l’excès inverse et de faire des coupures partout : l’internaute n’appréciera pas non plus de devoir imprimer trop de pages.

Les propriétés à utiliser :
– page-break-before (gestion du saut de page avant l’élément)
– page-break-after (gestion du saut de page après l’élément)
– orphans (gestion des lignes seules en bas de page)
– widows (gestion des lignes seules en haut de page)

Exemple :
h1, h2, h3, h4, h5, h6
page-break-after:avoid;

p
orphans: 2;


Dans l’exemple ci-dessus, aucun saut de page ne sera fait après un titre hn et aucun début de paragraphe ne sera imprimé avec moins de deux lignes en bas de page.

Les zones inutiles

Certaines zones très courantes sur un site web sont néanmoins inutiles sur une version imprimée.
C’est le cas par exemple du menu. L’internaute qui imprime une page n’a plus besoin, quand il voudra relire sa page, d’avoir dans sa lecture tous les items du menu imprimés.

Un formulaire n’a également plus de sens sur une feuille imprimée (sauf, bien-sûr, les formulaires fait pour l’impression).
Il n’est pas forcément utile que le formulaire soit encore visible sur une page contact, par exemple, qui aurait été imprimée pour garder une trace du numéro de téléphone, de l’adresse, etc.

Les liens tels que « Retour à l’accueil » peuvent aussi être évité sur une feuille d’impression. Il faut identifier ces liens et leur assigner une classe particulière pour pouvoir les retirer lors de l’impression.

Exemple :
#menu, #piedDePage, form, #retourHautPage
display: none;

.lienNonImprime
display: none;



Les informations perdues

En supprimant le menu, en ayant pas la barre d’adresse imprimée, certaines informations se retrouvent « hors de la page web ».
L’internaute retrouve souvent ce type d’information imprimée en en-tête et pied-de-page (avec la date, parfois le titre…) en fonction de son navigateur et de sa configuration.
Mais le webmaster n’a pas la main sur ces informations.

Pour palier à cela, on peut concevoir, sur chacune des pages, une zone qui ne sera pas visible pour les écrans mais qui le sera à l’impression.
Cette zone reprendrait des informations telles que le titre du site, son URL, des informations importantes qui pourrait manquer au lecteur de la page imprimée (l’email du webmaster, par exemple).

Exemple :
Sur la feuille de style pour écran :

#infosImpression
display: none;



Sur la feuille de style pour imprimante:

#infosImpression
display: block;



Intro

Ajax, Web 2.0, la mode est à l’asynchrone … Ajax est-il incontournable ? Est-il véritablement intéressant d’utiliser Ajax comme méthode d’échange d’information dans le cadre du développement d’un jeu ?

Petits rappels

AJAX, pour Asynchronous JavaScript and XML est une technique de développement web qui vise à rendre les pages plus ergonomiques. L’objectif est de donner une sensation de réponse instantanée à l’utilisateur. Le principe de base est terriblement simple : échanger de faibles quantités d’information via un appel asynchrone – et en général grâce à du code XML, entre le client et le serveur.

Quand on parle d’Ajax, on entend trois choses:

1. L’utilisation intensive de JavaScript
2. L’utilisation de l’objet XMLHttpRequest
3. L’utilisation du langage XML pour le transfert des informations

Les puristes ajouteront un soupçon de XSLT pour le rendu, mais ce sont des puristes 😉

Vous l’aurez tous compris, Ajax, comme le DHTML, n’est pas une technologie en soi, c’est le fait d’utiliser un groupe de technologie ensemble dans un but précis.

Utiliser Ajax a des avantages : meilleure gestion de la bande passante, interactivité améliorée, hype pour n’en citer que quelque uns. Cette technique a aussi des inconvénients : diminution de l’accessibilité, mise en péril de l’ergonomie à laquelle l’utilisateur est habitué, temps de réponses non maîtrisés et principe de l’asynchronisme généralement mal assimilés par les programmeurs débutants.

Mise en situation

Mettons-nous dans la peau d’un webmaster lambda. Il développe son premier jeu. Pour simplifier notre propos considérons que son jeu ne compte que trois éléments: des pages plutôt statiques, comme des news, un classement, ou une FAQ. Des pages plutôt dynamiques, comme une carte. Et des pages composées presque exclusivement de formulaires, comme l’administration de compte ou le passage d’ordres.

Comment juger de l’intérêt d’une technologie ? En dehors de l’aspect subjectif « j’implémente parce que j’en ai envie » ou « parce que ça m’amuse », mesurons le degré d’intérêt en fonction de trois critères : l’ergonomie, les performances et la simplicité.

Valeur ajoutée à l’ergonomie générale
Comment l’utilisateur va t-il percevoir ce changement ? Va-t-il avoir la sensation que les « performances » de l’interface sont améliorées ? Va-t-il disposer de nouvelles fonctionnalités qui s’intègrent harmonieusement avec le reste, avec les fonctions par défaut de son navigateur (par exemple avec le bouton Back) ?

Supposons que notre webmaster n’affiche que 5 news. Il pourrait vouloir proposer un lien « Voir les news suivantes », ou un accès aux « archive » avec un calendrier. Sans Ajax le principe est simple, on ajoute un paramètre au script qui affiche la page et on rafraichi la totalité de la page. Avec Ajax on économise l’appel à ce script. On ne rafraichi que le contenu que l’utilisateur demande : les news. Il reçoit sa réponse plus vite, sans le « clignotement » de la page qui se rafraîchi. Attention néanmoins à ne pas le dérouter. Il faut que le changement sur la page soit clair, bien visible.

En ce qui concerne la carte, il est nécessaire de supporter un minimum de scrolling. La solution du rafraîchissement de la page à chaque déplacement est possible, bien sur, mais fort limité tout de même. Sans parler que son jeu aura l’air à la traîne techniquement. Quand on parle de scrolling on pense forcement à maintenir un (ou des) buffer(s). Techniquement, Ajax est bien adapté à ce type d’utilisation. A tout moment il est possible de déclencher le pré chargement d’une partie de la carte de façon invisible. Maintenir le buffer devient plus simple. Le XML se prête aussi à ce type d’utilisation. Le buffer deviendra un ou plusieurs node(s) dont on assurera le rendu via une fonction JS qui va bien.

Reste les pages dotées de formulaires. Nous étions habitués à devoir les valider d’abord côté client, puis à éventuellement demander une correction à l’utilisateur. Depuis fort longtemps nous sommes tous habitué à vérifier nos formulaires une seconde fois côté serveur. Ajax apporte ici deux avantages majeurs :

1. la possibilité de proposer des informations contextuelles (pensez au système d’auto-completion de gmail par exemple).
2. la possibilité de valider le formulaire au fur et à mesure, donnant un feedback plus rapide à l’utilisateur, évitant ainsi la frustration du formulaire refusé.

Bien sur, ça n’exclu pas la vérification côté serveur, mais ici l’intérêt en terme d’ergonomie est énorme, puisque les formulaires sont partout dans nos jeux.

Gain de performances côté serveur
Que va-t-on gagner en définitive ? On peut estimer le gain en fonction du temps d’exécution des scripts. De la répartition des requêtes SQL. Du taux d’utilisation moyen des ressources. Mais globalement ce qui nous intéresse c’est surtout le temps de réponse du site.

Le serveur n’a pas besoin de calculer le rendu de toute la page. Il n’effectue le plus souvent qu’un seul SELECT, pour récupérer les informations demandées par l’utilisateur. L’économie ici est triple :

1. On économise sur les SELECT qu’aurait effectué le serveur si il avait du rafraîchir toute la page, puisque seules les infos demandées sont rafraîchies
2. On économise la bande passante : pas besoin de renvoyer tout le code HTML, mais seulement un petit bout de code XML.
3. On économise sur le rendu : raffinement supplémentaire, le rendu peut-être délégué à une fonction JS, autant d’économie en temps d’exécution PHP.

Ceci dit Ajax peut avoir un effet pervers : la multiplication des requêtes. Il est tentant par exemple d’effectuer un rafraîchissement automatique par polling. Une aide contextuelle dans un formulaire utilisé pour chaque passage d’ordre signifie une requête au serveur web (et potentiellement une requête SQL) à chaque fois. Si la solution peut-être envisageable attention aux ressources qu’elle requiert.

Simplicité de mise en œuvre
Est-il aisé d’implémenter cette solution ? Est-il plus aisé de continuer à utiliser les techniques habituelles de DHTML ? Pourra-t-on la maintenir facilement ? Pourra-t-on facilement l’améliorer ? Considérons pour le moment que notre MJ ne se base pas sur un framework existant.

Soyons réaliste, non Ajax n’est pas simple à mettre en œuvre. Il demande une certaine expérience du développement web, sans doute plus que le DHTML à son époque. Il demande également une grande rigueur dans le code. Il est souvent nécessaire de jongler avec les éléments via leur id’s, de pouvoir modifier le contenu à la volée, en respectant le look&feel du site, d’où le besoin intensif de CSS. Ajax nécessite aussi de bien comprendre le concept d’asynchronisme, d’en connaître les limites et les risques.

Conclusions

Nous approfondirons les points abordés dans la suite, mais d’ores et déjà une réponse s’impose : oui, Ajax peut nous être utile. Le gain d’ergonomie peut-être énorme : assistance au remplissage des formulaire, aide contextuelle, réactivité accrue, meilleure gestion des cartes, autant de domaine ou Ajax excelle. La mise en place demande tout de même un minimum de réflexion. Où l’appliquer, tout d’abord. Quel sera l’impact sur les performances du serveur ? Enfin, la conception même du jeu devra évoluer, on pourra dans un premier temps se contenter d’intégrer Ajax à l’existant, mais pour en tirer vraiment partit il faudra souvent repasser par la case développement. Stay tuned et rendez vous dans le numéro 2…

Bon, avant d’en arriver là, il serait bon de mettre en place ces fameux fichiers inclus.

En effet, un site internet est un objet éphémère, qui bouge, qui vie et qui change donc régulièrement. Si vous ne concevez pas vos pages avec un minimum de méthode, vous ne vous en sortirez pas. Alors, avant de lancer votre main sur la figure de votre ami, placez vos menus dans un fichier inclus.

include

Cette commande Php est simple à utiliser :

Ce morceau de code permet tout simplement de placer (d’inclure) le fichier « mon_fichier.php » à la place de cette ligne.

Imaginons que votre menu soit le suivant :


Fichier : menu.php

• Sommaire
• Forum

Vous pouvez placer dans le fichier d’index la ligne suivante en lieu et place du menu :





Et ceci sur toutes les pages de votre site où doit s’afficher votre menu.

Maintenant, si votre ami passe par là et vous propose une petite modification, vous pouvez lui dire « ok, dans 10 secondes, elle est faite ». Et vous n’avez qu’à modifier le fichier « menu.php ».

Quelques règles tout de même

Vous pouvez très bien placer du php dans le fichier inclus. Vous pouvez, par exemple, définir que le menu en cours n’est pas cliquable.

Il est de bon goût d’inclure un fichier de configuration au début de toutes vos pages Php. Ce fichier contient les paramètres de votre site, mais peu aussi contenir des fonctions que vous utilisez régulièrement. Vous pouvez aussi inclure 2 fichiers, l’un pour la configuration et l’autre pour les fonctions.

N’hésitez pas à nommer vos fichiers avec l’extension « .inc.php » afin de les reconnaître plus facilement. Il est bon également de les placer dans un dossier. Moins il y aura de fichiers à la racine de votre site et plus votre site sera simple à maintenir, sans compter que cela déchargera aussi votre serveur.

Ne tentez pas le diable en essayant d’inclure un fichier dont le nom est indiqué par une variable :





C’est une piste que les pirates aiment bien. On ne va pas rentrer dans les détails, mais sachez que c’est une porte ouverte. Si toutefois vous tenez absolument à faire un include avec une variable, vérifiez et revérifier avec des tests que la page que vous allez charger soit bien une page à vous, se trouvant sur votre serveur.

Et require alors ?

Php nous propose une autre fonction pour inclure un fichier : require

Avec require, un fichier ne sera inclus qu’une seule fois dans un autre. Par exemple, dans une boucle, un fichier include sera inclus autant de fois que la boucle tournera alors qu’une fichier chargé avec require ne sera chargé que la première fois.

require fonctionne de la même façon que include d’un point de vue syntaxique.

Mon site en morceau

Si vous souhaitez maintenir un site très facilement, faites en sorte de regrouper tous ce qui peut être regrouper et de les inclure dans vos pages à l’aide de require ou include.

Par exemple, les entêtes des pages html peuvent être mis dans un fichier « entete.php ».

Un peu plus loin

Il est tout à fait possible d’appeler un fichier distant et de lui passer des paramètres.

L’appel suivant fonctionne très bien :





Par contre, pour un fichier en local, ce n’est pas pareil. L’appel suivant ne fonctionnera pas :





En effet, il faut faire comme cela :





Tout simplement.

]]> https://www.magazine-jeux.com/generation-de-nombres-aleatoires/ Mon, 07 Aug 2006 05:17:00 +0000 https://www.magazine-jeux.com/generation-de-nombres-aleatoires/ Pour commencer, parcequ’il faut bien commncer un jour et par quelque chose, une machine ne sortira jamais réellement un nombre aléatoire au sens propre du terme. Les nombres générés par un programme sont en fait issus d’une suite mathématique.

Une méthode de calcul

Pour exemple simple, nous avons la méthode de Von Neumann qui consiste à prendre un nombre que l’on élève au carré puis, à prendre les chiffres du milieu comme résultat. Ce résultat est utilisé pour le prochain nombre et ainsi de suite.

Un exemple avec de vrais chiffres histoire de comprendre un peu mieux :


On commence avec le nombre suivant : 123
Elevé au carré : 123² = 15129
Donc, nous prenons les chiffres du milieu : 512 (c'est le premier résultat)
Et c'est reparti :
512² = 262144
Donc, nous avons comme résultat : 6214


Au passage, on constate que cette méthode utilise le résultat en terme de chaîne de caractères et non en nombre. Bref…

Il existe évidement beaucoup de méthodes.

La graine

Le nombre de départ est appelé la graine. C’est lui qui va déterminer la suite logique de nombres pseudos aléatoires. Il va donc de soit que ce nombre doit être lui-même aléatoire. Mais là, nous tournons en rond.

Pour sélectionner une graine de « qualité », nous prenons généralement le temps écoulé depuis l’allumage de l’ordinateur.

Et en Php ?

Pour faire simple et aller droit au but qui vous interresse, voici les fonctions vous permettant de générer des nombres aléatoires à partir du Php :


// Initialisation du générateur
srand((float) microtime()*1000000);

// Génération d'un nombre compris entre 1 et 6
$resultat = rand(1, 6) ;


Il s’emblerait d’après la documentation du Php que cette fonction (rand) soit un peu lente. Il existe donc une fonction qui serait plus « rapide » et, en tout cas, meilleure en terme de résultats.


// Initialisation du générateur
mt_srand((float) microtime()*1000000);

// Génération d'un nombre compris entre 1 et 6
$resultat = mt_rand(1, 6) ;


La seule différence est mt_ devant les fonctions.

Bon, d’accord, ce serait plus rapide. Alors testons !

Les tests

Nous avons donc effectuer une boucle de 1 million de générations et regardé en moyenne le temps écoulé :

rand : 1058 ms

mt_rand : 1058 ms

Difficile de dire que l’une est plus rapide que l’autre. Les tests ont été fait sur des serveurs Windows et Linux en Php 4 et 5, avec des valeurs de recherche comprises entre 1 et 6 puis, entre 1 et 6000. Nous retrouvons toujours les mêmes valeurs.

Les suites générées sont très certainement plus « aléatoires » avec la fonction mt_rand. Il est également fort possible que la fonction rand ait été reprogrammée.

Une utilisation particulière

L’aléatoire n’étant pas vraiment aléatoire, il est possible d’utiliser cette possibilité pour effectuer des calculs en fonction d’évènements extérieurs comme par exemple en fonction du jour du mois.

Voici une boucle qui affiche 10 valeurs aléatoires, 5 fois de suite :


for($j=1;$j<=5;$j++)
srand((float) microtime()*1000000);
for($i=1;$i<=10;$i++)
// Génération d'un nombre compris entre 1 et 6
$resultat = rand(1, 60000) ;
echo $resultat.":";

echo "
";



Voici le résulat (un des résultats en fait) :


9299:40472:54969:40395:10961:445:15792:18826:33600:26864:
8548:28017:19267:13263:10386:37151:28547:23509:51014:14292:
31035:3183:15109:46568:35950:32619:2386:43602:1372:17407:
51805:55513:38735:27750:52002:5818:55749:41044:4739:2881:
59050:23083:5448:9808:332:16542:31280:9302:53996:19728:


Voici la même boucle, mais en remplaçant l’initialisation du générateur par la ligne suivante :


srand(date("j"));


Le générateur est donc initialisé avec le jour du mois.

Nous avons le résultat suivant :


49653:63:12516:11456:26208:58327:22059:35442:49521:53193:
49653:63:12516:11456:26208:58327:22059:35442:49521:53193:
49653:63:12516:11456:26208:58327:22059:35442:49521:53193:
49653:63:12516:11456:26208:58327:22059:35442:49521:53193:
49653:63:12516:11456:26208:58327:22059:35442:49521:53193:


Vous aurez donc pour un même jour les mêmes résultats.

Ce système peut-être utilisé lorsque vous souhaitez afficher une information aléatoire chaque jour par exemple, mais que cette information soit la même toute la journée.

A vous de compliquez un peu le système pour trouver d’autres utilisations pertinentes.

]]> https://www.magazine-jeux.com/les-sessions-en-php/ Mon, 03 Jul 2006 05:10:00 +0000 https://www.magazine-jeux.com/les-sessions-en-php/ Introduit à partir de la version 4 du PHP, vous devez donc avoir la version 4.1.0 au moins afin de faire fonctionner correctement les exemples de cet article. Normalement, tout les hébergeurs ont au moins cette version.

Le principe

Les sessions permettent de conserver des informations côté serveur et de les utiliser ensuite à chaque fois qu’une page dynamique est créée. Ces informations sont propres à l’utilisateur. C’est-à-dire que chaque utilisateur dispose d’une session pouvant contenir plusieurs informations.

Contrairement aux cookies qui sont stockés côté client, les sessions sont stockées côté serveur. Evidement cela implique une sécurité accrue, mais en contre partie, cela demande d’avoir un peu plus la main sur les paramètres du serveur.

La durée de vie d’une session est définie au niveau serveur. Cette valeur peut-être consultée en utilisant la fonction phpinfo() puis, en consultant la ligne session.cache_expire.

Cette valeur est modifiable dans le fichier de configuration.

Création d’une session

Allez, c’est parti, voici le code permettant de démarrer une session :





Vous devez démarrer toutes vos pages dynamiques par cette commande. Elle est obligatoire sauf si la directive session.auto_start est à ON.

Les sessions sont alors sauvegardées dans un dossier. Vous pouvez consulter le nom de ce dossier en regardant la directive session.save_path dans le résultat d’un phpinfo().

Vous pouvez obtenir l’identifiant d’une session par la commande session_id().

Dans certains cas, notamment si votre jeu se trouve dans un sous domaine avec d’autres jeux, il est conseillé de nommer vous-même les sessions en utilisant la commande session_name() :





Enregistrement d’informations dans la session

La session est crée, il faut maintenant enregistrer des informations dedans :


$_SESSION['s_Pseudo'] = $Pseudo;


Cette ligne permet d’enregistrer dans une variable de session le contenu de la variable $Pseudo.

Vous pouvez évidement enregistrer plusieurs informations :


$_SESSION['s_Pseudo'] = $Pseudo;
$_SESSION['s_Identifiant'] = $Id;
$_SESSION['s_Age'] = $Age;


Essayez de nommer vos variables de session d’une façon logique. Ici, nous utilisons s_ devant le nom de la variable. Ceci afin d’éviter de les mélanger avec d’autres variables suivant la configuration de votre serveur.

Lecture des informations d’une session

Vous voilà donc avec une session et pleins d’informations dedans. Voyons comment relire les variables :


$Pseudo = $_SESSION['s_Pseudo'];


Tout simplement en faisant l’inverse que pour l’enregistrement.

Effacement et suppression des sessions

Pour effacer une variable de session, vous pouvez utiliser la commande classique unset() :

unset($_SESSION['s_Pseudo']);
if(isset($_SESSION['s_Pseudo']))
echo "erreur lors de la suppression.";
else
echo "La variable a bien été supprimée.";


Pour enfin supprimer complètement une session (utile pour proposer au joueur de se déconnecter par exemple) :


session_destroy();


N’oubliez pas de placer en haut de chaque page la commande de création de votre session.

]]>