Hum, vu que cette zone est pas très très... active...
Je me disais que peut être certains d'entre vous auraient envie qu'on fasse
un petit projet commun OpenSpace. Genre un petit logiciel, un jeu, ...
N'importe... histoire de mettre un peu d'animation ici

Votre avis?

Ami Julien, à la base, c'est un peu au modo de la zone d'animer sa zone, de lancer des discussions, de parler d'articles qu'il a lu/vu etc ...

Quant à une idée de projet, oui pourquoi pas, même si je dois avouer que mes dons de codeurs, je les utilise (trop) à mon boulot.

Un petit logiciel, oui pourquoi pas, encore faut-il une idée derrière

Vous n'avez qu'à créer un module de corrections orthographiques ( et peut-être grammaticales ) pour OpenSpace.
non ?

Hehe, c'est pas une mauvaise idée ça

Ouais, ou pkoi pas un petit jeu multi plateforme ? (bon ok, je range QNX dans mon tiroir, oubliez ce que j'ai dit )

un logiciel de visu en 3D de la bdd du forum ?

un truc réaliste je pense ..... faire un concurent de trrillian en Java (ou tcl/tk ou python...) portable facilement sous tous les os

Ah oui une sorte de chat pour le forum (comme il y avait avant dans l'ancienne version du forum), ça c'est un projet qui rulez bien des ciboulettes ça !

par le port 80 ou 8080 alors ...
( y a certains firewall qui sont un peu paranos par icic ... )

oui, malheureusement, c'est souvent le problème auquel on est confronté lors de la creation de système de chat. L'utilisation dui port 80 semble effectivement une bonne solution ... sauf quand un serveur squatte déjà le port, meme dilème avec le port 8080 vis à vis de tomcat, va falloir se creuser les méninges chers messieurs

ben, apache accepte les plugins ?

Pourquoi pas un gateway :
php [openspace] <-> Passerelle IRC <-> Serveur IRC

Si les sockets en php sont activés et qu'on peut héberger un serveur passerelle quelque part c'est jouable. Par contre ca veut dire interface web.

Y'a aussi possibilité de chercher un serveur libre quelque part et de coder un proxy http->irc .

j'avais codé une truc similaire y'a pas si longtemps de ca, j'avais ouvert un compte à peterpan pour qu'il essaie. C'etait loin d'etre parfait, mais ca avait le don fonctionner

Pas bête come idée, par contre je suis limité pour tout ce qui est dev web ;-)

En ce moment je m'autoforme aux opérations bitmap rapides (si j'ai le courage avec DirectX) en réalisant un soft de traitement d'image pour la télédétection.

QUOTE (Sha @ 23/04/2003 17:59)

Pas bête come idée, par contre je suis limité pour tout ce qui est dev web ;-) En ce moment je m'autoforme aux opérations bitmap rapides (si j'ai le courage avec DirectX) en réalisant un soft de traitement d'image pour la télédétection.

Télédétection? Traitement d'images? Heu...j'ai 2/3 idées de choses que j'aimerai essayer avec des images de modélisation de houle...

Tenez, voilà une base de travail :



perso, je vois pas du tout l'interet de modeliser un truc pareil

CODE

package org.nature.sea; /* * MytilusEdulis.java * * Created on 24 avril 2003, 11:40 */ import org.nature.Sex; /** La moule. * @author Pop */ public class MytilusEdulis extends org.nature.sea.Unionides.Eulamellibranches.Bivalves{        private Sex sex_;    private int age_;        /** Creates a new instance of MytilusEdulis */    public MytilusEdulis() {        super();    }        /** Creates a new instance of MytilusEdulis     * @param sex Sex.     * Sexe de la moule.     * Très important si on veut qu'elle se fasse fister par une autre moule.     * @param age int.     * Age de la moule.     * Très important car passé un certain âge MytilusEdulis n'hérite plus de org.nature.sea.Unionides.Eulamellibranches.Bivalves mais de org.nature.earth.Carnivores.Felides.Felis     */    public MytilusEdulis(Sex sex, int age){        setSex(sex);        setAge(age);    }        private Sex getSex(){        return sex_;    }    private int getAge(){        return age_;    }    private void setSex(Sex sex){        sex_=sex;    }    private void setAge(int age){        age_=age;    } }

