[Jeu Disponible!] Dope TrashCanners - Ouai, gros.

[yourykiki]

Je viens de tester, c'est vraiment sympa !

La musique et les graphismes sont cools, les armes donne un bon feeling, les bots sont durs !

Félicitation !

[Louck]

Merci .

Nous venons de déployer une nouvelle version du jeu, afin de résoudre le problèmes de connexion et d'affichage des lobby, en plus d'optimiser le système.

La prochaine étape est une version linux .

[Louck]

Je recherche un joueur sous Linux pour tester la nouvelle version le plus tôt possible.

Soit postez ici ou envoyez moi un MP .


Merci d'avance!

[yourykiki]

Yop je peux faire ca !

[Louck]

MP envoyé .

[Tchey]

Je recherche un joueur sous Linux pour tester la nouvelle version le plus tôt possible.

Soit postez ici ou envoyez moi un MP .


Merci d'avance!

Si c'est toujours valable, je peux tester la chose.

[yourykiki]

Je pense que ca pourrait être cool, pour voir si je suis un cas isolé avec le problème de passe muraille

[Louck]

MP envoyé aussi ! Je vais tester de mon côté en même temps

[Louck]

Ok c'est bien confirmé qu'il y a un problème de collision avec certains murs. Le plus étrange étant que la zone de collision est sur une même couche. Aucune idée d'oû cela peut venir.

EDIT: Bon c'est bien ce que je me doutais, certaines zones de collisions (qui ne sont pas de tailles fixes) sont mal prisent en compte par le jeu sous Linux. Je sais à peu près oû se trouve le code, reste à trouver un correctif et à tester.
Ca va prendre un peu de temps malheureusement. J'essaye de faire au mieux pour demain soir.

Merci à vous deux .

[yourykiki]

Bon courage

[Tchey]

Merci de supporter Linux, j'suis sûr qu'on sera plus de deux. Trois ou quatre, au moins.

Aucune idée d'oû cela peut venir.

EDIT: Bon c'est bien ce que je me doutais

Hummm...

[Louck]

Hummm...

Héhé .

Plus précisément, je sais où se trouve le code qui gère ce genre de collision (et heureusement, sinon ca serait horrible à chercher pour moi, sans debugger). Le vrai problème est que je n'ai aucune idée de pourquoi ca déconne: je ne fais pas non plus un code très technique et des calculs tellement fou que je mériterai un prix nobel.

Bref, je fais de mon mieux, normalement ce soir j'aurais quelque chose.

[Louck]

Merci à Tchey et à yourykiki pour les tests .

Je peux maintenant annoncer la sortie de la version linux

Télécharger la version Linux du jeu

Je fais une petite pause avant de poster un post mortem .

[schouffy]

J'ai joué avec les collègues à midi cette semaine. Unanimement, on a trouvé ça trop cool.
C'est fun, le feeling est bon, les assets sont top, le principe de base aussi. Les fins de parties sont complètement pétées avec des projectiles et des explosions dans tous les sens. En FFA c'est très drôle, en 2v2 c'est encore mieux.
Mon principal "reproche" : On ne peut jouer qu'à 4. Les maps sont assez grandes donc on passe parfois du temps à se trouver, et avec un plus grand nombre de joueurs ce serait encore plus fun je pense.
Après il y a des petits choses qui nécessitent des ajustements je pense, certaines armes sont pas très utiles et pareil pour les bonus (par exemple, la bombe quand on dash, super sur le principe, a une AOE tellement faible que c'est super galère de faire péter un mec avec).
Mais bon globalement c'est très positif, et on se refera sûrement des parties de temps en temps.
Bravo !

[Tchey]

Pas de moi, ce qui est une bonne chose, sur mon site de référence pour les jeux Linux : http://www.gamingonlinux.com/article...ing-twist.9294

[Louck]

Merci .

J'avais fait un post sur le reddit "linux_gaming". Ca a énormément de retours, c'est cool!
Par contre je pense que la communauté reddit est beaucoup basé sur le gratuit. Le jour où je ferais un jeu payant, aucune idée si j'aurais autant de monde .


En effet, j'ai que des retours positifs sur le concept, ce qui est cool. Je ferais bien un "DTC v2" avec un concept beaucoup plus approfondis (moins d'aléatoires avec un système de "classe", favoriser le "fun"de ceux qui gagnent, des NPC, etc...), mais ca implique de refaire tout le netcode du jeu (pour virer UNET) et de repasser un moment dessus.... J'attendrai une prochaine fois .

