Messages

1

Projets SFML / Re : [C++ - CardGame] President/Trouduc multijoueur (WIP)

« le: Février 14, 2016, 01:16:01 am »

Slt

Je passe sur le site sfml 2 fois par an je ne m'attendais pas à voir mon projet déterré. Les serveurs sont off depuis 2 ans. Mais si t'as des questions sur le code fourni, n'hésite pas

2

Projets SFML / Re : [C++ - CardGame] President/Trouduc multijoueur (WIP)

« le: Janvier 09, 2014, 04:47:55 pm »

ça m'intéresse effectivement ! Je vais regarder ça. Pour le code source n'hésite pas !

3

Projets SFML / Re : [C++ - CardGame] President/Trouduc multijoueur (WIP)

« le: Janvier 09, 2014, 04:18:06 pm »

Merci pour ton soutien ça fait plaisir d'entendre du positif

Aucun problème, le projet est open-source. J'ai encore du boulot de nettoyage effectivement, parce que l'accélération pour la démo de Noël a précipité les choses et que le résultat est dégueulasse.

Mais dès que j'aurais "camouflé" les infos sensibles, relatives au chiffrement RSA du mot de passe, un dépôt publique sera créé. En attendant, au cas par cas je peux filer 99% du code source, et fournir des réponses aux questions avec

Tu penses à quels sites ? Non pour le moment je me suis cantonné aux sites de développeur que je connais (sdz sfml et dvp).

4

Projets SFML / Re : [C++ - CardGame] President/Trouduc multijoueur (WIP)

« le: Janvier 09, 2014, 12:27:38 pm »

Merci d'avoir eu la sympathie de donner ton ressenti. Tout le monde s'accorde à dire a peu près la même chose que toi, plus précisément que le genre du jeu n'est pas spécialement populaire.

En tout cas merci pour ton retour ça fait déjà plaisir.

Ce jeu m'aura au moins apporter beaucoup de connaissances sur les différents aspects du développement d'un jeu

5

Projets SFML / Re : [C++ - CardGame] President/Trouduc multijoueur (WIP)

« le: Janvier 09, 2014, 01:32:12 am »

Très étonné que ce jeu n'est levé aucun intérêt... j'imagine qu'il y a une bonne raison, si tel le cas n'hésitez pas à m'en faire part je serai ravi d'améliorer le jeu selon les différents retours qui seront faits.


En tout cas, la difficulté à organiser une partie à 4 joueurs m'a fait me dire que je devrais inclure un mode solo, et une IA. Ceci est donc en préparation, et une nouvelle version de la démo sera donc fournie sous peu. Elle incluera pour le coup la fin des traductions en espagnol, et la version Mac.

Une nouvelle vidéo a été ajoutée dans le post principal. Regardez là, et lachez vos impressions, toutes les critiques sont les bienvenues, même si c'est pour expliquer pourquoi ce jeu ne vous attire pas

6

Projets SFML / [C++ - CardGame] President/Trouduc multijoueur (WIP)

« le: Décembre 29, 2013, 11:20:18 am »

Mister President

       

                                       


