# Jeux vidéo > Jeux vidéo (Discussions générales) > Le coin des développeurs >  [Jeu Disponible!] Dope TrashCanners - Ouai, gros.

## Louck

_This is hella bitchin!_


Télécharger le jeu
(Versions windows et linux disponibles)

*Réalisé par Louck (moi / développeur), Uubu (graphiste) et Bigju (compositeur)*

Comme annoncé dans mon topic "Unity Networking", j'avais pour projet de réaliser un nouveau jeu multijoueurs pour la fin de l'année, autour d'un concept.
Grâce au soutien de la Punxel Team (Uubu et Bigju), ca va envoyer du lourd.


*Dope TrashCanners*
Dope TrashCanners (ou DTC) est un jeu de shoot multijoueurs en 2D, dans lequel le but est de se faire un maximum de points en abattant ses rivaux.
Sauf que la particularité du Dope, c'est qu'à chaque fois qu'un joueur meurt, ce dernier revient... avec de nouveaux pouvoirs.

Votre pistolet ne fait pas le poids contre un fusil d'assaut ? Maintenant vous pouvez tirer trois fois au lieu d'une.
Ce n'est pas suffisant ? Allez, vos tirs peuvent rebondir contre les murs. Et si besoin, ils peuvent exploser au contact. C'est cadeau.
Vous mourrez trop souvent quand même ? Un petit bouclier vous fera du bien.
Mais au final, vous voulez changer de style de jeu ? Entrez en mode Berserker!

L'idée derrière ce concept est que les joueurs les plus faible peuvent se rattraper - se venger - en devenant de plus en plus fort techniquement, tout en offrant de nouveaux défis et de contraintes aux joueurs les plus forts.
La finalité est que la partie s'équilibre au fur et à mesure du temps, tout en la rendant fun pour les deux camps  ::): .

Bien sûr, les plus forts seront aussi récompensés pour leurs efforts... en effets graphiques, en une meilleure bande sonore, et en score  :;): .


Je résumerai l'avancé du projet dans ce topic. Pour les plus curieux, j'ai mis en place une page Trello (lien en haut du post).



*Point technique*
Le jeu sera développé sous Unity (dernière version). J'ai importé les systèmes/codes que j'ai réalisés sur mes précédents projets (dont l'IA) sous Unity.
Pour la première version du jeu, je vais utiliser les composants de base d'Unity pour réaliser la partie multijoueurs.

Aucune idée s'il y aura un système de matchmaking made-in-Unity, ou une simple liste de serveur. Cela dépendra des contraintes de gérer un master serveur seul.
Pour finir, les parties multijoueurs seront limités à 4 joueurs, seulement en ligne. Cette condition peut évoluer.

Si je souhaite que le jeu soit jouable sur navigateur, je ne confirme pas sa faisabilité (pour cause des contraintes techniques d'Unity3D pour le multi).
Sinon, le jeu sera jouable sous Windows, Linux et Mac, et sera optimisé de façon qu'un simple PC portable Dell puisse faire fonctionner le bousin  ::): .

Le jeu sera optimisé pour jouer au clavier + souris, étant donné le style du jeu. J'essayerai pour autant de faire fonctionner une manette XBox dessus.

Et ca sera gratuit  ::): .


A plus sous le bus!

----------


## schouffy

Aaah la patte Uubu !
Hâte de voir ce que ça va donner.

----------


## Grhyll

Oooh toujours aussi beau :D Bien curieux aussi !

----------


## Uubu

Merci, content que ça vous plaise !  ::lol::

----------


## Gwargl

Les graphismes de père U(u)bu me rappelle furieusement les zinzins de l'espace et Oggy et les cafards. Un lien ?

----------


## Ifit

Super, hésite pas à faire des points techniques c'était très intéressant.

Par contre pour le concept des faibles sont aidés pour rattraper les forts, vous pouvez aussi faire les forts ont des armes de plus en plus dur à utiliser pour kill (commencer au bazzoka , finir au petit pistolet). Et a chaque kill changement d'arme vers une arme plus faible/dur à utiliser.

C'est le principe d'un mod sur dota2 reborn : rubick wars. (c'est gratuit)

----------


## Uubu

J'avais plutôt The Grocery de Guillaume Singelin et Puppetmastaz en tête, mais ouaip j'aime bien les Zinzins également :  ::P:

----------


## Louck

> Par contre pour le concept des faibles sont aidés pour rattraper les forts, vous pouvez aussi faire les forts ont des armes de plus en plus dur à utiliser pour kill (commencer au bazzoka , finir au petit pistolet). Et a chaque kill changement d'arme vers une arme plus faible/dur à utiliser.


C'est une idée. Mais ca va devenir un peu plus compliqué à équilibrer si on doit pénaliser les plus forts ET booster les plus faibles  ::P: .

Par contre pour varier un peu les parties, les joueurs choisissent une arme au départ (parmi 6) ainsi qu'une "spécialisation", qui aura un impact sur la sélection des compétences. Par exemple, la spécialisation "Offensive" permet d'acquérir plus facilement des pouvoirs agressifs, lorsque notre protagoniste meurt  ::): .

----------


## Ifit

Je pensais plutot soit l'un soit l'autre, mais pas mixer les  2 concepts. Autrement c est trop dur  et quasi aucun reward au skill des joueurs

----------


## Poussin Joyeux

Super! Bonne chance pour ce nouveau jeu!  ::lol:: 

Tu vas gérer comment les personnages qui seront cachés derrière les immeubles? (si ta copie d'écran représente l'écran de jeu).

----------


## Louck

Ahah!

Magie  :Cigare: 




Spoiler Alert! 


Je pense qu'on fera en sorte que les personnages ne puissent pas passer derrière les immeubles, tout en laissant des marques au sol pour guider les joueurs. Sinon ca risque de flouer l'action (même si on affiche des ombres à travers les murs).



Sinon l'image affiché provient d'un concept d'Uubu. Les images/sprites seront bien là, mais il est peu probable qu'une map du jeu ressemble à ca  ::): .

----------


## Gafda

ohhh, trop bien ! Hâte de voir comment ça va se goupiller  :;): 

Le pixel'art est juste génial  :Bave:

----------


## Hideo

Abeaunhé !

----------


## BourrinDesBois

Super idée les gars, ça peut être vraiment fun et en plus c'est original, j'aime toujours autant la pâte, bien vu!

----------


## raaaahman

L'idée de booster les faibles me plaît bien, ça rajoute un côté fun pour des parties ou on se prend pas trop au sérieux. Et puis la Punxel Team qui en remet une couche, je ne peux qu'adhérer.  ::):

----------


## hyper

Ça va envoyer du pâté tout ça !
Abonné  ::P:

----------


## Louck

Merci pour vos premiers messages. C'est très motivant pour nous  ::): .

Pas grand chose à poster cette semaine. De mon côté, la réalisation du jeu débute sur la mis en place d'un système d'IA pour remplacer les joueurs absents. Et faire des bots qui en soient pas trop idiots, ca prend du temps  ::P: .

En outre, j'ai pu avancer sur le développement des armes et des spécialisations, dont en voici la liste (qui peut évoluer si besoin):


*Les armes: Le joueur sélectionne une seule arme au début de la partie et ne peut le changer*
*Fusil d'assaut*: L'arme le plus basique du jeu. La cadence est assez élevée, c'est assez précis et ca fait mal.*Revolver* (the "Gun", bro): Arme la plus précise du jeu, mais qui est limitée en nombre de tirs. Malgré sa faible cadence de tir, elle reste une arme très puissante qui peut abattre ses adversaires en quelques coups.*La mitraillette* ou le "Pew Pew": Est d'une cadence très élevée et peut se montrer très dangereuse. Meilleure arme pour flooder une zone de balles, mais reste la moins précise, la plus difficile à contrôler.*Le shotgun*: Ses cartouches permettent de faire un triple tir, mais avec une certaine imprécision. Au point blanc, l'arme est mortelle. Mais dans une portée plus éloignée, il devient moins facile de toucher ses ennemis.*Lance-roquettes*: Pour les amoureux des explosions. Meilleur moyen pour toucher les cibles quand on ne sait pas viser. Cependant l'arme n'est pas très maniable - par son recul, sa cadence et sa surcharge - et un seul tir ne suffit pas pour mettre en miette ses rivaux.*Lance-flammes*: Ne fonctionne que sur une très courte portée, ce qui rend l'arme très compliquée à utiliser dans des lieux ouverts. Néanmoins, ses flammes brûlent ses cibles, causant de lourds dégâts aux victimes.


*Les spécialisations: Le joueur peut se spécialiser (ou non) dans une branche de compétence et acquérir un faible bonus. Les noms peuvent changer.*
*Offensive*: +% dégâts et tailles des tirs. Spécialisation dans la branche "Attaque".*Défensive*: +% HP. Spécialisation dans la branche "Résistance".*Tactique*: +% vitesse dé déplacement. Spécialisation dans la branche "Utilitaire".*Duelliste*: -% délai de régénération. Spécialisation dans les branches mixtes "Attaque / Résistance".*Contrôle*: -% délai de récupération du Dash (ou "Roulade"). Spécialisation dans les branches mixtes "Résistance / Utilitaire".*Assassin*: -% surcharge arme. Spécialisation dans les branches mixtes "Utilitaire / Attaque".*RIEN*: Le joueur peut choisir de ne pas se spécialiser dans une branche spécifique et de recevoir aucun bonus. La contre partie est qu'il aura accès à toutes les compétences, et plus facilement aux compétences de la branche "Ultimate".


En même temps, je vous apporte des détails supplémentaires aux éléments du jeu  ::): .

*Les compétences*
Les compétences sont partagées dans 4 branches différentes: Attaque, Résistance, Utilitaire, et "Ultimate".
Les trois premières branches sont assez explicites: Soit on veut faire mal, soit on veut tenir dans les affrontements, soit on veut acquérir quelques outils pour retourner une certaine situation. Ces compétences sont conçus de façon que cela apporte un certain intérêt au joueur de les prendre, mais aussi qu'elles puissent impacter la tactique de l'adversaire.

Ensuite, nous avons la branche "Ultimate": C'est une branche spéciale, unique, qui peuvent impacter le gameplay du joueur.
J'avais évoqué, mon premier post, le mode "Berserker". C'est une compétence Ultimate qui apporte un gros buff aux dégâts du joueur, au fur et à mesure qu'il perd de sa vie. Cependant, il ne peut plus régénérer ses points de vies automatiquement.


*La surcharge des armes*
Les armes n'utilisent pas de munitions mais peuvent "surcharger": plus le joueur tir, plus son arme brûle. Si le joueur arrête de tirer durant un court laps de temps, l'arme se décharge rapidement.
Mais si le joueur ne s’arrête pas de tirer et dépasse la "limite", l'arme ne peut plus tirer et se décharge lentement.
En gros, je reprend le système qui est utilisé sur Punxel Agent  ::): .

En outre, le joueur peut régénérer ses HP au bout d'un long moment d’inaction (= une dizaine de secondes). La carte regorge de pack de soins qui ont pour but d'enclencher instantanément la régénération, dès que le joueur en ramasse un.
Par contre, si deux joueurs s'affrontent et qu'un des deux ramasse un pack, l'autre joueur peut l’empêcher de récupérer toute sa vie en le touchant (avec ses balles, hein).


*Le Dash*
Le joueur peut faire un "Dash" - ou une roulade - qui lui permet d'esquiver certains tirs et de passer derrière ses ennemis. Malheureusement, il y a un délai entre chaque utilisation d'une roulade.


Voila pour les derniers détails sur le projet  ::): .

Dès que le projet sera un peu plus avancé, nous pourrons spammer ce topic d'images et de sons  :;): .

----------


## raaaahman

> Dès que le projet sera un peu plus avancé, nous pourrons spammer ce topic d'images et de sons .


J'ai bien hâte!  :;): 

Je trouve juste un peu étrange le choix de ne limiter les joueurs qu'à une seule arme pour la partie, c'est toujours fun la course pour le spot de l'arme de folie. Bon, on verra bien.

