Sommaire
Suite au journal d'il y a quelques jours, j'ai donc essayé de supprimer les bugs les plus gênants, et voici la toute première version de Flukz. C'est assez rudimentaire, mais à peu près utilisable (enfin, j'espère).
Pour résumer, Flukz est un mini-jeu de shootem up qui fonctionne comme un wiki. Les "niveaux de jeu" sont entièrement paramétrables (ajouts de nouveaux types de sprites, position et vitesse des sprites, résistance aux tirs, musique de fond).
Compilation
Si vous voulez tester, vous allez devoir compiler les sources. Avant de commencer, assurez-vous d'avoir les paquets contenant la version de développement de la bibliothèque Qt. Sous debian/ubuntu, il faut installer les paquets "libqt4-dev" et "qtmobility-dev". Sur les autres distributions, il s'agit sans doute de noms similaires. Je ne sais pas trop si la séparation du paquet qtmobility est spécifique à debian ou non.
Ouvrez un terminal, placez-vous dans le répertoire qui vous convient et tapez les commandes suivantes :
* wget http://download.tuxfamily.org/flukz/flukz0.1.tar.gz
* tar -xzvf flukz0.1.tar.gz
* cd flukz0.1
* qmake
* make
* bin/flukz
Si la commande qmake ne fonctionne pas, c'est qu'il vous manque le paquet libqt4-dev indiqué plus haut.
Petite difficulté sous les versions récentes de debian/ubuntu, la séparation de Qtmobility du paquet principal a cassé les liens du Makefile créé par qmake. J'ai créé un petit script bash pour corriger ça, à exécuter entre qmake et make. La liste des commandes à taper sous debian/ubuntu devient :
* qmake
* bash debianpatch
* make
Sinon, j'ai aussi mis en ligne un binaire statique pour Windows.
Divers problèmes connus
Lors d'un test sur Lubuntu, j'ai eu des erreurs à l'exécution à cause de paquets manquants. J'ai eu besoin d'installer les paquets "libgnomeui-0" et "pulseaudio" pour que le programme s'exécute (sur Ubuntu, ce n'est pas utile, ces paquets sont déjà installés par défaut). N'hésitez à me faire des retours pour les autres distributions, j'ajouterai les infos adéquates dans le fichier README.
Pour une raison que je ne comprends pas, le binaire statique windows marche sur certains pcs que j'ai testé, mais pas tous. Il y a un pc sous windows 7 sur lequel il crashe au lancement du jeu. Et il crashe aussi exactement au même endroit quand je le lance sous ubuntu avec wine. C'est sans doute un seul et même problème, peut-être lié aux sons ou aux threads.
Utilisation
Quand vous lancez Flukz, vous voyez un "site" apparaître. Imaginez qu'il s'agit de la même chose que wikipedia, mais pour les jeux video, et cela devrait suffire pour comprendre l'essentiel du fonctionnement du logiciel. Vous pouvez éditer les pages (bouton en haut à droite), mais aussi les niveaux de jeux, ajouter de nouveaux graphiques de sprites au serveur ou des nouveaux sons, etc.
Et bien sûr, vous pouvez simplement jouer aux niveaux existants. A noter que lors du premier clic sur un niveau de jeu, il est possible que le logiciel semble lent à la réaction. C'est parce qu'il télécharge les fichiers de dépendances, et s'il y a dans le lot un fichier son qui fait 1Mo, ça peut facilement prendre quelques secondes (il n'y a pas d'animation qui montre le niveau d'avancement). Les fichiers déjà présents en cache sur la machine locale ne sont plus téléchargés ensuite, donc ce n'est lent que la première fois.
Pour créer une nouvelle page ou un nouveau niveau de jeu, c'est le même principe que wikipedia, il suffit de créer un lien sur une page existante, de cliquer, et d'éditer la page qui s'affiche. Ou bien, vous pouvez simplement taper le nom de la nouvelle page directement dans la barre d'adresse (mais si possible, essayez d'éviter les pages orphelines, car il n'y a pas encore d'outil pour les détecter).
Toutes les modifications (sauf le vandalisme bien sûr) sont les bienvenues. Si vous faites une bêtise involontairement, il y a toujours la possibilité de faire un revert (le revert est accessible à partir de la page de diff), donc n'hésitez pas à tenter des trucs. Vous pouvez aussi créer un compte utilisateur (icône de login en haut à droite), sinon vos contributions seront archivées avec votre adresse IP, comme sur wikipedia.
Bon, je ne garantis pas qu'on puisse faire des niveaux amusants avec le peu de fonctionnalités disponibles dans cette première version. Disons qu'il doit tout de même être possible de faire mieux que les deux niveaux bâclés que j'ai mis en ligne pour démarrer.
Attention, si vous ajoutez des fichiers externes d'images ou de sons, seules trois licences sont acceptées: GPL, CC-BY et CC-BY-SA. En particulier, les licences CC-BY-NC-SA ou BY-NC-ND, très courantes pour les fichiers de musique, ne sont pas acceptées.
Pour les sons, seuls les fichiers wav au format PCM à la fréquence 22050Hz sont supportés. Il y a des explications plus précises dans Flukz sur la façon de créer un fichier wav dans l'encodage correct avec le logiciel sox. Note : certains fichiers sons posent malheureusement quand même des problèmes, même avec l'encodage correct, avec un crash du logiciel.
Enfin, ne soyez pas surpris par les éventuels bugs. Je suis sûr qu'il en reste encore pas mal. N'hésitez pas à reporter les problèmes rencontrés sur la page BugList. A noter qu'il y a une sécurité aux alentours de 3 Mo qui bloque l'upload de fichiers trop volumineux (mais sans message d'erreur pour l'instant). Si l'upload freeze, ce n'est peut-être pas un bug, c'est peut-être que vous avez essayé d'uploader un fichier trop gros.
Détails techniques
Flukz est programmé entièrement en C++, avec la bibliothèque Qt. Le but était à l'origine de créer un simple shoot'em up rudimentaire, puis est venue l'idée de l'interfacer avec un wiki. Malheureusement, il n'y a pas vraiment de moyen simple d'interfacer une application externe avec un wiki, et puis c'était plus rigolo de recoder from scratch un wiki uniquement en C++ (ce qui s'est révélé d'ailleurs la partie la plus difficile à coder de Flukz jusqu'ici).
On en a profité pour définir notre propre protocole de communication client-serveur, comme ça il n'y a aucune dépendance dans Flukz aux technologies web habituelles (http, javascript, php, serveur web type Apache, etc). Le serveur accessible à l'adresse game.flukz.org (adresse par défaut dans le client) est simplement le programme Flukz lui-même lancé avec "bin/flukz --masterserver". Il tourne sur une machine virtuelle debian 64 bits, dont le noeud physique est situé en Suède, chez l'hébergeur Glesys.
Parmi les détails intéressants, les pages sont écrites dans une syntaxe wiki, mais ce code wiki n'est pas interprété par le serveur. Le code wiki est envoyé tel quel au client, et c'est le client lui-même qui le transforme en code html, juste avant l'affichage. Idem pour le calcul des différences entre deux versions d'une page. Les deux versions de la page sont envoyées au client, et c'est le client lui-même qui calcule les différences. Dans Flukz, autant que possible, c'est au client de faire le sale boulot :-) Le but est de réduire la charge du serveur, et aussi (un peu) la bande passante.
Autre astuce pour réduire la bande passante : Flukz compare automatiquement les hashs sha1 des fichiers en cache chez le client avec les hashs des fichiers sur le serveur, donc tant qu'un fichier ne change pas, il n'est plus téléchargé par le client. Les hashs sont également utilisés comme sécurité pour éviter des éditions conflictuelles d'une page. Si vous éditez une page et que celle-ci change entre temps, le commit sera bloqué (mais le message d'erreur sera seulement que l'écriture n'a pas été possible, affiner le message d'erreur est un todo).
Toujours à propos du serveur, la configuration actuelle chez Glesys est vraiment minimale, avec 256Mo de RAM et 50Go/mois de bande passante. Je ne suis pas très confiant sur le comportement du serveur dès que le nombre d'utilisateurs va dépasser une dizaine. Notamment, essayez d'être gentils sur l'ajout de fichiers sons pour l'instant. Même si les fichiers ne sont téléchargés qu'une seule fois par client grâce aux hashs, ça risque de peser lourd sur la bande passante. Au niveau des images de sprites, pas de souci par contre, car les fichiers png sont petits.
Dans la partie "jeu video", une difficulté technique a été la gestion des sons. C'est un peu le point faible de la bibliothèque Qt, parce qu'elle ne possède pas de mixeur, élément pourtant incontournable de tout jeu video, même embryonnaire. Heureusement, nous avons trouvé à peu près ce qu'il fallait avec Qt Game Enabler. Par contre, seuls les sons dans un format wav spécifique sont supportés, et il y a des bugs avec certains fichiers. Un support correct des fichiers sons ne sera pas facile.
Code source
Si coder ne vous fait pas peur, le repository subversion, c'est ici : svn://svn.tuxfamily.org/svnroot/flukz/flukz/trunk
Même si vous ne connaissez pas Qt, ça peut être l'occasion d'essayer, d'autant plus qu'il y a des pans entiers du logiciel qui peuvent être améliorés sans connaître Qt en détails.
Pour discuter du logiciel, je pense que c'est aussi simple de le faire directement dans Flukz, plutôt qu'avec des listes de mails. J'ai créé des pages BugList, TodoList, forum des développeurs, que vous pouvez modifier librement. Et même si vous n'avez pas l'intention de participer à la programmation, peut-être que vous avez une bonne idée de développement futur. N'hésitez pas à la proposer.
# vite une dépêche!
Posté par ZeroHeure . Évalué à 3.
y'a-t-il un modo dans la salle?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: vite une dépêche!
Posté par Yukito (site web personnel) . Évalué à 9.
C'est vraiment une première version, jamais testée par des utilisateurs externes au projet. Un journal discret me paraît préférable pour l'instant…
# Autre wiki en C++
Posté par Allan Simon (site web personnel) . Évalué à 1.
Rigolo, je suis en train aussi d'en coder un https://github.com/allan-simon/tatowiki (on sait jamais s'il y a des morceaux de code qui peuvent t-être utiles…), j'utilise un framework maison, basé lui-même sur le framework cppcms (http://cppcms.com/wikipp/en/page/main). La librairie permet d'avoir aux besoins, un serveur http embarqué ou de connecter a apache etc. via fastcgi, du coup cela évite de réinventer la roue tout en évitant masse de dépendance (et cppcms est inclus dans debian wheezy si j'ai bon souvenir)
Sinon si le hash est uniquement là afin d'assurer que la donnee est identique , sans contrainte de sécurité, il y a des hash plus rapide que sha1 , par exemple Murmurhash et Cityhash. Après évidemment, vu que tu ne dois pas en faire 5000 par secondes….
# Une capture d'écran svp !
Posté par JPEC . Évalué à 10.
Avec une petite capture d'écran le journal serait parfait ! Ça permettrait de se faire une petite idée du jeu et donner envie de l'essayer…
[^] # Re: Une capture d'écran svp !
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Voire une vidéo, car le concept du wiki qui devient un shoot, c'est très original et donc difficile à imaginer!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Une capture d'écran svp !
Posté par Yukito (site web personnel) . Évalué à 4.
Voici une capture d'écran en mode wiki. La disposition est très similaire à celle d'un wiki classique, avec sur la gauche des liens "Accueil" et "Modification récentes", et sur la droite, le contenu de la page en cours de visionnage (la page d'accueil sur cette capture d'écran).
Et voici une capture d'écran lors du mode shootem up (quand on clique par exemple sur le lien "premier jeu"). La fenêtre du logiciel se redimensionne automatiquement lorsqu'un niveau de shootem up est lancé, et le mode wiki devient invisible jusqu'à la fin du jeu.
# protocole
Posté par fredix . Évalué à 2.
Petite question à propos du protocole entre le client et le serveur. A priori il y a une socket persistante, pourquoi ne pas avoir utilisé XMPP ou zeromq ? C'est pas une critique et si c'est pour le fun je comprend aussi :)
[^] # Re: protocole
Posté par Yukito (site web personnel) . Évalué à 1.
Au niveau du protocole, j'ai volontairement évité les protocoles existants. A terme, je veux décentraliser certains aspects du logiciel (notamment en faisant des réplications des données sur les clients), donc http n'est pas adapté, mais je ne veux pas juste faire de l'échange de fichiers comme dans les logiciels peer-to-peer actuels, ou juste de l'échange de messages comme dans les logiciels de chat (xmpp). Au niveau des fichiers, par exemple, je veux pouvoir contrôler les fichiers, comme sur un site web classique.
Comme je ne sais pas vraiment la forme finale qu'aura le protocole, ni exactement à quoi il servira, je me suis dit que le plus simple, c'était de le faire à ma sauce, et de le faire évoluer au fur et à mesure que les besoins apparaîtront.
L'utilisation de hashs aussi bien dans le protocole que dans la structure de stockage des fichiers est d'ailleurs une préparation de la réplication des données entre les clients. En gros, quand un client voudra un fichier, il lui suffira de demander le hash au serveur maître, et le serveur maître enverra en plus du hash l'adresse d'un serveur esclave. Le client n'aura plus qu'à télécharger le fichier depuis le serveur esclave, et vérifier que les hashs correspondent.
[^] # Re: protocole
Posté par fredix . Évalué à 2.
Si je comprend bien (pas sûr) tu parles là de ton protocole métier, or tu aurais pu aussi bien l'intégrer dans XMPP ou Zeromq qui sont juste des protocoles réseaux. Par exemple ils gèrent tous les 2 le PUB/SUB ce qui permet d'envoyer une data ou un message vers N clients. A priori si tu souhaites faire la même chose tu devras développer cela dans ton serveur et ton client.
Sinon je vais creuser ton app, ca me parait très intéressant comme archi qui n'utilise pas pour une fois des technos web.
(désolé pour le doublon linuxfr/flukz).
# Pour le son
Posté par davandg . Évalué à 2.
Pourquoi ne pas utiliser phonon ? (qui est maintenant intégré à Qt)
Ou libvlc ?
[^] # Re: Pour le son
Posté par Yukito (site web personnel) . Évalué à 2.
Sauf erreur, je crois que ni phonon ni libvlc ne disposent de ce que j'avais vraiment besoin, à savoir le mixage en temps réel de sons issus de sources audio différentes. Mais il est fort possible qu'il y ait des choses dans libvlc qui pourraient être utiles pour supporter plus de formats audio.
# Malin!
Posté par Larry Cow . Évalué à 4.
L'idée est bonne, et me semble parfaite pour lutter contre l'idée que "dans le libre il n'y a pas de graphistes, que des codeurs".
Petite suggestion : rendre les fenêtres de propriétés "dockables" (et dockées par défaut), parce que c'est assez chiant qu'elles s'ouvrent toutes seules en permanence (genre à chaque clic sur un sprite, ou à chaque début d'édition de niveau).
Par ailleurs, le format de fichier (.fkz) est très complexe? Genre en faire un moteur Javascript pour affichage "dans un navigateur" pourrait aider les gens à partager leurs créations assez facilement (i.e. sans rien télécharger). Et du coup s'intégrer dans un "vrai" Wiki (même si je peux comprendre l'intérêt du client lourd).
[^] # Re: Malin!
Posté par Yukito (site web personnel) . Évalué à 1.
Oui, je vais essayer de déplacer la position par défaut de la fenêtre de propriétés sur le côté, ou de la "docker". En attendant, je te conseille de ne pas fermer la fenêtre de propriétés, parce qu'effectivement elle réapparaît à chaque clic. Il faut simplement la déplacer un peu sur le côté (sans la fermer). J'ai tellement pris l'habitude de faire ce geste en début d'édition d'un niveau que j'en avais oublié que c'était contre-intuitif.
# taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 24 février 2013 à 10:46.
J'ai pris le temps de tester le jeu et même de créer un niveau avec ces sprites : http://opengameart.org/content/spaceship-set-32x32px
Le concept est très bon, l'édition est facile et intuitive. L'ergonomie générale est un peu laborieuse et il y a de petits bugs de rafraîchissement, mais c'est un très beau proto!
Les améliorations que je verrais bien:
Vous devriez peut être aussi contacter shingo qui cherchait à porter son shmup pour linux: https://linuxfr.org/forums/programmationautre/posts/quel-langage-de-programmation-pour-developper-des-jeux-amateurs
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: taiste
Posté par _jordan_ . Évalué à 2.
Première approche intéressante, comme je l'ai dis dans les commentaires du forum, je trouve que les démos présentes ressemblent trop aux premiers shmup. La possibilité de faire pivoter le vaisseau en le contrôlant avec les joysticks d'une manette me semble par exemple quelque chose de beaucoup plus confortable. Ainsi on peut faire arriver les ennemis de différentes directions.
Effectivement, j'attends de voir un scripting du comportement de l'IA.
Peut être que je participerai au projet quand j'aurai un peu plus de temps.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1.
Oui, je vois ce que tu veux dire à propos du pilotage rotatif du vaisseau. Cela donne un gameplay complètement différent. Normalement, ce n'est pas trop dur à implémenter. En gros, il faut que je change la réaction du sprite du joueur lors de l'appui sur une touche et que j'ajoute un paramètre dans les niveaux pour choisir le type de gameplay.
Ce type de gameplay est d'ailleurs particulièrement intéressant si on fait des niveaux qui ne sont pas simplement rectangulaires mais recouvrent une surface qu'on peut explorer aussi bien en longueur qu'en largeur. Mais ça, par contre, c'est une modification nettement plus lourde étant donné le code actuel de Flukz.
[^] # Re: taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Vous avez un moyen pour vous suivre facilement? flURSS, tribune?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1.
A quoi tu penses plus précisément ?
A priori, il y a juste la liste des "modifications récentes" directement dans Flukz.
[^] # Re: taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Suivre les news du développement, par exemple "coucou, on a implémenté cette nouvelle friture", "attention le format va changer", "on cherche des testeurs pour la dernière release", etc…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1.
Je viens de créer une page "Nouveautés" dans Flukz. J'y listerai les principaux changements du code au fur et à mesure, comme ça, les personnes qui le souhaitent pourront se faire une idée des développements en cours.
[^] # Re: taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
http://flukz.org/wiki/doku.php?id=nouveautes&do=backlink ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1. Dernière modification le 26 février 2013 à 13:20.
Mmh, non, pas sur le web, dans le logiciel lui-même :-)
Au fait, au cas où tu n'aies pas vérifié depuis, le niveau que tu avais commencé a pas mal progressé depuis.
[^] # Re: taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Arg. Tu n'as pas un flURSS plutôt? Lancer le logiciel tous les jours, ça ne va pas le faire :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1.
Oui, c'est pas faux. En fait, il y a un flux rss pour le site web classique : http://flukz.org/wiki/feed.php . Je créerai demain une page "news" sur le wiki classique pour y faire des annonces de nouvelles fonctionnalités ou de nouvelle release, et comme ça elles seront visibles dans le flux rss du site.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1.
J'ai créé une section "news" sur la page principale du wiki classique. J'y ferai les annonces des principaux changements du code ou du contenu des niveaux (par exemple, une annonce quand on atteindra 10 niveaux de jeu), et normalement elles seront visibles dans le flux rss.
[^] # Re: taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Merci!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: taiste
Posté par Yukito (site web personnel) . Évalué à 1.
Ah, c'était toi :-). Merci d'avoir pris le temps de tester. Je réponds à tes différentes suggestions :
(et je vais essayer de contacter shingo, peut-être que ça peut l'intéresser, effectivement)
[^] # Re: taiste
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
A côté comme dans la plupart des designers:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# RMLL
Posté par MCMic (site web personnel) . Évalué à 2.
Comme tu as un concept über original et qu'il y a un thème jeu-libre aux RMLL 2013, n'hésite pas à proposer une conférence pour présenter ton concept : http://2013.rmll.info/fr/ac.html (le lien vers le formulaire est tout en bas de la page)
[^] # Re: RMLL
Posté par Yukito (site web personnel) . Évalué à 1.
Merci pour l'info. Malheureusement, je suis très loin (au Japon), et du coup, faire le déplacement est difficile. Mais je garde l'idée dans un coin, pour l'an prochain peut-être.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.