Développez Couché, saison 2 : le topic officiel

[L-F. Sébum]

LE SITE OFFICIEL DE DÉVELOPPEZ COUCHÉ : https://sites.google.com/site/developpezcouche/

Dernières mises à jour sur le site :

15 juin 2013 :
Canard PC n°278 est en kiosque. Vous y trouverez la dernière leçon.

1er juin 2013 :
Canard PC n°277 est en kiosque. Vous y trouverez la dix-septième leçon qui porte sur le contenu.

15 mai 2013 :
Canard PC n°276 est en kiosque. Vous y trouverez la seizième leçon qui porte sur la correction de bugs.

2 mai 2013 :
Canard PC n°275 est en kiosque. Vous y trouverez la quinzième leçon, troisième partie du cours sur le gameplay et les règles de jeu.

16 avril 2013 :
Canard PC n°274 est en kiosque. Vous y trouverez la quatorzième leçon, deuxième partie du cours sur le gameplay et les règles de jeu.

2 avril 2013 :
Canard PC n°273 est en kiosque. Vous y trouverez la treizième leçon, première partie du cours sur le gameplay et les règles de jeu.

15 mars 2013 :
Canard PC n°272 est en kiosque. Vous y trouverez la douzième leçon, qui porte sur les objets et l'inventaire.

4 mars 2013 :
Canard PC n°271 est en kiosque. Vous y trouverez la onzième leçon, quatrième partie du cours sur le monde de jeu.

15 février 2013 :
Canard PC n°270 est en kiosque. Vous y trouverez la dixième leçon, troisième partie du cours sur le monde de jeu.

3 février 2013 :
Canard PC n°269 est en kiosque. Vous y trouverez la neuvième leçon, deuxième partie du cours sur le monde de jeu.

3 février 2013 :
Canard PC n°269 est en kiosque. Vous y trouverez la neuvième leçon, deuxième partie du cours sur le monde de jeu.

15 janvier 2013 :
Canard PC n°268 est en kiosque. Vous y trouverez la huitième leçon, première partie du cours sur le monde de jeu.

3 décembre 2012 :
Canard PC n°266 est en kiosque. Vous y trouverez la septième leçon, seconde partie du cours sur l'univers de jeu.

17 novembre 2012 :
Canard PC n°265 est en kiosque. Vous y trouverez la sixième leçon, première partie du cours sur l'univers de jeu.

2 novembre 2012 :
Canard PC n°264 est en kiosque. Vous y trouverez la cinquième leçon, seconde partie du cours sur l'interface utilisateur.

18 octobre 2012 :
La section archives a été ajoutée. Vous y trouverez l'intégralité de la première saison de Développez Couché.

17 octobre 2012 :
Canard PC n°263 est en kiosque. Vous y trouverez la quatrième leçon, première partie du cours sur l'interface utilisateur. Le code source nécessaire à la leçon peut être téléchargé depuis la page avancement du projet.

1er octobre 2012 :
Canard PC n°262 est en kiosque. Vous y trouverez la troisième leçon, qui porte sur le moteur graphique. Le code source nécessaire à la leçon peut être téléchargé depuis la page avancement du projet.

14 septembre 2012 :
Canard PC n°261 est en kiosque ou ne devrait plus tarder. Vous y trouverez la deuxième leçon : le squelette du code et le moteur audio. Le code source nécessaire à la leçon peut être téléchargé depuis la page avancement du projet.

7 septembre 2012 :
Merci à tous ceux qui ont déjà envoyé des tiles. Tiens, tant que j'y pense, le jeu va avoir besoin d'une icône. Si ça tente quelqu'un, il faudrait une image en PNG avec transparence, 64x64 (mais qui doit pouvoir rester lisible affichée en 32x32 et même si possible en 16x16). Envoyez-la à l'adresse indiquée sur le site avec votre nom/pseudo si vous souhaitez être crédité. Si j'en reçois beaucoup on organisera un vote pour choisir la meilleure.

3 septembre 2012 :
Canard PC n°260 est en kiosque. Vous y trouverez la première leçon, l'exposition du projet. Le 15 septembre, dans le Canard PC n°261, on créera le squelette du code source (et, si on a la place, le moteur sonore, parce que c'est vite écrit).
Ah, et la section contribuer au projet est en ligne. Vous devriez y faire un tour. Quel que soit votre talent ou votre absence de talent, il y a du taf pour vous.