Editeur
T.I.E Studio (futur ex-Crim'17++)
This Is Everithing (This means imagination)

Présentation
Synopsis
Mister President est un jeu de carte multijoueur en ligne. Ce jeu est aussi connu sous le nom du Trouduc' et les règles sont simples : vous participez à une partie avec plusieurs joueurs (classiquement 4). L'ensemble des cartes sont distribuées et il ne vous reste plus qu'à vous en débarrasser dans un échange au tour par tour. Mais attention, on ne pose que des cartes supérieures à la dernière posée, et des paires au dessus des paires, etc ! Le gagnant devient président, le perdant trouduc, et à la partie suivante, le trouduc doit donner ses deux meilleures cartes au président, et récolter bien malgré lui les deux pires cartes du président...

Vous possédez un profil (login et mot de passe), associé à un compte qui vous permet de consulter votre historique, et de connaitre votre classement. La plupart des variantes sont intégrées et vous pouvez choisir la combinaison de votre choix dans les options du jeu. Vous pouvez créer une partie ou rejoindre une existante, soit en ligne, soit en WLAN (vous ou un ami crééz une partie et donnez votre adresse ip à vos amis qui peuvent vous rejoindre directement)

Découvrir le jeu en vidéo

Le petit plus ?
Mister President compte sortir du lot en apportant une touche humoristique quasi permanente. S'appuyant sur les données relevées dans les profils et les statistiques à court, moyen et long terme, le jeu apportera des alertes spéciales en cours de jeu avec des annonces "les profils contenant le pseudo "toto" sont les plus grands trouduc's de l'année 20yy". Il y aura également "des remises de prix" chaque mois puis chaque année pour les meilleurs présidents et trouducs du mois/de l'année ("trouduc of the year 2015"). Des trophées que tout le monde pourra constater lorsque vous débarquerez dans des parties ! ça promet ! :p

Règles du jeu classiques*
*la plupart de ces paramètres pourront varier à votre guise selon vos choix dans le menu option, selon les différentes variantes connues

• Ordre des cartes : 3 4 5 6 7 8 9 10 Valet Dame Roi As 2 ;
• Aucun ordre sur les couleurs ;
• Pas de joker ;
• Pouvoir mettre une carte de même valeur que la carte dans la défausse. Si le joueur suivant n'a pas cette carte alors il est "sauté" ;
• Révolution : lorsque l'on pose en même temps 4 carte identique alors l'ordre des cartes est inversé. On peut renversé la révolution en faisant une autre (Contre-révolution). Ne dure que le temps d'une partie ;
• Le nombre de carte est déterminé par le premier joueur qui joue. S'il pose 1 carte on continu en posant 1 carte jusqu'à ce que qqun prenne la main. Même principe pour 2, 3 et 4. Il est donc impossible de poser 3 cartes sur une carte ;
• Le 2 coupe. Il n'est pas possible de monter sur un 2. Cette carte respecte la régle précédente. Donc quand on joue en 3 cartes, il n'est possible de remporté la main en posant juste un seul 2 (mais avec trois 2 oui ^^) ;
• Le président donne deux de ses cartes (n'importe lesquelles) au trouduc. Le trouduc doit donner ses deux meilleurs cartes au Président. Par exemple, s'il y a deux As et un 2, il donne un As et un 2.
• Le vice pré donne une carte (n'importe laquelle). Le vice trou donne sa meilleur carte au vice pré ;
• Si le nombre de joueur est plus grand que 4, il y a ce qu'on appelle des "neutres". Ils ne donnent aucune carte ;
• Il est possible de jouer aucune carte

Genre
Jeu de carte jouable en ligne, ou en LAN/WLAN.

Technologies
C++11, SFML 2.0, SFGUI 0.1, php5, Apache 2, MySQL, SVN, NTL, RSA, CodeIgniter, Azure, CodeBlocks, MySQL Workbench 6.0

Open-Source ?
Oui, mais pour le moment je ne les diffuserai pas, car elles ont besoin d'un sacré nettoyage ! Pour le moment, nous en somme à environ 4000 lignes de code, tout compris.

Plateformes cibles
Windows, Mac, Linux (Et oui les 3 plateformes !)

Langues
Français, Anglais, Espagnol (et bien d'autres à venir)

Avancement (35%)
Déjà fait :

• Mode LAN/WLAN
• Début d'implémentation des règles
• Serveur amp
• Base de données
• Systèmes de tri
• Gestion basique de partie
• Menus
• WebService
• Système d'authentification
• Installeur

Todo List :

• Mode en ligne
• Options de gestion des règles
• Graphismes
• HUD Profil
• Gestion historique de partie

Demo jouable comme cadeau de Noël !
Bon, je suis désolé d'avance, mais pour le moment il va manquer une plateforme (Mac), car mes PCs ont décidés mutuellement de ne pas vouloir virtualiser un sytème d'exploitation Mac, et vais donc devoir attendre d'être au boulot où les PC sont plus souples ^^.

Amis espagnols, "discùlpeme", mais il va manquer également les traductions  espagnoles au complet, mais un ami s'en occupe, ce sera donc disponible sous peu.

Windows :
Download for Windows

Linux :
Download for linux

Attention Linux !

Une issue m'a été remonté il y a peu (bon d'accord par moi-même ), il semblerait qu'un problème de threading existe sous Linux avec la SFML. Donc pour le moment les linuxiens ne pourront que rejoindre une partie créée par un client windows ou Mac, le temps que j'évoque la chose sur ce forum à Laurent Gomila et les très bons utilisateurs de la SFML.

Bon voilà à peu près tout ... ah si ! Egalement :

Recrutement
Comme vous pourrez le constater, Nous (développeurs) avons absolument tout fait, y compris les graphismes, les traductions, etc ... je ne serais pas contre des volontaires rigoureux et passionnés autant que nous pour élever ce jeu au fort potentiel vers le haut, surtout que si pour le moment nous avons pu nous débrouiller, le jeu complet final contiendra des cinématiques, animations in-game, sans compter l'existant qui aurait bien besoin d'un petit coup de pinceau :lol:

• Graphistes 2D (pour les menus, les cartes, les futurs HUD profil, animations in-game (déplacement carte, remise de prix, animation gagnant, perdant, etc.. )
• traducteurs (italien, allemand, et tout ce que vous voulez graçe au système de traduction mis en place)
• Graphiste/artiste 3D (pour des cinématiques d'introduction (T.I.E Studio)) <= pas essentiel dans un premier temps

Avenir, avenir...
Si le jeu rencontre un certain engouement par sa démo jouable et les différents réseaux sur lequel il va être présenté, il se poursuivra vers une version finale complètement paramétrable (règles du jeu, commandes, infos profil, etc), avec l'ajout d'un profil détaillé, la génération de statistiques, historisation complète des parties, animations, bien plus de langues cibles, et toujours 3 plateformes cibles (mais pour le coup sans que l'une ou l'autre rencontre des soucis) et le jeu sera disponible en téléchargement via la méthode de commercialisation "Pay What You Want", autant dire gratuit si vous n'avez pas envie de payer pour ce jeu !

Pour résumer,



Vous voilà en présence de la démo jouable d'un jeu cross-platform multihread, multiplayer, multilingue, avec un serveur ouvert 24/24 7J/7 le tout open-source à l'avenir ambitieux et, si vous le voulez, prometteur, alors régalez vous, mesdames/mesdames les Présidents !

Des questions ?
N'hésitez pas, il y'aura une réponse à tout.

@+
L'équipe T.I.E Studio

7

Réseau / Re : Re : [client HTTP]réponse au format xml ?

« le: Janvier 20, 2013, 10:58:32 am »

Ben, oui, si tu encapsules ton XML dans une réponse au format HTTP, logiquement ça va commencer à fonctionner

Le cors en lui-même n'est pas interprété, donc qu'il contienne du XML ou du toto ne change rien pour SFML, elle le transmets tel quel sans problème.

D'après ce que tu m'avais dit, j'avais compris que la réponse ne contenait que du XML. Mais si c'est encapsulé dans du HTTP standard alors aucun problème, évidemment.

Note que ce qui termine l'en-tête ce n'est pas le champ Content-Type, c'est un double \r\n.

Exact.

Pour le contenu effectivement je me suis trompé, la visualisation du code source ne m'affichait pas toutes les infos. Mais bon tant mieux si tout rentre dans l'ordre. Maintenant je passer au problème suivant ^^ ( à savoir que le post n'a pas l'air d'envoyer le body que je fourni (ou plutot il l'envoie mais...), car à la réception, $_POST semble être vide :/)

Merci tout de même.

8

Réseau / Re : [client HTTP]réponse au format xml ?

« le: Janvier 20, 2013, 09:29:10 am »

Bon j'ai trouvé une solution avant de commencer à chercher dans le code source.

Et je penses que ça te fera même plaisir de le savoir, mais le xml est tout à fait pris en charge par ton client HTTP !

<?xml version="1.0" encoding="utf-8"?>
<xml><item>test numero un</item></xml>
 

Mais comme tout ça ne peut pas être magique, et que je commence à bien connaitre le fonctionnement interne de cette classe http, je savais qu'elle ne pouvait pas fonctionner sans que des infos supplémentaires aient été transmises, et j'ai donc intégré la classe http à mon code pour pouvoir la modifier. J'ai ensuite affiché l'ensemble des données reçues, et j'ai obtenu ceci :

HTTP/1.1 200 OK
Date: Sun, 20 Jan 2013 08:31:45 GMT
Server: Apache/2.2.22 (Win32) PHP/5.3.13
X-Powered-By: PHP/5.3.13
Status: 200
Content-Length: 78
Connection: close
Content-Type: application/xml
<?xml version="1.0" encoding="utf-8"?>
<xml><item>test numero un</item></xml>
 

Donc voilà ! peu importe les infos qui suivent le Content-Type, même du xml est pris en charge (étant donné qu'on ne fait que lire dans un buffer, je me doutais bien que ce n'était pas possible cette histoire d'incompatibilité).


Ah et oui la solution de ce problème :

// AVANT ...

 // We'll work on http://www.sfml-dev.org
 http.setHost("http://localhost/President/index.php");

 // Prepare a request to get the 'features.php' page
 sf::Http::Request request("testcontroller/test/id/1");


// APRES...
 // We'll work on http://www.sfml-dev.org
 http.setHost("http://localhost");

 // Prepare a request to get the 'features.php' page
 sf::Http::Request request("President/index.php/testcontroller/test/id/1");
 

Tout bête comme erreur

9

Réseau / Re : [client HTTP]réponse au format xml ?

« le: Janvier 19, 2013, 06:35:16 pm »

bonjour Laurent,

désolé de relancer le sujet, mais je n'arrive pas à décortiquer le corps type que sf::http attend d'une réponse http. Pourrais-tu me dire exactement à quoi doit ressembler le corps de ma réponse ?


Voilà la chose la plus pertinente que j'ai tenté :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
        <body>
             test numero un
        </body>
</html>
 

c'est le corps de la page www.sfml-dev.org/features.php qui fonctionne parfaitement, le contenu en moins biens sur. Mais jai toujours une erreur 1000 (invalid response)

Niveau code, je n'ai remplacé que l'host, et fourni le "controller/method/param/value" à la requete :

 // We'll work on http://www.sfml-dev.org
 http.setHost("http://www.sfml-dev.org");

 // Prepare a request to get the 'features.php' page
 sf::Http::Request request("features.php");

//devient...

 // We'll work on http://www.sfml-dev.org
 http.setHost("http://localhost/President/index.php");

 // Prepare a request to get the 'features.php' page
 sf::Http::Request request("testcontroller/test/id/1");
 

Et "http://localhost/President/index.php/testcontroller/test/id/1" contient exactement le contenu copié-collé dans ce message (le corps de features.php)

Une idée de ce qu'il me manque ?



Edit : pour être encore plus précis : voilà le contenu de la méthode appelée :

    function test_get()
    {
                HttpResponse::status(200);
                HttpResponse::setContentType('text/html');             
                HttpResponse::setData('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
                <body>
                        test numero un
                </body>
        </html>');
                HttpResponse::send();
    }
 

10

Réseau / Re : Re : [client HTTP]réponse au format xml ?

« le: Janvier 12, 2013, 03:09:24 pm »

En le modifiant de quelle manière ?

De toute façon, sf::Http::Response est conçu comme étant une réponse HTTP (avec son en-tête et tout ce qu'il contient). Ca n'aurait pas vraiment de sens de coller du XML ou du JSON dedans.

Justement en modifiant l'utilisation de sf::HttpResponse : après tout m_body est un std::string, et je ne dis pas que ce serait propre ni que ça aurait du sens, mais que ça pourrait marcher (et à moi éviter de passer par un client HTPP très ennuyeux style cURL++ ou libwww).

Pour la manière, j'ai deux solutions : aucune n'est propre, mais ce sont loin d'être les seules solutions (la mieux serait surement que je me serve de SFML Network pour créer une classe "sf::XmlResponse" ou "sf::Xml" pour ne pas utiliser sf::Http, mais je ne suis pas sur de comment gérer la méthode POST). Soit je passe la méthode parse à une visibilité publique, et je retire son appel de la méthode sendRequest, remplaçant par une autre méthode ou par du code directement pour coller le contenu de "receivedStr" dans le httpResponse, sans parsing, et modifier les autres membre de httpResponse selon la situation... soit en créant une méthode "parseXML" et en faisant un test du style :

if (toSend.getField("Content-Type") == "application/xml")
    parseXml(receivedStr);
else
   parse(receivedStr);
 

Mis à part cela, je penses que les clients http servent le plus souvent à attaquer des webServices, et peu d'entre eux renvoi des informations au format html. Généralement, je penses qu'il s'agit de format adapté au rapatriement de données, issues de base de données par exemple. A ce jeu le xml et encore plus le json (ou encore le csv) sont d'excellents atouts.

De plus, dans d'autres langages, comme en C#, un framework comme .Net permet de deserialiser très facilement le contenu d'un XML pour l'intégrer dans un DTO (grace aux attributes notamment), et les client http permettent de renseigner le "Content-Type", ce qui a un véritable effet. C'est ce que je souhaiterais reproduire avec la SFML (la dernière partie sur le Content-Type").


Edit: pour exposer le contexte : j'ai un jeu de carte en ligne (client/serveur) assez abouti (jouable en LAN/WLAN pour le moment, et en ligne prochainement si j'arrive à mettre en place ce dont on parle), utilisant de fond en comble la SFML, j'ai un serveur WAMP installé et prêt à être utilisé, et pour que le joueur puisse se connecter via un compte, j'ai mis une table profil au point que j'attaque avec le client via une couche de webservices, afin d'autoriser des connexion, et rapatrier des données d'historique de partie, et de trouver des parties en cours, ce qui permettra au client de rejoindre une partie sans demander l'adresse ip à l'utilisateur. le webService que j'ai mis au point s'appuie sur CodeIgniter et utilise un protocole REST vraiment sympa d'utilisation, permettant même de choisir son format de retour de réposne : xml, json, ou csv... quand j'ai vu un client http avec la SFML, je me suis dit banco : "je vais pouvoir faire la même chose qu'en .Net au boulot avec les HttpClient du framework".C'est pour cela que je cherche un moyen de contourner ce petit souci de format de réponse.

11

Réseau / Re : Re : [client HTTP]réponse au format xml ?

« le: Janvier 12, 2013, 11:03:47 am »

Ok, donc non c'est vraiment pas possible

sans modifier SFML je veux bien le croire, mais en modifiant sendRequest c'est pas possible non plus ?

12

Réseau / Re : [client HTTP]réponse au format xml ?

« le: Janvier 12, 2013, 10:35:35 am »

xml pur : voici le code source de la page dont j'ai posé un exemple en premier post :

<?xml version="1.0" encoding="utf-8"?>
<xml><item>toto</item></xml>
 

Et évidemment si je choisi le format json dans mon url le code source est encore plus démuni :

"toto"
 

13

Réseau / Re : [client HTTP]réponse au format xml ?

« le: Janvier 12, 2013, 09:42:12 am »

void Http::Response::parse(const std::string& data)
{
    std::istringstream in(data);

    // Extract the HTTP version from the first line
    std::string version;
    if (in >> version)
    {
        if ((version.size() >= 8) && (version[6] == '.') &&
            (toLower(version.substr(0, 5)) == "http/")   &&
             isdigit(version[5]) && isdigit(version[7]))
        {
            m_majorVersion = version[5] - '0';
            m_minorVersion = version[7] - '0';
        }
        else
        {
            // Invalid HTTP version
            m_status = InvalidResponse;
            return;
        }
    }

    // Extract the status code from the first line
    int status;
    if (in >> status)
    {
        m_status = static_cast<Status>(status);
    }
    else
    {
        // Invalid status code
        m_status = InvalidResponse;
        return;
    }

    // Ignore the end of the first line
    in.ignore(10000, '\n');

    // Parse the other lines, which contain fields, one by one
    std::string line;
    while (std::getline(in, line) && (line.size() > 2))
    {
        std::string::size_type pos = line.find(": ");
        if (pos != std::string::npos)
        {
            // Extract the field name and its value
            std::string field = line.substr(0, pos);
            std::string value = line.substr(pos + 2);

            // Remove any trailing \r
            if (!value.empty() && (*value.rbegin() == '\r'))
                value.erase(value.size() - 1);

            // Add the field
            m_fields[toLower(field)] = value;
        }
    }

    // Finally extract the body
    m_body.clear();
    std::copy(std::istreambuf_iterator<char>(in), std::istreambuf_iterator<char>(), std::back_inserter(m_body));
}
 

J'ai l'impression qu'il ne faudrait pas grand chose pour que ma version de sfml autorise le xml.. c'est réalisable  non ?

Je penses àjouter une nouvelle méthode parseXml et vérifier le Content-Type dans la méthode SendRequest mais je ne voudrais pas perdre mon temps^^ : si tu devais le faire tu ferais comment ? Je sais que la structure (m_body, etc) n'est pas spécialement adaptée, mais..

Dernière question : si c'était fait proprement tu trouverais cela intéressent que ton client Http accepte d'autre format en retour de requête ?


Edit : ou alors il suffirait  de dissocier le parsing de la méthode sendRequest, ce serait peut-être mieux non (ne s'occuper que des autres informations (status, ...), et transmettre les données brutes au m_body)?

14

Réseau / [client HTTP]réponse au format xml ?

« le: Janvier 12, 2013, 02:03:08 am »

Bonjour,

j'ai un web service respectant le protocole REST et utilisant l'API CodeIgniter et j'aimerais utiliser la SFML et son client HTTP pour envoyer mes requêtes GET et POST.  Malheureusement, je reçois le code erreur 1000 (invalid http response) là où mon web service renvoie quelque chose comme :

<xml>
   <item>
      toto
   </item>
</xml>
 

N'est-ce pas possible de récupérer des informations sous ce format ? (Même chose avec le format JSON).

Voici mon code :

     // Create a new HTTP client
     sf::Http http("http://localhost/President/index.php/testcontroller/");

     // Prepare a request to get the 'features.php' page
     sf::Http::Request request("test/id/1");
     request.setField("Content-Type", "application/xml");
     
     // Send the request
     sf::Http::Response response = http.sendRequest(request);

     // Check the status code and display the result
     sf::Http::Response::Status status = response.getStatus();

     if (status == sf::Http::Response::Ok)
     {
         std::cout << response.getBody() << std::endl;
     }
     else
     {
         std::cout << "Error " << status << std::endl;
     }
 

Merci d'avence pour votre aide..

15

DotNet / Re : XNA et SFML.NET ?

« le: Novembre 23, 2012, 06:23:21 pm »

Pas vraiment, j'ai mis de côté un peu ce truc car je devais finir un projet de jeu de trouduc en ligne (avec SFML) en WLAN (qui est fini d'ailleurs faudra que je penses à le poster quand j'aurais trouver un graphiste pour remplacer mes horribles cartes).

Cependant, a priori je dirais qu'il n'y a aucune raison "logicielle" pour que cela soit impossible. En effet, on peut toujours "mapper à la main" des objet d'un type structuré vers un autre. Il faut surement utiliser l'api XNA pour avoir une "RenderWindow" adaptée, mais rien ne t'empêche sous le capot d'utiliser les sprites sfml, etc, puis de les rendre compatible avec la "RenderWindow" version XNA.

C'est juste un exemple grossier, mais si c'était bien ta question alors oui c'est possible.