hum, t'as oublié une variable, celle de la sécrétion de la moule

LOL ca change de l'humour des newbies ca

QUOTE

private Sex getSex(){       return sex_;   }

Me fera toujours béer devant tant de simplicité

QUOTE (RICO @ 24/04/2003 11:58)

hum, t'as oublié une variable, celle de la sécrétion de la moule

T'inquiètes, j'ai fermement l'intention de modéliser une moule, et bien comme il faut. Je vais faire ça avec l'aide d'un pote thésard en bio. Fear le projet fonfon!

A propos de mon projet de traitement d'image, j'avance pas mal et je suis en train d'ajouter un paquet de filtres et manipulations diverses. Si vous avez des idées (si possible accompagnées d'algos) d'ajouts, notamment les photographes, n'hésitez pas, je filerais le soft en SPL (Sha public license : vous pouvez tout faire du moment que vous ne me citez pas ;-))

Etant donné l'intérêt de pas mal de membres pour les Jeux de Rôle, je me demandais si ça ne pourrait pas être une bonne idée de coder un logiciel permettant d'y jouer en ligne. Voilà comment je vois les choses :

• un logiciel serveur chez le Maître de Jeu qui lui permettrait de gérer la partie, du suivi du scénario (par exemple dans une fenêtre de texte avec possibilité d'ajouter des repères pour différents points importants) aux lancers de dés, etc.
  
• un logiciel client chez chaque joueur qui se connecterait donc au serveur, gèrerait le personnage du joueur, ses lancers de dés, etc.
  
• le logiciel utiliserait évidemment un module de chat sur lequel se déroulerait la partie, ce module intégrant différentes fonctions relatives au jeu et non présentes par défaut sur IRC par exemple,
  
• possibilité de skinner le logiciel,
  
• pourquoi pas la possibilité de se connecter à une base de données de monstres, vaisseaux, etc sur Internet permettant de récupérer une petite image et la description,
  
• le plus important à mon avis : le logiciel serait une simple base sur laquelle viendraient se greffer des plugins ajoutant un support spécifique à un jeu (génération de personnage, dés utilisés dans le jeu, dégats, trésors, etc), à un univers ou même à un scénario donné.

Voilà, bien entendu c'est assez vague pour le moment, ça ne demande qu'à être mieux défini.

Mmm...ça me plait ça.

Yes !

C'est un truc intéressant comme idée !
Si j'ai bien compris l'idée des plug-ins : Le "jeu de base" permettrait de jouer dans un style de jdr, mais avec les "plug-ins" associés, le monde pourrait être complètement différent. ( ie : de base par exemple AD&D et avec le plug-in adapté, "Shadowrun" ).

Questions :
les PNJ : qui les gèrent ?
Jeu persistant ou pas ?
Une idée de langage ?

Mmm, en fait je pensais que le logiciel "de base" incluerait juste le module de chat, les fonctions de lancer de dés et le support des skins par exemple. Les jeux en eux-mêmes seraient supportés grâce aux plugins mais effectivement peut-être faudrait-il envisager différents niveaux de plugins ? Un plugin général AD&D et des plugins Royaumes Oubliés et autres ?

L'idée des plugins est bien évidemment de faire un système très ouvert pouvant potentiellement supporter tous les jeux existants ou à venir.

Pour les PNJ a priori c'est le MJ qui les gère. Qu'entends-tu exactement par jeu persistant ? Pour le langage il faudrait quelque chose qui soit multi-plateformes non ? Ou est-ce qu'il serait possible de le faire disons en PHP de manière à ne pas avoir à installer quoi que ce soit et utiliser un serveur Web avec gestion des droits (si droit=MJ alors il aura accès à l'interface de gestion du jeu, si droit=joueur alors interface de gestion de personnage) ?