28 août 2012 :
Le site est en ligne et le premier cours sera publié dans le Canard PC 260, en kiosque le 1er septembre. Plus de contenu et d'informations seront publiés d'ici très peu de temps.

[Belhoriann]

Nice Mister Sebum !
J'avais justement envi de reprendre mon apprentissage du langage C# et de développer le jeu ultime mouahahaha

[Froyok]

Pour ceux n'ayant pas suivis la saison un, comment ça se passe au niveau du setup initial ?

[L-F. Sébum]

Pour ceux n'ayant pas suivis la saison un, comment ça se passe au niveau du setup initial ?

Tu trouveras la listes des programmes à installer dans la section "liens" du site. Et vu qu'on va développer un jeu complètement différent cette année, tu n'as pas besoin d'avoir suivi les cours de l'année dernière.

[Froyok]

Cool !
Vivement la rentrée !

[Molina]

Tu trouveras la listes des programmes à installer dans la section "liens" du site. Et vu qu'on va développer un jeu complètement différent cette année, tu n'as pas besoin d'avoir suivi les cours de l'année dernière.

J'ai séché pas mal de cours, mais il me semblait que c'était la base de la base archi basique...

[Belhoriann]

P'tite question :

Je suis en train de suivre ce tuto très (très) intéressant expliquant de façon simple et détaillée comment construire un moteur de jeu simple et réutilisable.

Il y a par exemple ce genre de schéma, décrivant l'architecture visée :





Tu vas faire comme ça aussi LFS ? Tu vas d'abords construire le moteur, puis le jeu l'utilisant, ou directement le jeu lui même ?

Question subsidiaire :

j'ai trouvé plein de façon de commencer à développer sur XNA.

Mais est-ce les meilleurs ?

[Louck]

Avis personnel: Tout dépend la façon dont tu veux développer ton programme.

Il existe des tonnes de façon pour concevoir un moteur de jeu. Ton architecture est un exemple. L'architecture du moteur Source en est un autre.

