Nuncabola, un Neverball en Java

Posté par (page perso) . Modéré par tuiu pol.
Tags :
14
2
fév.
2010
Jeu
Nuncabola est une réécriture de Neverball en Java, sous licence GPL v2.
Pour rappel, Neverball est un jeu d'action / adresse en 3D dans lequel le joueur contrôle une balle en inclinant le plateau de jeu à l'aide de la souris ou tout autre périphérique de contrôle (clavier, joystick, Wiimote...).

Pour le rendu 3D, Nuncabola s'appuie sur la bibliothèque LWJGL (Lightweight Java Game Library, licence BSD), il utilise également JInput et JOrbis.
Les performances du jeu sont excellentes, et il tourne n'importe où, du moment que vous avez une machine virtuelle java (JRE) en version 5 ou 6 et une 3D accélérée pas trop vieille.
Les dépendances sont incluses à l'archive. L'auteur se surnomme Elviz, c'est un contributeur régulier de Neverball, surtout en création de niveaux (la collection Nevermania, niveaux pour experts malsains confirmés), mais aussi un peu en code source.
C'est par ailleurs un excellent joueur, il détient à l'heure actuelle le plus grand nombre de records sur la Nevertable (table des records en ligne).

Elviz était gêné par un petit défaut de Neverball : un léger manque de fluidité dû à un problème dans la gestion de la physique. Ce fut la principale raison qui l'a poussé à se lancer dans le développement de Nuncabola, nom qui signifie Neverball en portugais, même si Elviz est allemand !

L'auteur n'a pas communiqué sur son logiciel en dehors du forum car, étant extrêmement perfectionniste, il ne souhaite le faire que lorsque son jeu aura atteint la qualité suffisante à ses yeux. De par mon expérience, il est d'une stabilité comparable à celle de Neverball.
Nuncabola évolue depuis déjà plus de 8 mois, et je trouve dommage qu'il reste peu connu compte tenu de sa finition, mais aussi parce que c'est un des rares jeux 3D Java libres de cette qualité. Et puis c'est du libre, donc pourquoi attendre pour partager ?

Depuis sa première version, Nuncabola évolue avec Neverball, l'un empruntant à l'autre les évolutions compatibles.

