Journal Dead Pixels Society

Posté par . Licence CC by-sa
34
27
oct.
2014

Bonjour Nal,

Dans la dernière dépêche d'une série que tu adores lire, j'avais évoqué la création d'un club de développement de jeu vidéo dans mon université. Voici quelques nouvelles !

Le club marche plutôt bien. Au total, c'est une soixantaine d'étudiants qui participent toutes les semaines à travers 5 projets (ça représente environ 1/3 des promos à peu près). Il y a majoritairement des informaticiens mais également des étudiantes de psycho et de lettres. Il y a même une étudiante de psycho qui est responsable d'un des projets ! Les groupes font entre 10 et 20 personnes, ce qui fait beaucoup quand on n'a jamais eu l'habitude de travailler à plus de 2. C'est d'ailleurs le principal challenge de ces projets, beaucoup plus que les aspects techniques liés aux jeux vidéo. Ce qui explique qu'au bout de 2 mois, il n'y ait pas encore beaucoup de code commité sur les dépôts.

Je vais vous présenter le projet dans lequel je suis impliqué, qui s'appelle Gzzzt. Au départ, je ne pensais pas qu'il y aurait beaucoup d'étudiants. Donc, je pensais pouvoir m'impliquer dans un projet. Mais au final, avec autant de projets, ce n'est pas forcément une bonne idée. Parce que tous les groupes ont besoin de conseils et d'aides, et malheureusement, comme je suis impliqué dans un groupe en particulier, je ne peux pas me consacrer aux autres autant que j'aimerais. Mais bref, voici le projet Gzzzt.

