JeuWeb Créez votre jeu par navigateur !

rwk · 27-05-2009, 09:58 AM

Salut à tous,

Aujourd'hui, je me demande comment vous gérez vos feedbacks sur les jeux...
Parce que pour ma part, j'ai de gros soucis.

En général, j'utilise un système à 3 varibales dans l'url
- Succes=texte à afficher => Ca me sort un joli texte en VERT
- Alerte=texte à afficher => Le joueur a fait une action qu'il ne peut pas faire pour des raisons d'incapacités : joli texte en Orange
- Erreur=texte à afficher => ça se sont toutes les erreurs que je juge "tentative frauduleuse" genre modification de l'url avec des params qui ne correspondent pas aux valeurs attentues... ca me fait un joli texte en rouge.

Pour cela, j'utilise la fonction header();

Code PHP :
<?php 

header("location:jouer.php?Succes=Vous avez attaqué machin qui perd Xpv et blablabla");

header("location:jouer.php?Alerte=Vous ne pouvez pas marcher sur cet élément du décor");

header("location:jouer.php?Erreur=Cette action est invalide"); 

**Sephi-Chan** · 27-05-2009, 10:34 AM

Dans CakePHP, les contrôleurs ont une méthode baptisée flash(string $message, string $url, integer $pause) qui génère (à la place du rendu habituel) une page qui contient un message. Ce message est un lien vers l'URL qu'on indique. On peut également spécifier une durée en secondes comme troisième argument, la page contiendra alors une redirection par meta vers l'URL demandée.

/* On utilise cette potion dans un contrôleur. */

$this->flash(

  "Le message a bien été édité.",

  "/posts/",

  3

);

Dans Ruby on Rails, les contrôleurs proposent également méthode flash, qui cette fois utilise une session. La particularité de cet espace de session est qu'elle est vidée à chaque requête.

# Dans le contrôleur.

if @user.save

  flash[:notice] = "Votre compte a bien été crée."

  redirect_to @user

else

  flash[:error] = "Une erreur est survenue."

  render :action => "new"

end



# Dans la vue (dans mon cas, le layout).

- if flash[:error]

  %p.message.error= flash[:error]

  

- if flash[:notice]

  %p.message.notice= flash[:notice]

Si la procédure se passe bien, dans Ruby on Rails, on arrivera donc sur la page qui montre le profil de l'utilisateur crée (car Ruby on Rails préconise les architectures RESTful), on aura donc :

<p class="message notice">Votre compte a bien été crée.</p>

Si on actualise ou que l'on change de page, le message disparaît.

Désolé d'être moins complet sur l'exemple de CakePHP, mais j'ai un peu oublié. ^^

Sephi-Chan

keke · 27-05-2009, 10:38 AM

Coucou,

Je n'ai pas la même notion de Feedback que toi :
http://fr.wikipedia.org/wiki/Feedback

J'ai donc un peu de mal à comprendre ce que tu indiques ^^. N'hésites pas à me remettre dans le droit chemin si je m'écartes du sujet.

>>>> J'ai testé les 2 variables, aucune des deux n'est nulle, jusqu'à preuve du contraire -5 est bien plus petit que 5...
Hum, il me semble que tu ai des soucis dans ta programmation. Se peut-il que le joueur ai -5 Thor en poche ? Ne pourrais-tu pas faire une fonction dans ta classe qui évalue l'argent de ton joueur ? Bon, tu ne demandes pas de solution ... alors je te donne juste des idées ^^

Pour en revenir à tes headers, je ne fonctionne pas du tout ainsi. J'utilise des formulaires (<forms>) qui me renvoie vers des fichiers .php dans lequel je traite toutes mes conditions.
L'usage que tu fais des header me semblent un peu trop permissif à la fraude...

kéké

rwk · (Modification du message : 27-05-2009, 10:43 AM par rwk.)

Avec des sessions, effectivement y a moyen...

Mais dans c'cas là, comment peut ton "terminer" le script et faire une redirection sans utiliser header...

genre

Code PHP :
<?php 

if($YaUneErreur)

{

  $_SESSION['Erreur'] = 'Vous avez merdé';

  //redirection=>comment ? exit ne le permet pas... et header et moi sommes en plein divorce

}

wild-D · 27-05-2009, 12:03 PM

faudra relire le manuel de header() ^^

sans vérifier, pour moi header() sert pas à envoyer quelque chose, mais à mettre dans le buffer d'en-tête http, ton élément d'en-tête (traduction, temps qu'il n'a pas été envoyé tu peux même rappeler header() pour écraser un appel fait précédement avec de nouveau paramètre, genre une redirection sur une toute autre page); de plus il ne stop pas l'exécution du script.
Je sais pas d'oû te viens cette idée (imagine si à chaque fois qu'on utilise cette fonction pour définir le charset fallait que le script s'arrête y aurait comme un sushi Big Grin

).

