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 nomorsad . É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 rewind (Mastodon) . Évalué à 3.
Codage, ça existe, mais c'est des maths, pas (trop) de l'informatique ;)
[^] # Re: Codation
Posté par PachaFonk . Évalué à 1. Dernière modification le 27 octobre 2014 à 21:09.
On m'aurait donc menti ? codage
[^] # Re: Codation
Posté par rewind (Mastodon) . É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 nomorsad . É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 CHP . É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 Victor STINNER (site web personnel) . É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 :
Si c'était à refaire :
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Conseils d'un ancien programmeur de jeu
Posté par rewind (Mastodon) . Évalué à 5.
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).
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.
Ç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).
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.
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 Antoine . Évalué à 2.
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 xcomcmdr . É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 rewind (Mastodon) . É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 xcomcmdr . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.