Les films (replays) de records sont parfaitement compatibles avec les dernières versions de Neverball.
Toutes les fonctionnalités de Neverball ne sont cependant pas implémentées, il manque notamment : la localisation (seul l'anglais est pris en charge), le compilateur de niveaux (mapc) et la gestion des périphériques d'inclinaison (comme la Wiimote).
Le jeu n'a pas non plus d'installateur, il se lance en passant le fichier jar à la machine virtuelle java.
Font aussi défaut un site officiel et une implémentation java de Neverputt ! (le mini-golf)
  • # LWJGL

    Posté par (page perso) . Évalué à 4.

    LWJGL est vraiment une très bonne bibliothèque pour développer des jeux. C'est vraiment dommage qu'elle ne soit pas incluse dans le JRE!

    http://devnewton.bci.im

    • [^] # Re: LWJGL

      Posté par (page perso) . Évalué à 5.

      C'est comme SDL et OpenGL, il aurait fallu les inclure dans la libc.
      • [^] # Re: LWJGL

        Posté par (page perso) . Évalué à -2.

        Non.

        http://devnewton.bci.im

        • [^] # Re: LWJGL

          Posté par (page perso) . Évalué à 4.

          Si.
          • [^] # Re: LWJGL

            Posté par (page perso) . Évalué à 4.

            ou pas :)
          • [^] # Re: LWJGL

            Posté par (page perso) . Évalué à 3.

            Je te fais une réponse longue puisque ça ne te semble pas évident et que tu n'as pas du te renseigner:


            - Java s'installe avec un ensemble de bibliothèques standards de bas et de haut niveau : JRE (ou plutôt J2SE selon le vocabulaire en vigueur). Ca va des entrées/sorties aux interfaces graphiques en passant par les accès aux bases de données. C'est un peu fourre tout, mais ça facilite énormément le travail de déploiement de logiciel sur de multiples plateformes. Le problème c'est que pour les jeux, il n'y a qu'une bibliothèque graphique 2D assez lente fournie en standard (Java2D). LWJGL, qui fournit un accès à la bibliothèque graphique 3D OpenGL, rendrait la distribution de jeux Java beaucoup plus facile.

            - en C, il n'y a pas d'équivalent au J2SE. Il y a juste une bibliothèque standard très très réduite.

            Ces deux situations sont forts regrettables pour le développeur de jeux, mais autant on peut espérer une évolution du J2SE, autant on est CERTAIN que jamais on ne verra la libc inclure OpenGL : pour des raisons pratiques et historiques ce n'est ni souhaitable, ni faisable.

            http://devnewton.bci.im

            • [^] # Re: LWJGL

              Posté par (page perso) . Évalué à 7.

              C'est donc pour cela que pour faire tourner la moindre applet web il faille se farcir le téléchargement de plus de 100 Mio de trucs qui ne serviront sans aucun doute jamais.

              Mon allusion à l'inclusion de SDL et OpenGL dans la libc étaient bien entendu sarcastiques, car autant la disponibilité de fonctions d'entrées/sorties de base, d'allocation mémoire et de gestion de données simples (chaînes de caractères ...) sont indispensables, autant l'inclusion de tout un paquet de fonctionnalités dont on ne se servira à peine de 5% de l'ensemble, et dont certaines font double emploi (AWT et Swing notamment), c'est n'importe quoi.

              Ces deux situations sont forts regrettables pour le développeur de jeux
              Il ne faudrait tout de même pas prendre les développeurs pour des billes. Un développeur SAIT installer son environnement de développement et les bibliothèques dont il a besoin.
              • [^] # Re: LWJGL

                Posté par (page perso) . Évalué à 4.

                C'est donc pour cela que pour faire tourner la moindre applet web il faille se farcir le téléchargement de plus de 100 Mio de trucs qui ne serviront sans aucun doute jamais.

                Il y a pire, puisqu'il faut aussi :

                - un OS qui fait plusieurs Go.
                - un PC avec écran, clavier et même une souris!
                - un logement avec de l'électricité.

                Bref c'est vraiment nul de ne pas pouvoir lancer une applet à poil dans la forêt!

                Il ne faudrait tout de même pas prendre les développeurs pour des billes. Un développeur SAIT installer son environnement de développement et les bibliothèques dont il a besoin.

                Le développeur oui (et encore les problèmes d'installation occupent plusieurs pages du forum de LWJGL), le joueur non. Il faut donc passer du temps à packager ces bibliothèques et ce n'est pas une partie de plaisir, car comme c'est un mix entre des bibliothèques Java et des bibliothèques natives, c'est assez galère.

                http://devnewton.bci.im

                • [^] # Re: LWJGL

                  Posté par (page perso) . Évalué à 5.

                  Bref c'est vraiment nul de ne pas pouvoir lancer une applet à poil dans la forêt!
                  Dans la forêt ? mais il faudrait alors des arbres !...

                  GNU's Not Unix / LINUX Is Not Unix Xernel

            • [^] # Re: LWJGL

              Posté par (page perso) . Évalué à 2.

              J2SE c'est un framework (grossièrement un amas de bibliothèques), quel est donc le rapport avec la libc (une seule bibliothèque) ?
              • [^] # Re: LWJGL

                Posté par (page perso) . Évalué à -2.

                >> J2SE c'est un framework (grossièrement un amas de bibliothèques), quel est donc le rapport avec la libc (une seule bibliothèque) ?

                Le rapport est « amas / un » et est valide pour tout « un » non nul.
    • [^] # Re: LWJGL

      Posté par (page perso) . Évalué à 1.

      Il est dommage par contre qu'elle ne supporte pas encore OpenGL ES, cela faciliterait sûrement le portage de jeu comme Nuncabola, et donc Neverball par extrapolation peu osée, sur des mobiles. Surtout ceux dont le framework est en Java, d'ailleurs :)
      • [^] # Re: LWJGL

        Posté par (page perso) . Évalué à 2.

        C'est malheureusement assez difficile : il faut faire un développement spécifique pour chaque type de mobile.

        http://devnewton.bci.im

        • [^] # Re: LWJGL

          Posté par . Évalué à 4.

          il faut faire un développement spécifique pour chaque type de mobile. Mais non, c'est du java !

          ====> [ ]
          • [^] # Re: LWJGL

            Posté par (page perso) . Évalué à 3.

            Justement LWJGL ce n'est PAS du Java. C'est un binding de bibliothèques C/C++ en Java.

            http://devnewton.bci.im

  • # Performances

    Posté par (page perso) . Évalué à 1.

    Voilà une occasion de comparer les performances entre Java et C ?
    Lequel fonctionne le plus vite sur une vieille machine? Quelle empreinte mémoire?

    ⚓ À g'Auch TOUTE! http://agauch.online.fr

    • [^] # Re: Performances

      Posté par (page perso) . Évalué à 2.

      Le moteur Nuncabola physique de Nuncabola diffère de celui de Neverball sur des aspects touchant typiquement aux performances, il c'est donc difficile de comparer.
      Nuncabola est davantage fluide, c'est justement sa raison d'exister.
      Par contre je n'ai pas de vieille machine sous la main.

      Pour l'empreinte mémoire, je ne suis pas très familier avec ça, j'ai trouvé sur un message de forum ici que gcore faisait l'affaire, mais voilà les valeurs :
      Nuncabola (processus java) : 1437 Mo !
      Neverball : 114 Mo
      • [^] # Re: Performances

        Posté par . Évalué à 1.

        Nuncabola (processus java) : 1437 Mo !
        Neverball : 114 Mo

        Autant le chiffre de Neverball me parait cohérant, mais celui de Nuncabola me parait un poil surestimer quand même ...

        Sinon je m'en vais essayer de jeu Java dès ce soir ^_^
        • [^] # Re: Performances

          Posté par (page perso) . Évalué à 3.

          PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
          3391 baud 20 0 1333m 132m 25m S 112 6.6 6:13.19 java


          il s'agit de mémoire virtuelle.
          Au lancement, la mémoire utilisée est d'environ 100 Mo, 132 après un jeu.

          En revanche, ce qui est un peu plus gênant, c'est les 100% d'un core pris :/ (bon j'en ai deux) et, ce, en permancence...

          Pour le lancer, ce serait pas mal d'avoir un nuncola.sh contenant :
          java -XX:+UseConcMarkSweepGC -jar nuncabola.jar

          Cela fonctionne correctement sur Mandriva Linux 2010.0 en x86_64 avec
          java-1.6.0-openjdk-1.6.0.0-0.20.b16.11mdv2010.0
          (téléchargement du .zip binaire+data puis unzip et zou lancement avec la commande ci-dessus).
    • [^] # Re: Performances

      Posté par (page perso) . Évalué à 3.

      Pour ça il faudrait que l'implémentation de toutes les fonctionnalités soit quasiment identique. je pense que le seul moyen de comparer serait qu'un développeur code deux fois la même chose en parallèle en faisant attention de ne faire que de l'adaptation de syntaxe et en utilisant aucune librairie externe autre que libc ou son équivalent en java.
      • [^] # Re: Performances

        Posté par . Évalué à 4.

        C'est là où je ne suis pas d'accord: quand tu fais du java, tu ne fais pas du C... Je trouve que les transpositions ne reflètent pas la réalité car ce n'est pas de cette manière que l'on code.

        Je ne dis pas que les micro benchmark ne sont pas intéressants mais qu'il ne faut pas leur donner plus d'importance qu'ils en ont: la VM est complexe, lente à démarrer, le garbage collector est peu prédictible, le JIT a parfois de très bonnes optimisations... Le mieux est de prendre les projets dans leur globalité en vérifiant bien que les deux avaient le même but (performances ,maintenance, etc...)

        Conclusion:Le bon outil pour le bon problème, et parfois C/C++/java peuvent tous être viable.

        PS: un petit lien de bench qui date maintenant http://marc.info/?l=tomcat-user&m=106036177509367&w=(...)
        • [^] # Re: Performances

          Posté par (page perso) . Évalué à 2.

          Le lien typique:
          http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)

          Et la mise en garde qui va bien: ce ne sont que des benchmarks, ils ne sont pas forcément représentatifs de l'usage réel, etc etc (mais je trouve cela tout de même assez intéressant, même si plein d'autres facteurs entrent en compte)

          Mathias
          • [^] # Re: Performances

            Posté par (page perso) . Évalué à 5.

            Pour précision, Neverball est codé en C, pas C++.

            Par ailleurs, le problème de fluidité de Neverball n'est pas lié au langage mais juste à l'implémentation du moteur physique.

            Dans la version 1.4.0, il n'y avait pas ce problème, cependant le comportement de la balle n'était pas assez constant d'une machine à une autre, ce qui pouvait poser des problèmes pour la compétition : un film (replay) enregistré sur une machine pouvait produire un résultat sensiblement différent sur une autre. Par exemple, si le joueur attrape une pièce en la frôlant, elle pouvait ne pas être prise sur une autre machine (pas cool).

            De plus, cet ancien moteur pouvait causer une différence de quelques centièmes de secondes sur un même parcours. Ceci a été observé plusieurs fois sur des niveaux très basiques où la trajectoire optimale est la ligne droite vers la sortie. Les meilleurs performances se battent souvent au centième de seconde...

            La correction du moteur a consisté à le rendre déterministe, càd qu'il est maintenant censé produire toujours le même résultat pour une même séquence de contrôle en entrée. Techniquement il a fallu rendre constant l'intervalle de temps entre 2 états internes du moteur, plutôt que dépendant des performances de la machine.
            Au niveau réalisme de la simulation on y perd un peu, mais au niveau gameplay / compétition, on y gagne.

            Par contre, ça a causé le problème de fluidité. Elviz l'a résolu dans Nuncabola en procédant à des interpolations d'états du jeu. Par contre personne dans l'équipe n'a été capable d'en faire autant pour Neverball (limites dans les compétences en maths).
            • [^] # Re: Performances

              Posté par (page perso) . Évalué à 4.

              Je me demande pourquoi l'auteur de Nuncabola n'a pas contribué à Neverball pour améliorer le moteur physique. Il y a une raison à cela ?

              « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

              • [^] # Re: Performances

                Posté par (page perso) . Évalué à 6.

                L'implémentation de l'interpolation d'état interne qui est la raison d'être de Nuncabola nécessitait la réécriture de beaucoup de code et surtout le changement de l'architecture.

                L'auteur a donc décidé de tout réécrire "from scratch" en imitant au plus près Neverball (mis à part l'interpolation). Il a des affinités avec le Java et la programmation objet et ne souhaitait donc pas le faire en C, il ne faut pas chercher plus loin à ma connaissance.
      • [^] # Re: Performances

        Posté par . Évalué à 1.

        Comme deja dit par un autre on ne code pas du tout de la meme maniere en C qu'en JAVA. Et surtout dans un jeu, ou on ne veut pas que le garbage collector se lance n'importe quand, ce qui pourrait freezer l'appli.
        Donc non ce n'est pas possible de faire la meme chose a la syntaxe pret.
        Et non ce n'est pas parce qu'il y a un garbage collector qu'il est impossible de gerer la memoire soi meme en JAVA (ou du moins la partie qui interesse).
  • # Release early, release often

    Posté par (page perso) . Évalué à -3.

    « L'auteur n'a pas communiqué sur son logiciel en dehors du forum car, étant extrêmement perfectionniste, il ne souhaite le faire que lorsque son jeu aura atteint la qualité suffisante à ses yeux. »

    Il n'a pas lu la cathédrale et le bazar lui...

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.