----------


## Louck

> Je trouve juste un peu étrange le choix de ne limiter les joueurs qu'à une seule arme pour la partie, c'est toujours fun la course pour le spot de l'arme de folie. Bon, on verra bien.


C'est une très bonne remarque  ::): .

En faite, je veux éviter le problème d'armement que possède Quake: "Le joueur débute avec arme classique et doit aller chercher mieux sur le terrain".
Le problème avec cette méthode, c'est que lorsqu'un joueur meurt, il perd tout son équipement et réaparait avec l'arme standard... contre des adversaires qui possèdent des armes bien plus puissantes, dont des lances-roquettes ou railguns.
La mort dans cette situation est très pénalisante et peut créer un certain déséquilibre, surtout en mode deathmatch. Si l'adverssaire est assez fort, il peut connaitre les points d'apparitions du terrain, et les "camper" afin de se faire des kills faciles.

La solution qui est utilisée par les jeux récents, c'est que le joueur débute directement avec une arme en main: pas de déséquilibre durant la partie, les joueurs s'affrontent sur un même niveau (en théorie).
Néanmoins, et en effet, il n'y a plus la course d'armement de Quake qui peut créer des situations intéressantes.

Pour ca, la solution que j'ai trouvé est de mettre en place des packs ou des bonus - dont les packs de soins - afin d'encourager les joueurs à rejoindre une certaine zone de la map et de récompenser ceux qui remportent l'affrontement dans la dite zone  ::): .
Après, ca ne se limite pas forcement à des packs de soins. Ca peut être des packs qui offrent un bonus aux dégats, un bonus de déplacement, etc...


Sinon, une règle qu'on peut mettre en place est que le joueur lache son arme à sa mort. Mais le joueur qui a abattu sa cible doit avoir une certaine motivation pour ramasser l'arme de la victime. Cela implique une action supplémentaire qui n'est pas forcemment intéressante, étant donné que le jeu ne contiendra pas 30 armes, et que ces derniers sont tous accessibles.
Sauf si quelqu'un arrive à me convaincre que cette idée est, malgré tout, bonne  ::P: .


L'objectif de proposer plusieurs armes au départ (et des spécialisations) est de faire varier le gameplay.
Ensuite, les parties seront très courtes (environ 3 à 5 minutes). Si un joueur a du mal à jouer avec une arme durant toute la partie, il recevra des compétences qui peut l'aider dans sa tâche. Au pire, il perdra quelques minutes.


Maintenant tout ce que je dis, c'est des hypothèses suite à mon expérience. Il y aura des tests sur le jeu: Si je vois que le système n'est pas fun, je trouverai une solution (par exmple, donner la possibilité de changer d'arme en cours de partie).

Mais c'est toujours bien de le souligner  ::): .

----------


## Louck

Le projet avance doucement mais sûrement. Je peine un peu avec l'IA, mais c'est normal: c'est chiant de faire un bot qui ne soit pas trop con  ::P: .

J'avais prévu de réaliser ce projet en deux ou trois mois... Au final, il nous en faudra un peu plus de temps, afin d'avoir un petit jeu qui claque  ::): .


Après avoir fixé les règles du jeu, nous commençons à travailler sur l'interface du jeu, sur ses éléments graphiques, et sur son "flow musical". 
La finalité est de pouvoir réaliser une jolie petite vidéo de notre projet pour vous le présenter. Une sorte de trailer  :;): .


Allez soyons fou: Je suis un très mauvais devin, mais je me donne un mois pour que le jeu n'utilise plus des carrés colorisés comme ressources graphiques  ::P: .

----------


## Louck

Semaines de galère pour coder un pathfinding correct. Mais je m'en sors  ::P: .
Les premières images commencent à s'intégrer dans le jeu. Il y a encore du travail, mais dès que l'essentiel est là, le trailer pourra se faire  :;): .

----------


## schouffy

Tiens j'ai jamais fait une utilisation en "prod" du navmesh. Tu utilises ça ? ça se passe pas bien ?

----------


## Hideo

Par curiosité tu utilises un algorithmes 'connu'  type A* pour ton pathfinding ?

----------


## Grhyll

(Je m'incruste pour répondre à schouffy : ouais ça marche pas mal  ::):  Y a quelques subtilités à saisir pour que ça marche bien comme tu veux, mais dans l'ensemble c'est quand même pas mal pratique, malgré certaines limitations. Et ça utilise un algorithme proche du A* je crois.)

----------


## schouffy

Tu l'as utilisé sur un "vrai" jeu, avec plein d'agents, ça se passait bien niveau perfs etc etc..?

----------


## Grhyll

Alors je l'utilise sur Furi, qui je l'espère peut être considéré comme un vrai jeu :D Par contre on a pas des masses d'agents. On utilise des offmesh link, des navmesh obstacles, y a eu une belle améliorations sur les performances de ces derniers avec Unity 5.jesaisplucombien d'ailleurs. A l'exception de quelques petites fonctionnements pas clairs dans la doc qu'il faut déduire soi-même, c'est pas mal chouette (et surtout bien intégré dans Unity, forcément).

----------


## schouffy

OK merci, c'est intéressant  ::):

----------


## Louck

Pour répondre rapidement, non je n utilise pas le navmesh d'Unity mais je réutilise mon système de pathfinding de Punxel Agent (algo Djikstra) avec quelques améliorations  ::): .
La grosse avantage de mon système est que la génération se fait tout seul (pour les maps sous Tiled) et j'ai un controle total sur le mouvement des bots. Ce n est pas la solution la plus optimisée mais je peux faire ce que je veux  ::):  (et il marche très bien  ::P:  ).

C est une des rares fonctionnalités d Unity que je n utilise pas nativement.

----------


## Louck

Enfin finis avec les bots  ::lol:: .

J'ai repris le système que j'ai mis en place sur Punxel Agent pour faire l'IA du jeu: Le *Behaviour Trees*.
Mais contrairement aux vilains de Punxel, la racaille de DTC ne possède pas plusieurs états. En réalité, ils ont tous le même objectif et un même comportement, mais avec quelques variables: l'un réagira plus vite aux attaques, un autre se focalisera sur les powerups du jeu, alors que le dernier sera plus en retrait. Au final, ils suivent une même branche "Search & Destroy": je pouvais faire le même code avec plusieurs gros bloc de "SI/SINON", des probabilités et des timers.

Est-ce que c'est un bon signe ? Difficile à dire vu que les bots suivent les règles du jeu. Et les règles sont très simple: chercher des powerups ou abattre ses rivaux. Cependant j'ai pu remarquer que le gameplay que j'ai mis en place n'était pas assez "jouissif". Si je voulais comparer un Quake/UT-like à mon jeu, ce dernier sera très pale et lent. Pour un jeu d'action, c'est bof.

Ainsi, je pense revoir un peu les règles du jeu dans l'objectif de le rendre un peu plus dynamique, tout en retravaillant un peu la technique: Le dash, les powerups et les armes, le "screenshake"... et bien sûr, le déplacement des protagonistes (pour un jeu en 2D en top-down, ca va être très compliqué  ::P: ).
Je vais en reparler durant la phase de peaufinement du jeu.



En attendant, je m'attaque un peu plus à l'intégration des éléments graphiques  :;): .

----------


## Tchey

Je veux.

----------


## Louck

Hey  ::): .

Je suis en pleine période de déménagement, pour le mois de Décembre. Du coup je n'ai pas beaucoup de temps devant moi pour bien avancer le code du projet durant ce dernier mois de l'année 2015.

Néanmoins, le projet va bientôt sortir de sa phase pré-alpha: le cœur du jeu est fait et tous les éléments nécessaires au bon fonctionnement d'une partie sont réalisés. A partir de là, c'est surtout une question de contenu, d'UI, d'images et de sons... avant la béta  ::): .
Par contre, je ne prévois pas de réaliser une démo publique comme pour Punxel Agent: cela nécessite beaucoup de temps et il est assez compliqué de faire une démonstration d'un jeu multijoueurs...


Bref!
Malgré le peu de temps que j'ai devant moi, je revois les règles du jeu pour rendre ce dernier plus dynamique (selon le problème que j'ai mentionné dans mon précédent post). C'est globalement des réglages à faire, ce qui n'est pas trop compliqué  ::): .

Je réfléchis aussi à réaliser une version anglaise du jeu. Pour un jeu exclusivement multijoueurs, j'estime très important de présenter notre jouet à des joueurs non-francophone  ::): . D'ailleurs, ce n'est pas quelque chose de très difficile à mettre en place: c'est surtout une fichier texte qui recense toutes les phrases du jeu sous différentes langues, chacune identifiée par un code. Etant donné que notre jeu d'action ne contient pas beaucoup de mots, ca peut se faire relativement vite  ::): .
Je vais m'amuse un peu avec le JSON dans ce cas  ::P: .

----------


## Hyperpenguin

Et une petite vidéo de gameplay ?  :Emo:  les sprites ont l'air trop mignon!

----------


## Hideo

Un teaser pour nowel :3

----------


## Louck

Ahah vous êtes gourmands  ::P: .

Il y aura bien un petit trailer pour le jeu. Cependant la priorité est la révision du gameplay (c'est sur quoi je travail actuellement).
Suite à ca il y aura des sessions de tests en interne afin de voir si tout est ok  ::): .

Je pense que je vais enregistrer ces sessions pour pouvoir faire la fameuse vidéo  :;): . Mais tout ca pour dire que ca ne sera pas pour maintenant malheureusement.

----------


## Gafda

Fais tournay les screens  :Vibre:  :Vibre:

----------


## Louck

Genre ca ? 
[MAJ]





http://s1.webmshare.com/6BVNn.webm

 ::trollface::

----------


## Hideo

:Bave:

----------


## schouffy

mdr l'affiche avec marqué teub  :^_^:

----------


## Louck

Bonne année  ::lol:: 

Je sors enfin de ce mois de décembre qui était très chargé IRL (qui peut se voir face aux dernières modifications sur le Trello  ::P: ). Je reprend le développement du jeu dès cette semaine  ::): .

Je vais essayer de mettre la double dose pour ce mois-ci.Je veux essayer de récupérer le retard et approfondir le netcode du jeu: Je vais nager dans la joie du Master Server, de l'Interpolation des données, de la prédiction des actions du joueur, et de la compensation de latence des projectiles. Woohoo  ::lol:: .
Je pense que je ferais un post détaillé sur la première version du netcode de notre projet - selon mon point de vue - dans les prochaines semaines  ::): .

Malheureusement, je n'aurais pas encore eu le temps de faire un trailer vidéo. J'essaye de planifier ca pour Février, dès que j'aurais un peu plus de lisibilité sur les tâches restants du projet.

----------


## Hyperpenguin

Bon courage! Et sinon la BO est comment? Y'a déjà des extraits?

----------


## Louck

Pas encore de concret au niveau de ma musique, malheureusement. Je préfére ne publier que des éléments finis ou qui soient "présentables", surtout pour ce genre de projet.

Tout ce que je peux énoncer, c'est que nous sommes partie sur un genre Hip-Hop ou assez proche, et que le ton de la musique évolue au fur et à mesure de la partie.
Mais vu que rien n'est encore fait, je ne peux pas confirmer le genre.



Spoiler Alert! 


Mais il est vrai qu'un genre proche de "Rage Against The Machine" serait cool  :;):

----------


## Louck

https://gfycat.com/ArcticHappygoluck...snappingturtle

Hopla  ::): .

Pendant que j’intègre les dernières réalisions d'Uubu, je m'occupe un peu plus du code réseau du jeu. 
Et autant dire - même si je me suis amusé à faire une architecture multijoueurs l'année dernière - que cela représente un très gros défi  ::P: .

