Il y a plusieurs choses qui rendent le développement et la diffusion de jeux libres différent du développement d'autres logiciels, je dirais même que c'est plus difficile. On ne demande pas la même chose à un utilitaire qu'à un jeu. Le premier doit faire son boulot, et le faire bien. Le second doit nous faire plaisir.
Un utilitaire peut être intéressant même si il est incomplet. Une version 0.1 est déjà utilisable, il ne reste qu'à y ajouter des fonctionnalités. De plus, ce développement se marie bien avec les contributions de la communauté. Il n'y a pas ou peu d'ordre dans les tâches à accomplir et le cahier des charges tient en une ligne : "Le programme X sert à faire un truc."
Du coté des jeux, je distingue deux catégories. D'une part les jeux sans scénario, une série de niveaux dont l'ordre n'a pas d'importance si ce n'est une augmentation de la difficulté (jeu de course, puzzles). On y joue de temps en temps et ça roule. Là, il y a une similarité avec les utilitaires.
D'un autre coté, il y a les jeux scénarisés. Ici, il n'y a pas d'état "fonctionnel" tant que le jeu n'est pas terminé car le cahier des charges inclus une histoire complète. Avoir un jeu avec 5 des 10 niveaux, sans finalité, ce n'est pas mieux que ne rien avoir. Les contributions des utilisateurs dans ce cas me semblent plus difficiles.
De plus, il y a un vrai problème de style dans les jeux libres. Ils sont laids ou font intervenir des manchots, ils ont une musique désagréable. On sent que les développeurs ont aimé développer leur jeu, mais qu'il manque une équipe artistique. Or, la première chose qui saute au yeux quand on lance un logiciel, c'est bien le look. Ensuite, ça ne doit pas être désagréable d'entendre la musique. Enfin, une fois ces deux étapes passées, il reste le gameplay. Il faut que ça soit fun et agréable.
De plus, la sélection des contributions me semble plus contrainte. S'il est facile de suivre un style de programmation, c'est beaucoup plus difficile de suivre un style graphique ou sonore. Aussi, les contributions doivent suivre la ligne scénaristique, il y a moins de libertés sur la créativité, moins de "tiens je vais ajouter ça, ça sera cool."
Pour finir, les logiciels utilitaires que nous utilisons seront toujours
améliorables, et on sera toujours plus satisfait d'eux. Alors que lorsque l'on a terminé un jeu, c'est terminé. On y rejouera par nostalgie et on finira par le supprimer.
Il y a eu un autre Windows qui était trop bien : Windows ME.
Bon, d'accord, il a été remplacé par XP un an après sa sortie. Mais c'était marrant quand même de voir des gens se précipiter à mettre ME parce que c'est trop cool, et se plaindre aussitôt que "argh ! encore planté !"
D'ailleurs, pour citer un résumé affiché par Google en cherchant Windows ME :
Microsoft Windows Me
Start here when Microsoft Windows Millennium Edition is not working how you expected.
support.microsoft.com/ph/6519
À votre avis, combien de temps avant que Windows Vista ait le même résumé ?
Et bien justement, nous avons fait des modifs pour que ça compile sur 64 bits et on cherches des gens pour nous confirmer que ça marche bien.
Ça à l'air de fonctionner actuellement (texté sur deux machines), mais nous voudrions avoir un peu plus de tests pour être sûrs. Dès qu'on aura eu deux ou trois bons retours supplémentaires, on refera une archive source.
Si quelqu'un est intéressé pour tester, n'oubliez pas de prendre le code source sur svn.
Je ne m'attendais pas à ce que vous remarquiez si vite que la physique est moyenne :)
On a eu beaucoup de mal à faire la physique, notamment du fait que les formules de cinétique fonctionnent bien avec du temps continu, mais c'est plus difficile à gérer avec le temps discret dans le jeu.
En fait on avait réussi à avoir un rendu crédible, mais dans la réalité un type de 100 kg ne saute pas très haut (genre deux pixels).
En tout cas nous notons vos remarques. Il faudra qu'on corrige ça pour la prochaine release :)
Tout d'abord, merci pour vos commentaires, ça fait plaisir d'avoir des retours.
Contrairement à ce que dit la dépêche, ce n'est pas la version finale du jeu qui sortira pas dans quelques mois, mais plutôt une première release pour l'éditeur de niveaux.
Pour le reste, je fais une petite réponse rapide pour tout le monde :
mcben :
Les graphistes sont indiqués sur le site, le wiki et le générique de fin. Il s'agit de Julien Lassalle, David Michineau et moi même. Il n'y a pas de fil rss pour le projet, on ne produit pas beaucoup de news en fait alors je ne sais pas si ça vaut le coup. Par contre il y a le wiki qui est assez vivant en période de développement.
Olivier :
Pour le rpm, nous n'avons pas de Mandriva sous la main, donc pas de rpm, désolé.
Sébastien :
Malheureusement ça ne compile pas sur une 64 bits, au moins parce qu'on a mis des "unsigned int" là où on aurait du mettre des size_t :( Nous essayons de résoudre le problème (réessayez en prenant le source sur svn), mais c'est pas facile sur nos machines 32 bits.
# différence de finalité
Posté par Julien Jorge (site web personnel) . En réponse au journal interrogation philosophique. Évalué à 2.
Un utilitaire peut être intéressant même si il est incomplet. Une version 0.1 est déjà utilisable, il ne reste qu'à y ajouter des fonctionnalités. De plus, ce développement se marie bien avec les contributions de la communauté. Il n'y a pas ou peu d'ordre dans les tâches à accomplir et le cahier des charges tient en une ligne : "Le programme X sert à faire un truc."
Du coté des jeux, je distingue deux catégories. D'une part les jeux sans scénario, une série de niveaux dont l'ordre n'a pas d'importance si ce n'est une augmentation de la difficulté (jeu de course, puzzles). On y joue de temps en temps et ça roule. Là, il y a une similarité avec les utilitaires.
D'un autre coté, il y a les jeux scénarisés. Ici, il n'y a pas d'état "fonctionnel" tant que le jeu n'est pas terminé car le cahier des charges inclus une histoire complète. Avoir un jeu avec 5 des 10 niveaux, sans finalité, ce n'est pas mieux que ne rien avoir. Les contributions des utilisateurs dans ce cas me semblent plus difficiles.
De plus, il y a un vrai problème de style dans les jeux libres. Ils sont laids ou font intervenir des manchots, ils ont une musique désagréable. On sent que les développeurs ont aimé développer leur jeu, mais qu'il manque une équipe artistique. Or, la première chose qui saute au yeux quand on lance un logiciel, c'est bien le look. Ensuite, ça ne doit pas être désagréable d'entendre la musique. Enfin, une fois ces deux étapes passées, il reste le gameplay. Il faut que ça soit fun et agréable.
De plus, la sélection des contributions me semble plus contrainte. S'il est facile de suivre un style de programmation, c'est beaucoup plus difficile de suivre un style graphique ou sonore. Aussi, les contributions doivent suivre la ligne scénaristique, il y a moins de libertés sur la créativité, moins de "tiens je vais ajouter ça, ça sera cool."
Pour finir, les logiciels utilitaires que nous utilisons seront toujours
améliorables, et on sera toujours plus satisfait d'eux. Alors que lorsque l'on a terminé un jeu, c'est terminé. On y rejouera par nostalgie et on finira par le supprimer.
[^] # Re: Vista, la meilleure raison de passer à linux
Posté par Julien Jorge (site web personnel) . En réponse au journal Vista c'est vraiment un OS rigolo :). Évalué à 1.
Bon, d'accord, il a été remplacé par XP un an après sa sortie. Mais c'était marrant quand même de voir des gens se précipiter à mettre ME parce que c'est trop cool, et se plaindre aussitôt que "argh ! encore planté !"
D'ailleurs, pour citer un résumé affiché par Google en cherchant Windows ME :
Microsoft Windows Me
Start here when Microsoft Windows Millennium Edition is not working how you expected.
support.microsoft.com/ph/6519
À votre avis, combien de temps avant que Windows Vista ait le même résumé ?
[^] # Re: À quand un ours sur la giraffe ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Plee The Bear sort de sa tanière et ça va faire mal !. Évalué à 2.
Ça à l'air de fonctionner actuellement (texté sur deux machines), mais nous voudrions avoir un peu plus de tests pour être sûrs. Dès qu'on aura eu deux ou trois bons retours supplémentaires, on refera une archive source.
Si quelqu'un est intéressé pour tester, n'oubliez pas de prendre le code source sur svn.
[^] # Re: La bête
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Plee The Bear sort de sa tanière et ça va faire mal !. Évalué à 1.
On a eu beaucoup de mal à faire la physique, notamment du fait que les formules de cinétique fonctionnent bien avec du temps continu, mais c'est plus difficile à gérer avec le temps discret dans le jeu.
En fait on avait réussi à avoir un rendu crédible, mais dans la réalité un type de 100 kg ne saute pas très haut (genre deux pixels).
En tout cas nous notons vos remarques. Il faudra qu'on corrige ça pour la prochaine release :)
[^] # Re: COmpile pas chez moi
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Plee The Bear sort de sa tanière et ça va faire mal !. Évalué à 2.
C'est vrai qu'on s'est un peu loupés là dessus. Pour lancer le jeu il faut taper "ptb"
ou plee-the-bear -g=/usr/local/share/plee-the-bear/game_description
[^] # Re: COmpile pas chez moi
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Plee The Bear sort de sa tanière et ça va faire mal !. Évalué à 2.
Tout d'abord, merci pour vos commentaires, ça fait plaisir d'avoir des retours.
Contrairement à ce que dit la dépêche, ce n'est pas la version finale du jeu qui sortira pas dans quelques mois, mais plutôt une première release pour l'éditeur de niveaux.
Pour le reste, je fais une petite réponse rapide pour tout le monde :
mcben :
Les graphistes sont indiqués sur le site, le wiki et le générique de fin. Il s'agit de Julien Lassalle, David Michineau et moi même. Il n'y a pas de fil rss pour le projet, on ne produit pas beaucoup de news en fait alors je ne sais pas si ça vaut le coup. Par contre il y a le wiki qui est assez vivant en période de développement.
Olivier :
Pour le rpm, nous n'avons pas de Mandriva sous la main, donc pas de rpm, désolé.
Sébastien :
Malheureusement ça ne compile pas sur une 64 bits, au moins parce qu'on a mis des "unsigned int" là où on aurait du mettre des size_t :( Nous essayons de résoudre le problème (réessayez en prenant le source sur svn), mais c'est pas facile sur nos machines 32 bits.
Merci pour vos commentaires,
Julien