Personnellement (et parce que j'aime bien titiller toute la partie technique de la chose), je conseil de concevoir et d'expérimenter son propre moteur de jeu, sans se baser sur une architecture du net. De cette façon, nous commettons un très grand nombre d'erreurs/bugs dans notre programme, des défauts de conception, et plein d'autres conneries. Mais c'est la meilleure façon pour comprendre certains éléments d'un moteur de jeu, comme l'interpolation et la gestion des entités.


Mais bien sûr, cela prend beaucoup de temps à concevoir un moteur de jeu "correct". Autant se focaliser sur le développement du jeu lui même, à partir d'un moteur existant.


PS: Mais je laisse le maitre LFS répondre à la question sinon

[war-p]

Avis personnel: Tout dépend la façon dont tu veux développer ton programme.

Il existe des tonnes de façon pour concevoir un moteur de jeu. Ton architecture est un exemple. L'architecture du moteur Source en est un autre.

Personnellement (et parce que j'aime bien titiller toute la partie technique de la chose), je conseil de concevoir son propre moteur de jeu, sans se baser sur une architecture du net. De cette façon, nous commettons un très grand nombre d'erreurs/bugs dans notre programme, des défauts de conception, et plein d'autres conneries. Mais c'est la meilleure façon pour comprendre certains éléments d'un moteur de jeu, comme l'interpolation et la gestion des entités.


Mais bien sûr, cela prend beaucoup de temps à concevoir un moteur de jeu "correct". Autant se focaliser sur le développement du jeu lui même, à partir d'un moteur existant.


PS: Mais je laisse le maitre LFS répondre à la question sinon

Oui, entièrement d'accord, l'organigramme doit correspondre avant tout au besoins spécifique de l'application, le cas contraire pose des tonnes de contraintes (il n'y a qu'a voir le cas de l'UDK, dès que l'on veut faire autre chose que du fps)

[Louck]

Après j'ai vu des tonnes d'exemples d'architectures de jeux, mais j'ai toujours du mal à les comprendre ou à les mettre en place pour des projets (avec toutes les subtilités et optimisations). Et j'aime bien tout ce qui est technique .

Néanmoins le tuto en question n'est pas non plus mauvais. Il y a pas mal de choses intéressantes et le mec explique bien. Dommage qu'il c'est arrêté en court de chemin :/

[Jereak]

Oui, entièrement d'accord, l'organigramme doit correspondre avant tout au besoins spécifique de l'application, le cas contraire pose des tonnes de contraintes (il n'y a qu'a voir le cas de l'UDK, dès que l'on veut faire autre chose que du fps)

Je ne suis pas tout à fait d'accord, c'est d'ailleurs ça qui fait la force des moteurs de jeu les plus connus et les plus utilisés (UDK, Unity, ...) : la base qui existe déjà est totalement abstraite et permet de faire n'importe quel type de jeu. Certaines limites techniques empêchent souvent de faire du MMO, mais c'est un autre problème.

Dans le cas d'UDK, que tu prends comme exemple, j'aurais plutôt tendance à dire : "Avec UDK, il est plus aisé de faire des FPS, car beaucoup de classes supplémentaires existent déjà pour simplifier leur création."
Pour faire d'autres types de jeu, on se passe tout simplement de ces classes, il n'y a aucune contrainte. Il suffit de ne pas utiliser les classes trop haut niveau orientées FPS.

[Belhoriann]

Oui, entièrement d'accord, l'organigramme doit correspondre avant tout au besoins spécifique de l'application, le cas contraire pose des tonnes de contraintes (il n'y a qu'a voir le cas de l'UDK, dès que l'on veut faire autre chose que du fps)

Je plussoie. Pour avoir taté de l'UDK pendant 2 mois je dois dire que c'est une vraie galère pour rendre neutre la chose afin de repartir sur des bases saines.

Après j'ai vu des tonnes d'exemples d'architectures de jeux, mais j'ai toujours du mal à les comprendre ou à les mettre en place pour des projets (avec toutes les subtilités et optimisations). Et j'aime bien tout ce qui est technique .

Néanmoins le tuto en question n'est pas non plus mauvais. Il y a pas mal de choses intéressantes et le mec explique bien. Dommage qu'il c'est arrêté en court de chemin :/

Oui le tuto dévoile plein de petites choses pratiques, comme la gestion en cascade "Engine > GameScreen > Component" que j'aime bien.
C'est vraiment super dommage qu'il se soit arrêté en cours de route, mais au moins il y a la base d'un moteur neutre sur lequel on peut bâtir un truc perso.

[Jereak]

Je plussoie. Pour avoir taté de l'UDK pendant 2 mois je dois dire que c'est une vraie galère pour rendre neutre la chose afin de repartir sur des bases saines.

Je pense que beaucoup de gens ont ce problème car ils partent d'exemples trouvés sur le net, et la plupart de ces exemples sont des FPS. C'est ce qui m'a posé problème moi aussi, le premier jeu que j'ai voulu faire avec UDK n'est pas un FPS. Sauf que très rapidement une fois qu'on a compris comment fonctionnent les classes de base, on peut créer sa "base saine" en 5 minutes.
En revanche il est vrai que certaines classes basiques (GameInfo, Controller, ...) sont un peu contaminées par des fonctionnalités très FPS, mais qu'il suffit d'ignorer.

Edit : PS : je me demande par contre si on est pas un peu en train de pourrir le topic ou si c'est dans le sujet ? ^^

[Belhoriann]

On pourris légèrement mais c'est en liaison avec ma question qui elle est directement liée au topic

[war-p]

Je ne suis pas tout à fait d'accord, c'est d'ailleurs ça qui fait la force des moteurs de jeu les plus connus et les plus utilisés (UDK, Unity, ...) : la base qui existe déjà est totalement abstraite et permet de faire n'importe quel type de jeu. Certaines limites techniques empêchent souvent de faire du MMO, mais c'est un autre problème.

Dans le cas d'UDK, que tu prends comme exemple, j'aurais plutôt tendance à dire : "Avec UDK, il est plus aisé de faire des FPS, car beaucoup de classes supplémentaires existent déjà pour simplifier leur création."
Pour faire d'autres types de jeu, on se passe tout simplement de ces classes, il n'y a aucune contrainte. Il suffit de ne pas utiliser les classes trop haut niveau orientées FPS.

Va voir mon sujet sur mon projet, tu vas voir que pour faire un simulateur de voiture, je suis obligé de faire des contorsions, tout ça à cause des classes abstraites non conçues pour ça, après je dis pas qu'il n'y a pas moyen, je dis juste que le moteur tel quel, n'est pas fait pour.

[Jereak]

Là j'avoue que je n'ai jamais touché aux véhicules, donc je veux bien te croire si tu dis que l'abstraction n'est pas top.
Je me basais uniquement sur ce que j'ai déjà eu l'occasion de faire avec UDK, et pour l'instant aucun problème pour divers types de jeux : sidescroller à la mario, tower-defense, contrôle de KActor (balle à faire rouler) en guise de pawn, etc. Ce n'est pas forcément exhaustif, mais ça donne déjà un bon aperçu je pense. ^^

[L-F. Sébum]

On va construire un moteur de roguelike complet qui gérera entités, monde, affichage et son. Le cours du numéro 261 portera justement sur la structure du projet.

[Belhoriann]

Ok, ça me conforte un peu dans ma motivation de construire d'abords le moteur pour ensuite batir le jeu dessus.

[war-p]

Ben, en général, tu fais ça... Cela dit avec xna, une bonne partie du moteur existe déjà, il "ne reste" qu'a construire la logique de jeu par dessus.

[Belhoriann]

Oui m'enfin on voit de nombreux tuto qui ne parlent pas une seconde de moteur et montre directement comment faire un petit jeu directement.

[Louck]

Il est possible de faire un jeu avec du code qui fait saigner les yeux, avec une structure qui peut hanter ta famille pour 13 générations.

Une bonne structure de jeu (et des méthodes génériques) permet de mieux le maintenir et de le faire évoluer, les doigts dans le nez.

[ElGato]

Oui m'enfin on voit de nombreux tuto qui ne parlent pas une seconde de moteur et montre directement comment faire un petit jeu directement.

La quasi-totalité des projets de débutants qui commencent par faire un moteur n'aboutissent pas.
Bon d'une façon générale la quasi-totalité des projets amateurs n'aboutissent pas mais quand on commence dans le JV par coder un moteur on est vraiment sûr de ne pas finir.

Ça dépend un peu de là où on place le curseur du "moteur" évidemment - il y a bien un moment où l'on doit faire des choses soi-même - mais pour un niveau de détail comme celui décrit dans l'article linké plus haut ça me semble totalement hors de portée pour un débutant. Ça n'est pas parce qu'on peut suivre l'article qu'on pourra construire un jeu là-dessus.
Rien que créer une map intéressante pour un jeu multi, ou inventer un gameplay de casse-brique intéressant en GameMaker c'est très difficile. Ceux qui passent par ces étapes ont beaucoup, beaucoup plus de chance de finir un projet plus compliqué ; et encore, ça n'est sûrement pas la majorité.

Ou alors il faut prendre conscience que ce qui intéresse, au fond, c'est la technique et pas vraiment le gameplay - dans ce cas-là réinventer la roue est un très bon moyen d'apprendre, c'est vrai. Mais faut savoir prendre assez de recul pour s'en rendre compte (personnellement je sais toujours pas et ça me fait perdre un temps fou).

Au passage, c'est la raison pour laquelle je suis impressionné par le boulot de Louis-Ferdinand Sébum sur Développez Couché. Mais je ne pense pas me tromper en disant qu'il n'en est vraiment pas à son premier projet, ni même son dixième.

[L-F. Sébum]

Au passage, c'est la raison pour laquelle je suis impressionné par le boulot de Louis-Ferdinand Sébum sur Développez Couché. Mais je ne pense pas me tromper en disant qu'il n'en est vraiment pas à son premier projet, ni même son dixième.

Si tu comptes en projets entamés, je dois avoir passé la barre des cent. Sans exagérer. Certains sont (étaient ?) même bien avancés.

Si tu comptes en projets terminés, un. World of Ideas, mon jeu de combat avec des philosophes. Et c'était vraiment de la merde, un truc tout naze fait pour déconner.

Mais c'est très utile de passer par là. C'est un peu comme ce qu'on dit aux aspirants écrivains : écrivez n'importe quoi mais écrivez chaque jour. Faites vos putains de gammes. Codez des moteurs : vous laisserez forcément tomber avant la fin mais vous pigerez mieux le fonctionnement "bas niveau" d'un jeu et vous saurez optimiser. Codez à partir de moteurs déjà faits : vous apprendrez ce qui marche et ne marche pas dans un gameplay. Codez n'importe quoi mais codez chaque jour.

Maintenant quand je code, c'est clean, c'est rapide, je hiérarchise mes priorités, je sais où je vais. Surtout, je connais mes forces : je sais quel projet je peux espérer mener à bien. Là, j'ai deux gros projets (celui de cette année pour développez couché et un autre) dont je SAIS qu'il seront terminés d'ici douze mois. Et si aucun des deux ne sera le nouveau Minecraft, ce seront des petits jeux très sympas.

L'autre solution est bien sûr d'aller dans une école. Mais on rigole beaucoup plus en étant autodidacte.

[ElGato]

Ouaip, mais t'as une motivation sans faille, et probablement pas mal d'affinité avec la technique. Si tu veux juste faire un gameplay amusant, il faut signaler que ça n'est pas obligatoire de commencer par échouer quinze fois en se lançant dans un truc trop technique.
C'est comme commencer l'écriture par une saga en dix volumes. Ça n'est pas raisonnable. C'est toujours valable pour les sagas en dix volumes d'ailleurs.

La case de l'école c'est un peu "dommage" effectivement, puisque c'est quand même plus marrant d'être à l'arrache (enfin, personnellement, je préfère), tant que c'est encore possible.


J'aimerais beaucoup trouver un journal d'amateur complet qui expliquerait très régulièrement son avancée dans le développement d'un jeu...Avec le jeu fini (plus ou moins) à la fin. Ceux qui s'y tiennent plus de 2-3 mois sont très rares ; en fait je ne connais personne qui l'ai fait en dehors des blogs pas vraiment détaillés ni très funs des étudiants en école de JV.

[Belhoriann]

Merci pour vos posts très enrichissants

Sebum, c'est toi qui a enfanté de cette chose ?

[L-F. Sébum]

Ouaip, mais t'as une motivation sans faille, et probablement pas mal d'affinité avec la technique.

Bof... Si j'avais une motivation sans faille j'aurais fini plus de projets. Quant à mon affinité avec la technique... euh... t'as pas idée comme je galère pour coder en C++, même des choses relativement simples.

Par contre j'aime bien prendre des petits bouts de trucs et puis les assembler ensemble, comme dit King Ju. Il faut avoir le goût du bricolage pour ces choses là.

Si tu veux juste faire un gameplay amusant, il faut signaler que ça n'est pas obligatoire de commencer par échouer quinze fois en se lançant dans un truc trop technique.

Le problème c'est que beaucoup de débutants ont plus grands yeux que grand ventre. T'as qu'à voir tous les projets de MMO par des gens qui n'ont jamais écrit une ligne de code de leur vie. Même sans aller jusque là, la plupart des projets amateurs partent dans tous les sens et on sent que leurs auteurs n'ont qu'une vague idée de ce que devra être le "produit fini".

Se casser les dents sur quelques difficultés permet de faire la part des choses, d'apprendre à se débarrasser du gras et de réaliser ce qui fait, précisément, un gameplay amusant.

Sebum, c'est toi qui a enfanté de cette chose ?

Oui. Testé par Emile Zoulou dans je ne sais plus quel numéro de Canard PC, mais je n'y écrivais pas encore.

[Don Moahskarton]

J'aimerais beaucoup trouver un journal d'amateur complet qui expliquerait très régulièrement son avancée dans le développement d'un jeu...Avec le jeu fini (plus ou moins) à la fin. Ceux qui s'y tiennent plus de 2-3 mois sont très rares ; en fait je ne connais personne qui l'ai fait en dehors des blogs pas vraiment détaillés ni très funs des étudiants en école de JV.

Bah... j'ai eu l'idée de Namuh ya 3ans et depuis, j'ai appris le C++, zbrush et maya pour lui. Dès que j'ai du temps libre je le dépense dessus. (Et Minecraft et Shootmania, restons sérieux)
Ya 3ans je rentrais en term, la depuis je refais une année de maths spé. Donc amateur complet.
Après, mon blog est pas super détaillé. Et le jeu est loin d'être fini.

J'ai fais mes débuts en 4em, en Dark Basic, et sa communauté t'aurai plu je pense : c'était un nid a projets, où j'ai vu beaucoup de démo jouable. Sans toujours aller jusqu'au jeu fini, elles allaient souvent a 90% de leur réalisation.
(Si l'on omet le diction qui dit que "quand un jeu est fini a 90%, il reste les autres 90%")

Mais j'ai du mal à comprendre pourquoi les gens lâchent si vite que ça. Le JV c'est tellement pluri-disciplinaire : photoshop, Zbrush, prog, la MAO, écriture du scénario, design du gameplay, etc... Quand yen a marre d'un truc, mettons photoshop, on peut passer a la prog ou a la musique.

Ya bien des gens qui passent plusieurs années sur WoW a taper des mobs. Alors pourquoi pas à faire un jeux vidéo ?

[Jereak]

La case de l'école c'est un peu "dommage" effectivement, puisque c'est quand même plus marrant d'être à l'arrache (enfin, personnellement, je préfère), tant que c'est encore possible.
[...]
J'aimerais beaucoup trouver un journal d'amateur complet qui expliquerait très régulièrement son avancée dans le développement d'un jeu...Avec le jeu fini (plus ou moins) à la fin.

Pour l'école, si c'est spécialisé jeux vidéo je ne sais pas trop comment ça marche. Mais si c'est de l'informatique en général, c'est plus que dommage : c'est clairement pas le bon choix.
J'entre en 3e année de ce qu'on peut appeler une "école d'ingénieurs en informatique" (les guillemets ne sont pas péjoratifs hein, il y a plein de choses bien), mais ce n'est clairement pas là que j'ai appris à coder et encore mois à faire un jeu vidéo.
On a bien eu des dizaines d'heures de cours de programmation (Java, C/C++, autres) et des projets de prog pas trop ridicules, mais quand je vois le niveau des étudiants qui se sont contentés de suivre ces cours ben... ça fait peur : la plupart seraient incapables de coder un Mario tout basique. Aucune école ne vaut un travail personnel acharné et la quantité de projets qu'on peut faire seul.

Sinon pour le "journal d'amateur", en ce qui me concerne j'essaie de tenir des notes au fur et à mesure de mon avancement dans mon projet actuel, et je pensais reprendre tout ça à la fin pour le rédiger un peu plus. Pourquoi pas en faire un petit article. Tout n'est pas très intéressant, mais si ça peut mettre en valeur des erreurs à ne pas faire, c'est déjà pas mal. Quand je l'aurai fait je te ferai signe si je me souviens de cette discussion.

Mais j'ai du mal à comprendre pourquoi les gens lâchent si vite que ça. Le JV c'est tellement pluri-disciplinaire : photoshop, Zbrush, prog, la MAO, écriture du scénario, design du gameplay, etc... Quand yen a marre d'un truc, mettons photoshop, on peut passer a la prog ou a la musique.

Entièrement d'accord ! C'est ce que je n'arrête pas de répéter aux gens qui me disent : "Mais comment tu fais pour passer ta vie à faire ton jeu, ça doit être chiant à force ?!". Mais ils ne veulent pas me croire.

[war-p]

Bah... j'ai eu l'idée de Namuh ya 3ans et depuis, j'ai appris le C++, zbrush et maya pour lui. Dès que j'ai du temps libre je le dépense dessus. (Et Minecraft et Shootmania, restons sérieux)
Ya 3ans je rentrais en term, la depuis je refais une année de maths spé. Donc amateur complet.
Après, mon blog est pas super détaillé. Et le jeu est loin d'être fini.

J'ai fais mes débuts en 4em, en Dark Basic, et sa communauté t'aurai plu je pense : c'était un nid a projets, où j'ai vu beaucoup de démo jouable. Sans toujours aller jusqu'au jeu fini, elles allaient souvent a 90% de leur réalisation.
(Si l'on omet le diction qui dit que "quand un jeu est fini a 90%, il reste les autres 90%")

Mais j'ai du mal à comprendre pourquoi les gens lâchent si vite que ça. Le JV c'est tellement pluri-disciplinaire : photoshop, Zbrush, prog, la MAO, écriture du scénario, design du gameplay, etc... Quand yen a marre d'un truc, mettons photoshop, on peut passer a la prog ou a la musique.

Ya bien des gens qui passent plusieurs années sur WoW a taper des mobs. Alors pourquoi pas à faire un jeux vidéo ?

Bah, en plus ElGato oublie les quelques projets présents sur le forum qui avancent régulièrement.

[LaVaBo]

On va construire un moteur de roguelike complet qui gérera entités, monde, affichage et son. Le cours du numéro 261 portera justement sur la structure du projet.

Il y a quoi alors dans le 260, tu reviens sur l'installation de l'environnement?