en php, je peux éventuellement mettre la main à la pâte, ca serait assez fandart =)

je pense qu'il est nécessaire de fournir le minimum requis pour que l'ensemble fonctionne : chat, dés, skin(s), univers(AD&D), règles, création de perso, etc...

jeu existant ou à venir ? Tu penses à "c0nnard 462, le jeu d'rôle d'OpenSpace" ?

Il serait intéressant de faire gérer les PNJ par le serveur ... un peu d'intelligence pour ces PNJ que diable ! Et puis un meneur de jeu n'as pas forcément que les PNJ en tête... non ?

jeu persistant : si t'es pas connecté, ben tu existe encore dans le jeu ...
jeu non persistant : si t'es pas connecté, on ne peut pas te "tuer" ...

Pour le langage, multi-plate forme : c'est possible de faire ça via le web ( PHP / ASP / javascript ), mais je penses qu'il serait appréciable de déporter "la charge" du jeu sur les clients aussi... JAVA, non ?
------------------------
Par contre, si c'est du PHP, comme RICO, je peux mettre la main à la pâte !

En ce qui concerne le "minimum requis pour que l'ensemble fonctionne", rien n'empêche de fournir un plugin AD&D et un Star Wars (par exemple) dans le pack de base.

Pour ce qui est de la gestion des PNJ, il faut voir ce qu'il est possible de faire, et définir précisémment tout ça.

Pour le jeu persistant, à la base je pensais simplement à un jeu comme "en vrai", c'est-à-dire que la partie a lieu quand tout le monde est là, est en pause si tout le monde s'en va ou qu'un joueur quittant la partie n'est plus présent dans le jeu.

Pour le langage, plus j'y pense et plus le PHP me semble intéressant étant donné que beaucoup de gens l'utilisent sur leurs serveurs (pensont aux exportations vers d'autres sites que OpenSpace), que ça permettrait de ne rien avoir à installer chez soi, que l'on pourrait y jouer derrière un firewall (mais pas au boulot, bien sûr ), etc.

Ah mais moi aussi ça me botte.

En php j'ai toutefois peur qu'on soit trop limité. Je pense plutôt à un double moteur : un en php, et un en un autre langage qui permettrait des parties en "live" qui partageraient les même normes, normes qui inclueraient les règles, les feuilles de perso, les ressources...

QUOTE

Pour le jeu persistant, à la base je pensais simplement à un jeu comme "en vrai", c'est-à-dire que la partie a lieu quand tout le monde est là, est en pause si tout le monde s'en va ou qu'un joueur quittant la partie n'est plus présent dans le jeu.

Oui sinon on code un mud quoi.

Dans quel sens limité ?

QUOTE (Guepi @ 22/05/2003 15:04)

Dans quel sens limité ?

Dans le sens confort d'utilisation et d'interface d'une part, obligation de fonctionner en mode "déconnecté", ce qui amènera forcément à quelques approximations, ...

QUOTE

(mais pas au boulot, bien sûr ), etc.

Et merde.....

C'est une idée tres sympa en effet

mais pourquoi ne pas dans un premier temps partir sur une base de plug pour Mirc par exemple, et une fois tout les rouages fonctinnants, partir sur un systeme de chat avec multiple connect, skins etc...

Fistez moi si je dis une connerie....

QUOTE (Darko @ 22/05/2003 15:19)

Fistez moi si je dis une connerie....

Par plaisir aussi on peut ?

QUOTE (Darko @ 22/05/2003 16:19)

QUOTE (mais pas au boulot, bien sûr ), etc. Et merde..... C'est une idée tres sympa en effet mais pourquoi ne pas dans un premier temps partir sur une base de plug pour Mirc par exemple, et une fois tout les rouages fonctinnants, partir sur un systeme de chat avec multiple connect, skins etc... Fistez moi si je dis une connerie....

/me fiste Darko


Sérieusement, pourquoi se limiter dès le départ ?
Un programme de Chat basique, c'est très simple à faire.

Voui, voilà. Et puis au delà de l'intérêt intrinsèque du programme il faut aussi que ça puisse être intéressant au niveau de son développement. Là on pourrait toucher à la fois à la communication instantanée, à la gestion des plugins, des skins et pourquoi pas des bases de données. Et je pense qu'il est important de fournir un outil "stand alone" qui ne nécessite donc pas l'utilisation d'autres logiciels.

Ca me botte aussi pas mal =) Mais mes compétences sont limitées (voire inexistantes) dans le domaine de la prog. réseau.

