TourDeJeu, le réseau des jeux en ligne alternatifs : jeux web, casual MMOs, jeux par forum ou par e-mail. En savoir +
En ligne : 751 jeux, 7126 news, 26537 commentaires
 

Recherche de jeu par critères - Un jeu au hasard !

Le guide des jeux en ligne alternatifs

Comment crer son jeu et le grer ?

Les Focus

Tech. : Le programmeur cologique
Tech. : automatisation et mails
Salon MondeDuJeu 2002
Revue de presse des JpC
Humour : 1001 raisons pour jouer
Ludique : le joueur parfait
Ludique : dcouverte du JpC
PHP : accs base de donnes
PHP : structure du site
Ludique : JpC et Temps rel
Jeux de rles sans rgles
Humour : astrologie du JpC
Tech. : Bases de donnes
MJ : les joueurs multiples
PHP : utilit pour un JpC
PHP : c'est quoi ?
Tech. : l'analyse des ordres
Ludique : dbutants et vtrans
Tech. : archi Ultraball 2100
Ludique : les jeux de pronos
Tech. : le site Web d'un JpC
Humour : football et wargame
Prsentation de TourDeJeu

Devenir un dveloppeur cologiste

Partez sur une bonne base

Partir sur une bonne base
Vertiges de la base de donne ! Merveille que ces petites cases qui se remplissent et qui constituent le coeur de votre jeu. Jusqu' ce qu'elle sature ; qu'elle dborde ; et que la moindre recherche demande plusieurs minutes. L encore, il y a des rflexes importants pour ne pas gaspiller l'nergie du serveur.