Pour la première version, je vais utiliser les composants classiques d'Unity. Sauf pour l'interpolation, que je me chargerai moi même pour pouvoir avoir un meilleur tickrate (la solution proposée par Unity n'est pas top, et semble bien bugué).


Sinon, tout est toujours question de données quand on souhaite synchroniser la partie d'un joueur avec un autre. Mais le jeu n'est pas toujours composé de données. Il y a aussi les événements: quand un joueur meurt, quand un autre tire, quand une caisse explose... Il faut forcement prévenir le client de ces situations, pour que ce dernier affiche un jet de sang, plein de particules et une jolie explosion.
Via UNet, le serveur peut informer le client des événements via un appel ClientRPC. Sauf que c'est assez coûteux  :tired: .
A voir plus tard si je trouve une alternative plus légère pour répondre à ce problème. Mais je ne pense pas pouvoir tout régler à coup de snapshots ou de données, sans créer un retard d'exécution (chose qui ne se fait pas via la méthode ClientRPC).


Le plus difficile néanmoins, sera de jouer avec le Lag Compensation et, surtout, le Hit Detection. Contrairement à beaucoup de jeux, les armes de DTC sont des projectiles. Certes rapides, mais pas assez pour pouvoir faire du RayCasting pour tester le toucher des balles. Et rien que ca, c'est un très gros problème: si un joueur tire une roquette avec une latence de 500ms, est-ce qu'il doit partir au moment où le joueur clique, ou lorsque le serveur intercepte la requête du joueur ?
Si le tir part au clique - alors les victimes verront la roquette apparaître au milieu du vide, à une certaine distance du tireur (équivalent aux 500ms). Ce qui ne serait pas très lisible pour tout le monde, sauf pour l'attaquant.Si le tir part à la réception de la requête par le serveur, alors le tireur devra prévoir une marge de 250ms environ (500/2) pour bien viser sa cible... ce qui est très compliqué pour le tireur. Mais uniquement pour lui. La Prédiction ne fonctionnera pas dans ce cas là.


En faisant quelques recherches sur le wiki de Valve (TF2) et sur le moteur de Quake 3, ils n'utilisent pas le Lag Compensation sur les gros projectiles. Ils utilisent la deuxième solution, la plus logique.
Je vais voir de mon côté si je peux faire de la Lag Compensation sur mes tirs, mais avec une certaine limite: En gros si le joueur n'a pas beaucoup de latence, on peut prédire son tir de quelques millisecondes.
Par contre, il ne faut pas non plus pénaliser ceux qui ont un problème de latence. Il y aura plein de tests pour s'assurer de cela  ::): .


En attendant, je dois finaliser le Master Server (et sa sécurité) et la synchronisation des données.

----------


## BourrinDesBois

Toujours aussi classe les visuels les gars, sinon j'avais pas du tout calculé le sigle du jeu! DTC, la classe!

PS : Ca a vraiment l'air méga chiant le multi.

----------


## schouffy

> [WEBM]
> Le plus difficile néanmoins, sera de jouer avec le Lag Compensation et, surtout, le Hit Detection. Contrairement à beaucoup de jeux, les armes de DTC sont des projectiles. Certes rapides, mais pas assez pour pouvoir faire du RayCasting pour tester le toucher des balles.


Sur des projectiles rapides, j'ai de très bons résultats en faisant du linecast entre la position du projectile et la position de la frame précédente. Tu ne peux pas résoudre tes problème de hit detection avec ce genre de trucs ? Ou j'ai rien compris à ton problème ?

----------


## Grhyll

Je pense que tu n'as pas compris le problème ^^' Tu as l'air de parler du projectile qui est passé derrière sa cible le temps d'une frame, alors que Louck a l'air de parler du fait que comme le projectile n'est pas instantané, on ne peut pas dire au moment où il est tiré s'il va toucher ou non (puisque pendant les 10ms qu'il lui faut pour aller jusqu'au niveau du joueur, celui-ci pourrait avoir bougé).

Comme dit Bourrin, très beaux visuels ! Toutes ces discussions sur le netcode, ça me fiche un de ces maux de crâne, par contre XD C'est typiquement le genre de trucs auxquels je suis allergique à coder ^^'

----------


## Louck

J'avais un site avec des illustrations, mais je ne le retrouve plus  ::(: .

En bref, l'idée derrière le Lag Compensation, c'est que le serveur peut "revenir en arrière" pour traiter les requêtes des joueurs qui ont des problèmes de latence.

Par exemple, si Alice a une latence de 500ms et tire avec sa lance roquette, le serveur recevra l'info tardivement, mais devra simuler l'action 250ms plus tôt (500/2). Ce qui fait que lorsque le serveur doit avertir les autres joueurs qu'Alice tire avec son arme, ces derniers ne verront pas la roquette apparaître au niveau du canon de l'arme, mais 250ms plus loin (car le tir s'est fait 250ms plus tôt. La grosse balle a pu faire un certain trajet pendant ce temps).

Quand le tir est instantané et quasiment invisible aux yeux des joueurs (cf les fusils d'assauts, pistolets classiques, fusils à pompes, etc...), ce n'est pas un problème que la balle s'affiche tardivement car les joueurs ne le voient pas... sauf les effets.
Mais lorsque la balle est visible/lent et spawn dans le vide, la partie perd en cohérence (et les victimes ne peuvent pas prévoir une roquette qui apparait à une certaine distance du tireur).


Concernant le Hit Detection, en réalité ca concerne surtout les projectiles instantanés: ils utilisent le RayCasting (ou LineCast, ou HitScan) étant donné la taille de la balle (et permet de régler certains problèmes du Lag Compensation... tout en créant d'autres). Le calcul est différent des gros projectiles qui ont leurs propres Hitbox  ::): .

Dixit le wiki Valve:



> Prediction and lag compensation can be passed off for hitscan weapons because they are instant and invisible. This is not so with projectiles. To predict a rocket would mean *the server spawning it a long way away from a lagged firer, potentially right in a surprised target's face*: a very visible inconsistency that would also hurt gameplay, since players expect to be able to see projectiles coming.


Je ne sais pas si c'est un peu plus clair. 





> PS : Ca a vraiment l'air méga chiant le multi.


Très.
J'ai trop sous-estimé le projet, mais c'est un mal pour un bien. Cependant, il est clair que ca sera pas avant très longtemps que je referai un nouveau projet multijoueurs  ::P: .

----------


## Uubu

Merci pour vos retours sur les visouels, c'est encourageant !  :;):

----------


## Louck

Yo!

Tout va pour le mieux dans le meilleur des mondes. Le projet avance et une première version béta sera prévue pour début mars  ::): .
Ceci-dit, je prévois au moins 3 mois pour peaufiner le bébé. Minimum. Si je ne prévois rien de plus à côté (comme une version anglaise et web  ::siffle:: ).

Je prévois sûrement des tests pour cette première version béta, mais avec que quelques joueurs. J'en dirais un peu plus à ce sujet.


Pour l'instant, je me bat avec l'interface du jeu et la partie technique (saleté de Nat punch-through grrr), tout en admirant les autres jeux, qui sont 1000x mieux que le notre (

Spoiler Alert! 


Undertale  :Emo:  

).

Bref!


Je prévois d'intégrer des effets de lumières dans le jeu, pour dynamiser un peu le terrain.
Pour l'instant ce ne sont que des lumières statiques, générées en temps réels (pas de lightmap) pour une question de simplicité. Plus tard, les tirs et les explosions produiront eux aussi de la lumière. Et qui sait... peux-être un cycle jour/nuit ?  :;): 

Qu'est-ce que vous en pensez ?

 

 

Ce n'est pas encore parfait, il reste quelques imperfections à régler et un calibrage à faire (du moins au niveau de la lumière d'ambiance).

En l'état, ce n'est pas très très optimisé... dixit la carte graphique Intel  ::P: . A voir si je pourrais optimiser le bousin via des lightmaps, générés à la volée via le code. Néanmoins, cela semble très compliqué à faire. Voir impossible  :tired: .

----------


## raaaahman

Je trouve le tout très agréable à l'oeil. Le tout sauf cette perspective sur les voitures.  ::mellow:: 
Faut la changer, mais radicalement.

Me tarde de canarder en tout cas.  :;):

----------


## Louck

T'entends quoi par changer la perspective des voitures ?

----------


## Hyperpenguin

> Je trouve le tout très agréable à l'oeil. Le tout sauf cette perspective sur les voitures. 
> Faut la changer, mais radicalement.
> 
> Me tarde de canarder en tout cas.


Je pense que c'est une bête rotation du sprite d'origine, déjà vu dans d'autre screen. Ça fait le taff en placeholder mais c'est pas très joli  :^_^: 

- - - Mise à jour - - -




> tout en admirant les autres jeux, qui sont 1000x mieux que le notre (Undertale  ).


C'est pas trop le lieu pour en parler, mais oui  :Emo:  en plus c'est pas très beau mais ça fonctionne, la magie fonctionne !

----------


## Grhyll

Même avis concernant les voitures, à l'horizontale c'est top, à la verticale c'est euh... pas top  ::): 
Le reste est cool !

----------


## Louck

Oh!

Oui c'est moi le coupable  ::P: . J'ai voulu faire mumuse avec les sprites de notre grand Uubu... quoi qu'un peu trop  ::P: .

Je vais retravailler ca  ::): .

----------


## raaaahman

> T'entends quoi par changer la perspective des voitures ?