Mon principal "reproche" : On ne peut jouer qu'à 4. Les maps sont assez grandes donc on passe parfois du temps à se trouver, et avec un plus grand nombre de joueurs ce serait encore plus fun je pense.

Je pense que certaines cartes sont, en effet, trop grosses. Après il faut que le joueur puisse "respirer" entre deux conflits, ou doit pouvoir se planquer.
Pour se faire une idée, la map "référence" du jeu est Neighbourhood.

[Ashley TOUCRU]

J'avais fait un post sur le reddit "linux_gaming". Ca a énormément de retours, c'est cool!
Par contre je pense que la communauté reddit est beaucoup basé sur le gratuit. Le jour où je ferais un jeu payant, aucune idée si j'aurais autant de monde .

Ben, comme tu l'as dit l'autre jour sur Steam, on n'attend pas les mêmes choses d'un jeu gratuit et d'un jeu payant. Si, comme tu nous l'as indiqué, vous mettez les moyens pour créer un jeu plus riche et aussi pro que celui-là, je ne me fais pas trop de souci pour son succès. Les gens seront prêts à payer. Tout dépendra du prix.

[Louck]

Post mortem

Hola .
Avant de commencer, ce post mortem ne concerne que moi - mon expérience sur le projet - et pas toute l'équipe, étant donné que nous n'avons pas le même travail, ni le même point de vue.
Je tiens tout de même à remercier Uubu et Bigju pour leurs efforts, leurs idées et leurs super travaux sur le projet. Sans eux, il n'y aurait pas eu de DTC (et le nom du jeu serait encore moins glorieux).

Ca va sûrement parler un peu technique. Désolé pour ceux qui ne comprennent pas.
Enfin, contrairement à beaucoup de Post Mortem, je vais commencer par la partie "THE BAD".


THE BAD!

Le netcode (comme de par hasard!)
Plus sérieusement, faire un jeu multijoueurs en ligne n'était pas une mauvaise expérience. Mais ce n'était pas non plus un travail des plus fascinant, surtout lorsque nous sous-estimons tout ce qu'il faut faire pour rendre un jeu en ligne viable (de plus que j'ai un problème pour perfectionner mes projets).
Ci-dessous, je vais tenter de résumer tous les points noirs et obstacles que j'ai du surmonter, pour vaincre le goliath Netcode. Etape par étape.

Pour ceux qui ne veulent pas lire, je le résume en quelques lignes:

Spoiler Alert!

UNet et les parefeux ?
De.
La.
Merde.

• Niveau 1: L'échange des données

C'est sûrement la partie la plus simple du netcode, surtout avec le framework réseau d'Unity3D - UNet - qui permet de translater les données du jeu aux autres joueurs de la partie avec une simple ligne de code. Vraiment, c'est tellement enfantin que nous pouvons abuser de cette fonctionnalité sans problèmes. En ajout, UNet offre beaucoup d'outils pour pouvoir paramétrer la façon dont les données sont échangées sur le réseau, dont le QoS (Quality of Service).

Malheureusement, UNet a un gros problème pour gérer le perte de paquets: sur la version pré-release, il n'était pas rare que des joueurs meurent sans pouvoir respawn. Et lorsque le jeu prenait en compte notre mort, il n'était pas exceptionnel que notre cadavre ne disparaissait pas, ce qui provoquait le bug suivant: lorsqu'on tirait, aucune balle sortait de notre canon, mais de celui de notre précédent corps.
La solution à ce problème ? Utiliser le QoS le plus coûteux d'UNet, pour s'assurer que les données arrivent bien à destination, sans micro-coupures. Mais le coût de la bande passante explose .

Il y a aussi un truc un peu embêtant concernant les données: Il est difficile de savoir à quel moment un objet du jeu a été synchronisé avec le serveur et quand il était mis à jour. Le framework manque une fonction "LorsqueJeSuisSynchronise()", qui fonctionne comme un "Start()" classique mais pour le réseau.

Enfin, l'autre soucis à ce sujet, c'est que toutes les données sont gérées côté serveur. Dans le fond c'est bien, car les données sont bien synchronisés entre les joueurs et la réconciliation est très faible. Malheureusement le serveur envoi des informations en trop au client (dont certaines animations et l'usage des compétences), consommant la bande passante. Je peux éviter cela en faisant simuler certaines informations du côté client.