Ca m'interesse aussi. Sous QNX of course mais bon, ca tombe bien, je suis en train d'apprendre je suis 100% partant pour ma part, on commence la phase de definition quand ?

Ha après je vous laisse le bébé, je ne suis pas développeur et je n'ai pas la moindre idée de la manière de gérer un projet. Il faudra probablement passer par SourceForge ?

Ce n'est pas forcément nécessaire de passer par SourceForge, et je pense que tous les avis sont bons ... même et surtout de la part de non-développeurs !

La prochaine étape, c'est : Le Cahier des Charges
Après ce cahier ( lu et approuvé ), c'est : le Cahier des Fonctionnalités !
Après, seulement, c'est la phase de programmation.

c seulement sur le net? remarque les premiers jeux de role utilisaient que le texte...

Cahier des charges, Specs fonc, spec tech, planning de prod, ressources managing...argh...nan...pas ça!

PoP > t'es au chômage t'as plein de temps libre

Ouais mais bosser avec un pro ça fait trop mal

QUOTE (Sha @ 22/05/2003 19:56)

Ouais mais bosser avec un pro ça fait trop mal

Sha > Tu parles de qui ?

Pop > merci de te proposer
Alors, chef de projet ?

Guepi> De personne en particulier, ça me fait grave honte, c'est tout =)

Sha > je croyais que tu pensais que Pop est un pro ...
je suis rassuré ...

Pop

QUOTE (Sha @ 22/05/2003 21:46)

Guepi> De personne en particulier, ça me fait grave honte, c'est tout =)

grosse erreur, il ne faut pas avoir honte de soi parce qu'on ne sait pas faire quelque chose, l'important c'est d'en être conscient et de vouloir apprendre! regarde moi et mon topic en html, meme pas honte

A la limite je peux essayer de bosser sur des skins pour la mise en place de l'engin, parce qu'en prog me suis arreté au Basic du TO7-70....

QUOTE

Cahier des charges, Specs fonc, spec tech, planning de prod, ressources managing

Mais il manque encore quelques trucs : les contrats d'interfaces techniques, les M.E.P (manuels de mises en prod), guides d'utilisateurs, specs fonctionnelles détaillés, les contrats tout court (c'est bien connu on ne démarre pas quelquechose sans avoir signer)

Tout cela serait bien sûr incomplet sans une équipe : chef de projet, chef de groupe, manager, commerciaux (pour assurer la promotion), développeurs, architectes techniques, sponsors, un directeur technique, des exploitants (un fois la mise en prod réalisée, of course), des directeurs de personnel, directeur du groupe demande ponctuelle (dans le cas de problème), le groupe de correction d'anomalie, chargé de corriger les différents bugs etc ...

Je vous propose de fixer une première réunion visant à nommer nos différents intérvenant (dont le ICRT, intervenant de compte rendu technique).

IAfin de tester la solidité de l'appli, nous procéderons également, d'un commun accord, à des tests de charges afin de juger
de la solidité et de l'éfficacité. Ces tests commenceront d'ici deux mois, ce qui impliquent que les développements commenceront au plus tard, d'ici une semaine.

...

Oh et puis non, ça me rappellerait trop le boulot, finalement.