1) ce que tu as mis en header ne partira que lors du premier echo, ou toute autre sortie de contenu (flush()). Qui va forcer l'envoi de contenu et donc va envoyer en premier ton en-tête http.

2) et donc logique que pour arrêter l'execution du script; faut faire suivre ton header() d'un exit.

--
tu peux aussi utiliser une redirection javascript; mais franchement pas ce qu'il y a de plus élégant.(autant utiliser header())
--

le plus élégant, une redirection interne dans ton moteur de jeu. Faut pour ça que ton moteur de jeu supporte ce genre de "redirection". La plupart du temps si tu travailles en POO tu auras donc une classe de dispatching. Et tu vas donc réinitialiser celle-ci avec ta "redirection" plutot que l'URI "originale" envoyée par le client.(Si t'es en procédural, c'est aussi faisable a priori; mais faut adapter ton système en conséquence)

Holy · (Modification du message : 27-05-2009, 12:32 PM par Holy.)

Un problème classique. Faut bien structurer ses pages pour pouvoir faire le tout gaiement ^^

Perso ma structure est toujours la même:

Code :
inclusion de fichier config et autre

- Si traitement à faire, je traite + gestion des erreurs éventuels

- Si le traitement est réussi, je peux rediriger sur une autre page éventuellement.

- Inclusion de l'header de ma page

- Corps de ma page

- Footer

Et en synthétique en PHP, ça me donne ça:

Code PHP :
<?php

require('./config.php');

// J'instancie plusieurs variables "génériques"

$erreur = ARRAY();

$titre = 'Modification du pseudo';

//=====================

// Traîtement POST-formulaire

//=====================

// Une simple condition pour savoir si un formulaire a été activé

if(isset($_POST['action'])) {

    // Si un formulaire a été déclenché, je le traite ici, je commence directement par un "gestionnaire" d'erreurs

    // (l'exemple qui suit est complètement factice)

    if($x > 0) {

        $erreur['x'] = 'C\'est pas bien t\'as fait une erreur!';

    }

    elseif($y >= 8) {

        $erreur['y'] = 'J\'ai dit non!';

    }

    // Je vérifie qu'il n'y a pas eu d'erreurs pour aller plus loin dans le traitement du formulaire

    if(count($erreur) == 0) {

        // Je fais le traitement du formulaire ici, exemple rapide avec une requête SQL factice

        $sql = "UPDATE player SET pseudo = 'LULINSUPERSTAR' WHERE idPlayer = '99999'";

        if(query($sql, __FILE__, __LINE__) === TRUE) {

            // Fonction de redirection

            succes('Votre pseudo a bien été changé', './exemple.html');

        }

    }

}

//=====================

// Fin traîtement POST-formulaire

//=====================

// inclusion de l'header

require('./header.php');

    echo '        

        <p class="title">Changement de pseudo</p>

        <form action="" method="post">

        <br />

        <label for="pseudo">Nom du héros:</label>

        <input type="text" id="pseudo" name="pseudo" size="15" maxlength="14" value="',$pseudo,'" />

        ',affiche_erreur($erreur['pseudo']),'<br />

        <input type="submit" value="S\'engager" class="bouton" />

        <input type="hidden" name="action" value="subscribe" />

        </form>'.n();

require("./footer.php");

?>

rwk · (Modification du message : 27-05-2009, 01:41 PM par Sephi-Chan.)

Citation :faudra relire le manuel de header() 34

sans vérifier, pour moi header() sert pas à envoyer quelque chose, mais à mettre dans le buffer d'en-tête http, ton élément d'en-tête (traduction, temps qu'il n'a pas été envoyé tu peux même rappeler header() pour écraser un appel fait précédement avec de nouveau paramètre, genre une redirection sur une toute autre page); de plus il ne stop pas l'exécution du script.
Je sais pas d'oû te viens cette idée (imagine si à chaque fois qu'on utilise cette fonction pour définir le charset fallait que le script s'arrête y aurait comme un sushi 1).

1) ce que tu as mis en header ne partira que lors du premier echo, ou toute autre sortie de contenu (flush()). Qui va forcer l'envoi de contenu et donc va envoyer en premier ton en-tête http.

2) et donc logique que pour arrêter l'execution du script; faut faire suivre ton header() d'un exit.

--
tu peux aussi utiliser une redirection javascript; mais franchement pas ce qu'il y a de plus élégant.(autant utiliser header())
--

le plus élégant, une redirection interne dans ton moteur de jeu. Faut pour ça que ton moteur de jeu supporte ce genre de "redirection". La plupart du temps si tu travailles en POO tu auras donc une classe de dispatching. Et tu vas donc réinitialiser celle-ci avec ta "redirection" plutot que l'URI "originale" envoyée par le client.(Si t'es en procédural, c'est aussi faisable a priori; mais faut adapter ton système en conséquence)