Gzzzt est (ou sera) un clone de Bomberman/Dynablaster en réseau dans un univers de robots. Les traditionnelles bombes seront remplacées par des boules électriques (d'où le nom du jeu). Évidemment, à terme, on espère pouvoir mettre tous les bonus/malus bien connus de ce type de jeu, mais on en est encore loin. Une des difficultés du jeu est la partie réseau temps réel et plus particulièrement, c'est l'occasion de tester des techniques de prédictions côté client. Pour l'instant, un petit moteur physique basique a été développé, à partir d'une excellente série d'articles sur la création d'un moteur physique complet. Les articles sont très bien mais le code source donné en exemple est rempli de bugs très sévères. Heureusement, j'ai pu les identifier et les corriger et ça a l'air de fonctionner. J'ai aussi simplifié le moteur en enlevant les forces (inutiles dans le jeu pour l'instant) et en gardant uniquement la partie collision. La partie réseau est également en train d'être développée petit à petit. Côté technos, on a opté pour ce bon vieux C++/SFML, et les cartes seront définies grâce à Tiled.

Pour la suite, on espère pouvoir avoir une version zéro à la mi-novembre. Le timing est très serré mais on a à peu près tous les éléments en place. J'essaierai de donner des nouvelles de temps en temps.

  • # Codation

    Posté par . Évalué à 2.

    On ne dit plus "développement" ou "programmation" voyons!

    Quand on est hype, on dit le "codage". Même les spécialistes (les ministres) le disent :-p

    Merci c'est tout désolé.

    • [^] # Re: Codation

      Posté par . Évalué à 3.

      Codage, ça existe, mais c'est des maths, pas (trop) de l'informatique ;)

      • [^] # Re: Codation

        Posté par . Évalué à 1. Dernière modification le 27/10/14 à 21:09.

        On m'aurait donc menti ? codage

        • [^] # Re: Codation

          Posté par . Évalué à 2.

          Je pensais aux codes correcteurs mais effectivement, ça va un peu plus loin. En tout cas, ça n'a rien à voir avec «programmation» ou «développement»

        • [^] # Re: Codation

          Posté par . Évalué à 1.

          Si ça existe, pourquoi je trouve ce mot aussi laid?
          Suis-je le seul à avoir mal aux oreilles quand média et politiques parlent de "codage à l'école"?

          • [^] # Re: Codation

            Posté par . Évalué à 3.

            Pas plus que lorsque mes collegues "codeurs" parlent de ce qu'ils ont "codé".

            Après tout, si les gens du métier eux-meme font l'erreur, pourquoi le reprocher aux journalistes et hommes politiques ?

  • # Conseils d'un ancien programmeur de jeu

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

    Salut, j'ai appris à programmer en C++ en codant sur le jeu Wormux sur lequel on a bossé à plusieurs. Le développement a duré plusieurs années. Problèmes rencontrés pendant le dev :

    • bibliothèque de jeu ClanLib qui subissait de lourde modifications internes, API instable
    • j'ai passé 3 mois à porter tout le jeu de ClanLib 0.6 à 0.7. Finalement, tout le jeu a été réécrit pour SDL
    • le moteur physique a été codé à partir de nos cours de physique au lycée : le moteur était plutôt bancal, instable et bogué
    • le réseau est arrivé très tard dans le jeu et fonctionnait mal sur Internet (bien en local avec une très faible latence)
    • on a passé une grosse partie du temps à s'occuper des aspects qui n'ont pas de lien avec le jeu directement : pile graphique, réseau, entrées-sorties, etc.

    Si c'était à refaire :

    • Développer le réseau dès le premier jour
    • Penser le réseau pour Internet : latence importante (50 ms à 500 ms ?) et perte de paquet
    • Choisir une bibliothèque qui gère la majorité des aspects du jeu et qui est réputée stable : je ne sais quoi conseiller en 2014

    Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.

    • [^] # Re: Conseils d'un ancien programmeur de jeu

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

      Ça c'est du commentaire, merci. Si ça peut rassurer l'équipe de dev, j'ai souvent joué en LAN à Wormux et on a bien rigolé :)

    • [^] # Re: Conseils d'un ancien programmeur de jeu

      Posté par . Évalué à 5.

      Problèmes rencontrés pendant le dev :
      bibliothèque de jeu ClanLib qui subissait de lourde modifications internes, API instable

      Ici, j'ai conseillé SFML parce que je connais bien, que je suis le développement et que la 2.1 est plutôt bien fichu (ça permet de faire du graphique, mais aussi du son et du textes avec gestion des fontes, et du réseau).

      le moteur physique a été codé à partir de nos cours de physique au lycée : le moteur était plutôt bancal, instable et bogué

      Pour des jeux où la physique compte beaucoup, je conseille Box2D (et je pense que Wormux fait partie de ces jeux là). Mais pour l'exemple que je donne, il n'y a pas beaucoup de physique et des trucs bien maîtrisés donc ça vaut le coup de refaire un bout de code pour ça.

      le réseau est arrivé très tard dans le jeu et fonctionnait mal sur Internet (bien en local avec une très faible latence)

      Ça, j'ai prévenu tous les groupes dès le départ. Le réseau, ce n'est pas quelque chose qu'on ajoute après avoir fait un jeu solo. Et je pense qu'inconsciemment, j'avais Wormux en tête parce que je me souviens avoir lu au cours des news sur LinuxFR la difficulté à faire ce travail d'ajout. Donc tous les jeux solos resteront solo et les jeux réseaux le sont dès le départ. Et je les ai prévenu que le réseau, c'était pas facile, surtout quand on veut faire du temps-réel (ce qui est le cas pour tous les groupes).

      on a passé une grosse partie du temps à s'occuper des aspects qui n'ont pas de lien avec le jeu directement : pile graphique, réseau, entrées-sorties, etc.

      Est-ce que ça ne dépend pas des libs utilisées ? Avec SFML où tout est intégré, et où les interfaces sont très simples à utiliser, j'espère que ça se passera bien et qu'on pourra se concentrer sur les aspects importants. Mes expériences avec des projets semestriels utilisant SFML me donnent plutôt confiance sur ces aspects.

      Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.

      10 ans après, c'est guère mieux. Bon, on a des pilotes libres qui sont tout à fait convenables pour les jeux développés dans le cadre du club. Mais niveau libs, c'est quand même pas la joie parfois. Quand j'ai commencé Akagoria, dans Debian, Box2D était packagé comme un cochon (changement du nom de la lib par rapport au reste du monde !) et SFML en était encore à la version 1.6 alors que la 2.1 était sorti depuis un moment quand même. Donc, au départ, je compilais tout ça à la main. Depuis, ça s'est amélioré, les packages sont maintenant présents, mais seront-ils maintenus ? Rien n'est moins sûr. Les jeux, c'est vraiment le parent pauvre des distributions malheureusement.

    • [^] # Re: Conseils d'un ancien programmeur de jeu

      Posté par . Évalué à 2.

      Choisir une bibliothèque qui gère la majorité des aspects du jeu et qui est réputée stable : je ne sais quoi conseiller en 2014

      La grosse tendance, dans le jeu vidéo indépendant (i.e. qui n'a pas beaucoup de moyens), c'est d'utiliser Unity3D, qui n'est pas libre mais permet de faire des jeux multi-plateforme (Gnulinux est supporté).

  • # Moteur physique

    Posté par . Évalué à 4.

    Pourquoi un moteur physique pour un dyna blaster ?
    J'y jouais souvent sur mon amiga 600 et j'ai du mal à voir le besoin.
    Pure curiosité ceci dit. Merci!

    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Moteur physique

      Posté par . Évalué à 2.

      Et bien pour gérer les collisions (joueur/terrain, joueur/bombe, etc). On pourrait le faire à la main directement, mais avoir cette fonctionnalité encapsulée dans une classe permet d'en avoir une abstraction sympa. Après, quand je dis moteur physique, ce n'est pas un truc énorme non plus, ça tape dans les quelques centaines de lignes, guère plus.

      • [^] # Re: Moteur physique

        Posté par . Évalué à 2.

        Ah ok. Pour moi moteur physique ça veut dire gérer la gravité, pas les collisions (mais ça n'est pas totalement illogique)

        Merci pour ta réponse !

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Suivre le flux des commentaires

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