Ben là j'ai l'impression que la route c'est un mur et que les voitures roulent à la verticale. Il faudrait plutôt que l'on voit le coffre+vitre arrière, le toit, pas le pare-brise, et un bout du capot pour que tu les place dans ce sens et que ce soit raccord à la perspective (l'isométrie plutôt) générale (en gros t'as besoin d'un autre sprite).

----------


## BourrinDesBois

Bof ou tu les affiches qu'à l’horizontal et t'en mets pas à la verticale. Je pense que ça choquera plus personne après.

----------


## Roscopolo

> Ben là j'ai l'impression que la route c'est un mur et que les voitures roulent à la verticale. Il faudrait plutôt que l'on voit le coffre+vitre arrière, le toit, pas le pare-brise, et un bout du capot pour que tu les place dans ce sens et que ce soit raccord à la perspective (l'isométrie plutôt) générale (en gros t'as besoin d'un autre sprite).


Le perspective sent bon le LSD, oui.

Tes recommandations aideraient certainement mais le problème est plus grave que ça: la route elle-même ne colle pas avec les bâtiments. Ou alors il faut que ce soit une route en pente faon San Francisco (mais dans ce cas il faut ajuster les voitures et certains objets comme les plaques d'égouts).

Cela dit comme dit Grhyll on devrait s'habituer. A défaut de quoi on se consolera en sachant que le jeu connaîtra une notoriété mondiale en tant que premier jeu 2D à pouvoir reproduire les sensations nauséeuses de la VR.  ::o: 


Pour finir sur une note positive : j'aime l'ambiance de nuit, les couleurs, et ce petit tag représentant une main d'Horus. Ça fleure bon le cyberpunk rétro et le monde en déréliction.

----------


## Uubu

Et voilà  ::P:

----------


## Gafda

> Et voilà 
> 
> http://36.media.tumblr.com/25649649b...4dbo1_1280.png


Classe ! 

L'affiche "teub"  ::XD::

----------


## raaaahman

> Je pense que c'est une bête rotation du sprite d'origine, déjà vu dans d'autre screen. Ça fait le taff en placeholder mais c'est pas très joli





> Bof ou tu les affiches qu'à l’horizontal et t'en mets pas à la verticale. Je pense que ça choquera plus personne après.


Mouiii, peut-être que j'essaierai de lire les messages et de réfléchir un peu avant d'ouvrir mon bec...  ::unsure:: 




> Tes recommandations aideraient certainement mais le problème est plus grave que ça: la route elle-même ne colle pas avec les bâtiments. Ou alors il faut que ce soit une route en pente façon San Francisco (mais dans ce cas il faut ajuster les voitures et certains objets comme les plaques d'égouts).


Ah tu trouves? Personnellement je n'ai pas de problème de perception sur la première image, mais peut-être est-ce une à mon habitude des jeux vidéos (et des documents axonométriques)...




> Et voilà


Ca c'est de la réactivité!  ::o: 
Par curiosité: tu as essayé de les faire sur trois cases aussi?

----------


## Uubu

> Par curiosité: tu as essayé de les faire sur trois cases aussi?


Non j'ai pas testé, mais ouaip' j'ai hésité.  ::): 




> Classe ! 
> 
> L'affiche "teub"


Merci  ::ninja::

----------


## Louck

Ca devrai être mieux  ::P: .




J'en chie à peaufiner l'interface du jeu. Mais c'est bientôt finis:



J'ai tout de même une bonne nouvelle: une première version bêta du jeu sera prête pour début mars  ::lol:: .
Si vous êtes intéressés pour un test, n'hésitez pas à m'en informer ici sur le topic  ::): . Etant donné que c'est un jeu multijoueurs, les tests seront organisés le soir avec moi.

Il reste encore pas mal de taf (du contenu, des sons) et des bugs/problèmes à régler (dont le fameux NAT punchtrought et la prédiction réseau) pour sortir la version finale du jeu. Donc il faudra - encore - patienter  :;): .

----------


## Grhyll

Oui effectivement c'est mieux  ::):

----------


## Hideo

Bien, très bien ! 

Opé pour tester si je suis dispo quand vous faites vos tests  :;):

----------


## Gafda

Owaiii ! Partant pour testay !

----------


## raaaahman

C'est même fort bô!

Et je suis également partant pour tester, ça vous fera un adversaire facile pour tester les armes... A moi la dope!  ::ninja::

----------


## BourrinDesBois

Comment ça marche quand on passe derrière les buildings, est-ce qu'ils ne seraient pas un peu haut. J'aime bien le partie pris de ta perspective mais ça donne une impression de verticalité étrange.

----------


## Louck

Ca a toujours été de la merde de gérer l'affichage des protagonistes derrière un mur, dans un contexte 2D. J'avais le même problème sur un projet mobile: qu'on affiche les murs en transparents ou une simple ombre du personnage, c'est totalement illisible. Pour un jeu d'action, ce n'est pas top.
Du coup, les personnages ne passent pas derrière les gros bâtiments ou les gros murs.

----------


## BourrinDesBois

Ah ouais et ça fait pas trop bizarre?

----------


## Louck

> Ah ouais et ça fait pas trop bizarre?


Ca dépend des jeux. Pour certains, ce n'est pas un problème d'afficher une ombre ou de rendre le mur invisible (par exemple, le jeu Stardew Valley). Pour d'autres, ca peut rendre l'action moins lisible, sauf si le jeu est prévu pour (les bushs de LoL pour exemple).

Mais après je viens d'y réfléchir: l'autre solution serait de ne pas afficher toute la façade de l’appartement mais uniquement sa base (la partie bloquante). Nous pouvons faire ca, mais cela aurait un impact sur l'esthétique du jeu.
Pour l'instant, on abuse de la "logique du jeu-vidéo"  ::P: .

----------


## Louck

Il y aura un petit retard concernant le test du jeu.
J'ai appris très récemment qu'une fonctionnalité d'Unity qui permet de synchroniser le "temps" entre le client et le serveur (Network.Time) ... et bien... ne synchronise pas vraiment sur certaines plateformes  :tired: .
Du coup je revoie un peu mon code, tout en corrigeant les petits trucs dérangeants: le manque de fluidité, l'input lag, grosse interpolation, etc...

Peux-être que je serais un peu plus disponible pour les tests la semaine prochaine ou la semaine d'après.

----------


## Louck

Je ne pensais pas reparler de mes aventures avec le netcode. Mais c'est le meilleur moyen pour expliquer le retard du test, qui est repoussé jusqu'à une prochaine fois  ::P: .

Bienvenue dans le monde merveilleux du développement réseau.


*Le calme avant la tempête*

Avant d'avoir débuté les tests, étant naïf, je voulais faire un netcode simple mais bonne, sans inconsistance ou perte de synchronisation (lockstep protocol, pour ceux qui connaissent). Mon système d'interpolation fonctionne bien (pour fluidifier l'action du côté client, en contre partie d'un retard de traitement) et les échanges de données se font correctement. Je n'avais pas encore fait de tests avec du bon lag (100-200ms), mais l'ensemble était bon.

Je savais qu'un jour j'allais faire de la prédiction, pour limiter la latence. Mais je ne pensais pas le faire aussi tôt: le premier test que j'ai fais avec Uubu c'est résulté par un gros input lag, lorsqu'il a essayé de se déplacer. Totalement injouable.

Quelques corrections et modifications plus tard (meilleure réaction au mouvement, réduction de l'interpolation ...), la partie est un peu plus jouable, mais faute d'une API un peu lourde, il n'était pas conseillé d'avoir un ping supérieur à 100 ms....

J'avais donc deux choix:
Soit repartir de 0 avec l'architecture multijoueurs, pour travailler directement sur la couche inférieure. Beaucoup plus de travail, je dois sûrement tout revoir, mais je me débarrasse de la grosse surcouche made by Unity.Soit je fais de la "Prédiction côté client", ce que je redoutais le plus.


N'étant pas fou, j'ai pris la deuxième solution.



*"Mais dis moi Jamy, qu'est ce que la Prédiction côté client ?"*



"C'est très simple!

Le problème des jeux en ligne, c'est la latence. Pour que le tir d'un joueur soit pris en compte, il faut attendre que le clique de sa souris soit transmis au serveur, vérifié et traité par ce dernier, avant que la réponse du traitement soit retourné au client. Pour certaines connexions, l'attente peut être de 50 à 150 millisecondes. Mais ca peut être beaucoup plus! Et ce genre d'attente peut être très contraignant pour certains jeux-vidéos en temps réels.

Il existe tout de même une solution à ce problème, qui est *très simple*: Lorsque le joueur clique sur le bouton gauche de sa souris, en plus de transmettre l'action au serveur, le client l'exécute aussi tôt sur son jeu! Au lieu d'attendre la réponse du serveur, le client anime le tir de son arme sur sa cible. Ainsi, le joueur ne ressent aucune latence lorsqu'il tire avec son arme.

Nous appelons cela de la "prédiction" étant donné que le client "prédit" l'action qui va être exécuté sur le poste du client, sans attendre la validation du serveur.
Mais si le code client est exactement le même que le code serveur, alors le client peut faire ses propres validations et confirmer le tir de son côté. Il ne devrait pas avoir de problèmes!


N'est ce pas ?"





*Opération "Réconciliation"*

La prédiction est extrêmement utile pour réduire l'input lag dans les jeux en ligne. Cela s'applique surtout pour les déplacements du protagoniste et pour certaines actions fréquentes (dont le tir des armes). Son intégration est très simple.

Par contre, sa mise en place importe son petit lot de défauts:
Que le joueur joue avant que le serveur traite l'information signifie qu'il peut prendre de l'avance sur la partie. Si le joueur a une latence inférieur à 100ms, ce n'est pas trop important. Mais au delà, cela peut être gênant. De plus, certaines actions peuvent se passer entre temps... ... qui peuvent être pris en compte du côté serveur et non du côté client. On parle alors de désynchronisation entre le serveur et le client, et ca peut être fatal: https://www.youtube.com/watch?v=KoytwvSZ_swEt encore, faut il être *sûr* que les actions qui sont exécutées du côté serveur soient les mêmes du côté client. Ce qui n'est pas le cas quand le moteur physique entre en jeu.

Pour résoudre ces différents défauts, nous arrivons au plan B: la "Réconciliation serveur". En gros, le serveur transmet le résultat de ses traitements au client. Ce dernier compare son résultat avec celui du serveur. S'il n'y a pas une grosse différence, on laisse faire. Sinon, on corrige le tir: si le joueur est trop éloigné de sa véritable position, alors il sera téléporté.


C'est là qu'on arrive au problème de Dope TrashCanners. Et de probablement beaucoup de jeux multijoueurs.
Pour les déplacements des gladiateurs, j'utilise le moteur physique: pour les tests de collisions, des explosions et autres effets, c'est indispensable. Cependant le moteur physique d'Unity n'est pas déterministe: il ne fonctionne pas exactement de la même façon du côté serveur et du côté client. Il est donc possible que le client se déplace un peu plus rapidement que du côté serveur, ou qu'un test de collision passe pour l'un et pas pour l'autre.

D'oû l'importance de bien régler la marge d'erreur pour la réconciliation serveur:
S'il est trop bas, le jeu sera le plus synchronisé possible. Mais étant donné les imperfections du moteur physique, le protagoniste aura le syndrome de Parkinson et bougera/se téléportera à chaque pas (  :Vibre:  )S'il est trop haut, le jeu sera parfaitement fluide pour le client. Par contre, il peut avoir l'impression que certaines actions soient mal prises en compte: un tir qui touche la cible mais dont les dégâts ne sont pas affichés. Ou croire qu'on est couvert derrière un mur, jusqu'à qu'on se fasse touché "par hasard". Bref, mal synchronisé.

Il faut donc trouver le bon milieu. Et c'est le gros défi que j'entreprend à l'heure actuel.
Et c'est encore mieux quand la latence est élevée  :Fuck:  .





*TL;DR:* Je veux une architecture client-serveur bien synchronisé + J'ai sous-estimé la prédiction = Caca.

J'hésite à imposer une option cliente pour activer le mode Lockstep (avant) ou mode Prediction (après), comme il se fait sur Path of Exile. Mais pour un projet amateur, je ne sais pas si cela vaut le coup.

Voili voilou.

----------


## raaaahman

Très intéressant... pour une excuse! 

Spoiler Alert! 


Je déconne bien entendu.

  ::ninja::

----------


## BourrinDesBois

C'est vraiment chiant en fait un jeu vidéo. Cela dit merci pour le pavé, c'est toujours sympa le cours de mécanique.

----------


## schouffy

Putain le réseau c'est à se tirer une balle.

----------


## Grhyll

Ahahah à chaque fois que je lis une note de toi sur le sujet, ça repousse un peu le jour où je m'imagine oser toucher à du réseau :D

----------


## Louck

:D.

Je pense que je vais me répéter, mais c'est un peu la dernière fois que je vais faire un jeu en réseau tellement c'est complexe, surtout pour un projet amateur.
Au mieux, si je devais le refaire, ca sera pour un DLC payant  ::P: . Mais pour un projet qui devait être petit et amateur à la base ? C'est un peu trop.

Ca reste pour autant une bonne expérience si on veut s'intéresser à la technique. Très périlleuse, mais très instructif..


Je me souviens du premier post de mon topic sur l'architecture multijoueurs: j'étais en mode YOLO en pensant que le plus gros défi provenait de l'échange des données sur le réseau et de quelques techniques. Mais en réalité, ce n'est que le plus simple: la suite, c'est surtout du bidouillage, du dirty hacking, ou des solutions de contournement de façon à ce que le jeu soit jouable par tous (p*tain de NAT punchthrough).


Du coup je ne peux pas promettre un "très bon netcode" dans le sens où la partie sera 100% synchronisé et qu'il n'y ai aucune latence lorsque le joueur appuie sur une touche avec un ping de 50-100ms. D'ailleurs, aucun jeu en temps réels ne peut le promettre.

----------


## schouffy

ça a l'air chiant à coder et en plus chiant à tester/debugger  ::(: 
Coop locale FTW  :^_^:

----------


## SeanRon

> :D.
> 
> Je pense que je vais me répéter, mais c'est un peu la dernière fois que je vais faire un jeu en réseau tellement c'est complexe, surtout pour un projet amateur.
> Au mieux, si je devais le refaire, ca sera pour un DLC payant . Mais pour un projet qui devait être petit et amateur à la base ? C'est un peu trop.
> 
> Ca reste pour autant une bonne expérience si on veut s'intéresser à la technique. Très périlleuse, mais très instructif..
> 
> 
> Je me souviens du premier post de mon topic sur l'architecture multijoueurs: j'étais en mode YOLO en pensant que le plus gros défi provenait de l'échange des données sur le réseau et de quelques techniques. Mais en réalité, ce n'est que le plus simple: la suite, c'est surtout du bidouillage, du dirty hacking, ou des solutions de contournement de façon à ce que le jeu soit jouable par tous (p*tain de NAT punchthrough).
> ...


rien ne t'empêche de le passer en payant, non ?

----------


## Louck

> rien ne t'empêche de le passer en payant, non ?


Du tout, mais le jeu n'est pas pensé pour être "payant" (à mon goût). Sinon j'aurais passé encore 6 mois dessus pour le peaufiner à mort et pour lui ajouter tout ce qu'il faut (genre un système de progression, une partie communautaire ou une friends list, etc...).

De plus que les joueurs attendent un certain service et suivi quand le jeu a été payé... ce qui est hardos quand ce dernier est exclusivement multijoueurs  ::P: .


EDIT: Aux dernières nouvelles, j'ai pu mettre en place un système de prédiction qui semble fonctionner avec une faible marge d'erreur. Cependant le moteur physique me pose toujours un soucis quand le joueur se déplace dans plusieurs directions inverses (genre staffe gauche-droite).

Ca avance doucement mais sûrement. Mais pour l'instant, je ne fais que des tests en local et en mode "dirty". Quand je vais devoir faire le test avec de la latence, ca va être beaucoup plus fun.

----------


## Louck

Je peine toujours sur cette histoire de prédiction, mais j'ai fais des progrès depuis les dernières semaines.
Récemment, j'ai développé un petit système que j'ai prénommé le "slow reconciliation": en gros, la position du joueur est automatiquement corrigé sur le temps, mais lentement, de façon à que le joueur ne le perçoit pas.
Par exemple si le joueur avance plus vite que le serveur, alors il sera très légèrement ralentie afin de correspondre à la position de ce dernier. Mais personne ne le remarquera  ::): .

Ce n'est que quelques lignes de codes, mais cela me permet de corriger la majorité de mes problèmes de synchronisation  ::): .

Maintenant, je joue avec la latence. Ca va être chaud  :tired: 


En outre, j'ai corrigé un gros paquet de bugs jusqu'à maintenant. Mais il m'en reste encore un bon paquet à régler  :tired: .
Je risque de faire une petite pause en Avril pour me tenter la Ludum Dare.

----------


## raaaahman

Garde la motivation!  :;):