Ca m'avait paru logique au début aussi qu'il faille un exit, vu que header justement ne permet qu'à définir les entêtes...

Sauf que que j'ai pris surement la mauvaise habitude de ne pas mettre de exit; vu que header trainait en général en fin de script... Plus rien derrière.

Surement que dans ma tête, l'amalgame s'est fait : header n'a pas besoin d'exit.
J'viens de relire la doc... et effectivement, faut exit;

Mais bon, l'idée surtout était de voir comment chacun a son approche de la gestion du feedback.

Les forums utilisent le "action réussie, vous allez être redirigés dans X secondes". D'autres calent une page intermédiaire...
D'autres te laissent des pages blanches avec l'erreur et un gros "démerde toi".

@Holy, tu utilises un gros tableau $erreur dans lequel tu stockes toutes les erreurs possibles puis tu appelles celle que tu veux ? Ou alors, tu enregistres au fur et à mesure tes erreurs dans le tableau !?

genre dans ton fichier de config tu as un

$erreur['machin1'] = 'truc1';
$erreur['machin2'] = 'truc2';
$erreur['machin3'] = 'truc3';
$erreur['machin4'] = 'truc4';
$erreur['machin5'] = 'truc5';

et tu as une fonction affiche_erreur(numéro de l'erreur) ?

Autant j'y vois clairement un avantage pour de la gestion multilangue...
Ca s'rait pas con comme système ça non plus.

Citation :le plus élégant, une redirection interne dans ton moteur de jeu. Faut pour ça que ton moteur de jeu supporte ce genre de "redirection". La plupart du temps si tu travailles en POO tu auras donc une classe de dispatching. Et tu vas donc réinitialiser celle-ci avec ta "redirection" plutot que l'URI "originale" envoyée par le client.(Si t'es en procédural, c'est aussi faisable a priori; mais faut adapter ton système en conséquence)

J'ai carrément rien compris. Je sais pas si c'est du à ma digestion après le repas.
Tu appelles quoi "redirection interne" ?

Holy · 27-05-2009, 02:32 PM

Bah c'est un peu comme tu veux.

Personnellement je gère les messages d'erreur au cas par cas. Mais donc oui, j'ai un tableau $erreur que je remplis en fonction des erreurs possibles. Donc si les conditions sont remplies pour qu'il y aie une erreur, j'instancie $erreur['quelquechose'].

Ce qui me permet très facilement de vérifier si il y a eu une erreur. Si je dois exécuter le script, il me suffit de faire count($erreur) == 0.

Après pour l'affichage, j'ai une fonction affiche_erreur qui me permet d'afficher le message de l'erreur qui est passé en paramètre (et qui ne l'affiche pas si la valeur passée en paramètre est vide).

Donc en gros et par exemple, si $x ne peut pas être plus grand que 10:

Code PHP :
<?php

if($x > 10) {

$erreur['x'] = 'Votre x est trop grand. Veuillez désigner un x de valeur maximale 10.';

}

if(count($erreur) == 0) {

// Ici j'exécute le script vu qu'il n'y a eu aucune erreur

}

echo affiche_erreur($erreur['x']); // N'affichera rien si pas d'erreur

// Ici mon formulaire

?>

wild-D · 27-05-2009, 02:43 PM

ce que je propose de faire ce que fait holy, mais en plus compliquer Smile

on va prendre la cas basique pour expliquer le concept; vas surtout pas l'appliquer tel quel :

t'as un fichier central index.php
dans tes url tu utilise une variable action, qui défini en fait le fichier-action à "executer".
et hop tu execute cette action.





//include

include_once 'configuration.php';

include_once 'fonctions.php';



//input

$action = isset($_GET['action'])?$_GET['action']:'actionpardefaut';



//

include $action.'.php';

ça marche bien sur les lien de tes page suffit de faire des liens type index.php?action=UNEACTION et pour faire une redirection interne sur une autre action; ça peut ce faire;

tu force la définition des variables $_GET, tu lance l'action désirée, et tu exit pour pas continuer sur l'action initiale;

dans un fichier-action tu pourra avoir une redirection interne



....

//

if(xyz){//oups y a une erreur ou que sais-je



  $_GET['action'] = 'UNEAUTREACTION';



  include 'index.php';

  exit;

}



//l'action normale si pas xyz

...

dans la pratique on fait rarement ça de manière aussi rusto-procédurale (mais on utilise de jolie classe pour faire joli), mais reste que le principe de base c'est juste ça.

rwk · 27-05-2009, 02:46 PM

Oui, bah du coup, ça change pas beaucoup de ce que je fais pour gérer mes évènements.
Faut juste que j'arrête de passer le feedback en GET ^^