Nous avons gardé le mode réseau et l'intelligence artificielle sur la Todo List pour ceux qui souhaiteraient s'y intéresser.
Si le jeu avance, nous avons cependant besoin de vous : en effet, nous sommes actuellement 4 développeurs / graphistes actifs, ce qui est plutôt juste !
Toutes les bonnes volontés sont donc acceptées !
Cela peut-être pour vous l'occasion de découvrir la programmation avec ClanLib ou tout simplement de passer un bon moment avec le jeu et nous faire part des améliorations qui vous feraient plaisir. Depuis la version 0.5, beaucoup de travail a été fait pour sortir la version 0.6 beta1 :
- plein de nouvelles armes : uzi, corde ninja, jetpack, marteau pneumatique, low gravity, parachute, supertux, gnou fou, sainte grenade
- nouvelle interface
- réécriture du moteur physique
- création d'un moteur de particules de fumée, d'explosion
- ajout de particules en arrière plan du décor
- réécriture de la boucle de jeu
- amélioration de l'occupation mémoire
- personnages et cartes plus jolis (enfin, on l'espère ;-)
- ...
Comme indiqué, le mode réseau et l'intelligence artificielle, ce sera pour bientôt, avec votre aide.
Toutes les bonnes volontés sont donc acceptés pour participer à la réalisation de la version 0.6 :
- de nouvelles cartes
- la conception des futures armes
- des sons ! il en manque notamment pour le vol du supertux, des nouveaux profils par équipes, etc.
- la mise à jour du site web et des documentations
- du développement ;-) : nouvelles armes, réseau, intelligence artificielle, ...
- traductions
- ...
Aller plus loin
- Site officiel du jeu (3 clics)
- Télécharger la version 0.6 beta1 ou CVS (1 clic)
- Liste des tâches (2 clics)
- Liste des bugs (1 clic)
- Guide pour s'impliquer dans le développement (1 clic)
# Clanlib
Posté par pef . Évalué à 7.
[^] # Re: Clanlib
Posté par Snark_Boojum . Évalué à 6.
Il ne faut pas jeter le bébé avec l'eau du bain...
Snark sur #gnomemeeting
[^] # Re: Clanlib -> Portage vers SDL
Posté par gentildemon . Évalué à 10.
Clanlib fournit une API sympathique mais le code derrière est pas très stabilisé... Si la version 0.6 de ClanLib était bien, la version 0.7 manque clairement de stabilité, certaines fonctions sont déclarées mais se contentent de faire un return 0
Je pense que le portage nous fait tous un peu peur, mais vu l'avenir de Clanlib, c'est préférable.
[^] # Re: Clanlib -> Portage vers SDL
Posté par encre (site web personnel) . Évalué à 3.
<ma_vie>
Pour info je voulais faire tourner wormux sous OS X, j'avais déjà commencé à patcher clanlib pour avoir un truc un peu plus propre quant au configure sous OS X (et puis avoir les bons .pc pkgconfig, et autres). Bon bein je vais jeter tout ça ;)
</ma_vie>
[^] # Re: Clanlib -> Portage vers SDL
Posté par gentildemon . Évalué à 4.
T'as du bien t'amuser avec clanlib, quand on voit que la release 0.7.8 compile pas sans éditer certains fichiers pour supprimer des #include ...
Tu es le bienvenu si tu veux nous aider pour le portage, au moins en testant sous OS X puisque SDL est vraiment multiplateforme.
[^] # Re: Clanlib -> Portage vers SDL
Posté par CrEv (site web personnel) . Évalué à 4.
Tiens, c'est peut-être pour ça que j'arrive pas à faire un rpm de la version cvs...
Il me sort un problèmes avec /usr/include/ClanLib-0.7/ClanLib/Network/IRC/dcc_download.h
M'enfin, j'ai hate de tester ;)
[^] # Re: Clanlib -> Portage vers SDL
Posté par Mildred (site web personnel) . Évalué à 3.
Quelle est alors la pertinence de HappyBoom ? Si si je comprend bien a été développé suite a un raz le bol de c++ et de la clanlib ?
Surtout que SDL, c'est en C tout simple, non ?
en plus pygame utilise SDL, il me semble ...
le journal: http://linuxfr.org/~gentildemon/19173.html(...)
explication HappyBoom: http://linuxfr.org/comments/615488.html#615488(...)
sinon, je veux bien aider pour faire des pages web du site wormux mais je connais encore très mal wormux alors ...
je vais tenter de voir ce que je peux faire.
[^] # Re: Clanlib -> Portage vers SDL
Posté par gentildemon . Évalué à 4.
Ça ne nous obligent pas pour autant à réécrire tout le code comme de réécrire en python.
Pour Happyboom, je ne sais, après c'est aussi une question de motivation de personnes et de nombre, personnelement je me vois pas tout réécrire de zéro.
[^] # Re: Clanlib -> Portage vers SDL
Posté par kynou . Évalué à 2.
J'ai un Zaurus (PDA sous Linux) et je serai tenter de faire un portage dessus (Wormus dans le metro... trop cool) avec SDL ça devient possible.
J'ai zieutter un peu Happyboom...
Je préfere de loin le Python au C/C++ (aaahhh.... les goûts et les couleurs....) mais il est vrai que réecrire tout en Python risque de prendre du temps surtout que pour Happyboom la conception est un peu différente c'est donc plus qu'une simple réécriture... et apparement ils ne sont que deux...
mais bon... tout n'est que question de motivation...
[^] # Re: Clanlib -> Portage vers SDL
Posté par tgl . Évalué à -2.
Parcequ'il est sous Linus ton metro ?... trop cool :)
[^] # Re: Clanlib -> Portage vers SDL
Posté par timid . Évalué à 2.
Personnellement, Clanlib 0.7.8, compile nickel chez moi (sauf sous windows, mais là c'est une autre affaire !)
La 0.9 qui est sur le SVN compile pas par contre
Pour ce qui est de SDL, j'ai déja développé avec les deux librairies et je trouve clanlib beaucoup plus sympathique à utiliser et beaucoup plus complète, même si elle est un peu leakée et que certaines fonctions ne sont sont pas encore implémentés (celà dit, je ne suis jamais tombé sur une fonctionnalité non implémentée de clanlib qui existe dans SDL)
Après, le projet a l'air un peu mort, mais je ne sais pas trop ce qui en est, et puis SDL non plus n'évolue plus depuis presque 2 ans maintenant (il suffit de voir les dernières dates de mise à jour du CVS)
[^] # Re: Clanlib -> Portage vers SDL
Posté par durandal . Évalué à 4.
[^] # Re: Clanlib -> Portage vers SDL
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Je suis content pour toi, tu fais parti des 1% des gens qui ont réussi la compilation (et utilisaton) de ClanLib sans problème. Les autres ont divers problèmes. Il faut recompiler ClanLib à la main car il n'existe AUCUN paquet (Debian, Mandrake, ..., ah si, peut-être Gentoo, mais Gentoo, ça compile nan ? ;-)). C'est long et ça bloque à divers niveaux (dépendences par ex.). Et très souvent, ça plante encore à la fin. En particulier, les possesseurs de cartes ATI et Nvidia (hum, 90% des joueurs ?) avec pilote proprio n'ont pas l'accélération matérielle (pourtant fonctionnelle dans tous les jeux non-ClanLib), ce qui donne une image par seconde (Wormux est donc INJOUABLE).
Après, ça nous empêche techniquement de compiler Wormux sous Windows car aucun développeur n'a réussi ce challenge.
N'espérez surtout pas de compatibilité entre SDL et ClanLib, les dév. n'en ont que faire (ma tentative l'an dernier a été sabordée). Les dév. de ClanLib sont d'ailleurs très fermés et peu coopérants. Ils auraient par exemple pu tenter de stabiliser leur version 0.7 pour aider le packaging des jeux (comme Wormux). A la place, ils ont lancé une version 0.9 encore plus expérimentale :-(
Haypo (un des deux conférenciers de Game Over 2005)
# La corde
Posté par Wawet76 . Évalué à -4.
Il y a déjà eu des discutions sur l'implémentation de cette accessoire ?
Perso, je trouve la corde trop puissante dans Worms 2. Pour le gameplay, je trouve qu'elle ne devrait pas permettre de se pousser vers le haut.
[^] # Re: La corde
Posté par Wawet76 . Évalué à 0.
[^] # Re: La corde
Posté par gentildemon . Évalué à 3.
[^] # Re: La corde
Posté par Mildred (site web personnel) . Évalué à 10.
mais:
- 5 "munitions" ne sont pas suffisantes pour bien tester
- dans le Worms original, les munitions ne sont pas décrémentées lorsque tu relance la corde et que et est en l'air
- la corde est toujours lancée dans la même direction. Pas très pratique pour se déplacer
lorsqu'on balance à gauche, la corde devrait se lancer vers la gauche avec le même angle ... et lorsqu'on se balance vers la droite, la corde devrait se lancer à droite.
On peut le faire je pense en changeant le sens du joueur lorsqu'il passe d'un coté a l'autre de la verticale
d'autres trucs graphiques:
- dans WA, on a un arrière plan au terrain (cf screenshot Wikiepdia). Lorsqu'on fait exploser le terrain, l'arrière plan reste
- les grosses armes (dynamite par exemple) trouent aussi larrière plan
- les cratères sont recourvert d'une jolie couche jaune (voir screenshoot)
- les objets du terrain (palmiers, ...) n'ont pas d'arrière plan
- dans un terain en plain air, le joueur ne devrait pas mourrir lorsqu'il sort du terrain ... et on devrait pouvoir scroller avec une suffisament grande marge sur les cotés et le haut ... pour pouvoiir suivre un minimum les objets qui sortent comme les armes qu'on lance haut et les vers qui sautent haut
dans un terrain plain air, si le joueur sort sur les cotés, il devrait mourrir noyé ....
- il manque l'eau qui permet d'avoir de la marge vers le bas pour pouvoir scroller ... et mieux voir l'action
- remarque déja faite mais parfois on ne sait pas quel ver est en train de jouer car il est hors-caméra
Voila, j'espère que je me suis faite comprendre ...
Et, j'aimerais bien aider a coder tout ca mais j'ai déja pas mal de mal a comprendre le C++ ...
[^] # Re: La corde
Posté par Victor STINNER (site web personnel) . Évalué à 3.
- dans un terain en plain air, le joueur ne devrait pas mourrir lorsqu'il sort du terrain ... et on devrait pouvoir scroller avec une suffisament grande marge sur les cotés et le haut(...)
Y'a un pb de conception là. Tout ce qu'ont voit à l'écran est en fait une très grosse image (ou plutôt deux : avant et arrière-plan). Il faudrait retoucher un peu le code pour ça.
- il manque l'eau qui permet d'avoir de la marge vers le bas pour pouvoir scroller ... et mieux voir l'action
C'est pas très clair. Il y a déjà de l'eau dans Wormux (terrain Grenouilles par ex.).
- remarque déja faite mais parfois on ne sait pas quel ver est en train de jouer car il est hors-caméra
Par défaut, la caméra suit le personnage actif. Si on scrolle manuellement, il n'y a plus de "tracking". Il faut retaper "C" pour réactiver ça.
Haypo
# De beaux progrès !
Posté par Jeremy Monnet . Évalué à 3.
J'adore worms (on y joue souvent avec ma copine : ca dure 20-30 minutes, c'est sympa et pas trop prenant), et la ca pourrait presque le remplacer (en plus ca m'éviterait de rebooter pour jouer !)
Par contre c'est dommage le segfault quand on quitte ... ;-)
[^] # Re: De beaux progrès !
Posté par Wawet76 . Évalué à 10.
[^] # Re: De beaux progrès !
Posté par Mildred (site web personnel) . Évalué à 4.
[^] # Re: De beaux progrès !
Posté par Victor STINNER (site web personnel) . Évalué à 2.
ClanLib est à l'origine de nombreux problèmes, mais c'est quand même pas TOUJOURS sa faute :-) Pour le cas du segfault en quittant, la faute est partagée. ClanLib est un peu trop optimisé. Du coup, il manque deux-trois if pour les cas un peu tordus. Ici, on détruit d'abord l'objet "écran" et après les objets graphiques. Or, les objets graphiques ont besoin de l'objet écran lorsqu'ils sont détruits. Bref, ça bloque.
La faute du côté de Wormux est qu'il faudrait détruire manuellement chaque objet graphique (faire image = CL_Surface(); => objet vide, pointeur NULL à la manière ClanLib) avant de détruire l'objet écran (CL_Display::deinit() je crois bien).
D'ailleurs, Wormux a tendance à conserver trop longtemps les objets graphiques en mémoire. D'où une consommation excessive de la mémoire vidéo. Problème corrigé dans la derniè version béta si j'ai bien compris.
Haypo
# Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par gentildemon . Évalué à 3.
http://cvs.gna.org/viewcvs/*checkout*/wormux/wormux/HACKERS.fr.txt(...)
[^] # Re: Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par gentildemon . Évalué à 7.
Merci pour la remarque, je supprime de suite.
[^] # Re: Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
« We were able to search the patent databases of the USA, Canada, Japan, and the European Union. The Unisys patent expired on 20 June 2003 in the USA, in Europe it expired on 18 June 2004, in Japan patent expired on 20 June 2004 and in Canada it expired on 7 July 2004. The U.S. IBM patent expires 11 August 2006, (we are still searching the databases of other countries). »
[^] # Re: Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par Zenitram (site web personnel) . Évalué à 4.
Meilleure raison? ;-)
[^] # Re: Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par Gof (site web personnel) . Évalué à 4.
[^] # Re: Guide pour s'impliquer dans le développement en FRANÇAIS
Posté par Charles-Victor DUCOLLET . Évalué à 3.
et je ne parlerais pas du taux de compression qui ecrase le GIF en profondeur... (attention, seulement dans les meme condition... parce que 16 millions de couleurs et 256 niveau de transparence, ca peut prendre plus de place que 256 couleur dont UNE transparente...)
conclusion : le PNG c'est bien !
# En tous cas... merci
Posté par sylvain cherrier (site web personnel) . Évalué à 10.
L'année dernière, en vacances, il ne faisait pas très beau, et j'ai installé une Fedora (je crois) sur mon portable...
Et les enfants se sont fait des parties endiablées de wormux....
D'ailleurs, ca reste pour eux 'le jeu des vacances'...
Très sympa, merci à l'équipe...
# ClanLib vs SDL
Posté par Zenitram (site web personnel) . Évalué à 1.
Car les defauts de SDL, j'en ai vu quelques uns :
- Le CVS n'est pas très MAJ, ext-ce que ca continue aussi d'evoluer, ou est-ce aussi "mort" que ClanLib?
- Les fonctionnalités ont l'air moindre.
Tous ca vu de loin.
Quel est le "plus" qui fasse changer?
[^] # Re: ClanLib vs SDL
Posté par Zakath (site web personnel) . Évalué à 1.
[^] # Re: ClanLib vs SDL
Posté par timid . Évalué à 1.
[^] # Re: ClanLib vs SDL
Posté par Victor STINNER (site web personnel) . Évalué à 2.
SDL est multi-plateforme. Ce qui est loin d'être le cas de ClanLib (ex: Mac OSX, cf. quelques commentaires plus haut).
SDL est performant en 2D sans accélération matérielle. ClanLib 0.7+ oblige l'utilisation d'OpenGL (la détection de l'accélération matérielle est boguée pour les pilotes proprio d'Ati et Nvidia d'ailleurs) et est inutilisable en rendu "logiciel".
Il existe de nombreuses contributions pour SDL, comme par exemple le rendu de police TTF.
J'ai cru en ClanLib très longtemps, car l'idée est géniale : couche au-dessus de DirectX, SDL, et autre (multi-plateforme & multi-librairie graphique), API génialissime, etc. Mais le développement est très lent, donc inutilisable pour un jeu.
Haypo
# comment participer ?
Posté par Axel R. (site web personnel) . Évalué à 1.
Comment faire pour le mettre sur le serveur ?
Axel
[^] # Re: comment participer ?
Posté par gentildemon . Évalué à 2.
Sinon, si tu comptes contribuer plus régulièrement, inscris toi sur gna.org et rejoins le groupe wormux pour accéder en lecture/écriture au CVS (mais on va bientôt passer à subversion pour la version en portage).
[^] # Re: comment participer ?
Posté par Axel R. (site web personnel) . Évalué à 1.
Axel
# HappyBoom
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Je suis à l'origine du projet HappyBoom lancé en avril 2005. Le but est d'écrire un nouveau moteur de jeu qui serait utilisable pour Wormux. J'ai TOUT remis à plat, et j'ai essayé de ne plus reproduire les même erreurs :
- Langage Python plutôt que C++ : je trouve que le temps de compilation (et de débogage) est trop important avec C++. Et Python est tellement sympa
- Le jeu est découpé physique en trois partie : logique du jeu (server), entrée clavier/souris (input) et affichage (view).
- Génie logiciel : je sais pas si je vais survivre à la torture de Damien (l'autre développeur), mais on va essayer d'écrire de vrais documents de spécification AVANT de coder :-)
- Le réseau est la première chose qui a été développée (et non la dernière)
- SVN plutôt que CVS (on me dit dans mon oreillette que Wormux a aussi fait le bon choix tout récement)
Il en ressort de nombreux avantages :
- On peut écrire des clients dans de nombreux langages et avec divers librairies (ex: client en Perl utilisant GTK, client en Python utilisant pygame, etc.). J'aimerai tenter l'expérience d'être capable d'avoir plusieurs "vues" d'une même partie en texte, 2D et 3D simultanément. C'est possible pour d'autres types de jeu (Awalé, en cours de gestation), mais peut-être pas pour Wormux (trop axé sur le rendu 2D).
- On peut avoir un serveur décentralisé (serveur "dédié"), mais aussi avoir client+serveur sur le même PC
- On peut imaginer des clients "fantomes" qui ne font que visionner une partie sans interagir (pour voir une finale sur écran géant par ex.)
- Une intelligence artificielle s'intègre super facilement vu que le client envoie des actions (genre "tirer", "changer d'arme", ...) plutôt que des touches claviers. Et vu qu'en plus on peut utiliser n'importe quel langage, on peut imaginer une IA sur un PC dédié écrit en Prolog ou autre langage plus orienté IA ;-)
L'écriture d'un client est simplifiée par le fait qu'il peut ne pas gêrer toutes les fonctionnalités (ex: ignorer tout ce qui concerne le chat). On lui envoie également que le strict nécessaire. Un client "IA pure" ne recevra rien concernant le rendu à l'écran par ex. => économie de bande passante.
Aujourd'hui, HappyBoom, c'est :
- un jeu "BoomBoom" presque jouable : crée pour tester le moteur, et surtout la partie réseau (ce qui m'a obligé à passer par UDP pour garder une bonne fluidité dans le suivi d'un objet en mouvement constant)
- un site web MediaWiki
- un document de spécification version 0.2 toujours au stade de brouillon
- une marmite d'idée qui bouillone
Les deux développeurs étaient en vacances, mais ça va beaucoup s'accélérer vu qu'on va se retrouver (je prend un appart au dessus de Damien) et que j'ai enrolé un 3e développeur (à vérifier) ... J'ai pensé à un jeu Awalé, ça serait sympa ça (j'ai une idée d'IA costaux en tête). Et peut-être aussi un jeu de Dames ...
Site web de HappyBoom (on s'est fait plaisir, on s'est pris un .org chez OVH) :
http://www.happyboom.org/Accueil(...)
Pour les développeurs :
http://developer.berlios.de/projects/happyboom/(...)
Haypo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.