----------


## Uubu

Quelques items :  ::): 



Et une map :

----------


## Hyperpenguin

Woaw c'est grand comme map, c'est prévu pour combien de joueur? Et pour les items, on peut avoir un descriptif?

----------


## raaaahman

Dope!

Et pour la taille de la carte, 'faut aussi prendre en compte la vitesse des joueurs ainsi que le taille d'un écran de joueur, si ça se trouve ça va quand même canarder à tout va!

----------


## Louck

Pour répondre, la taille moyenne d'une map est de 40-45 cases de chaque côté et la vitesse minimum d'un protagoniste est de 4 cases / seconde.
Le jeu est optimisé pour être joué à 4 (des bots sont prévus pour).

Même si les maps sont très grandes, nous essayons au mieux de centraliser l'action - via les powerups et un radar - afin que les joueurs puissent se retrouver rapidement et se foutent sur la gueule  :;): .


Pour les objets, perso, je préfère ne pas tout dévoiler afin de garder la surprise dans le jeu  :;): . Tout ce que je peux dire, c'est que ces objets sont des powerups, qui peuvent être ramassés sur le terrain et offre un gros bonus à durée limitée: soit une arme secondaire, soit un boost passive (soins, vitesse...), soit un boost critique (devenir très résistant mais lent).

----------


## Grhyll

Yay ça avance ^^

----------


## Louck

On fait actuellement une petite pause pour tenter la jam suivante:
https://itch.io/jam/lowrezjam2016

Le développement reprendra dans 2/3 semaines. Et si tout se passe bien (en croisant les doigts) j'aurais assez de temps pour sortir ENFIN une version testable pour le mois prochain.

----------


## Louck

Alors ?
Le jeu est-il mort ?
Est-il abandonné ?

...



  

Même s'il y a eu une pause entre-temps, le jeu est toujours en cours de développement. Juste que la période de peaufinage est un peu... longue  ::P: .

Mais il y a eu des améliorations depuis. Dont par exemple:
Un radar: Pour repérer les objectifs, powerups, et ses futurs cibles un peu trop bruyants.Un système jour/nuit: La lumière du jeu (source et ambiante) change à chaque début de partie pour varier le thème.Un meilleur screenshake.Beaucoup d'optimisation, d'amélioration graphique et de corrections de bugs  ::P: .Et surtout, un meilleur netcode (même si ce n'est pas encore parfait  ::ninja:: ).

Il reste encore du travail. Je prévois de l'ajout de contenu (armes, powerups et compétences) et je vais tenter de produire une version WebGL.
En attendant, je continue de travailler encore sur le netcode. Aujourd'hui, je travaille sur l'optimisation du Master Server, qui est une grosse plaie.

Ensuite, je vais commencer à intégrer les nouvelles maps du jeu et les sons. Peux-être que je demanderais à des gens de tester après cette phase  ::P: .

----------


## Grhyll

> Même s'il y a eu une pause entre-temps, le jeu est toujours en cours de développement. Juste que la période de peaufinage est un peu... longue .


Ces fameux 10 derniers % qui prennent 90% du temps :D Bon courage !

----------


## Louck

Merci  ::P: .


Bon, je pense avoir finis avec l'optimisation de Master Server, en plus d'avoir changé d'hébergeur pour m'assurer d'avoir une bande passante correcte au jour J.
Aujourd'hui et les prochains jours, je m'attaque à l'intégration des maps de notre chère Uubu en plus de concevoir une nouvelle.

Il y aura au total 6 maps dans la version finale. Nous tentons de varier un peu le style de chaque map afin de faire varier le plaisir  ::): .

----------


## raaaahman

Ooooh ça prend forme!

La question qui tue: décors destructibles ou pas?  ::P:

----------


## Louck

Les seuls éléments destructibles du jeu seront les caisses (en bois ou explosifs). Les décors du jeu ne le sont pas, afin de bien délimiter le terrain du jeu  ::):  (de plus que ca demanderait beaucoup plus de travail graphique, pour cause de la vue 3/4. A côté, Punxel Agent c'est EZ PZ).

----------


## Ashley TOUCRU

> Ooooh ça prend forme!
> 
> La question qui tue: décors destructibles ou pas?


Y aura-t-il des véhicules ?  ::ninja::

----------


## Ornithorix

Tu pourrait commenter sur ton master server? Perso j'utilise le master server tout pret de unity (qui se trouve aux states et du coup je fais un filtre pour recevoir sur mon client juste les hosts qui lancent juste la même version de mon jeu ), mais je me posais la question d'en créer un et de le hoster sur un ordi perso. Tu utilise quoi comme techno, quel langage utilisé?

----------


## Louck

PHP  ::P: 
Hébergé sur un serveur web  ::P: .

Pour l'instant, mon MS ne sert qu'à lister les lobbys du jeu. Il n'y a pas de système de matchmaking pour le moment.
Néanmoins, je n'ai pas encore trouvé de solution pour le problème de port forwarding (NAT Punchthrough). Il est possible que je change un peu le MS d'ici là pour résoudre ce défaut.


Bref, pour simplement lister les lobbys, même avec un système de chat et de liste d'amis, un serveur web suffit amplement.

----------


## Zub

Je découvre la projet et j'ai bien hâte de voir ce que ça va donner  ::): 

Bon courage !

----------


## Louck

Merci  ::): .

J'avance sur l'intégration des maps et le tutoriel, mais il y aura sûrement certains éléments à retravailler pour que ca soit fun  ::): .

Bigju a pu m'envoyer les premiers morceaux du jeu, qui seront joués durant la partie. Je vous laisse admirer un de ses titres  :;): .
https://www.dropbox.com/s/1v1nqwm06r...1_mid.wav?dl=0

Nous prévoyons 2 thèmes musicales dans la version finale, chacun composé de 5 morceaux (du soft au plus hard). L'idée est que la musique évolue selon les performances du joueur: plus le joueur exécute des joueurs, plus la musique a tendance à évoluer vers du rock/metal/boom-boom. A l'inverse, plus le joueur se fait victimiser, plus la musique devient lent et doux.

J'essaye de voir si je peux intégrer quelques effets graphiques sympas, dépendants de la musique  ::): .

----------


## Louck

Uubu qui fait toujours un bon boulot sur DTC  :;): .

J'attaque l'intégration des bruitages cette semaine. Ca consiste surtout à de la recherche/création, donc ca prend un peu de temps  ::P: .

Dans un même temps, je retravaille certains mécanisme de gameplay pour les rendre plus intéressants ou plus impactant. Je donnerais un peu plus d'info quand ca sera au poil  ::): .
Une vidéo sur youtube résume à peu près ce que je cherche à reproduire:

----------


## Uubu

J'ai fignolé un peu les portraits cités par Louck.  ::):

----------


## Ashley TOUCRU

> J'ai fignolé un peu les portraits citer par Louck.  
> 
> https://67.media.tumblr.com/0e1d19d9...o3_r1_1280.png


Perso je trouve dommage que le premier ne soit pas un poil plus orange (clair) pour se démarquer davantage du deuxième.  ::):

----------


## raaaahman

Oui mais tous les autres sont successivement en dégradé (sauf le 5 qui se démarque plus), du coup il faudrait tous les changer aussi, non? (Mais tous sont super cool)

----------


## Louck

C'est surtout dépendant de la couleur que sélectionne le joueur à son personnage  :;): .

----------


## Ashley TOUCRU

> Oui mais tous les autres sont successivement en dégradé (sauf le 5 qui se démarque plus), du coup il faudrait tous les changer aussi, non? (Mais tous sont super cool)


Disons que je trouve le graphisme sympa comme tout, mais que si les couleurs se distinguaient davantage je trouverais ça encore mieux.  :;): 

Dans cet esprit :



Bon, comme d'hab', avec la qualité de TofCanard on voit à peine la différence.  :tired: 

*Edit :* j'ai accentué l'effet pour qu'on se rende mieux compte...

----------


## raaaahman

C'est sur que pour distinguer les joueurs on aurait tendance à vouloir des contrastes forts.

----------


## Uubu

Merci pour vos retours. Bien vu Ashley TOUCRU !  :;):  Au départ une teinte similaire était présente, mais on l'a viré pour éviter qu'un perso ne puisse se fondre dans le décor :



Il y a aussi beaucoup d'autres éléments d’environnement de cette couleur, vu qu'on a utilisé une palette avec un nombre de couleur restreint.
Voilà toutes les déclinaisons de couleurs des personnages, il n'y a effectivement pas de orange/marron :

----------


## Ashley TOUCRU

> Il y a aussi beaucoup d'autres éléments d’environnement de cette couleur, vu qu'on a utilisé une palette avec un nombre de couleur restreint.
> Voilà toutes les déclinaisons de couleurs des personnages, il n'y a effectivement pas de orange/marron :
> 
> https://67.media.tumblr.com/3dfe1277...4dbo1_1280.png


Ouais, forcément. Je me doutais bien qu'il devait s'agir de quelque chose dans ce genre.  ::):

----------


## Louck

Hola  ::): .

Ca fait un petit moment que je n'ai pas posté grand chose, étant donné que je suis à fond dans l'optimisation du jeu.
Mais du coup, j'ai pas mal de choses à dire  ::): .

Tout d'abord, j'avais parlé quelques posts plus tôt que j'allais revoir certains éléments de gameplay. En réalité je n'ai pas modifié grand chose, mais j'ai apporté certaines règles au jeu pour le rendre plus intéressant.

Par exemple, le jeu tourne autour d'un système de powerup: tu en ramasses un, tu deviens temporairement plus fort. Il y a trois types de powerups: les classiques (packs de soins, boost de vitesse...), des armes secondaires, ou des "ultimates": un gros buff qui altère le comportement du joueur mais avec quelques malus.
Le problème c'est qu'il était très facile de cumuler les powerups, surtout pour les joueurs les plus forts: en plus d'aller chercher les powerups dans des zones fixés, il est aussi possible de les récupérer sur le cadavre de sa victime (s'il restait encore du temps). Il n'était pas anodin d'avoir 4 ou 5 powerups sur soit, lorsqu'on domine la partie.

