Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 3 sur 9 PremièrePremière 123456789 DernièreDernière
Affichage des résultats 61 à 90 sur 241
  1. #61
    Ca devrai être mieux .




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

  2. #62
    Oui effectivement c'est mieux
    @Grhyll / 3-50.net
    Projet actuel : oQo

  3. #63
    Bien, très bien !

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

  4. #64
    Owaiii ! Partant pour testay !

  5. #65
    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!

  6. #66
    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.

  7. #67
    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.

  8. #68

  9. #69
    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" .

  10. #70
    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 .
    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.

  11. #71
    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 .

    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_sw
    • Et 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 ( )
    • 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 .





    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.
    Dernière modification par Louck ; 14/03/2016 à 14h32.

  12. #72
    Très intéressant... pour une excuse!
    Spoiler Alert!
    Je déconne bien entendu.

  13. #73
    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.

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

  15. #75
    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
    @Grhyll / 3-50.net
    Projet actuel : oQo

  16. #76
    :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).


    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.

  17. #77
    ça a l'air chiant à coder et en plus chiant à tester/debugger
    Coop locale FTW

  18. #78
    Citation Envoyé par Louck Voir le message
    :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).


    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.
    rien ne t'empêche de le passer en payant, non ?

  19. #79
    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 .


    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.
    Dernière modification par Louck ; 15/03/2016 à 20h58.

  20. #80
    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


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

  21. #81

  22. #82

  23. #83
    Woaw c'est grand comme map, c'est prévu pour combien de joueur? Et pour les items, on peut avoir un descriptif?
    Le premier chef d'œuvre d'une longue série, cliquez ici
    Le second, cliquez

  24. #84
    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!

  25. #85
    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).

  26. #86

  27. #87
    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.

  28. #88
    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 .

    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 .
    • Et surtout, un meilleur netcode (même si ce n'est pas encore parfait ).


    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 .

  29. #89
    Citation Envoyé par Louck Voir le message
    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 !
    @Grhyll / 3-50.net
    Projet actuel : oQo

  30. #90
    Merci .


    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 .


Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •