Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 23 sur 38 PremièrePremière ... 13151617181920212223242526272829303133 ... DernièreDernière
Affichage des résultats 661 à 690 sur 1123
  1. #661
    Ok j'ai compris maintenant, ça semble en effet pas mal adapté à ton jeu
    Dont le rendu est cool d'ailleurs !

  2. #662
    Merci beaucoup.
    Pour l'anecdote si vous voulez utiliser Bakery, n'oubliez pas d'activer "Generate Lighmap's UV" sur les modèles sinon cela ne fonctionnera pas toujours. Trois jours que je cherchais pourquoi certains prefab ne gardaient pas l'éclairage et on a enfin trouvé via expérimentations...

  3. #663
    Je suis en version 2017.3. Je peux migrer jusqu'au 2018 stable (je ne sais plus quel numéro), sauf que n'importe quel upgrad me demandera de refaire mes niveaux (mais tous mon code et UI restent nickel avec quelques modifications) parce que ça a la bonne idée de bouger mes rotations et transform et l'échelle.
    Ce qui est de l'ordre d'une bonne journée de boulot au moins si je me rappelle bien de mes niveaux.

    Les versions supérieures valent le coup ? Sachant que mon but, c'était peut être d'aller jusqu'au 2020 car il y a une feature de polybrush qui me plairait bien mais je peux vivre sans largement.

  4. #664
    Perso n’ayant aucune volonté d’en faire un truc vendable et donc à s’arracher les cheveux dès qu’un truc buggait en passage de version, j’ai suivi toutes les montées de version proposées.

    Ce que j’ai pu voir c’est que le passage à 2018 a pété plein d’assets que certains n’ont jamais remis au goût du jour.
    Au final maintenant ça m’a obligé à tout faire moi même et je le regrette pas du tout.

    La 2019 m’a apporté beaucoup d’anomalies de perfs dont j’ai déjà parlé ici. Et pas mal de trucs dépréciés qu’il a fallut remettre en ordre.
    Par contre l’outil terrain et shader graph était enfin au niveau.

    La 2020 m’a apporté un bond en perfs, et de la maturité supplémentaire dans les fonctions proposées sans trop de problème de transition.
    Par contre j’ai perdu beaucoup de temps à switcher vers HDRP... pour finalement tout remettre en place ou presque.
    Shader graph m’a permis de me débarasser des shaders piqués à droite à gauche pour refaire les miens par ce biais.

    Y’a que mon fog of war que j’ai perdu sans solution
    J’utilisais un projector qui n’est plus au même niveau avec le decal projector.

    Donc à mon humble niveau de connaissance, ça se bonifie sur ce que je manipule mais tout ce qui est job system and co et nouvelle méthode de programmation remplaçant le monobehavior je ne sais pas.

    Edit : ah si depuis la 2020, le temps de chargement de Unity est super long, il fait des refresh à tout va et c’est un peu relou.
    Dernière modification par Sifr ; 08/11/2020 à 16h49.

  5. #665
    Vers 2018/début 2019, y'a vraiment eu un pas en arrière je trouve. Tout était pété de partout, le SRP commençait à être poussé mais n'était pas encore prêt du tout. Maintenant je trouve que tout fonctionne relativement bien (depuis les versions 2019 LTS un peu avancées), je pense que tu as tout intérêt à migrer mais effectivement ça peut demander pas mal de boulot.
    Si toutes tes modifs de transform sont "similaires" tu peux sans doute faire un script qui fait la mise à jour pour toi.

  6. #666
    Si ce n'est que les informations de transform que tu perds, il n'y a pas trop mort d'homme à migrer, comme le dit schouffy.
    On est sur la 2019.4.1f1 LTS si ma mémoire est bonne et on a pas trop envie de migrer plus haut, d'une part parce qu'il n'y a pas de 2020 LTS, d'autre part parce qu'on a pas envie de réécrire tous nos shaders, aussi facile cela puisse être(même si on devra y passer un jour). On y est mieux que sur la précédente LTS 2018 en tout cas et de plus en plus d'assets demandent 2019 minimum.
    EDIT : Et bien sur crée une nouvelle branche dans ton code pour le passage à la nouvelle version, afin de pouvoir toujours avoir la version de base comme comparaison. Avec Hub qui gère une tonne d'installs de l'éditeur dans des versions différentes, tu peux vraiment faire de la comparaison facilement.
    Dernière modification par Grosnours ; 09/11/2020 à 10h30.

  7. #667
    Merchi.
    C'est quand même beaucoup d'emmerde... J'ai fait en sorte que mes asset soit modulaires, donc j'ai BEAUCOUP d'objets dans une scène.... Faudra que je teste, je me demande si le fait que les prefab soient en fils dans la hiérarchie ne fout pas la merde.

    Vous avez intérêt à ce que l'UI et les feature en plus vaillent la peine . Surtout que pour une fois, mon jeu est stable sans un message d'erreur, .

  8. #668
    Citation Envoyé par Molina Voir le message
    Surtout que pour une fois, mon jeu est stable sans un message d'erreur, .
    Ca c'était avant

  9. #669
    Besoin d’un petit conseil histoire de pas perdre du temps pour rien : je suis passé sous HdRP, tout tourne bien et entre temps j’ai joué avec VFX Graph et ça en met plein les mirettes.

    Du coup je me demande si je vais pas repasser tous mes particles systems sous VFX graph.

    Mais j’ai un doute, car y’a des trucs qui me semblent être plus lourds à mettre en oeuvre.

    Est ce qu’on peut vraiment faire par VFX graph tout ce qui est fait avec le particle system ? A performance équivalente ?
    Balancer une roquette avec un sillage de fumée ? Un railgun bien classe ?

    Ou ça sert pas à grand chose et faut savoir se contenter de ce qu’on a et VfX graph c’est pour de l’effet ponctuel qui doit claquer dans la mise en scène ?

  10. #670
    D'après ce que j'ai compris (on utilise pas VFX graph) cela remplace peu ou prou les particules avec de meilleures performances (en particulier sur une tonne de particules sur desktop ou n’importe quoi avec un GPU correct) mais avec quelques limitations (GPU, collisions). Bref, ça dépend de ce que tu veux faire.
    Là on fait du low poly, les particules en faible nombre suffisent large.

  11. #671
    Bon y a pas à dire, avec les particules VFX c'est vachement plus brillant et beau

    Par contre ça fait une bonne centaine d'effets en tous genres à recréer - ça va me prendre du temps.
    Et puis la fumée... woua c'est chaud, heureusement qu'il y a des tutos mais c'est tellement agréable de finesse

  12. #672
    Je viens de passer à la 2020.2 en ayant suivi jusqu'à la 2020.1.17...

    Eh ben ça m'a pas tout cassé pour un coup, juste perdu le depth test dans mes shaders en shader graph parce qu'ils ont changé des checks de zone/fonction et mon fog of war ne fonctionne de nouveau plus.
    Décidément ils veulent pas stabiliser leur Decal Projector...

    Quand j'aurai réussi à fiabiliser mon fog je pourrai enfin partager un truc potable.

  13. #673
    C'est très rarement conseiller de changer la version du moteur ou d'un package en cours d'un projet, pour éviter les soucis que tu rencontres .

    Sauf, bien sûr, si c'est critique. J'ai du le faire sur un projet de jeu en VR pour le rendre compatible avec les derniers casques, mais ca m'a pris énormément de temps pour tout re-tester et corriger ce qui a changé/cassé.

  14. #674
    Hello les Canards,

    J'ai cette année repris des études en LP. (dev multi-supports) Une UE comporte un projet collectif (groupe de 4)

    Le thème étant la découverte du patrimoine de la ville, on a choisi de faire un mini RPG (type Secret of mana, toute proportion gardée évidemment...) à destination des plus jeunes.

    Globalement l'idée c'est d'avoir une quête qui donne une ligne directrice et qui incite le joueur à se déplacer IRL sur certains sites (monuments etc.) de la ville pour achever certaines quêtes et /ou débloquer une nouvelle zone. (donc géolocalisation sur mobile à implémenter)
    Pour le reste ce sera un RPG "classique" avec des quêtes ludiques qui renseignent sur le patrimoine et des combats "simples" au tour par tour.
    On a choisi d'utiliser Unity. Les semaines passent et on va devoir rapidement avancer.

    Est-ce que des canards sont connus pour bien connaître Unity ? Mon idée c'est simplement de pouvoir échanger et de prendre quelques conseils car j'ai le sentiment qu'on a sous estimé la complexité du projet et ça m'inquiète un peu. (et qu'il s'agit au passage d'un coeff 10 qui potentiellement peut planter mon diplôme )

    J'aimerais bien également savoir ce que vous pensez du choix du moteur.
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



  15. #675
    Vous avez combien de temps? Vous êtes 4 développeurs?
    Avec le peu d'infos que tu as donné, c'est un peu difficile de voir le type de renseignements que tu attends.
    Unity semble être un choix correct; renseigne toi bien avant de commencer sur l'interaction entre le moteur et les capacités du tél type géoloc ou réalité augmentée.
    Peut-être que si ton jeu n'est pas très graphique ou interactif, une app native ou React Native ou Flutter peut être un meilleur choix car l'accès aux ressources du tél sera simplifié. Faites aussi en fonction de vos connaissances actuelles évidemment.

  16. #676
    J'ai pas tout compris. Tu veux utiliser du GPS dans Unity ? Utiliser Unity dans ton browser qui lui utilisera le GPS ?
    Tout cela est possible mais pas forcément facile (mais alors du tout) ni souhaitable en termes de perfs. On est plusieurs ici à avoir un peu de bouteille avec Unity, donc pose toutes les questions que tu veux.

    EDIT : pour avoir via ma femme contact avec des tonnes d'étudiants qui font des projets via Unity, il faut vraiment que vous définissiez le plus exactement possible votre jeu : histoire, gameplay, mécaniques, etc.. De là (ce n'est pas le process le plus standard mais vous avez le luxe de procéder ainsi) tu pourras en déduire ce dont vous avez besoin techniquement de manière beaucoup plus claire et précise. C'est le genre de décisions à faire le plus en amont possible car changer en cours de route est plutôt catastrophique.
    Dernière modification par Grosnours ; 26/01/2021 à 12h30.

  17. #677
    On voudrait que la position de l'utilisateur, quand il joue sur mobile, puisse être géolocalisée et déclenche un évènement directement dans le jeu. Ce serait une grosse plus-value à notre projet mais effectivement on ne mesure pas la complexité.

    En terme de temps c'est assez court. La soutenance finale est prévue le 29 juin mais entre temps, on va devoir présenter plusieurs prototypes.
    1er mars : Prototype 1 : Maquette fonctionnelle Interactive, MVP pour tester son idée
    15 avril : Prototype 2 : Fonctionnalité coeur, MVP pour briefer son équipe technique
    31 mai : Prototype 3 : Prototype complet, MVP à diffuser au public

    Précisément on a définit nos prototypes ainsi :

    Prototype 1 :
    • Contenu : Page d’accueil / Carte simplifiée / Déplacement du joueur sur la carte / Portage sur mobile / Récupération de sa localisation.
    • Objectif : Vérifier l'UX du jeu à travers les premières interactions basiques d’un joueur : utiliser la page d’accueil et placer correctement les commandes de déplacements. Se confronter dès le début aux parties les plus importantes du MVP.
    Prototype 2 :
    • Contenu : Prototype 1 / Gestion des interactions (Quêtes, combats, informations patrimoine).
    • Objectif : Rendre le jeu interactif
    Prototype 3 :
    • Contenu : Prototype 2 + Création de tous les bâtiments, les quêtes, la carte complète et tout le contenu de l’histoire.
    • Objectif : Avoir un jeu jouable sur mobile et avoir le fil conducteur du jeu

    Au niveau graphique ce serait vraiment à l'image des RPG qu'on retrouve sur Snes par exemple mais avec des combats simplifiés au tour par tour.

    Oui on est 4 développeurs et on découvre tous Unity.

    Pour le moment on est en train de faire le mini tuto Creator Kit: RPG disponible dans le Learn du Hub.

    Ce qui m'inquiète c'est de ne pas mesurer la charge de travaille.

    Par exemple est-ce que vous considérez comme faisable rapidement par des débutants de :
    Créer un menu simple pour entrer dans le jeu
    Créer une MAP avec quelques éléments de décor, quelques bâtiments, un PNJ qui donne une quête (rendre visite à PNJ B par exemple et valider)

    L'idée de géolocaliser l'utilisateur avec son mobile ça vous semble utopique ?
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



  18. #678
    Pas du tout utopique, mais je comprend pas comment ton jeu fonctionne.
    Tu te déplace in game, ou tu te déplaces dans la réalité et ça update ta position in game ? Si c'est l'option 1, à quoi sert la géoloc? Si c'est l'option 2, à quoi servent les commandes de déplacement dans le jeu?

  19. #679
    Admettons que tu sois en train de jouer sur ton mobile chez toi. Pour accéder à la zone B, un PNJ te demande de reconstruire le pont X. Là tu dois te rendre IRL à ce pont X : lancer le jeu avec la position d'activée, là tu reconstruis le pont et tu peux donc continuer à progresser dans le jeu.

    En fait notre objectif c'est d'inciter les plus jeunes à se rendre vraiment sur les lieux pour découvrir le patrimoine et pour ça on a pensé qu'il faudrait forcément géolocaliser l'utilisateur pour valider qu'il est bien au bon endroit IRL et donc que l’évènement "le pont se reconstruit" se déclenche à ce moment. Pour le déclencher il faudrait et que le joueur soit au bon endroit in game et à l'endroit voulu IRL.
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



  20. #680
    Je vois. Dans ce cas, je pense que la géoloc n'est pas du tout la partie complexe de ton projet.
    Regarde le lien dans mon post précédent, c'est très simple sur le papier d'obtenir la position GPS dans Unity.

    Je te recommanderais de procéder ainsi pour vérifier la faisabilité:
    - Utilise un outil de cartographie (genre https://www.keene.edu/campus/maps/tool/) pour déterminer les coordonnées GPS d'une zone que tu veux utiliser comme trigger
    - Fais toi une mini app unity qui te géoloc et affiche un truc si tu entres dans les coordonnées en question
    - va la bas et vérifier que ça fonctionne et que la précision te convient.

    Si ça fonctionne, tu sais comment trigger des événements en fonction de la position GPS et tu sais que ça fonctionne bien.
    Ensuite, oublie complètement cette partie, et crée ton jeu sans te soucier de la géoloc. Au lieu de vérifier la position pour activer tes quêtes ou autre, tu peux juste appuyer sur un bouton qui permet de simuler que "ok ta géoloc est conforme, valide la quête".
    A la fin, il te suffira de remplacer le code "appui sur le bouton" par le code "vérification qu'on est dans la bonne zone gps".

    Vu ce que tu comptes faire comme jeu, utiliser RPG maker te simplifierait sans doute beaucoup la tâche (je ne connais pas l'outil, mais je sais qu'il est fait pour ça). Si tu as une API de geoloc dans RPG maker, c'est tout bon (mais j'y crois pas trop, encore que). Peu importe l'outil que tu choisis, vérifie d'abord la faisabilité de ta feature de géoloc dans cet outil.
    Dernière modification par schouffy ; 26/01/2021 à 13h25.

  21. #681
    Excellents conseils de schouffy.
    Validez techniquement la partie GPS d'abord (car critique dans votre idée), puis passez ensuite au reste. Reste qui d'ailleurs n'est pas insurmontable. Oui il est relativement facile de faire un Main Menu (une scène) pour accéder ensuite à une autre scène avec le jeu ou des éléments du jeu dedans. Une scène simple avec PNJ et décor cela peut être très vite fait aussi.

    Maintenant j'aimerais juste que vous creusiez un peu plus le gameplay lui-même. Le joueur qui joue à ton jeu va devoir se déplacer sur place. Très bien. Mais comment rendre cela organique et intéressant ? Parce que dit comme cela c'est un peu chiant de voir le jeu qui se met en pause le temps que je fasses quelques kilomètres. Comment relier au plus près le monde que vous voulez créer avec le monde réel pour justifier les contraintes de placement que vous voulez imposer à l'utilisateur ?
    Certaines applications procèdent de la façon inverse en réagissant au déplacement du joueur via nouvelles interactions/infos/popups quand il approche un certain lieu. Cela pourrait aussi être une piste.

    Il y a tout un corpus d'applications/jeux mobiles qui utilisent le GPS au cœur de leur gameplay (avec sans doute Pokemon Go comme figure de proue), c'est toujours intéressant de voir comment eux procèdent et s'ils ont eu de bonnes idées que vous pouvez réutiliser.

  22. #682
    Merci pour vos conseils.
    On va tenter de valider que techniquement ça fonctionne la position GPS. C'est une bonne idée de créer une mini app pour simplement tester cette partie.

    Pour la partie gameplay, on est vraiment en train d'en discuter pour affiner nos idées mais tu as raison sur les points que tu soulèves Grosnours.

    Concernant RPG Maker je ne connais pas l'outil mais je suis pas certain que ce soit bien perçu et en plus on a des contraintes comme par exemple versionner le projet et travailler à 4 sur des branches distinctes.
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



  23. #683
    Par curiosité, pourquoi cette dernière contrainte ?
    Cela ne vous force pas à bosser à 4 chacun dans votre coin, ce qui est un peu le contraire de ce qu'on veut nourrir dans un travail de groupe ?

  24. #684
    Et je connais pas RPG maker encore une fois, mais ça reste un outil pour faire des jeux, un processus très itératif, donc je serais vraiment surpris que ce ne soit pas compatible avec les systèmes de versioning.

  25. #685
    Citation Envoyé par Grosnours Voir le message
    Par curiosité, pourquoi cette dernière contrainte ?
    Cela ne vous force pas à bosser à 4 chacun dans votre coin, ce qui est un peu le contraire de ce qu'on veut nourrir dans un travail de groupe ?
    Actuellement on est en full distanciel (on est aussi tous en alternance, d'où la contrainte de temps qui me fait peur) et je pense que c'est pour nous forcer à bien se partager les tâches et à utiliser git.
    Tous les 4, je pense qu'on va pas se revoir avant longtemps. C'est pas forcément idéal pour le travail de groupe mais on n'a pas le choix.
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



  26. #686
    Bosser chacun sur une branche différente, c'est une sale idée, crois moi. ça va être un cauchemar à tout fusionner à la fin.
    Bossez tous sur une branche identique de développement, et tirez une branche quand vous partez sur une feature importante qui risque d'impacter les autres. Puis quand c'est fini tu refusionnes dans la branche principale.

    Jette un oeil à Git flow. Quitte à utiliser quelque chose, autant prendre direct les bons réflexes.

  27. #687
    C'est une contrainte des enseignants ou que vous vous êtes fixés vous-mêmes ?
    Parce que je me vois mal procéder comme vous au quotidien avec mes deux collègues, le travail de l'un nourrissant le travail des autres. Typiquement avec Unity tu peux travailler sur du script, sur une scène, sur des assets ou sur un mix de tout cela. Ce qui veut dire que en amont découper tout cela (et les taches qui vont avec) en 4 morceaux plus ou moins étanches c'est extrêmement difficile.

    - - - Mise à jour - - -

    Citation Envoyé par schouffy Voir le message
    Bossez tous sur une branche identique de développement, et tirez une branche quand vous partez sur une feature importante qui risque d'impacter les autres. Puis quand c'est fini tu refusionnes dans la branche principale.
    Voilà.
    Le branching c'est quand tu va faire un truc vraiment distinct/nouveau.

  28. #688
    En fait sur le projet précédent (un app Android) on avait :
    une branche dev_prénom
    une branche feature_dev
    une master

    Chacun d'entre nous faisait son dev sur sa branche puis on faisait une MR qui était intégré à feature_dev et un seul s'occupait de gérer les conflits. La même personne s'occupait de merger dans master.
    Par contre c'est vrai qu'on avait au préalable tout découpé pour ne pas se marcher dessus et donc au final on a eu très peu de conflits.

    Je fais remonter que ça peut être très compliqué de faire comme ça avec Unity, merci. (le repo a été crée que ce matin)
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



  29. #689
    C'est pas lié à Unity, c'est juste une pratique pas terrible que plus vous allez utiliser, plus vous aurez du mal à désapprendre quand vous bosserez dans un environnement professionnel.
    Par contre dans Unity y'a une option à cocher pour que les scènes soient enregistrées en textuel et pas en binaire, n'oubliez pas de l'activer pour rendre les merges possibles.

  30. #690
    C'est vrai que c'est complètement différent là ou je bosse depuis un an où on tire une branche depuis master pour chaque ticket. (qui est un dev distinct à chaque fois)
    C'est noté pour l'enregistrement des scènes merci.
    Battletag : Sariyah#2734 / ID PS5 : Oo_Sariyah_oO



Page 23 sur 38 PremièrePremière ... 13151617181920212223242526272829303133 ... DernièreDernière

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
  •