• Niveau 2: L'interpolation et la prédiction du mouvement des joueurs.

Dans une des premières versions du projet, je voulais vérifier si cela valait le coup que je fasse de la Prédiction cliente ou non. Pour ceux qui ne le savent pas: ca consiste à simuler le résultat envoyé par le serveur, afin de rendre le jeu beaucoup plus fluide et réduire l'input lag.

Au départ, je pensais que ce n'était pas nécessaire: avec une bonne connexion (à moins de 100ms), j'estimais que l'input lag serait très faible.
Après 20 secondes de test, j'en ai déduit que j'étais très con.


Tout ca pour dire que j'ai mis en place l'"Interpolation des données" et la "Prédiction cliente" sur notre projet.
Pour l'interpolation, c'est une des techniques le plus simple à mettre en place, mais il faut tout de même faire attention: il faut prendre en compte le temps du serveur lors de l'envoi de ses données, au milliseconde près, et de ne pas se fier au temps mesurés par le client... Erreur que j'ai fait.
Et lorsque j'ai dit au milliseconde près. C'est. Au. Milliseconde. PRES. La moindre imprécision peut créer des mouvements décalés et désagréables dans le jeu.

Concernant la Prédiction, j'utilise une méthode différente qui n'est pas la meilleure: La technique la plus connue est, après réception des données du serveur, de rejouer les actions faites par le client, depuis la dernière donnée reçue par le serveur (avec une marge de manoeuvre pour éviter les saccades). De mon côté, je recalcule la position du joueur à partir du dernier paquet: Cette technique fonctionne, mais peut produire des résultats étranges lorsque le joueur s'approche trop près de certains obstacles.

Malheureusement, j'avais un gros problème. Le genre de problème qui m'a pris plus de deux mois pour le résoudre.
Vous vous souvenez lorsque j'ai dit qu'il faut mesurer au milliseconde près le temps du serveur ?
Et bien c'est la même chose pour le client et dans l'envoi de ses actions (se déplacer, tirer, dash, ...).
Sauf que l'architecture réseau est assez sadique, surtout avec Windows: ON NE PEUT PAS MESURER AU MILLISECONDE PRES (ou du moins, très difficilement).

Le bug en question est que les données envoyées par le client arrivent tardivement, de quelques millisecondes, jusqu'au serveur. Donc, ce dernier interprète les mouvements du joueur avec un certain retard.
Le décalage en lui même est négligeable. Mais a force de se déplacer, le décalage entre le client et le serveur devient de plus en plus important, jusqu'à que le client corrige brusquement la position du joueur, en le téléportant.
La solution que j'ai mis en place pour ce problème est que le client corrige "délicatement" la position du joueur, au fur et à mesure du temps. La correction est à peine visible pour ne pas gêner l'action du joueur, mais est bien présente pour limiter les téléportations forcées et avoir une partie beaucoup plus synchronisée avec le serveur.


Bon! C'étais assez pénible cette partie... Je pense avoir fait le plus gros.... N'est-ce pas ?

• Niveau 3: Le Lobby

UNet possède une démo de son système de lobby en plus de son wiki. Malgré tout, j'ai eu quelques galères pour mettre en place ce système sur notre jeu.
Le truc le plus important à gérer pour un lobby c'est ses "échecs": lorsqu'un joueur perd la connexion, lorsqu'il rejoind un lobby complet, lors d'un timeout, etc... Sauf qu'UNet, malgré ses TROP nombreuses méthodes, reste une grosse boite noir à ce sujet: Nous n'avons aucune idée de comment les erreurs sont gérées et nous ne savons pas vraiment à quel moment les méthodes sont invoquées. Heureusement qu'une partie du code source d'UNet est accessible pour avoir une idée de comment cela fonctionne, sinon ca serait très pénible à déboguer. Surtout qu'il n'est pas possible de faire du débogage aisée avec UNet: la moindre perte de synchronisation et il faut recommencer les tests .

Bref, j'ai pas mal bidouillé le système de lobby pour qu'il fonctionne sur notre projet. Je plains ceux qui doivent travailler avec la couche de bas niveau.


Bon... Je pense avoir tout dit. Ca ne peut pas être plus chiant...

• Niveau 666: LA CONNEXION AU LOBBY

