Balazar est sous licence GPL et est un jeu de l'association Nekeme Prod. qui a pour but de promouvoir les jeux libres. Nekeme Prod. sera présent à Solution Linux la semaine prochaine.
Tous les gens souhaitant participer à Balazar sont les bienvenus, en particulier : des programmeurs (réseau notamment), des graphistes, des musiciens, des scénaristes,... Balazar est programmé en Python et utilise Soya, le moteur 3D de Slune. Il devrait achever de convaincre les plus réticents quand à la possibilité de réaliser des jeux 3D dans ce langage ;-)
Les graphismes ont été réalisés avec des outils libres (Blender, Gimp).
Des paquets ne devraient pas tarder à arriver (Debian et Mandrake en particulier).
Pour ma part je serais à Solution Linux les 2 et 3 février et on peut me trouver sur les canaux IRC #slune et #nekeme sur le serveur FreeNode.
Aller plus loin
- Balazar (74 clics)
- Copies d'écran (30 clics)
- Le moteur Soya 3D (27 clics)
- Slune (63 clics)
- Nekeme Prod. (56 clics)
# en attendant une présentation à Game Over ?
Posté par enzodegap . Évalué à 5.
J'espère que l'on s'y croisera d'ici là.
Tu m'as convaincu qu'en à l'utilisation de Python de le développement de jeux.
[^] # Re: en attendant une présentation à Game Over ?
Posté par VACHOR (site web personnel) . Évalué à 4.
-1- On peut programmer un jeu avec un langage qui rame
-2- Ceux qui programment en python aiment les champignons
[^] # Re: en attendant une présentation à Game Over ?
Posté par MsK` . Évalué à -8.
Ce qui explique pourquoi j'aime pas python
~~> []
# Ouaih !
Posté par guix77 . Évalué à 5.
Y'a pas longtemps je passais sur le site de Balazar et les copies d'écran m'ont impressionné ! Surtout que je sais que ça devrait être *fluide* et ça même sur mon ATI 7200... puisque c'est le même moteur que Slune.
Super bonne nouvelle donc :-)
[^] # Re: Ouaih !
Posté par Wawet76 . Évalué à 9.
# euh?
Posté par Marc (site web personnel) . Évalué à 8.
http://home.gna.org/oomadness/images/balazar3.jpeg(...)
Me semble qu'il manque une lettre à "reproduction"
Remarque presque HS, mais bon, c'était ça ou rien =)
# Modeleur 3D simple
Posté par rangzen (site web personnel) . Évalué à 5.
Si par exemple on veut juste faire une épée pour aider balazar ou un niveau pour aider pywracer, blender est vraiment trop gros pour ça. J'avais très envie de jouer avec soya et c'est l'apprentissage de blender qui me bloque. Dommage.
# Félicitations !
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
Aujourd'hui beaucoup de gens disent que les jeux libres n'ont pas de réel intérêt par rapport aux jeux proposés par les boîtes de prod. Cependant, beaucoup de petites boites de développeurs ferment ou sont rachetées. L'exigence du public et des testeurs est de plus en plus élevée (qualités graphiques à l'aspect hyper réaliste, musiques digne d'un orchestre symphonique, jouabilité, intelligence artificielle, scénarios fleuves non linéaires...). Il suffit d'ailleurs de voir les "fuites" sur les consoles nouvelles génération (ps3, xbox2 etc.) avec leur futurs super disques durs et super puces pour se dire qu'il faudra bientôt (il faut déjà ?) des super-programmes et des super robots avec des super capteurs pour créer ces super jeux (en gros des jeux de la qualité des films tels que FF ou Shreck ou autres, mais.... en jeu !). D'où les prises de risque incroyables pris par les grosses boites développant des "nouveaux" jeux (Tomb Raider 24, Deus Ex 7, Myst 12).
Les développeurs de jeux imaginatifs n'ayant qu'une ou plusieurs machines, leur équipe, leur imagination et leur intelligence sont ils une espèce en voie de disparition ? Apparemment il n'existe pour l'instant que quelques alternatives : développer pour les consoles portables (technique plus abordable), développer des jeux gratuits, sharewares ou libres distribués sur le net... Pour ces 3 dernière solution, on peut utiliser des outils plus ou moins adaptés (C, flash, Java, Python etc...) qui aident considérablement.
Mais pour ne pas réinventer la roue, certains développeurs, musiciens ou graphistes nous font don d'un moteur de jeu (soya, cube...), de musiques, de modèles pour blender entre autres choses. Même si les données du jeu ne sont pas forcément libre de droits (ce qui pourraient permettre même à certains de vendre la partie "données" de leur jeu), ils peuvent s'appuyer sur ces fondations libres, c'est pourquoi je remercie vivement ceux qui y croient et qui y ont travaillé.
J'aurais juste une question après ce long post (désolé) :
Pourquoi diantre Balazar n'est-il ni sur le site de Nekeme ni celui de jeuxlibres.net (très bon site de surcroit, fait avec templeet si je ne m'abuse) ?
[^] # Re: Félicitations !
Posté par Sylvain (site web personnel) . Évalué à 10.
Je pense que cette image du langage qui rame, et di au test qui s'effectue sur des petit algorythme et le temps de start de python le flingue comparer au C.
Mais une fois les librairies chargés les perfomances sont largement honorable pour un langage à Vm.
Il te suffit d'aller sur le site de pygame de regarder l'interview du gars d'un der derniers jeux de wizard of the coast ( quand meme ) programmer en python.
Et il dit que dans tous les problemes rencontrés en aucun cas la vitesse d'execution de python etait mis en cause bien au contraire !
interview:
http://www.pygame.org/interview/stevemoret.shtml(...)
Le jeu en question:
http://www.greyhawkgame.com/(...)
Python est un langage qui rulez :)
[^] # Re: Félicitations !
Posté par spotty . Évalué à 4.
[^] # Re: Félicitations !
Posté par brunoc . Évalué à 4.
Mais c'est bel et bien une interprétation de cette forme optimisée qui est mise en oeuvre. Dans tous les cas, je ne pense pas que l'on ait à faire à une machine virtuelle : de nombreux modules de base (syslog, win32, fcntl, etc...) dépendent de l'OS sous-jacent. Ce principe est contraire au fonctionnement d'une VM. Tu me diras, Java utilise une VM et avec JNI, tu peux forker et autres unixeries. Oui.
[^] # Re: Félicitations !
Posté par Éric (site web personnel) . Évalué à 6.
> nombreux modules de base (syslog, win32, fcntl, etc...) dépendent de
> l'OS sous-jacent
Tu peux faire du virtuel avec une implémentation uniquement sur un OS ou deux. Rien n'oblige une machine virtuelle à être totalement portable. De plus le fait que le code puisse utiliser des librairies du système ne veut pas dire que lui même ne tourne pas dans une VM.
Le fait est que ce n'est pas la machine qui exécute directement le code pyc/pyo mais une pseudo machine, une machine virtuelle.
[^] # Re: Félicitations !
Posté par brunoc . Évalué à 4.
Muh ? Donc tout langage interprété est un langage à machine virtuelle, car introduisant un niveau de "virtualisation" ? Ca me parait un peu fort... J'avais plutôt l'idée d'une machine virtuelle qui encapsule totalement les supports matériels sur lesquels elle est lancée, fournissant ainsi une interface et un comportement identique pour toute implémentation, genre Java. Mais Java n'interprète-t-il pas un bytecode compilé pour sa VM ?
Bon, c'est vrai qu'au final, c'est un peu flou... Quelqu'un connait précisément les différences entre un langage interprété et un langage à VM (s'il y en a).
[^] # Re: Félicitations !
Posté par Larry Cow . Évalué à 7.
Une machine virtuelle est, comme le signale le monsieur du dessus, un programme qui simule une machine (existante ou non). Donc qui simule une architecture à base - généralement - de processeur, mémoire, registres, interruptions, etc. Les machines virtuelles Java en sont l'exemple le plus évident, mais on peut aussi citer les émulateurs de consoles/sasfépus ou certains débuggers.
Un interpréteur, strictement, est un automate qui évalue "à la chaîne" des expressions (les "instructions" du langage).
L'ambiguïté vient du fait qu'un processeur (et donc, par extension, une machine virtuelle, puisqu'elle en simule un) peut être assimilé à un interpréteur: il "éxecute" en effet des instructions à la chaîne. La différence majeure tenant, à mon sens, dans le niveau d'abstraction pratiqué. Un interpréteur travaille généralement avec des données de haut niveau (idéalement: des maths) qu'il _évalue_. Une machine virtuelle travaille généralement sur des données plus proches de celles que manipulerait une vraie machine (notamment dans le cas des émulateurs, mais la VM Java n'est pas si éloignée que cela d'une machine réelle, si on excepte sa quantité "faramineuse" (potentiellement infinie, en fait) de registres).
Bref, j'espère que j'ai pas trop dit de conneries.
[^] # Re: Félicitations !
Posté par brunoc . Évalué à 1.
[^] # Re: Félicitations !
Posté par TeXitoi (site web personnel) . Évalué à 5.
En fait, la JVM n'est pas une machine à registre, mais une machine à pile : quand on fait un appel a une fonction par exemple, on empile les args et on fait appelle à la fonction. Ca fait que c'est en fait vachement facile de programmer en "assembleur java" (voir jasmin : http://jasmin.sourceforge.net/(...) )
[^] # Re: Félicitations !
Posté par Yusei (Mastodon) . Évalué à 6.
En fait, ta définition d'une machine virtuelle est en réalité la définition d'une interface, et elle s'applique à n'importe quel traducteur d'un langage vers un autre. Quand on programme dans un langage, même en C, on se fiche de savoir si la machine sur laquelle le programme sera exécuté est réellement ce qu'elle semble être. La seule chose importante est que le compilateur ou l'interpréteur fait en sorte que l'implémentation réelle de la machine nous soit invisible, et que la machine semble donc se comporter comme le langage la décrit.
On a donc toujours plus ou moins une machine virtuelle quelque part. Quand on parle de langage à machine virtuelle, par opposition aux "autres" langages, c'est essentiellement pour dire que la machine virtuelle est simulée par la machine réelle pendant que le programme est exécuté, par opposition aux langages pour lesquels on a un traducteur de la machine virtuelle vers la machine réelle qui fait la traduction une bonne fois pour toute. Donc les langages interprétés sont, effectivement, des langages à machine virtuelle.
Je pense que ce qui te gêne est simplement le fait que Java est un langage qui utilise deux machines virtuelles (en général). On a d'une part la machine virtuelle Java, et d'autre part le langage qui est lui aussi une machine virtuelle, de plus haut niveau. On a un traducteur de Java-le-langage vers Java-la-MV, et ensuite on a simulation de Java-la-MV pour exécuter le programme.
[^] # Re: Félicitations !
Posté par marmoute (site web personnel) . Évalué à 3.
-O Turn on basic optimizations. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo.
Given twice, causes docstrings to be discarded.
le o fait des optimisation basic (ca doit pas etres génial mais c'est ttj mieux que rien et ca evite un truc lent pour des bouts de code pas forcement super écrit. et ca coute rien) avec OO ca vire les docstrings car a par pour le devellopement elle servent a rien.
[^] # Re: Félicitations !
Posté par tito (site web personnel) . Évalué à 8.
Parceque notre bien aimé jiba ne nous (m'a) pas prévenu qu'il mettrais une news sur linuxfr, et donc, rien a été préparé :) C'est fait dans le désordre...
Et pour jeuxlibres.net, ce n'est pas fait avec templeet, mais avec un framework perso :) (et merci pour le compliment)
[^] # Re: Félicitations !
Posté par Jiba (site web personnel) . Évalué à 5.
[^] # Re: Félicitations !
Posté par Tuxmym . Évalué à 5.
[^] # Re: Félicitations !
Posté par Jiba (site web personnel) . Évalué à 4.
[^] # Re: Félicitations !
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
# c'est joli !
Posté par Laurent Coustet . Évalué à 2.
# Pour la version anglaise...
Posté par Fred Albrecht . Évalué à 4.
"Avez vous déjà été acheté par votre propre épée" ne voulant rien dire dans le contexte...
[^] # Re: Pour la version anglaise...
Posté par Matafan . Évalué à 4.
# Désinstallation ?
Posté par Tuxmym . Évalué à 3.
Le script setup.py ne répond pas à une commande "uninstall".
Tout bon logiciel doit pouvoir se désinstaler facilement.
[^] # Re: Désinstallation ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
[^] # Re: Désinstallation ?
Posté par neil . Évalué à 0.
[^] # Re: Désinstallation ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
[^] # Re: Désinstallation ?
Posté par neil . Évalué à 3.
[^] # Re: Désinstallation ?
Posté par RuleZ . Évalué à 2.
gcc -pthread -shared build/temp.linux-i686-2.3/_ode.o build/temp.linux-i686-2.3/matrix.o -Lode-0.5/lib -L/usr/lib -L/usr/local/lib -L/usr/X11R6/lib -L/sw/lib/ -lm -lGL -lGLU -lSDL -lfreetype -lcal3d -lstdc++ -lode -o build/lib.linux-i686-2.3/soya/_ode.so
/usr/bin/ld: ne peut trouver -lode
collect2: ld a retourné 1 code d'état d'exécution
error: command 'gcc' failed with exit status 1
Traceback (most recent call last):
File "./setup.py", line 28, in ?
do("cd %s; python setup.py %s -f" % (package_dir, " ".join(sys.argv[1:])))
File "./setup.py", line 12, in do
raise RuntimeError, command
RuntimeError: cd soya; python setup.py build -f
Par contre, jdois avoir de la merde dans les yeux, mais je trouve pas ou reporter les bugs ?
[^] # Re: Désinstallation ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
Pour reporter des bugs, tiens c'est pas bete ca, c'est ou jiba ? :)
[^] # Re: Désinstallation ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
http://nekeme.net/forum/viewforum.php?f=22(...)
Par ailleurs, on reflechit a la creation d'une Mailing liste et d'un chan irc. En attendant ya #slune et #nekeme sur freenode.
[^] # Re: Désinstallation ?
Posté par RuleZ . Évalué à 3.
La compilation marche nickel maintenant :)
Toujours un peu de mal à comprendre les messages d'erreurs ...
Par contre, tant pis pour l'execution :
* Balazar * Balazar lives in /home/rulez/download/Balazar-with-deps-0.1
* Soya 3D * Using 8 bits stencil buffer
* Soya 3D * ERROR : OpenGL is not ready... Soya will crash soon i guess :-(
* Soya 3D * Warning : glGetString returns NULL!
Erreur de segmentation
J'aurais toujours du mal avec les sources, à partir du moment ou faut compiler c'est mort pour moi ... J'vais attendre avec patience un package précompilé je pense :p
[^] # Re: Désinstallation ?
Posté par Rémi Hérilier . Évalué à 2.
# Petits bugs
Posté par HoloAddict (site web personnel) . Évalué à 1.
- Impossible de prendre une photo (embétant pour avancer) sans avoir cette errreur :
File "image.pyx", line 52, in _soya.screenshot
ImportError: No module named PIL.Image
-lorsque l'on combat près d'une montagne, on peut parfois la traverser si l'on reçoit un coup nous propulsant dans la montagne
Suis-je le seul à avoir le problème de la photo ?
[^] # Re: Petits bugs
Posté par EdB . Évalué à 2.
[^] # Re: Petits bugs
Posté par HoloAddict (site web personnel) . Évalué à 1.
Je trouve juste dommage qu'il n'y ai pas un espèce de configure qui demande toute les libs nécéssaires, tel ode ou PIL.
M'enfin, maintenant je vais aller photographier ce temple voir ce qu'il y a après (^_^)
[^] # Re: Petits bugs
Posté par Tuxmym . Évalué à 1.
# Paquet Debian
Posté par ʭ ☯ . Évalué à 0.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Paquet Debian
Posté par Marc Dequènes (site web personnel) . Évalué à 5.
deb http://debian.duckcorp.org/experimental/binary-i386/ ./
Il sera uploadé officiellement ds Debian quand le package aura été paufiné, probablement pr la 0.2.
Il lui faut soya 0.9.2 disponible ici :
deb http://debian.duckcorp.org/unstable/binary-i386/ ./
(Slune 1.0.7 est dispo au même endroit)
Soya 0.9.2 et Slune 1.0.7 seront bientôt uploadé dans Debian.
Have a lot of FUN !
[^] # Re: Paquet Debian
Posté par RuleZ . Évalué à 2.
Ca marche terrible chez moi alors que les sources compilées plantaient juste avant (mais ça ne vient pas du jeu, root+pleins de conneries=mon système .. faudrait que je fasse un nettoyage "à la windows")
Ca a l'air déja super jolie, et ça tourne vraiment bien, surprenant (vieille Geforce2 + cpu 1Ghz) !
Rien que la première impression, c'est déja BRAVO !
[^] # Re: Paquet Debian
Posté par roychris . Évalué à 1.
* Balazar * (Psyco not found ; if you are using an x86 processor, installing psyco can speed up Balazar a little)
Traceback (most recent call last):
File "/usr/games/balazar", line 110, in ?
soya.set_root_widget(soya.widget.Image(None, soya.Material.get("splash"), resize_style = ("maximize",)))
TypeError: __init__() got an unexpected keyword argument 'resize_style'
* Soya3D * Quit...
[^] # Re: Paquet Debian
Posté par Jiba (site web personnel) . Évalué à 1.
# quelqu'un à un timbre?
Posté par loran . Évalué à 1.
Ok, je me propose... mais à qui on s'adresse? Quelle adresse?
Il faut timbrer?
[^] # Re: quelqu'un à un timbre?
Posté par loran . Évalué à 1.
Désolé (c'est lundi, j'ai bouffé des champignons, ma copine m'a quitté... etc...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.