Du coup, j'ai apporté quelques modifications: dans un premier temps, le joueur ne peut porter qu'un seul type de powerup à la fois. Donc pas de doublon ou de mec overdosés. De plus, le powerup ne se drop plus sur les cadavres des joueurs, sauf s'ils n'ont pas été utilisé durant au moins 4 secondes.
Enfin, en second temps et le plus intéressants, ramasser un powerup apporte un nouveau effet au joueur: selon le type, ils peuvent le soigner (partiellement ou totalement) ou incrémenter son compteur de dashs.
L'objectif, en plus de donner de la valeur à ces bonus, c'est que le joueur pourra faire un choix: Par exemple, le joueur possède un powerup de type A qui lui semble intéressant. Cependant il se fait rapidement amocher durant un combat. Il pourra alors faire le choix de sacrifier son powerup contre un autre de même type, mais avec l'avantage de récupérer ses points de vies.


Une autre modification que j'ai apporté au gameplay, c'est que la destruction des caisses rapportent aussi des points. Ca n'apporte pas autant que de tuer ses adversaires (voir presque pas du tout), mais cela permet d'aider les joueurs qui sont en difficultés, en contre partie de se faire "entendre" par ses nemesis. L'idée, c'est que cette règle permet de contre-balancer le principe que les caisses ne sont là que pour protéger les joueurs.


Il y a encore quelques modifications qui sont prévus au niveau du gameplay, mais je suis en pleine réflexion  :;): .


De l'autre côté, je peaufine (again, again, again, and again) le code réseau du jeu. En réalité, le jeu fonctionne bien: je l'ai testé rapidement avec d'autres joueurs (merci à JazzMano et Akheris  :;): ) pour vérifier que le jeu ne saute pas en cours de route. Sauf que ce n'est pas non plus parfait (surtout quelques problèmes de connexion au lobby et rollbacks du joueur local trop fréquents) et je suis entrain de tester le moteur contre des cas extrêmes: Grosse latence, perte de paquets, donnés dans le désordre, micro coupures, etc etc... Je recommande d'ailleurs l'outil Clumsy (pour windows) qui permet de foutre le bordel sur son réseau  ::): .

Par contre, je pense que je ne vais pas réutiliser Unet pour les prochains projets: même si c'est bien intégré dans Unity et offre le plus basique, il a tout de même quelques défauts. Par exemple, leur composant pour gérer l'Interpolation est bugué à mort, leur simulation de lag est un cauchemard (et qui m'a fait croire beaucoup de choses), leur système de serveur relay n'est psa top, et dès qu'il y a un problème, l'API n'hésite pas à couper instantanément la connexion: J'avais fait un test de Packet Tampering, le client s'est arrêté en même pas une seconde.
Bref, ca m'a fait perdre beaucoup de temps ces histoires, en plus que faire un jeu multijoueurs est - après expérience - pas facile :/.


Sinon, le côté positif est que j'ai trouver une solution pour le problème de ports, en utilisant Open.Nat. Mais j'expliquerai cela une prochaine fois  ::P: .

En attendant, je retravaille un peu les maps du jeu. Il y aura sûrement quelques screens bientôt  :;): .

----------


## Grhyll

Ca me donne envie de pleurer chaque fois que je lis tes aventures avec le code réseau  ::'(: 
Curieux de tester en tout cas, si tu organises un petit tournoi pour une bêta CPC un de ces 4 !

----------


## Louck

Héhé  ::P: .

Après ca reste une bonne expérience de faire un jeu multijoueurs. Mais il est clair que la prochaine fois, je prévoirai beaucoup plus de temps à sa mise en place et j'utiliserai autre chose qu'UNet.

----------


## Louck

Un peu de travail sur les couleurs et les lumières.

J'ai rajouté aussi un nouveau élément au gameplay. Surprise  ::P: .

----------


## Poussin Joyeux

Aucune voiture n'a ses phares allumées? 
Ca joue bien sur l'ambiance en tout cas la lumière des gyrophares!  :;):

----------


## Louck

Yo!

Pas trop de news en ce moment, à l'exception que nous éradiquons - encore et encore - les bugs par-ci par là en plus d'améliorer le reste.


Je suis un peu dans cet état là.


Par contre, je peux assurer à 99% (j'anticipe la loi de Murphy) qu'il y aura une version bêta pour mi-Décembre  ::lol::  . Des tests seront prévus pour cette période, durant un mois environ, avant une release courant Janvier  ::): .

Peux-être que je remplirai mon petit objectif de faire un petit trailer jusqu'à là  ::P: .


Bref!
A part ca, grâce aux travaux d'Uubu, nous avons intégrer un nouveau élément au jeu: les buissons.



Pourquoi des buissons ?

Il était une fois, Uubu et moi, nous avons conçu deux éléments de level design, en plus des murs et des power-ups:
 - Des zones de couvertures destructibles, sous le doux nom de "caisse", qui limitent les mouvements et les tirs des joueurs
 - Des "grilles", sorte de mur où le joueur peut tirer à travers.

Après une réflexion à 2h du mat, dans ma tête de tordu, je me suis dit:
"Tient, le jeu limite pas mal le déplacement du joueur, mais il peut tirer n'importe où sans problèmes. Et si nous faisons l'inverse ? Un mur magique que nous pouvons traverser, mais qui bloque les tirs ?"

Du coup, avec l'aide du Uubu, nous avons réfléchit sur un nouveau élément de level design "logique" (= au sens "logique dans un jeu-vidéo") qui répondrait à cette idée idiot.
Rapidement, l'idée d'un buisson sort du lot. Mais pas n'importe quel buisson: un buisson magique© !

En gros, le joueur devient invisible lorsqu'il rentre dans un buisson. Les autres joueurs peuvent le voir s'ils entrent dans le même buisson ou s'il décide d'utiliser son arme. Tant qu'il n'attaque pas, le joueur peut se déplacer librement dans le buisson en restant à couvert.
Cependant, le buisson a une particularité: *Le personnage caché dans le buisson ne peut être touché par aucune balle venant de l'extérieur.* Le seul moyen d'attaquer le joueur est d'entrer dans le buisson ou d'attendre qu'il engage le combat (pour sortir de son trou).

Buisson magique©, Bitch!

Il y a bien sûr deux exceptions à la règle: La première est que le lance-flamme - un power-up du jeu - peut cramer les joueurs cachés dans le buisson. La seconde exception est que le joueur peut blesser sa cible en dashant sur lui, même caché. Certains appelleront cela un "dash-check"  :;): .

La finalité, comme pour les autres éléments du jeu, est de diversifier les possibilités tactiques du jeu  ::): .


Voili voilou pour les news du moment!


PS: Pour les phares, il y a deux explications:
 - Officiel: Trop coûteux en ressource graphique, et l'effet peut être de trop (du moins, pour notre projet).
 - Officieuse: Uubu a bien dessiné des phares dans ses concepts, mais j'étais trop 

Spoiler Alert! 


(con)

 aveugle pour le voir.

Par contre, j'ai intégré un petit truc fun pour les lumières du jeu  :;): .

----------


## Hideo

:Bave:

----------


## Tchey

Ça me plait.

----------


## Hyperpenguin

Cool cool cool des news! Pas mal cette idée de buisson, ça ne sera que des buissons ou ça peut être un tas de vieilles frippes / tas d'ordures / monceau de billet de banque pour varier niveau graphique?

----------


## Ashley TOUCRU

> Cool cool cool des news! Pas mal cette idée de buisson...


Ouais, la mise en application peut permettre pas mal de possibilités.  :;):

----------


## Louck

Merci  ::): .




> Pas mal cette idée de buisson, ça ne sera que des buissons ou ça peut être un tas de vieilles frippes / tas d'ordures / monceau de billet de banque pour varier niveau graphique?


Il y a de l'idée!  ::): . Mais pour l'instant, c'est uniquement sous la forme de buisson pour que les joueurs puissent l'identifier rapidement dans la map  :;): .
Sinon il faudrait rajouter un indicateur pour que les joueurs sachent qu'ils peuvent se cacher dedans.

----------


## Ashley TOUCRU

> Sinon il faudrait rajouter un indicateur pour que les joueurs sachent qu'ils peuvent se cacher dedans.


S'ils sont aussi cons maladroits que moi, ils trouveront rapidement le moyen de foncer dedans et de s'apercevoir qu'on peut les traverser.  ::P:  Sinon, en début de tableau, sous prétexte de course-poursuite tu crées un mini-scénario où il faut poursuivre quelqu'un, et qui oblige le joueur à travers et les buissons. Un truc du genre...  ::):

----------


## Louck

Aussi mais ca impliquerait de faire ca à chaque fois qu'il y a un nouveau élément, et ca demande du temps  ::P: .

Sinon, quand je parlais de lumières:


J'avais envie d'un peu de fun, du coup elle scintillent au rythme de la musique  :;): .

----------


## Joq le pecheur

Les graphismes sont vraiment chouettes, je vous souhaite une belle réussite.

J'imagine que c'est un gros travail pour les lampes/musiques. Toutes les lumières sont synchrones ou est-ce que certaines diverses lumières correspondent à plusieurs instruments ?

----------


## Louck

Ahah!  ::P: 

A la base, je voulais faire agir les lumières aux beats de la musique. Cependant après avoir utilisé plusieurs algos, le résultat n'était pas génial... Au final, le résultat est bien mieux en utilisant la fréquence de la musique (en récupérant les données du spectrum).

Ensuite pour la variation, c'est un bête random à chaque frame, pour donner, justement, l'impression que chaque lumière joue une partie de la musique, que d'avoir un truc monotone  ::): .

La solution de lier une lumière à un instrument n'est pas mauvaise. Mais ca impliquerait beaucoup de boulot (surtout pour le compositeur) et une certaine difficulté à faire jouer un "orchestre" aux yeux du joueur, s'il ne voit pas toutes les sources lumineuses.

----------


## Hideo

Tiens, ça m'intéresse de savoir de quelle manière dont tu as implémenté cette histoire de musique qui scintille en rythme.

J'avais fais un projet similaire, j'utilisais l'énergie instantanée pour détecter les "beats" mais vu le gif les lumières n'ont pas l'air d'être calées sur le même rythme du coup j'imagine que tu as utilisé quelque chose de différent ?

Edit: Ok j'ai ma réponse  ::P: 

Effectivement je vois très bien ce que tu veux dire par rapport au résultats finalement assez mauvais, sur de la techno ou quelque chose ou les beats sont très marqués ca me donnait des résultats pas trop mauvais mais dès qu'on sortait de ce type de musique...aie

----------


## Louck

Je pense qu'un détecteur de beat fonctionnerait pour certaines types de musiques, dont le beat est vraiment marqué. Sinon de ce que j'ai compris, c'est une histoire de moyenne de fréquence, dont on cherche le pique.
Vu que la musique de DTC évolue selon les performances du jeu - au plus calme au plus hard - il était certains que ca n'allait pas très bien marcher.

----------


## Hideo

J'utilisais ce document pour avoir quelques info, tu es peut-etre tombé dessus également.

J'avais utilisé la détection simple, et tu as bien compris l'idée : on prend la moyenne de l'énergie instantanée sur une certaine durée, si à l'instant T on est largement au dessus de cette moyenne (moyennant un facteur à définir) pof on à un beat.
Simple et suffisant pour ce que je devais faire, mais un peu trop naif.

Juste en dessous ça parle de l'implémentation que tu as surement utilisé d'une certaine manière.

----------


## Louck

Je n'avais pas vu ce document, mais oui globalement c'est ca  ::): .