Ne charger que le ncessaire
Une base de donnes permet de stocker la fois des donnes d'usage frquent et d'usage trs rare. Il est important de les dissocier, pour que, dans le droulement du jeu, seules les informations utiles soient recharges. Prenons le cas d'un jeu impliquant un personnage. Il sera important de dissocier les donnes du joueur (identifiant, mot de passe, e-mail) qui ne sont utiles qu' la connexion, et les donnes portant sur son personnage (points de vie, points d'action...) qui font l'objet d'un rechargement rgulier. L'idal, c'est de crer autant de bases qu'il y a de types de donnes dans le jeu : une base pour les objets, une pour les amis du joueur, que sais-je ? N'oubliez pas de faire correspondre chaque table, par exemple avec le mme numro d'identifiant pour le joueur et le personnage correspondant.

La mme question doit se poser pour de nombreux dtails. Est-il ncessaire de charger la liste complte des joueurs alors qu'il n'y en a que trois proximit ? Est-il ncessaire de charger la liste complte des objets transports par le joueur alors qu'on peut les "cacher" dans un sac dos qui s'ouvre dans ce but ?

Le choix pertinent des donnes afficher impose parfois des contorsions techniques (par exemple calculer les coordonnes minimales et maximales de visibilit d'un joueur pour afficher les personnages dont les coordonnes sont comprises dans cet intervalle). Au chapitre de l'arbitrage entre mySQL et PHP, il est parfois difficile de choisir le plus efficace. Un conseil : minimiser la charge PHP en faisant porter les calculs et le tris de donnes sur la base, qui est optimise pour. Il faut par exemple proscrire l'usage de "SELECT *" si seul un nom est ncessaire "SELECT nom" sera plus appropri. Il y a d'autres petits trucs pratiques. Si vous souhaitez afficher les 10 premiers enregistrements (par ex. les en-ttes des 10 derniers messages), pas la peine de charger toute la table en mmoire : "SELECT en_tete FROM jeu_messages LIMIT 10" permettra d'conomiser beaucoup de chargements puisque la recherche s'arrte ds que le 10e enregistrement est charg.

Le cas le plus critique est celui des messages : a enfle, a gonfle et a devient trs difficile compacter. Demandez-vous si la liste des messages doit tre charge systmatiquement en dbut de page. Une page ddie sera peut-tre approprie. Au besoin, il est possible de n'afficher que le dernier message, ou d'avertir le joueur qu'un message est arriv. Une requte "SELECT id FROM jeu_message LIMIT 1" permet de "dtecter" un nouveau message sans surcharger la base.

Compacter les donnes dans la base
On ne le rptera jamais assez : quand on n'a pas de ptrole, il faut avoir des ID (hum hum...). L'ID (pour index), c'est la cl de l'efficacit dans une base mySQL. Ce n'est pas facile admettre pour un dbutant, mais chaque joueur, chaque message, chaque objet du jeu ne doit tre reprsent que par un chiffre. Pourquoi ? Pour des raisons de rapidit et de libert. J'ai moi-mme dbut en faisant rfrence chaque personnage par son pseudonyme, qui me paraissait suffisamment unique pour tre reprsentatif. Mon code PHP comportait des tableaux de type $points["Roberto L'colo"]. Oui mais voil : tout d'abord j'ai eu de nombreux bugs cause des apostrophes et guillemets, notamment dans les requtes mysql. D'autre part le temps ncessaire pour une requte est bien plus important lorsqu'il s'agit de rechercher "Roberto L'colo" que pour rechercher "4055" dans un index. Cela tient la nature des donnes stockes dans la base.

Dans un champ "text" (ou "char" ou "blob"), chaque caractre est cod par 1 octet. Notre nom "Roberto L'colo" occupe donc 15 octets. Supposons qu'il soit dfini* par un index compris entre 0 et 65535 : cette valeur se code sur 3 octets. Cela signifie que, chaque fois que vous ferez rfrence ce personnage par son ID dans une requte ou un calcul PHP, la quantit de donnes calculer sera 5 fois plus petite qu'en utilisant son pseudo. Et croyez-moi, s'il y a 5000 joueurs sur votre partie, votre hbergeur vous remerciera de cet effort. * Cela ne signifie pas que le pseudo doive disparatre, mais il ne doit pas servir d'identifiant pour un joueur

Cette rduction s'applique aux autres donnes. Pour chaque valeur que vous souhaitez stocker dans la base, choisissez judicieusement le type de donnes. Comment faire ? Evaluez simplement la valeur MAXIMUM qui sera utile. Sans rentrer dans le dtail des types de donnes mySQL, voici quelques indications gnrales :

  • ID (identifiant de joueur) : MEDIUMINT UNIQUE -> permet de stocker 65536 joueurs avec un index automatique (en auto-increment, c'est mieux). Et si jamais vous atteignez les 65000 joueurs vous pouvez passer en INT (mySQL convertit sans problme les valeurs lorsqu'on augmente la longueur), ce qui vous autorisera 16 millions de joueurs, mais vous devriez le voir venir.
  • ID (autre identifiant) : s'il y a plusieurs parties dans votre jeu, utilisez par exemple un TINYINT (256 valeurs) pour les reprer. Pour les identifiants de messages, le type INT s'impose. Mieux vaut partir sur une valeur basse, quitte l'augmenter quand on constate que a ne va pas suffire.
  • Pseudonyme de personnage : c'est une valeur "lourde" qui pourrait tre place dans une table part si les accs la table des persos sont frquents ; par exemple dans la table des joueurs. Pour la longueur, prfrer un champ de type CHAR avec une longueur de 25 (a vitera les dlires de joueurs qui crent des noms de 500 caractres).
  • Valeur alternative oui/non ou 0/1 : SET avec pour valeur '0','1' ou 'oui','non' -> permet de dfinir les valeurs possibles pour un champ : chaque champ peut alors occuper 1 seul bit de donnes (un huitime d'octet) dans la base. Par comparaison un champ texte avec "oui" ou "non" occupe 24 fois plus d'espace.
  • Valeur numrique (points de vie, etc) : vous de dterminer le maximum acceptable, sans bloquer les joueurs puissants. En gnral, on optera pour du MEDIUMINT (65536).
  • Date : je n'ai pas de donnes prcises ce sujet : je prfre stocker les dates sous forme de timestamp (obtenue par un mktime() en PHP) dans un champ INT (a donne le nombre de secondes coules depuis le 1/1/1970, par exemple 1055190185), ce qui permet de manipuler les dates plus simplement qu'avec les fonctions DATE() de mySQL. Il est possible que je me plante sur ce sujet ; je reste ouvert aux suggestions.

    Enfin, si votre systme s'y prte, il peut tre intressant de multiplier les rfrences, mme si a impose une gestion trs rigoureuse. Dans Tratognse, on peut envoyer un mme message 10, 30, 40 personnes la fois. Au dpart, j'ai cr un message pour chaque destinataire. Si l'on compte l'ID de l'metteur, celle du rcepteur, le texte et la date d'mission du message, ma base est trs vite devenue astronomique (3 Mo de donnes pour "seulement" 12000 messages hebdomadaires). Puisque la seule donne qui changeait pour chaque rcepteur tait son ID, j'ai dcid de crer UN SEUL message de rfrence, pour 30 ou 40 messages qui "pointaient" vers ce message en ne comportant qu'un numro de rcepteur. Avec ce systme un peu compliqu, j'ai rduit la table 700ko, ce qui a considrablement acclr les accs la base. Ensuite, a complique un peu la rception et le "nettoyage" des messages trop vieux, mais on s'en sort.

    Retour au sommaire de l'article