(littéralement)

Je savais qu'il fallait que je trouve une solution pour que les joueurs puissent se rejoindre. Par contre, j'ai sous-estimé la protection des routeurs/box, et sur-estimé la patiente des joueurs. D'ailleurs, beaucoup de routeurs filtrent aussi le port ICMP, qui permet de pinger les serveurs: les lobbys ne s'affichaient plus à cause de cela (le dernier patch corrige ce défaut).

Malgré les solutions que j'ai mis en place (UPNP/PMP, check du Master Server...), tant que les joueurs n'ont pas configurés leur routeur, personne ne peut joindre leur lobby. J'ai tout de même tenté de trouver une solution: il y en a plusieurs mais qui impliquent tous - sans exception - l'utilisation d'un serveur tiers (dédié ou VPS) qui a un certain coût financier. Au final, vu notre projet, j'ai pris le risque de ne pas mettre en place cette solution.
Par contre, je recommanderai à tous ceux qui se lancent dans la réalisation d'un jeu en ligne de réfléchir à cette étape.

Pour le Master Server, je suis passé par un serveur Web assez simple. Mais il fallait que je passe sur un service payant, car la version gratuite ne pouvait pas survivre 10 utilisateurs concurrents (si ce n'est pas moins).



Pfiou, j'ai résumé à peu près mes galères avec le netcode du jeu. Je pense avoir loupé beaucoup de détails. Mais l'essentiel est là.

Si c'étais moins pénible, j'aurais travaillé sur une partie "communautaire" pour le jeu. Mais j'aurais eu besoin d'encore plus de temps pour mettre en place cela.

Bon après je me plains beaucoup. Mais en outre du problème de connectivité, je pense que je m'en sors assez bien avec le netcode du jeu... en comparant à beaucoup de jeux (dont les plus récents).


La charge de travail
A la base, j'ai estimé la réalisation du jeu sur 4 mois avant la béta-test. Pour tenir ce délai, j'ai du passer de nombreux soirs à développer les règles et les fonctionnalités du jeu.
Sauf que j'ai mal calculé:
- La charge de travail d'un jeu en ligne.
- Le temps pour faire les bruitages du jeu.
- Ma connerie de vouloir faire du "bon" contenu.

Ce qui fait que le projet a duré presque une année et six mois... à passer de nombreux soirs à développer. Du coup, à vouloir trop travailler, je perdais petit à petit la motivation et l'envie de continuer, en plus de me fatiguer .

Bon, c'est des choses qui arrivent, lorsque nous manquons d'expériences ou lorsque nous cherchons à estimer vers le bas la charge de travail. La prochaine fois, je me fixerai une limite sur mon temps de travail, au risque de prendre plus de temps à produire un jeu.


Level design
Nous avons tentés de diversifier les maps du jeu dans le concept et en jouant avec les couleurs.
Cependant le résultat est que nous avons réalisés des maps bien trop grandes et peu diversifiés graphiquement (malgré les couleurs), en plus de manquer d'une certaine dynamisme. De mon point de vue, en outre de la partie multijoueurs, c'est notre plus gros point faible. Nous essayerons de retravailler cela pour le prochain projet.




THE GOOD!

Unity3D
Personnellement, DTC est mon premier gros projet que je viens de réaliser sous Unity3D. Par gros, je parle d'un projet qui dure quelques mois et qui ne concernent pas une gamejam .
Malgré les défauts et ses limitations que je pouvais surpasser avec mon moteur fait maison (cf notre ancien jeu "Punxel Agent"), Unity3D offre malgré tout énormément de choses à notre projet, que ce soit dans la facilité de faire fonctionner et tester un jeu, et dans ses nombreux composants graphiques, physiques et utilitaires qui simplifient grandement la vie. Tous ces plus ont un énorme impact sur la qualité de notre jeu: entre Punxel Agent et Dope TrashCanners, il y a eu un gros pas (les travaux extraordinaires d'Uubu et de Bigju ont beaucoup joués aussi ).


Système de "Modifiers"
En plus de vouloir faire un jeu multijoueurs sous Unity, je voulais aussi réaliser un système de "Modifiers" modulables, qui pourrait être réutilisés dans les prochains projets.
Par "Modifiers", je parle des attributs passives que je peux attribuer à un élément du jeu, que ce soit une modification d'une propriété (point de vie d'un joueur, temps de réapparition d'une caisse, ...) ou un "événement" (effet lors d'un Dash, effet lors d'une attaque ...). J'ai surtout utilisé ce système pour gérer les compétences du jeu: lorsque le joueur sélectionne une nouvelle compétence à sa mort, je lui applique un Modifier. Derrière, le système fait en sorte de gérer l'accumulation de ces Modifiers, le délai d'exécution, et bien d'autres choses.

A l'origine, je pensais que ce système serait très compliqué à mettre en place. En réalité, cela m'a pris que peu de temps et le résultat est épatant (le langage C# aide pas mal). Il n'est pas encore parfait, mais j'en reste très content .


Analyse des données du jeu
Etant donné que nous travaillons sur un jeu multijoueurs, je voulais mettre en place un outil d'analyse pour vérifier le nombre de serveurs et le nombre de joueurs qui se connectent. C'est la première fois que je met en place un système du genre, mais elle m'a apportée énormément d'informations sur la façon dont les joueurs jouent au jeu. C'est d'ailleurs grâce à ça que j'ai pu déceler certains bugs de connexion au lobby.

C'est un outil que nous sous-estimons beaucoup. Je vais le réutiliser dans le prochain projet, pour mieux analyser le comportement des joueurs . Peux-être que je vais exploiter Google Analytics pour ca.

PS: La seule information "critique" que je récupère des joueurs est l'adresse IP hashé. C'est tout .




NEXT!

Suite à ce projet, je n'ai plus trop envie de me replonger sur la réalisation d'un jeu multijoueurs en ligne. Même s'il y a une demande, cela nécessite beaucoup de travail pour le réaliser et de payer un serveur (ou de mettre en place une solution pour gérer la connectivité P2P). Cependant, si un futur projet fonctionne bien, il n'est pas impossible que je retravaille cette fonctionnalité .

Je vais continuer à travailler avec Unity3D. Ce framework est un peu overkill pour faire de la 2D (par rapport aux autres moteurs), mais m'offre la capacité de créer et de faire évoluer mes propres "outils". Ce qui est un gros plus pour moi, en plus de sa facilité d'utilisation et de ses composants.

Mon prochain objectif est de commercialiser un jeu-vidéo. Je pense que nous avons acquis assez d'expériences pour pouvoir nous lancer dedans, avec la superbe équipe que nous sommes .
L'autre objectif est de peaufiner le game-design. DTC a un bon pitch et une idée intéressante, mais, à mon avis, ca manque de profondeur et a des points noirs que nous devons retravailler.


Je vous dis à bientôt pour un prochain projet .

[Ashley TOUCRU]

Ton résumé est très intéressant, même pour quelqu'un comme moi qui ne comprends pas en détails l'ensemble des explications -plus particulièrement je suis une bille en réseau. C'est presque le genre de texte qui devrait figurer en tête de la discussion "Réaliser son jeu avec Unity" car j'imagine qu'il doit bien refléter toutes les étapes que l'on peut rencontrer quand on se lance dans un jeu, même sans ambition de le commercialiser.
En tous cas, encore merci pour DTC qui nous a fait passer quelques heures bien sympa. Et connaissant les copains avec qui je joue, il n'est pas exclu qu'il soit relancé de temps en temps.

[Joq le pecheur]

Super projet, super résumé, et bravo d'être allé au bout !

[Hideo]

J'aime beaucoup le travail qui vous faites, j'ai hâte de voir votre prochain projet


Merci pour le Post Mortem, une très belle façon de conclure !
Petite question sur tes Modifiers, ta description me faire fortement penser au patern decorator tu es partis dans cette direction la ou tu as fais quelque chose de différent ?

[raaaahman]

Félicitations d'en être venu à bout! (On a même une version lunux, c'te classe)

Pas de grande surprises sur les difficultés que tu as rencontré pour la partie réseau, on en a déjà entendu parlé. Mais c'est chouette d'avoir pris le temps de résumer et mettre en forme tout ça, ça pourrait en avertir d'autres qui voudrait se lancer dans "un petit jeu multi, tout simple".

[Louck]

Merci .

Petite question sur tes Modifiers, ta description me faire fortement penser au patern decorator tu es partis dans cette direction la ou tu as fais quelque chose de différent ?

C'est presque ca. Disons que j'utilise le système d'événement de C# (qui suit à peu près la même idée que le pattern Decorator).

Pour simplifier, un Modifier peut être soit:
- Un modificateur de valeur.
- Un événement.

Chaque Modifier est lié à un type ou à un code.

Par exemple tous les Modifiers qui ont un impact sur les points de vies du joueur utilisent tous le code "HEALTH_MODIFIER". Le joueur débute avec 100 HP, et possède deux Modifiers: un multiplicateur par 2 et un autre multiplicateur par 3.
Lorsque je veux connaitre les HP réels du joueur, j'invoque la fonction dédiée avec le code "HEALTH_MODIFIER" qui me retournera le résultat 600 (100 * 2 * 3).

Pour les événements c'est légèrement différent: je ne récupère pas un résultat mais j'invoque tous les fonctions qui sont liées à un code.


L'objectif de ce système est que je puisse ajouter aisément des modificateurs d'attributs et des événements/compétences au jeu sans me préoccuper du système qu'il y a derrière.
Pour l'instant, ca ne concerne que des attributs et compétences passives. Pour les compétences actives, c'est une autre histoire.

[yourykiki]

Félicitation à l'équipe pour être resté motivé jusqu'au bout !
De mon point de c'est difficile de raler sur le manque de profondeur pour un tel jeux (Gratuit et produit par des bénévoles), surtout que le feeling et l'idée sont bons.

Du coup c'est quoi le point de vue de Uubu et bigju sur le fait de bosser sur un jeu vidéo gratos mené par toi ? :D

[Grhyll]

Intéressant, tout ça ! J'ai d'ailleurs fait passer à des amis qui vont avoir besoin de se pencher prochainement sur du réseau

[Bigju]

Du coup c'est quoi le point de vue de Uubu et bigju sur le fait de bosser sur un jeu vidéo gratos mené par toi ? :D

Salut à tous et merci pour les retours le jeu et la musique, c'est cool. Je passe rarement par ici pour commenter mais j'ai suivi le thread en lecteur.

Pour ce qui est de mon ressenti je vais aller droit au but : bosser "gratos" c'est évidemment quelque chose que j'évite, et c'est très souvent quelque chose que je dénonce, que ça soit pour mon métier ou celui des autres (les graphistes se reconnaîtront).
Après je suis conscient que dans des projets amateurs le pognon est un élément complètement inexistant, qui plus est dans un milieu comme le JV qui est saturé d'offre, avec une attention quasi-monopolisée sur des grandes entreprises, du coup quand j'ai du temps j'essaie de m'intéresser à certains d'entre eux. Parce que la plupart du temps dans des projets indés la musique est souvent confiée à des amateurs, et le résultat n'est pas forcément à la hauteur du travail réalisé en dev et design, puisque c'est un peu le parent pauvre.

Quand on a commencé à parler de Punxel Agent avec Louck, il avait déjà fini Hâtü et je savais qu'il pouvait finir un projet. Et c'est sa principale qualité en tant que dev, il finit les choses, sans les bâcler, probablement avec du retard (c'est normal, une deadline c'est fait pour être dépassé ), mais il va au bout, et c'est une qualité malheureusement trop rare (je juge personne, c'est très très compliqué de finir un jeu vidéo, d'autant plus quand on est amateur ). Mais personnellement c'est tout ce que j'attends de projets comme Punxel ou DTC, c'est un pari sur l'avenir.

Je sais que le prochain projet sera encore meilleur, et que ça deviendra payant à un moment ou à un autre, aussi bien professionnellement que financièrement.

[Tchey]

Merci de partager ces pensées, la lecture est intéressante.

[Uubu]

Merci pour vos retours ! Content que ça vous plaise.

Du coup c'est quoi le point de vue de Uubu et bigju sur le fait de bosser sur un jeu vidéo gratos mené par toi ? :D

Je vois ça comme une collab', qui pourrait mener à un projet plus conséquent. Et puis plus simplement, c'est cool de bosser avec Louck !

[Louck]

Toujours cool de bosser avec vous deux!

[Louck]

J'ai fais un petit tour sur Youtube, par pur hasard, avant de tomber sur pas mal de petites vidéos sur notre projet .







D'ailleurs, c'est une chose que nous négligeons beaucoup avec les vidéos YouTube: en dehors d'apporter une visibilité, ca permet de voir comment les joueurs jouent à un jeu et d'avoir leurs commentaires en direct. Ce qui est très intéressant pour nous .