Le seul problème est que ca fait une moyenne d'un ensemble de fréquences. Si on veut reproduire correctement le beat, il faut se baser sur la ou les bonnes fréquences (où le beat intéragit le plus) ainsi de définir le threshold selon la musique donnée. Bref, pour un bon résultat, il faudrait reconfigurer l'algo pour chaque musique.

----------


## Louck

Petite mauvaise nouvelle du jour, mais les tests du jeu seront repoussés.. d'une semaine  ::P: .

Le temps de pouvoir mettre en place une UI un peu plus sympa  ::): .




Sinon niveau correctif, j'ai enfin réussi à corriger toute les merdouilles du netcode  ::lol:: . Restes plus que des tests réels avec de vrais joueurs pour casser mon rêve  ::trollface:: .
Tous les éléments prévus sont aussi intégrés au jeu. A l'exception de l'UI du dessus, il me reste à revoir les bruitages du jeu pour que ca ne soit pas trop dégueulasse, et - encore et toujours - quelques touches de finitions.


Donc avec le retard, je pense pouvoir sacrifier un peu de mon temps libre pour débuter les tests dès début janvier, la semaine du 2 au 8  :;): .
S'il y a des intéressés, n'hésitez pas à me MP avec une préférence de dates et heures.


PS: Ca ne sera pas un jeu web mais un jeu à télécharger. En théorie, c'est compatible Windows et Linux, mais je n'ai pas pu faire de test sur ce dernier.

----------


## Ashley TOUCRU

> Les graphismes sont vraiment chouettes, je vous souhaite une belle réussite.


Ouais, c'est vraiment de plus en plus alléchant.  ::):

----------


## Louck

Bonne fête  ::): .

https://webmshare.com/play/WJxPP

Etant en vacance, je peux avancer tranquillement la correction des derniers bugs du jeu  ::P: .

Les tests sont toujours prévu pour la semaine du 2 au 8 s'il y a encore des personnes intéressés  :;): .

----------


## Patate

Des flinges, des explosions, que du bon à venir ! tu vas le distribuer comment après la phase de test ?

----------


## Louck

Par itch.io  ::): .

A la base je pensais faire une version web. Sauf que la version WebGL a des restrictions au niveau du code réseau, pour des raisons de sécurité: impossible de créer un serveur depuis cette plateforme.
Il y a bien une solution à ce problème, mais ca impliquerait qu'on mette en place un gros Master Server qui se charge de tout. Ce n'est pas un problème de temps, mais de coût financier.

Du coup, nous publierons le jeu pour Windows et Linux uniquement. S'il y a beaucoup de joueurs (et donc de serveurs), nous ferrons une version Web client-only.

----------


## Patate

Ok ! Et gratuit ou payant?

----------


## Louck

Gratuit!

----------


## Louck

Bonne année!




Si des personnes sont intéressés pour tester le jeu cette semaine, n'hésitez pas à m'envoyer un MP  ::): .

----------


## Ashley TOUCRU

C'est jouable en multi ? Si c'est le cas, ça m'intéresse pour tester avec une bande de Canards.  :;):

----------


## Louck

C'est un jeu multijoueurs oui. Mais pour les tests, ca sera quand les joueurs seront disponibles, au plus tôt  ::): .

----------


## Ashley TOUCRU

Jusqu'à combien de joueurs ? Comment 'faut s'organiser, on te donne nos disponibilités ou est-ce que tu peux nous mettre à disposition le jeu et on teste quand on peut ?  ::huh::

----------


## Joq le pecheur

J'ai eu l'occasion de jouer un peu et c'est déjà très amusant en l'état.

Pas évident d'avoir du recul car le jeu est prenant  ::):

----------


## Grhyll

Je confirme, c'est pas mal awesome  ::):

----------


## Ashley TOUCRU

Mais peut-on y jouer à plusieurs ?  ::siffle::

----------


## Grhyll

> C'est un jeu multijoueurs oui.


 :;): 

Actuellement c'est 1 à 4, tu as envoyé un pm à Louck comme il demandait, pour les playtests ?

----------


## Patate

Il y a des bots pour une version offline ? Je ne pourrais pas tester au vu de mes dispo !

----------


## Ashley TOUCRU

> Actuellement c'est 1 à 4, tu as envoyé un pm à Louck comme il demandait, pour les playtests ?


Non, j'ai dû rater ça !  ::O:  J'aimerais bien le tester avec d'autres potes. J'en fais la demande de ce pas...  ::unsure::

----------


## Louck

Il y a moyen même si c'est un peu tard maintenant  :;): . Je t'ai envoyé un MP.

----------


## Grhyll

S'il y a une nouvelle session ce week-end et qu'il y a des places libres (et que je suis dispo à ce moment), je suis chaud pour en être de nouveau :P

----------


## Louck

J'ai surtout reçu beaucoup d'avis et il faut que je commence à les traiter  ::P: .

Ca sera dans 1 mois  :;): .

----------


## raaaahman

> S'il y a une nouvelle session ce week-end et qu'il y a des places libres (et que je suis dispo à ce moment), je suis chaud pour en être de nouveau :P


Je suis volontaire pour me faire canarder également. A moi la doooope  :Bave:  ... hum, les compétences je veux dire...

----------


## Louck

Je tiens à remercier ceux qui ont pu tester le projet et faire leurs retours  ::): .

A l'exception de quelques bugs, la majorité des retours porte sur la nécessite d'implémenter de nouveaux modes de jeux ou de quoi configurer les parties et les bots  ::): . Du coup, je vais prendre le temps pour intégrer ces paramètres en jeu.

Voici une liste non exhaustive d'idées en tête (non confirmée pour être intégrer en jeu. Ca dépendra de la charge de travail):
 - Pouvoir jouer en équipe.
 - Un mode "Coop": les joueurs doivent survivre aux vagues d'IA de plus en plus forts.
 - Un mode "Destruction": le score est calculé selon destruction des caisses du jeu.
 - Un mode "Rounds": Les joueurs réapparaissent de nouveau lorsque tout le monde est mort.
 - Possibilité de configurer la durée d'une partie.
 - Possibilité de configurer le type de compétences, d'armes et de powerups autorisées en jeu.
 - Possibilité de configurer les caisses du jeu.
 - Possibilité de configurer les HP, Dash, Vitesse des joueurs.


Si vous avez d'autres idées, je suis ouvert  ::): .
Néanmoins je me répète: Ce ne sont que des idées. Je ne peux pas confirmer leurs intégrations.

----------


## Ashley TOUCRU

J'ajoute :
- Disposer des éléments "explosifs" qui pètent quand on tire dessus. Ça peut considérablement ajouter de la stratégie et du fun.  :;):  Je pense notamment à ce qui existe dans Broforce, avec peut-être moins le côté "on détruit tout le paysage".  ::P:

----------


## Louck

Après réflexion, et étant donné le temps restant pour le projet et les retours que j'ai vu, il n'y aura pas vraiment de modes fixes au jeu. Néanmoins le jeu sera ouvert à plusieurs paramètres qui pourront, à la fin, alterner le jeu de plusieurs façons.

Ce qui est sûr, c'est qu'il sera possible de faire du Deathmatch seul ou en équipe (dépendant de la couleur choisie par les joueurs). Ensuite, l'host pourra paramétrer certains éléments du jeu, dont:

- Temps du jeu.
- HP du joueur.
- Vitesse de déplacement du joueur.
- Vitesse de récupération d'un Dash.
- HP des caisses.
- Type de caisse forcée (bois, metal ou explosive)
- Score au kill ou à la destruction (deux paramètres indépendantes).
- Temps de respawn des powerups.
- Délai d'attente avant l'acquisition d'une nouvelle compétence.
- Arme et compétence forcées (deux paramètres indépendantes).
- Mode de réapparition (à temps classique ou lorsque tout les joueurs sont vaincus).

Enfin, je vais ajouter un bouton "Paramètres aléatoires", qui va alterner certaines règles du jeu de façon aléatoire  ::): .

Ca sera sûrement plus simple et ca va probablement répondre aux besoins des joueurs.

----------


## Louck



----------


## Hyperpenguin

Je découvre les explosions  ::mellow::  je trouves qu'elles mériteraient des petites retouches, elles sont énormes et toute flous  :Emo:

----------


## Louck

Uubu est dessus  :;): . Le problème est que les sprites d'origines font du 32x32 pixels. Hors, les explosions du jeu font au moins le triple de cette taille  ::P: .
Il y a aussi le filtre trilinéaire qui n'aide pas, mais la version pixelisé n'est pas non plus top.

En ajout, j'ai remarqué que la compression des vidéos sur certains sites dégueulasse bien le rendu final des vidéos  :tired: . Je tenterai de faire une vidéo de meilleure qualité la prochaine fois.

----------


## Louck

Hey  ::): .

Petite mauvaise nouvelle aujourd'hui, la sortie du jeu se fera plutôt début/courant février.
La raison revient au très grands nombre de retours, qui nécessiteront un peu plus de mon temps pour tous les traiter. Dont un cas étrange que beaucoup de testeurs m'ont relevés: le jeu freeze de temps en temps, du côté serveur.

Sauf que le jeu freeze:
 - Uniquement sur la version compilé du jeu (en mode éditeur, ca marche niquel)
 - Impossible de déboguer du coup.
 - Pas de traces de logs de la part d'Unity.
 - Pas de traces dans le profiler.

Du coup, je m'amuse depuis plus d'une semaine à optimiser comme un idiot et à retester beaucoup de fonctionnalités du jeu. Mais la source du mal n'est toujours pas trouvé  :tired: .

Bref, j'informerai un peu plus des avancés des correctifs. Mais il faudra un petit mois, gros max, pour s'assurer que le jeu marche bien.

----------


## Ashley TOUCRU

Bon courage, vous touchez au but !  ::lol::

----------


## Louck

Bon après une semaine de galère, je pense avoir trouvé la source du problème des freezes:



Spoiler Alert! 


Unity semble avoir des problèmes de performances avec mon jeu lorsqu'il est compilé pour du 64 bits. En 32 bits, ca marche niquel.



Bon en théorie ca implique que le jeu sera légèrement moins performants (surtout pour la création/destruction des éléments du jeu). Mais c'est mieux ca que se taper de longs freezes en pleine partie.

Après je ne suspecte pas uniquement le moteur d'Unity3D pour ce problème. Je pense que c'est une accumulation de beaucoup de cas qui font que mon projet déconne.

Bref, une semaine plus tard, je peux enfin avancer  :tired: .


A part ca, autre nouvelle, le mois de février risque d'être très chargé pour moi. Je vais faire de mon mieux pour livrer le projet durant la semaine du 13 au 19 Février. Sinon ca sera la première semaine de Mars, vu que j'ai aussi besoin d'un peu de temps pour vérifier que le Master serveur n'explose pas les premiers jours et que les parties multijoueurs fonctionnent bien pour tout le monde.

----------


## Ashley TOUCRU

Prends le temps, un mauvais lancement peut tout gâcher.  :;):  Parle-z-en à Tripwire et Red Orchestra 2.  ::P:

----------


## Louck

Je veux surtout conclure ce projet  ::P: .
Mais oui, ca sera finis quand tout sera bon.

----------


## Uubu

C'est laborieux, mais je pense avoir trouvé.  ::):  La version 32*32 px :


La version 96*96 px :

----------


## Louck

Et on s'entraine à se faire mumuse avec les vidéos  ::P: .





Meilleure qualité: https://fat.gfycat.com/YoungPlainBrownbutterfly.webm

----------


## Septimium

Ca à l'air vraiment pas mal ce que vous avez créé là !

Hate de pouvoir poser mes petits doigts velus dessus dans quelques jours !  ::P:

----------


## Ashley TOUCRU

> Ca à l'air vraiment pas mal ce que vous avez créé là !
> 
> Hate de pouvoir poser mes petits doigts velus dessus dans quelques jours !


Il est carrément marrant, je l'affirme. Surtout que si les nouveaux modes de jeu et autres features font l'objet d'une mise à jour, ce sera encore plus énôôôrme !  ::lol::  :Vibre:

----------


## Joq le pecheur

super l'explosion !

----------


## Ashley TOUCRU

> C'est laborieux, mais je pense avoir trouvé.  La version 32*32 px :
> http://tof.cx/images/2017/02/05/e20e...32711fc0c8.gif
> 
> La version 96*96 px :
> http://tof.cx/images/2017/02/05/814e...ceb6dba875.gif


Par curiosité, t'as combien d'images dans cette animation ?  ::huh::

----------


## Tchey

> Par curiosité, t'as combien d'images dans cette animation ?


8 ?

----------


## Uubu

Content que ça vous plaise.  ::):  Oui c'est huit. La frame 1 avec la croix, c'est juste pour indiquer le point de départ de l'explosion.

----------


## Ashley TOUCRU

OK. Et du coup, pourquoi 8 ? C'est lié à une quelconque contrainte technique, ou c'est juste que c'est ce qui te convient pour cette animation ?  ::huh::

----------


## Uubu

En général, je suis les "normes" du pixelart (sprites en 16*16 ou en 32*32px. Animations avec 4, 8 ou 16 frames, palette de 4, 8, 16 ou 32 couleurs...etc). Ca évite de partir dans tous les sens et ça permet de gagner du temps (surtout avec les animations).
Mais je m'en écarte dès que ça coince, car ça devient vite contraignant. 

Avec 8 frames, je trouve son rendu suffisant pour ne pas avoir à en ajouter.
Sur les autres essais d 'explosion j'étais parti sur beaucoup plus de frames... Mais c'était moins folichon.  ::P:

----------


## Ashley TOUCRU

> En général, je suis les "normes" du pixelart (sprites en 16*16 ou en 32*32px. Animations avec 4, 8 ou 16 frames, palette de 4, 8, 16 ou 32 couleurs...etc). Ca évite de partir dans tous les sens et ça permet de gagner du temps (surtout avec les animations).
> Mais je m'en écarte dès que ça coince, car ça devient vite contraignant. 
> 
> Avec 8 frames, je trouve son rendu suffisant pour ne pas avoir à en ajouter.
> Sur les autres essais d 'explosion j'étais parti sur beaucoup plus de frames... Mais c'était moins folichon.


Merci pour ces explications. J'y vois plus clair dans tes choix graphiques.  :;):

----------


## Rom1

Je débarque après tout le monde, mais wow Oo, ça a l'air top votre projet  ::o:

----------


## Ashley TOUCRU

Ouais, je confirme. En multi online on a bien rigolé. Avec les nouvelles options de jeu, ça devrait tabasser grave.  :;):

----------


## Louck

Ahah  ::P: .
Les nouvelles options fonctionnent et correspondent bien à la liste que j'ai indiqué plus haut.

Par contre il n'y aura pas le bouton "random", vu que le résultat n'est pas super. Sinon il me faudrait un certains temps et des tests pour faire quelque chose de correct.

----------


## Ashley TOUCRU

> Ahah .
> Les nouvelles options fonctionnent et correspondent bien à la liste que j'ai indiqué plus haut.
> 
> Par contre il n'y aura pas le bouton "random", vu que le résultat n'est pas super. Sinon il me faudrait un certains temps et des tests pour faire quelque chose de correct.


Bonne nouvelle !  ::lol::  Quand est-ce que vous mettez le jeu en téléchargement, du coup ? Vous touchez au but ?  ::rolleyes::

----------


## Louck

On s'approche du but oui. J'ai réussi à débloquer un gros bug hier soir (à 2h du matin  ::lol:: ).
Il me reste néanmoins certaines choses à régler et à bien vérifier, dont la configuration de la partie et le mode team-deathmatch.

A mon avis, je pense prévoir une sortie pour fin de la semaine suivante. Soit Jeudi ou Vendredi soir. S'il y a un pépin, ca sera pour la semaine suivante.

----------


## Ashley TOUCRU

Bonne nouvelle !  ::lol::  Je relancerai les copains avec qui on l'avait testé en beta !  :;):

----------


## schouffy

Cool bonne chance pour la release ! J'y jouerai au taff avec les copains !

----------


## Louck

Je pense prévoir une sortie pour *Vendredi à 21h*  :;): .
Si des joueurs puissent être là - même un peu plus tôt - pour vérifier que le démarrage fonctionne très bien  ::): .

----------


## Grhyll

Je peux pas garantir ma présence à 100%, mais si je suis dispo, je serai là !

----------


## Rom1

Hâte de voir ça  ::):

----------


## Louck

Bon, c'est pas vraiment la meilleure date pour sortir un jeu (vu les sorties qu'il y a en ce moment), mais je maintiens tout de même ce soir  ::P: .

----------


## Grhyll

Ouais, ça risque d'être un peu dur d'obtenir de l'attention ^^' C'est courageux ! Et désolé, je ne serai finalement pas dispo pour une partie de launch  ::(:  Mais s'il y a des canards chauds pour jouer ce week-end (genre dimanche), je serai là !

----------


## Hyperpenguin

J'ai hâte quand même (parce que j'ai pas prévu d'acheter une Switch  :Emo:  )

----------


## Rom1

Ça sort sur quelle plateforme ?

----------


## Louck

> Ouais, ça risque d'être un peu dur d'obtenir de l'attention ^^' C'est courageux ! Et désolé, je ne serai finalement pas dispo pour une partie de launch  Mais s'il y a des canards chauds pour jouer ce week-end (genre dimanche), je serai là !


Disons que notre plan marketing représente l'absolu zéro, même si on poste à gauche et à droite  ::P: . Et je doute que notre projet intéresse ceux qui attendent comme des fous Zelda ou Ghost Recon.

Perso, je suis plus dans l'optique que le projet doit finir. Si je devais vraiment attendre pour sortir un jeu au bon moment, ca serait dans 4 mois. Et encore...





> Ça sort sur quelle plateforme ?


PC Windows. A voir selon les retours si nous faisons une version Linux (car pour l'instant j'ai pas le matos pour le tester correctement).

----------


## Rom1

Ça d'accord, je me suis mal exprimé en fait. Ça sort sur Steam ? Itch.io ? Gamejolt ? Enfin en gros, où est ce qu'on pourrait récupérer la bête ? ::P:

----------


## Louck

Itch.io  :;): . Mais je filerai un lien pour ca, don't panic  ::P:

----------


## Rom1

Ok cool ! Merci  :;):

----------


## Louck

Un an et demi de réalisation plus tard.

Après avoir affronté Unity3D.

Après avoir souffert avec le netcode.

Après avoir fêter Noël. Deux fois.



Ubbu, Bigju et Louck présentent leur nouveau bébé  :Cigare: 

Télécharger le jeu

Bon jeu  :;): .


Maintenant, restes plus qu'à croiser les doigts  ::P: .

----------


## Hyperpenguin

ça dl

- - - Mise à jour - - -

je test c'est super cool je défonce des bots là.

- - - Mise à jour - - -

J'ai perdu  ::):

----------


## La Chouette

> PC Windows. A voir selon les retours si nous faisons une version Linux (car pour l'instant j'ai pas le matos pour le tester correctement).


Je vais probablement le tester sur ma partition Windows, mais si ça me plait, une version Linux m'intéresserait beaucoup.

----------


## Rom1

Oh yeah !

----------


## Louck

> Je vais probablement le tester sur ma partition Windows, mais si ça me plait, une version Linux m'intéresserait beaucoup.


Je prend note  ::): . Mais oui ca dépendra s'il y a assez de joueurs, de plus qu'il me faudra des volontaires pour bien le tester  ::P: .

----------


## Grhyll

Yeaaah congratulations à vous trois \o/

Des canards chauds pour une session demain ? Genre à 11h, ou 17h ?

----------


## Louck

Je peux faire bouche trou à 11h si besoin  ::P: .

----------


## Rom1

Je peux être là à 11h aussi   ::):

----------


## chymz

Très fun ! +1 pour la version Nunux  ::):

----------


## Hyperpenguin

moi je suis libre à 17h demain.

----------


## Rom1

On se retrouve sur un Discord ou un Mumble pour s'organiser ça alors?

----------


## Grhyll

J'ai du retard >_< Mais je suis là ! Et sinon oui un Discord ou Mumble ça serait bien mais je connais pas trop tout ça pour ma part :/
Edit : j'ai créé un lobby !
Edit 2 : Je vais griller une clope en attendant de voir si quelqu'un trouve mon lobby ! Louck, vous l'avez ptête déjà fait, mais ça serait sympa de créer un canal officiel pour que les joueurs se retrouvent, bien signalé sur la page itchio pour se coordonner !

----------


## Louck

Désolé un peu de retard, le sommeil m'a rattrapé :/.

Je vais voir pour un Discord. Je le mettrais en place dans la soirée.

----------


## Tchey

C'est bon maintenant vous pouvez faire la version Linux, hop hop hop.

----------


## Louck

Pas mal de choses en priorité avant. Mais je pense prévoir une version pour Linux durant la semaine prochaine  ::): . Il me faudra par contre des testeurs "Linux" pour mercredi.

A prendre note que je ne peux pas certifier que ca marchera.

----------


## Louck

Hopla!

https://discord.gg/Gek73sx

Ca sera plus simple si les joueurs se réunissent dans ce channel pour trouver des parties ou chercher d'autres joueurs  ::): .

----------


## La Chouette

> Hopla!
> 
> https://discordapp.com/channels/2880...30676723433473
> 
> Ca sera plus simple si les joueurs se réunissent dans ce channel pour trouver des parties ou chercher d'autres joueurs .


Marche pas, ton lien.

Si besoin de testeur Linux pour mercredi, je suis dispo. Pas encore essayé sous Windows, par contre.

----------


## Grhyll

Nice ! Oui ça permettra peut-être de s'organiser un peu plus facilement, là du coup mes propositions sont tombées à l'eau (notamment à cause de moi-même, je le concède)  ::(:

----------


## Louck

Pardon, trompé de lien  ::P: . Je viens de le corriger ci-dessus.

Sinon ca commence bien, le Master Server est tombé  :tired: . Normalement ca sera corrigé demain dans la matiné, au pire le soir avec un patch.

----------


## Louck

Voila nous avons changés de Master Server (pour un serveur beaucoup plus performant), en espérant que ca ne va pas crasher aussi vite que l'autre.

Enfin si c'est le cas, c'est plus que de la malchance que j'ai  :tired: .

----------


## Ashley TOUCRU

Félicitations, les amis !

Content d'avoir pu participer modestement au Beta test de ce petit jeu bien sympathique auquel je suis néanmoins une bille.  :;): 

Bon courage pour la suite.  ::rolleyes::

----------


## Louck

Je ne sais pas ce qu'est "itcm" comme site, mais j'ai pas mal de vues venant de ce site.
http://itcm.co.kr/index.php?mid=game...nt_srl=3393409


Pendant ce temps, les joueurs galèrent pour se rejoindre.
Je vais encore faire du hardcore patching cette semaine.

----------


## Hyperpenguin

> http://tof.canardpc.com/view/8be2070...5e2b137437.jpg
> 
> Je ne sais pas ce qu'est "itcm" comme site, mais j'ai pas mal de vues venant de ce site.
> http://itcm.co.kr/index.php?mid=game...nt_srl=3393409
> 
> 
> Pendant ce temps, les joueurs galèrent pour se rejoindre.
> Je vais encore faire du hardcore patching cette semaine.




Gégé le feature sur la même page que Night in the Woods

----------


## Hideo

Ow sweet ! Féloche à vous  :;):  

Malheureusement pas énormement de temps pour les prochains jours, mais ca sera testé !

----------


## 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é  ::P: .

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  ::P: .

----------


## 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  ::P: .


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  ::P: .




> 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  :tired: .

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  ::P: .
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  ::lol::  (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  ::ninja:: .




*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.  ::rolleyes::

----------


## 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é.  ::rolleyes::  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é  :Indeed: ), 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

::wub::  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  ::lol:: .







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  ::): .

----------


## Uubu

Celle-ci montre bien les intérêts du jeu (multi, dash...) :  ::):

----------

